Get a Block

post https://rpc.chain49.com/cardano/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.

Responses

Response body

object

block

object

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 BlockIndentifier, all future calls for that same BlockIdentifier must return the same block contents.

block_identifier

object

required

The block_identifier uniquely identifies a block in a particular network.

parent_block_identifier

object

required

The block_identifier uniquely identifies a block in a particular network.

timestamp

int64

required

≥ 0

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.

transactions

array of objects

required

transactions*

object

transaction_identifier

object

required

The transaction_identifier uniquely identifies a transaction in a particular network and block or in the mempool.

operations

array of objects

required

operations*

object

operation_identifier

object

required

The operation_identifier uniquely identifies an operation within a transaction.

related_operations

array of objects

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.

related_operations

object

index

int64

required

≥ 0

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.

network_index

int64

≥ 0

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).

type

string

required

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.

status

string

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).

account

object

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).

amount

object

Amount is some Value of a Currency. It is considered invalid to specify a Value without a Currency.

coin_change

object

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).

metadata

object

Has additional fields

related_transactions

array of objects

related_transactions

object

network_identifier

object

The network_identifier specifies which network a particular object is associated with.

transaction_identifier

object

required

The transaction_identifier uniquely identifies a transaction in a particular network and block or in the mempool.

direction

string

required

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

metadata

object

Transactions that are related to other transactions (like a cross-shard transaction) should include the tranaction_identifier of these transactions in the metadata.

Has additional fields

metadata

object

Has additional fields

other_transactions

array of objects

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.

other_transactions

object

hash

string

required

Any transactions that are attributable only to a block (ex: a block event) should use the hash of the block as the identifier. This should be normalized according to the case specified in the transaction_hash_case in network options.

Language

Credentials

Header

URL


xxxxxxxxxx
12
1
curl --request POST \
2
     --url https://rpc.chain49.com/cardano/block \
3
     --header 'accept: application/json' \
4
     --header 'content-type: application/json' \
5
     --data '
6
{
7
  "network_identifier": {
8
    "blockchain": "cardano",
9
    "network": "mainnet"
10
  }
11
}
12
'

Click Try It! to start a request and see the response here! Or choose an example:

application/json

200Expected response to a valid request

500unexpected error