Build Once. Integrate Your Blockchain Everywhere.
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.
Key | Value | Description |
---|---|---|
Content-Type | application/json |
Get a transaction in a block by its Transaction Identifier. This endpoint should only be used when querying a node for a block does not return all transactions contained within it.
All transactions returned by this endpoint must be appended to any transactions returned by the /block method by consumers of this data. Fetching a transaction by hash is considered an Explorer Method (which is classified under the Future Work section).
This method can be used to let consumers to paginate results when the block trasactions count is too big to be returned in a single BlockResponse.
Calling this endpoint requires reference to a BlockIdentifier because transaction parsing can change depending on which block contains the transaction. For example, in Bitcoin it is necessary to know which block contains a transaction to determine the destination of fee payments. Without specifying a block identifier, the node would have to infer which block to use (which could change during a re-org).
Implementations that require fetching previous transactions to populate
the response (ex: Previous UTXOs in Bitcoin) may find it useful to run a
cache within the Rosetta server in the /data directory
(on a path that does not conflict with the node).
Key | Value | Description |
---|---|---|
Content-Type | application/json |
Combine creates a network-specific transaction from an unsigned transaction and an array of provided signatures.
The signed transaction returned from this method will be sent to the
/construction/submit
endpoint by the caller.
Key | Value | Description |
---|---|---|
Content-Type | application/json |
Preprocess is called prior to /construction/payloads
to construct a
request for any metadata that is needed for transaction construction
given (i.e. account nonce).
The options
object returned from this endpoint will be sent to the /construction/metadata
endpoint UNMODIFIED by the caller (in an offline execution environment). If
your Construction API implementation has configuration options, they MUST
be specified in the /construction/preprocess
request (in the metadata
field).
Key | Value | Description |
---|---|---|
Content-Type | application/json |
Derive returns the network-specific address associated with a public key.
Blockchains that require an on-chain action to create an
account should not implement this method.
Key | Value | Description |
---|---|---|
Content-Type | application/json |
Payloads is called with an array of operations
and the response from /construction/metadata
. It returns an
unsigned transaction blob and a collection of payloads that must
be signed by particular addresses using a certain SignatureType.
The array of operations provided in transaction construction often times
can not specify all “effects” of a transaction (consider invoked transactions
in Ethereum). However, they can deterministically specify the “intent”
of the transaction, which is sufficient for construction. For this reason,
parsing the corresponding transaction in the Data API (when it lands on chain)
will contain a superset of whatever operations were provided during construction.
Key | Value | Description |
---|---|---|
Content-Type | application/json |
Get any information required to construct a transaction for a specific
network. Metadata returned here could be a recent hash to use, an
account sequence number, or even arbitrary chain state. The request
used when calling this endpoint is created by calling /construction/preprocess
in an offline environment.
You should NEVER assume that the request sent to this endpoint will be
created by the caller or populated with any custom parameters. This must
occur in /construction/preprocess
.
It is important to clarify that this endpoint should not pre-construct
any transactions for the client (this should happen in /construction/payloads
).
This endpoint is left purposely unstructured because of the wide scope
of metadata that could be required.
Key | Value | Description |
---|---|---|
Content-Type | application/json |
TransactionHash returns the network-specific transaction hash for
a signed transaction.
Key | Value | Description |
---|---|---|
Content-Type | application/json |
Parse is called on both unsigned and signed transactions to understand the intent of the formulated transaction.
This is run as a sanity check before signing (after /construction/payloads
)
and before broadcast (after /construction/combine
).
Key | Value | Description |
---|---|---|
Content-Type | application/json |
Submit a pre-signed transaction to the node. This call should not block on the transaction being included in a block. Rather, it should return immediately with an indication of whether or not the transaction was included in the mempool.
The transaction submission response should only return a 200 status
if the submitted transaction could be included in the mempool.
Otherwise, it should return an error.
Key | Value | Description |
---|---|---|
Content-Type | application/json |
Get all Transaction Identifiers in the mempool
Key | Value | Description |
---|---|---|
Content-Type | application/json |
Get a transaction in the mempool by its Transaction Identifier. This is a separate request than fetching a block transaction (/block/transaction) because some blockchain nodes need to know that a transaction query is for something in the mempool instead of a transaction in a block.
Transactions may not be fully parsable until they are in a block (ex: may
not be possible to determine the fee to pay before a transaction is
executed). On this endpoint, it is ok that returned transactions are
only estimates of what may actually be included in a block.
Key | Value | Description |
---|---|---|
Content-Type | application/json |
This endpoint returns a list of NetworkIdentifiers that the Rosetta
server supports.
Key | Value | Description |
---|---|---|
Content-Type | application/json |
This endpoint returns the version information and allowed network-specific types for a NetworkIdentifier. Any NetworkIdentifier returned by /network/list should be accessible here.
Because options are retrievable in the context of a NetworkIdentifier,
it is possible to define unique options for each network.
Key | Value | Description |
---|---|---|
Content-Type | application/json |
This endpoint returns the current status of the network requested. Any
NetworkIdentifier returned by /network/list should be accessible here.
Key | Value | Description |
---|---|---|
Content-Type | application/json |
Get an array of all AccountBalances for an AccountIdentifier and the BlockIdentifier at which the balance lookup was performed. The BlockIdentifier must always be returned because some consumers of account balance data need to know specifically at which block the balance was calculated to compare balances they compute from operations with the balance returned by the node.
It is important to note that making a balance request for an account without populating the SubAccountIdentifier should not result in the balance of all possible SubAccountIdentifiers being returned. Rather, it should result in the balance pertaining to no SubAccountIdentifiers being returned (sometimes called the liquid balance). To get all balances associated with an account, it may be necessary to perform multiple balance requests with unique AccountIdentifiers.
It is also possible to perform a historical balance lookup (if the server
supports it) by passing in an optional BlockIdentifier.
Key | Value | Description |
---|---|---|
Content-Type | application/json |
Key | Value | Type |
---|---|---|
baseUrl | / | string |