Parse a Transaction

post https://rpc.chain49.com/cardano/construction/parse

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

Responses

Response body

object

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

signers

array of strings

[DEPRECATED by account_identifier_signers in v1.4.4] All signers (addresses) of a particular transaction. If the transaction is unsigned, it should be empty.

signers

account_identifier_signers

array of objects

account_identifier_signers

object

address

string

required

The address may be a cryptographic public key (or some encoding of it) or a provided username.

sub_account

object

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.

metadata

object

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.

Has additional fields

metadata

object

Has additional fields

Language

Credentials

Header

URL


xxxxxxxxxx
13
1
curl --request POST \
2
     --url https://rpc.chain49.com/cardano/construction/parse \
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
  "signed": true
12
}
13
'

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