curl --request POST \
--url https://example.com/block \
--header 'Content-Type: application/json' \
--data '{
"network_identifier": {
"blockchain": "bitcoin",
"network": "mainnet",
"sub_network_identifier": {
"network": "shard 1",
"metadata": {
"producer": "0x52bc44d5378309ee2abf1539bf71de1b7d7be3b5"
}
}
},
"block_identifier": {
"index": 1123941,
"hash": "0x1f2cc6c5027d2f201a5453ad1119574d2aed23a392654742ac3c78783c071f85"
}
}'{
"block": {
"block_identifier": {
"index": 1123941,
"hash": "0x1f2cc6c5027d2f201a5453ad1119574d2aed23a392654742ac3c78783c071f85"
},
"parent_block_identifier": {
"index": 1123941,
"hash": "0x1f2cc6c5027d2f201a5453ad1119574d2aed23a392654742ac3c78783c071f85"
},
"timestamp": 1582833600000,
"transactions": [
{
"transaction_identifier": {
"hash": "0x2f23fd8cca835af21f3ac375bac601f97ead75f2e79143bdf71fe2c4be043e8f"
},
"operations": [
{
"operation_identifier": {
"index": 5,
"network_index": 0
},
"type": "Transfer",
"related_operations": [
{
"index": 1
},
{
"index": 2
}
],
"status": "Reverted",
"account": {
"address": "0x3a065000ab4183c6bf581dc1e55a605455fc6d61",
"sub_account": {
"address": "0x6b175474e89094c44da98b954eedeac495271d0f"
}
},
"amount": {
"value": "1238089899992",
"currency": {
"symbol": "BTC",
"decimals": 8,
"metadata": {
"Issuer": "Satoshi"
}
}
},
"coin_change": {
"coin_identifier": {
"identifier": "0x2f23fd8cca835af21f3ac375bac601f97ead75f2e79143bdf71fe2c4be043e8f:1"
}
},
"metadata": {
"asm": "304502201fd8abb11443f8b1b9a04e0495e0543d05611473a790c8939f089d073f90509a022100f4677825136605d732e2126d09a2d38c20c75946cd9fc239c0497e84c634e3dd01 03301a8259a12e35694cc22ebc45fee635f4993064190f6ce96e7fb19a03bb6be2",
"hex": "48304502201fd8abb11443f8b1b9a04e0495e0543d05611473a790c8939f089d073f90509a022100f4677825136605d732e2126d09a2d38c20c75946cd9fc239c0497e84c634e3dd012103301a8259a12e35694cc22ebc45fee635f4993064190f6ce96e7fb19a03bb6be2"
}
}
],
"related_transactions": [
{
"transaction_identifier": {
"hash": "0x2f23fd8cca835af21f3ac375bac601f97ead75f2e79143bdf71fe2c4be043e8f"
},
"network_identifier": {
"blockchain": "bitcoin",
"network": "mainnet",
"sub_network_identifier": {
"network": "shard 1",
"metadata": {
"producer": "0x52bc44d5378309ee2abf1539bf71de1b7d7be3b5"
}
}
}
}
],
"metadata": {
"size": 12378,
"lockTime": 1582272577
}
}
],
"metadata": {
"transactions_root": "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347",
"difficulty": "123891724987128947"
}
},
"other_transactions": [
{
"hash": "0x2f23fd8cca835af21f3ac375bac601f97ead75f2e79143bdf71fe2c4be043e8f"
}
]
}Get a Block
Get a block by its Block Identifier. If transactions are returned in the same call to the node as fetching the block, the response should include these transactions in the Block object. If not, an array of Transaction Identifiers should be returned so /block/transaction fetches can be done to get all transaction information. When requesting a block by the hash component of the BlockIdentifier, this request MUST be idempotent: repeated invocations for the same hash-identified block must return the exact same block contents. No such restriction is imposed when requesting a block by height, given that a chain reorg event might cause the specific block at height n to be set to a different one.
curl --request POST \
--url https://example.com/block \
--header 'Content-Type: application/json' \
--data '{
"network_identifier": {
"blockchain": "bitcoin",
"network": "mainnet",
"sub_network_identifier": {
"network": "shard 1",
"metadata": {
"producer": "0x52bc44d5378309ee2abf1539bf71de1b7d7be3b5"
}
}
},
"block_identifier": {
"index": 1123941,
"hash": "0x1f2cc6c5027d2f201a5453ad1119574d2aed23a392654742ac3c78783c071f85"
}
}'{
"block": {
"block_identifier": {
"index": 1123941,
"hash": "0x1f2cc6c5027d2f201a5453ad1119574d2aed23a392654742ac3c78783c071f85"
},
"parent_block_identifier": {
"index": 1123941,
"hash": "0x1f2cc6c5027d2f201a5453ad1119574d2aed23a392654742ac3c78783c071f85"
},
"timestamp": 1582833600000,
"transactions": [
{
"transaction_identifier": {
"hash": "0x2f23fd8cca835af21f3ac375bac601f97ead75f2e79143bdf71fe2c4be043e8f"
},
"operations": [
{
"operation_identifier": {
"index": 5,
"network_index": 0
},
"type": "Transfer",
"related_operations": [
{
"index": 1
},
{
"index": 2
}
],
"status": "Reverted",
"account": {
"address": "0x3a065000ab4183c6bf581dc1e55a605455fc6d61",
"sub_account": {
"address": "0x6b175474e89094c44da98b954eedeac495271d0f"
}
},
"amount": {
"value": "1238089899992",
"currency": {
"symbol": "BTC",
"decimals": 8,
"metadata": {
"Issuer": "Satoshi"
}
}
},
"coin_change": {
"coin_identifier": {
"identifier": "0x2f23fd8cca835af21f3ac375bac601f97ead75f2e79143bdf71fe2c4be043e8f:1"
}
},
"metadata": {
"asm": "304502201fd8abb11443f8b1b9a04e0495e0543d05611473a790c8939f089d073f90509a022100f4677825136605d732e2126d09a2d38c20c75946cd9fc239c0497e84c634e3dd01 03301a8259a12e35694cc22ebc45fee635f4993064190f6ce96e7fb19a03bb6be2",
"hex": "48304502201fd8abb11443f8b1b9a04e0495e0543d05611473a790c8939f089d073f90509a022100f4677825136605d732e2126d09a2d38c20c75946cd9fc239c0497e84c634e3dd012103301a8259a12e35694cc22ebc45fee635f4993064190f6ce96e7fb19a03bb6be2"
}
}
],
"related_transactions": [
{
"transaction_identifier": {
"hash": "0x2f23fd8cca835af21f3ac375bac601f97ead75f2e79143bdf71fe2c4be043e8f"
},
"network_identifier": {
"blockchain": "bitcoin",
"network": "mainnet",
"sub_network_identifier": {
"network": "shard 1",
"metadata": {
"producer": "0x52bc44d5378309ee2abf1539bf71de1b7d7be3b5"
}
}
}
}
],
"metadata": {
"size": 12378,
"lockTime": 1582272577
}
}
],
"metadata": {
"transactions_root": "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347",
"difficulty": "123891724987128947"
}
},
"other_transactions": [
{
"hash": "0x2f23fd8cca835af21f3ac375bac601f97ead75f2e79143bdf71fe2c4be043e8f"
}
]
}Body
A BlockRequest is utilized to make a block request on the /block endpoint.
The network_identifier specifies which network a particular object is associated with.
Show child attributes
Show child attributes
"bitcoin"
If a blockchain has a specific chain-id or network identifier, it should go in this field. It is up to the client to determine which network-specific identifier is mainnet or testnet.
"mainnet"
In blockchains with sharded state, the SubNetworkIdentifier is required to query some object on a specific shard. This identifier is optional for all non-sharded blockchains.
When fetching data by BlockIdentifier, it may be possible to only specify the index or hash. If neither property is specified, it is assumed that the client is making a request at the current block.
Response
Expected response to a valid request
A BlockResponse includes a fully-populated block or a partially-populated block with a list of other transactions to fetch (other_transactions). As a result of the consensus algorithm of some blockchains, blocks can be omitted (i.e. certain block indices can be skipped). If a query for one of these omitted indices is made, the response should not include a Block object. It is VERY important to note that blocks MUST still form a canonical, connected chain of blocks where each block has a unique index. In other words, the PartialBlockIdentifier of a block after an omitted block should reference the last non-omitted block.
Blocks contain an array of Transactions that occurred at a particular BlockIdentifier. A hard requirement for blocks returned by Rosetta implementations is that they MUST be inalterable: once a client has requested and received a block identified by a specific BlockIdentifier, all future calls for that same BlockIdentifier must return the same block contents.
Show child attributes
Show child attributes
The block_identifier uniquely identifies a block in a particular network.
The block_identifier uniquely identifies a block in a particular network.
The timestamp of the block in milliseconds since the Unix Epoch. The timestamp is stored in milliseconds because some blockchains produce blocks more often than once a second.
x >= 01582833600000
Transactions contain an array of Operations that are attributable to the same TransactionIdentifier.
Show child attributes
Show child attributes
The transaction_identifier uniquely identifies a transaction in a particular network and block or in the mempool.
Show child attributes
Show child attributes
Any transactions that are attributable only to a block (ex: a block event) should use the hash of the block as the identifier.
"0x2f23fd8cca835af21f3ac375bac601f97ead75f2e79143bdf71fe2c4be043e8f"
Operations contain all balance-changing information within a transaction. They are always one-sided (only affect 1 AccountIdentifier) and can succeed or fail independently from a Transaction. Operations are used both to represent on-chain data (Data API) and to construct new transactions (Construction API), creating a standard interface for reading and writing to blockchains.
Show child attributes
Show child attributes
The operation_identifier uniquely identifies an operation within a transaction.
Show child attributes
Show child attributes
The operation index is used to ensure each operation has a unique identifier within a transaction. This index is only relative to the transaction and NOT GLOBAL. The operations in each transaction should start from index 0. To clarify, there may not be any notion of an operation index in the blockchain being described.
x >= 05
Some blockchains specify an operation index that is essential for client use. For example, Bitcoin uses a network_index to identify which UTXO was used in a transaction. network_index should not be populated if there is no notion of an operation index in a blockchain (typically most account-based blockchains).
x >= 00
Type is the network-specific type of the operation. Ensure that any type that can be returned here is also specified in the NetworkOptionsResponse. This can be very useful to downstream consumers that parse all block data.
"Transfer"
Restrict referenced related_operations to identifier indices < the current operation_identifier.index. This ensures there exists a clear DAG-structure of relations. Since operations are one-sided, one could imagine relating operations in a single transfer or linking operations in a call tree.
The operation_identifier uniquely identifies an operation within a transaction.
Show child attributes
Show child attributes
The operation index is used to ensure each operation has a unique identifier within a transaction. This index is only relative to the transaction and NOT GLOBAL. The operations in each transaction should start from index 0. To clarify, there may not be any notion of an operation index in the blockchain being described.
x >= 05
Some blockchains specify an operation index that is essential for client use. For example, Bitcoin uses a network_index to identify which UTXO was used in a transaction. network_index should not be populated if there is no notion of an operation index in a blockchain (typically most account-based blockchains).
x >= 00
[{ "index": 1 }, { "index": 2 }]Status is the network-specific status of the operation. Status is not defined on the transaction object because blockchains with smart contracts may have transactions that partially apply (some operations are successful and some are not). Blockchains with atomic transactions (all operations succeed or all operations fail) will have the same status for each operation. On-chain operations (operations retrieved in the /block and /block/transaction endpoints) MUST have a populated status field (anything on-chain must have succeeded or failed). However, operations provided during transaction construction (often times called "intent" in the documentation) MUST NOT have a populated status field (operations yet to be included on-chain have not yet succeeded or failed).
"Reverted"
The account_identifier uniquely identifies an account within a network. All fields in the account_identifier are utilized to determine this uniqueness (including the metadata field, if populated).
Show child attributes
Show child attributes
The address may be a cryptographic public key (or some encoding of it) or a provided username.
"0x3a065000ab4183c6bf581dc1e55a605455fc6d61"
An account may have state specific to a contract address (ERC-20 token) and/or a stake (delegated balance). The sub_account_identifier should specify which state (if applicable) an account instantiation refers to.
Show child attributes
Show child attributes
The SubAccount address may be a cryptographic value or some other identifier (ex: bonded) that uniquely specifies a SubAccount.
"0x6b175474e89094c44da98b954eedeac495271d0f"
If the SubAccount address is not sufficient to uniquely specify a SubAccount, any other identifying information can be stored here. It is important to note that two SubAccounts with identical addresses but differing metadata will not be considered equal by clients.
Blockchains that utilize a username model (where the address is not a derivative of a cryptographic public key) should specify the public key(s) owned by the address in metadata.
Amount is some Value of a Currency. It is considered invalid to specify a Value without a Currency.
Show child attributes
Show child attributes
Value of the transaction in atomic units represented as an arbitrary-sized signed integer. For example, 1 BTC would be represented by a value of 100000000.
"1238089899992"
Currency is composed of a canonical Symbol and Decimals. This Decimals value is used to convert an Amount.Value from atomic units (Satoshis) to standard units (Bitcoins).
Show child attributes
Show child attributes
Canonical symbol associated with a currency.
"BTC"
Number of decimal places in the standard unit representation of the amount. For example, BTC has 8 decimals. Note that it is not possible to represent the value of some currency in atomic units that is not base 10.
x >= 08
Any additional information related to the currency itself. For example, it would be useful to populate this object with the contract address of an ERC-20 token.
{ "Issuer": "Satoshi" }CoinChange is used to represent a change in state of a some coin identified by a coin_identifier. This object is part of the Operation model and must be populated for UTXO-based blockchains. Coincidentally, this abstraction of UTXOs allows for supporting both account-based transfers and UTXO-based transfers on the same blockchain (when a transfer is account-based, don't populate this model).
Show child attributes
Show child attributes
CoinIdentifier uniquely identifies a Coin.
Show child attributes
Show child attributes
Identifier should be populated with a globally unique identifier of a Coin. In Bitcoin, this identifier would be transaction_hash:index.
"0x2f23fd8cca835af21f3ac375bac601f97ead75f2e79143bdf71fe2c4be043e8f:1"
CoinActions are different state changes that a Coin can undergo. When a Coin is created, it is coin_created. When a Coin is spent, it is coin_spent. It is assumed that a single Coin cannot be created or spent more than once.
coin_created, coin_spent {
"asm": "304502201fd8abb11443f8b1b9a04e0495e0543d05611473a790c8939f089d073f90509a022100f4677825136605d732e2126d09a2d38c20c75946cd9fc239c0497e84c634e3dd01 03301a8259a12e35694cc22ebc45fee635f4993064190f6ce96e7fb19a03bb6be2",
"hex": "48304502201fd8abb11443f8b1b9a04e0495e0543d05611473a790c8939f089d073f90509a022100f4677825136605d732e2126d09a2d38c20c75946cd9fc239c0497e84c634e3dd012103301a8259a12e35694cc22ebc45fee635f4993064190f6ce96e7fb19a03bb6be2"
}The related_transaction allows implementations to link together multiple transactions. An unpopulated network identifier indicates that the related transaction is on the same network.
Show child attributes
Show child attributes
The transaction_identifier uniquely identifies a transaction in a particular network and block or in the mempool.
Show child attributes
Show child attributes
Any transactions that are attributable only to a block (ex: a block event) should use the hash of the block as the identifier.
"0x2f23fd8cca835af21f3ac375bac601f97ead75f2e79143bdf71fe2c4be043e8f"
Used by RelatedTransaction to indicate the direction of the relation (i.e. cross-shard/cross-network sends may reference backward to an earlier transaction and async execution may reference forward). Can be used to indicate if a transaction relation is from child to parent or the reverse.
forward, backward The network_identifier specifies which network a particular object is associated with.
Show child attributes
Show child attributes
"bitcoin"
If a blockchain has a specific chain-id or network identifier, it should go in this field. It is up to the client to determine which network-specific identifier is mainnet or testnet.
"mainnet"
In blockchains with sharded state, the SubNetworkIdentifier is required to query some object on a specific shard. This identifier is optional for all non-sharded blockchains.
Transactions that are related to other transactions (like a cross-shard transaction) should include the transaction_identifier of these transactions in the metadata.
{ "size": 12378, "lockTime": 1582272577 }{
"transactions_root": "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347",
"difficulty": "123891724987128947"
}Some blockchains may require additional transactions to be fetched that weren't returned in the block response (ex: block only returns transaction hashes). For blockchains with a lot of transactions in each block, this can be very useful as consumers can concurrently fetch all transactions returned.
The transaction_identifier uniquely identifies a transaction in a particular network and block or in the mempool.
Show child attributes
Show child attributes
Any transactions that are attributable only to a block (ex: a block event) should use the hash of the block as the identifier.
"0x2f23fd8cca835af21f3ac375bac601f97ead75f2e79143bdf71fe2c4be043e8f"
Was this page helpful?