Transaction type according to the original blockchain specification, clause 4.2.4. ordinary - 0, storage - 1, tick - 2, tock - 3, splitPrepare - 4, splitInstall - 5, mergePrepare - 6, mergeInstall - 7
unknown - 0, preliminary - 1, proposed - 2, finalized - 3, refused - 4
Transaction processing status
Address of an account for the transaction (Tip: check the notion of an Account collection in the specification)
Transaction logical time. LT and the account address define the transaction on the blockchain
hash of the previous transaction for the account
logical time of a previous transaction for the account
The number of generated outbound messages (one of the common transaction parameters defined by the specification)
The initial state of account. Note that in this case the query may return 0, if the account was not active before the transaction and 1 if it was already active
The end state of an account after a transaction, 1 is returned to indicate a finalized transaction at an active account
Dictionary of transaction inbound message ID's as specified in the specification
Dictionary of transaction inbound messages as specified in the specification
Dictionary of transaction outbound message ID's as specified in the specification
Dictionary of transaction outbound messages as specified in the specification
Total amount of fees that entails account state change and used in Merkle update
Same as above, but reserved for other coins that may appear in the blockchain
Hashes of the account state before and after the transaction
The storage phase is present in ordinary, merge, split, storage and tock transactions, so a common representation for this phase includes three fields. The first defines the amount , the second can be empty, the third specifies the account status change
storage_fees_collected, storage_fees_due, status_change
Fields show amounts related to storage fees and account status change (e.g. it may be frozen or remain active (unchanged))
The account is credited with the value of the inbound message received. The credit phase can result in the collection of some due payments
The sum of
due_fees_collected and credit must equal the value of the message received, plus its
ihr_fee if the message has not been received via Instant Hypercube Routing, IHR (otherwise the
ihr_fee is awarded to the validators).
The code of the smart contract is invoked inside an instance of TVM with adequate parameters, including a copy of the inbound message and of the persistent data, and terminates with an exit code, the new persistent data, and an action list (which includes, for instance, outbound messages to be sent). The processing phase may lead to the creation of a new account (uninitialized or active), or to the activation of a previously uninitialized or frozen account. The gas payment, equal to the product of the gas price and the gas consumed, is exacted from the account balance. If there is no reason to skip the computing phase, TVM is invoked and the results of the computation are logged. Possible parameters are covered below.
0: skipped, then only
skipped_reason is defined. 1: not skipped, then other fields for the phase are filled
Reason for skipping the compute phase. According to the specification, the phase can be skipped due to the absence of funds to buy gas, absence of state of an account or a message, failure to provide a valid state in the message
This flag is set if and only if
exit_code is either 0 or 1.
This parameter reflects whether the state passed in the message has been used. If it is set, the
account_activated flag is used (see below)
The flag reflects whether this has resulted in the activation of a previously frozen, uninitialized or non-existent account.
This parameter reflects the total gas fees collected by the validators for executing this transaction. It must be equal to the product of
gas_price from the current block header.
This parameter reflects the gas limit for this instance of TVM. It equals the lesser of either the tokens credited in the credit phase from the value of the inbound message divided by the current gas price, or the global per-transaction gas limit.
This parameter may be non-zero only for external inbound messages. It is the lesser of either the amount of gas that can be paid from the account balance or the maximum gas credit
These parameters represent the status values returned by TVM; for a successful transaction,
exit_code has to be 0 or 1
the total number of steps performed by TVM (usually equal to two plus the number of instructions executed, including implicit RETs)
These parameters are the representation hashes of the original and resulting states of TVM
If the smart contract has terminated successfully (with exit code 0 or 1), the actions from the list are performed. If it is impossible to perform all of them—for example, because of insufficient funds to transfer with an outbound message—then the transaction is aborted and the account state is rolled back. The transaction is also aborted if the smart contract did not terminate successfully, or if it was not possible to invoke the smart contract at all because it is uninitialized or frozen.
The flag indicates absence of funds required to create an outbound message
Account status change according to the list of statuses provided by the specification
Hash of the action list created during the compuation phase
If the transaction has been aborted, and the inbound message has its bounce flag set, then it is “bounced” by automatically generating an outbound message (with the bounce flag clear) to its original sender. Almost all value of the original inbound message (minus gas payments and forwarding fees) is transferred to the generated message, which otherwise has an empty body.
0 - Negfunds, 1 - Nofunds, 2 - Ok
Amount to be bounced back
The flag is set either if there is no action phase or if the action phase was unsuccessful. The bounce phase occurs only if the
aborted flag is set and the inbound message was bounceable.
The fields below cover split prepare and install transactions and merge prepare and install transactions, the fields correspond to the relevant schemes covered by the blockchain specification.
length of the current shard prefix