Links
Comment on page

Field Descriptions

Below you can find some key types descriptions.
All types descriptions can be found in GraphQL schema as it is self-descriptive. Just go to playground and click "DOCS". Docs in Playground are the latest.
These types are met in most of GraphQL queries result data.

Account type

Recall that a smart contract and an account are the same thing in the context of the Everscale Blockchain, and that these terms can be used interchangeably, at least as long as only small (or β€œusual”) smart contracts are considered. A large smart-contract may employ several accounts lying in different shardchains of the same workchain for load balancing purposes.
An account is identified by its full address and is completely described by its state. In other words, there is nothing else in an account apart from its address and state.
Can be queried by following fields:
FIELD
TYPE
DESCRIPTION
id
string
Account address in raw format
acc_type
uint8
The current status of the account according to original Everscale blockchain specification: uninitialized - 0, active - 1,frozen - 2
last_paid
uint256
Contains either the unixtime of the most recent storage payment collected (usually this is the unixtime of the most recent transaction), or the unixtime when the account was created (again, by a transaction)
due_payment
​hex string (uint256)
If present, accumulates the storage payments that could not be exacted from the balance of the account, represented by a strictly positive amount of nanotokens; it can be present only for uninitialized or frozen accounts that have a balance of zero tokens (but may have non-zero balances in other cryptocurrencies). When due_payment becomes larger than the value of a configurable parameter of the blockchain, the ac- count is destroyed altogether, and its balance, if any, is transferred to the zero account.
last_trans_lt
uint64
the last account's transaction logic time
balance
uint128
Account balance in nanotokens
balance_other
{ currency: uint32, value: hex string (uint256) }
Array of other currency balances
split_depth
uint8
Number of the split depth for large contracts. Is present and non-zero only in instances of large smart contracts.
tick
bool
May be present only in the masterchainβ€”and within the masterchain, only in some fundamental smart contracts required for the whole system to function
code
base64
If present, contains smart-contract code encoded with in base64
data
base64
If present, contains smart-contract data encoded with in base64
data library: ,
base64
If present, contains library code used in smart-contract
proof
base64
Merkle proof that account is a part of shard state it cut from. Merkle proof struct encoded with base64.
boc
base64
Bag of cells with the account struct encoded with base64.

Transaction Type

The table below shows how our GraphQL scheme matches fields of Everscale transaction TLB schemes. In most cases, the specification is quoted to describe the fields. Meaning of fields is also sometime self-explanatory.
For more details, check the specification at https://test.ton.org/tblkch.pdf.
FIELD
TYPE
DESCRIPTION
id
string
transaction hash
tr_type
int
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
status
unknown - 0, preliminary - 1, proposed - 2, finalized - 3, refused - 4
Transaction processing status
block_id
string
block hash
account_addr
uint256
Address of an account for the transaction (Tip: check the notion of an Account collection in the specification)
lt
​
Transaction logical time. LT and the account address define the transaction on the blockchain
prev_trans_hash
​
hash of the previous transaction for the account
prev_trans_lt
​
logical time of a previous transaction for the account
now
​
block creation time
outmsg_cnt
​
The number of generated outbound messages (one of the common transaction parameters defined by the specification)
orig_status
​
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
end_status
​
The end state of an account after a transaction, 1 is returned to indicate a finalized transaction at an active account
in_msg
​
Dictionary of transaction inbound message ID's as specified in the specification
in_message
​
Dictionary of transaction inbound messages as specified in the specification
out_msgs
​
Dictionary of transaction outbound message ID's as specified in the specification
out_message
​
Dictionary of transaction outbound messages as specified in the specification
total_fees
​
Total amount of fees that entails account state change and used in Merkle update
total_fees_other
​
Same as above, but reserved for other coins that may appear in the blockchain
old_hash, new_hash
uint256
Hashes of the account state before and after the transaction
credit_first
​
​
STORAGE (phase)
​
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))
CREDIT (phase)
​
The account is credited with the value of the inbound message received. The credit phase can result in the collection of some due payments
due_fees_collected
​
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).
credit
​
​
credit_other
​
​
COMPUTE (phase)
​
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.
compute_type
​
0: skipped, then only skipped_reason is defined. 1: not skipped, then other fields for the phase are filled
skipped_reason
​
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
success
​
This flag is set if and only if exit_code is either 0 or 1.
msg_state_used
​
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)
account_activated
​
The flag reflects whether this has resulted in the activation of a previously frozen, uninitialized or non-existent account.
gas_fees
​
This parameter reflects the total gas fees collected by the validators for executing this transaction. It must be equal to the product of gas_used and gas_price from the current block header.
gas_used
​
See above
gas_limit
​
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.
gas_credit
​
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
mode
​
​
exit_code, exit_arg
​
These parameters represent the status values returned by TVM; for a successful transaction, exit_code has to be 0 or 1
vm_steps
​
the total number of steps performed by TVM (usually equal to two plus the number of instructions executed, including implicit RETs)
vm_init_state_hash, vm_final_state_hash
​
These parameters are the representation hashes of the original and resulting states of TVM
ACTION (phase)
​
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.
success
​
​
valid
​
​
no_funds
​
The flag indicates absence of funds required to create an outbound message
status_change
​
Account status change according to the list of statuses provided by the specification
total_fwd_fees
​
Amount in tokens
total_action_fees
​
Amount in tokens
result_code
​
​
result_arg
​
​
tot_actions
​
​
spec_actions
​
​
skipped_actions
​
​
msgs_created
​
​
action_list_hash
​
Hash of the action list created during the compuation phase
total_msg_size_cells
​
​
total_msg_size_bits
​
​
BOUNCE (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.
bounce_type
​
0 - Negfunds, 1 - Nofunds, 2 - Ok
msg_size_cells
​
​
msg_size_bits
​
​
req_fwd_fees
​
​
msg_fees
​
​
fwd_fees
​
Amount to be bounced back
aborted
​
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.
destroyed
​
​
tt
​
​
split_info
​
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.
cur_shard_pfx_len
​
length of the current shard prefix
acc_split_depth
​
​
this_addr
​
​
sibling_addr
​
​
prepare_transaction
​
​
installed
​
​
proof
​
​
boc
​
​

Message type

Message layout queries. A message consists of its header followed by its body or payload. The body is essentially arbitrary, to be interpreted by the destination smart contract. It can be queried with the following fields.
FIELD
TYPE
DESCRIPTION
id
hex string
message hash
msg_type
internal - 0, extIn - 1, extOut - 2
Returns the type of message
status
unknown - 0, queued - 1, processing - 2, preliminary - 3, proposed - 4, finalized - 5, refused - 6, transiting - 7
Returns internal processing status according to the numbers shown.
block_id
String
Block identifier of the block where the message was last seen.
body
base64
Bag of cells with the message encoded with base64
split_depth
uint8
split depth. This is only used for special contracts in masterchain for deploy messages
tick
bool
This field is present only in deploy messages of special contracts (to masterchain)
tock
bool
This field is present only in deploy messages of special contracts (to masterchain)
code
base64
Bag of cells. Represents contract code in deploy messages.
data
base64
Bag of cells. Represents initial data for a contract in deploy messages
library
base64
Bag of cells. Represents contract library in deploy messages
src
String
Returns source address string
dst
String
Destination address
created_lt
uint64
Logical creation time automatically set by the generating transaction.
created_at
uint32
Creation unixtime automatically set by the generating transaction. The creation unixtime equals the creation unixtime of the block containing the generating transaction.
ihr_disabled
bool
IHR is disabled for the message.
ihr_fee
uint128
This fee is subtracted from the value attached to the message and awarded to the validators of the destination shardchain if they include the message by the IHR mechanism.
fwd_fee
uint128
Original total forwarding fee paid for using the HR mechanism; it is automatically computed from some configuration parameters and the size of the message at the time the message is generated.
import_fee
uint128
Importing fee of the message
bounce
bool
If the transaction has been aborted, and the inbound message has its bounce flag set to true, then it is β€œbounced” by automatically generating an outbound message (with the bounce flag clear and bounced flag set to true) to its original sender.
bounced
bool
If the transaction has been aborted, and the inbound message has its bounce flag set to true, then it is β€œbounced” by automatically generating an outbound message (with the bounce flag clear and bounced flag set to true) to its original sender.
value
​
Internal message value in tokens. May or may not be present
value_other
​
Value of the message in other currency as name and amount of other crypto currencyMay or may not be present.
proof
base64
Merkle proof that message is a part of a block it is taken from. It is a bag of cells with Merkle proof struct encoded with base64.
boc
base64
A bag of cells with the message structure encoded with base64.

MsgEnvelope type

Message envelopes are used for attaching routing information, such as the current (transit) address and the next-hop address, to inbound, transit, and outbound messages.
FIELD
TYPE
DESCRIPTION
msg_id
string
Message id. Link to message id (message hash)
next_addr
string
A line with intermediate address. Message next-hop next-hop address
cur_add
string
A line with intermediate address. Message current (or transit) address
fwd_fee_remaining
​
Remaining forwarding fee in tokens. Explicitly represents the maximum amount of message forwarding fees that can be deducted from the message value during the remaining HR steps; it cannot exceed the value of fwd_fee indicated in the message itself.

InMsg type

A type to specify the parameter of the inbound message. You can query the source of the message, the reason for it's being imported into this block, and some information about its β€œfate” β€” its processing by a transaction or forwarding inside the block.
FIELD
TYPE
DESCRIPTION
msg_type
external - 0, ihr - 1, immediately - 2, final - 3, transit - 4, discardedFinal - 5, discardedTransit - 6
Message type
msg:
​
Message ID
transaction
​
Transaction ID
ihr_fee
uint128
This value is subtracted from the value attached to the message and awarded to the validators of the destination shardchain if they include the message by the IHR mechanism.
in_msg
​
Contains message envelope.
fwd_fee
​
Forwarding message fee in tokens
out_msg
​
More research required
transit_fee
​
transit fee in tokens
transaction_id
uint64
transaction ID
proof_delivered
​
​

Block type

FIELD
TYPE
DESCRIPTION
status
unknown - 0, proposed - 1, finalized - 2, refused - 3
Returns block processing status
global_id
uint32
global block ID
want_split
bool
​
seq_no
​
​
after_merge
bool
​
gen_utime
uint 32
Block creation time
gen_catchain_seqno
​
​
flags
​
​
master_ref
​
​
prev_ref
​
External block reference for previous block.
prev_alt_ref
​
External block reference for previous block in case of shard merge.
prev_vert_ref
​
External block reference for previous block in case of vertical blocks.
prev_vert_alt_ref
​
​
version
uin32
block version identifier
gen_validator_list_hash_short
​
​
before_split
bool
​
after_split
bool
​
want_merge
bool
​
vert_seq_no
​
​
start_lt:
uint64
Logical creation time automatically set by the block formation start. Logical time is a component of the Everscale Blockchain that also plays an important role in message delivery is the logical time, usually denoted by Lt. It is a non-negative 64-bit integer, assigned to certain events. For more details, see the Everscale blockchain specification
end_lt
uint64
Logical creation time automatically set by the block formation end.
workchain_id
uint32
workchain identifier
shard
​
​
min_ref_mc_seqno
​
Returns last known master block at the time of shard generation.
prev_key_block_seqno
​
Last key block seq_no
value_flow
​
​
to_next_blk
​
Amount of tokens amount to the next block.
to_next_blk_other
​
Amount of other cryptocurrencies to the next block.
exported
​
Amount of tokens exported.
exported_other
​
Amount of other cryptocurrencies exported.
imported
​
Amount of tokens imported.
imported_other
​
Amount of other cryptocurrencies imported.
from_prev_blk
​
Amount of tokens transferred from previous block.
from_prev_blk_other
​
Amount of other cryptocurrencies transferred from previous block.
master
​BlockMaster​
Contains information about shards, key block config params, etc. Present only in masterchain blocks
minted
​
Amount of tokens minted in this block.
minted_other
​
Amount of other cryptocurrencies minted in this block.
fees_imported
​
Amount of import fees in tokens
fees_imported_other
​
Amount of import fees in other currrencies.
in_msg_descr
​
Array of InMsg decribed messages.
rand_seed
​
Need more research.
out_msg_descr
​
​

BlockMaster Type

FIELD
TYPE
DESCRIPTION
min_shard_gen_utime
​
​
max_shard_gen_utime
​
​
shard_hashes
BlockMasterShardHashes { workchain_id: Int shard: String descr: BlockMasterShardHashesDescr}
List of shards present in the masterchain block
shard_fees
BlockMasterShardFees
​
recover_create_msg
InMsg
​
prev_blk_signatures
BlockMasterPrevBlkSignatures
​
config_addr
String
​
config
​BlockMasterConfig​
Blockchain config information. Present only in key blocks

BlockMasterShardHashesDescr type

ShardHashes is represented by a dictionary with 32-bit workchain_ids as keys, and β€œshard binary trees”, represented by TL-B type BinTree ShardDescr, as values. Each leaf of this shard binary tree contains a value of type ShardDescr, which describes a single shard by indicating the sequence number seq_no, the logical time lt, and the hash hash of the latest (signed) block of the corresponding shardchain.
FIELD
TYPE
DESCRIPTION
seq_no
uint32
sequence number
reg_mc_seqno
string
Representation hash of shard block's root cell. Returns last known master block at the time of shard generation. The shard block configuration is derived from that block.
start_lt
​
Logical time of the shardchain start.
end_lt
​
Logical time of the shardchain end.
root_hash
string
Representation hash of shard block's root cell. Returns last known master block at the time of shard generation. The shard block configuration is derived from that block.
file_hash
​
Shard block file hash.
before_split
bool
Everscale Blockchain supports dynamic sharding, so the shard configuration may change from block to block because of shard merge and split events. Therefore, we cannot simply say that each shardchain corresponds to a fixed set of accountchains. A shardchain block and its state may each be classified into two distinct parts. The parts with the ISP-dictated form of will be called the split parts of the block and its state, while the remainder will be called the non-split parts. The masterchain cannot be split or merged.
before_merge
bool
​
want_split
bool
​
want_merge
bool
​
nx_cc_updated
bool
​
flags
​
​
next_catchain_seqno
​
​
next_validator_shard
​
​
min_ref_mc_seqno
​
​
gen_utime
uint32
Time of the block creation
split_type
​
none - 0, split - 2, merge - 3
split
​
​
fees_collected
​
Amount of fees collected int his shard in tokens.
fees_collected_other
​
Amount of fees collected int his shard in other currencies.
funds_created
​
Amount of funds created in this shard in tokens.
funds_created_other
​
Amount of funds created in this shard in other currencies.

BlockMasterConfig Type

BlockMasterConfig type field is present only in key blocks. The previous key block seq_no is always present in all masterchain blocks in prev_key_block_seqno field.
This structure contains all Everscale blockchain configurations parameters.
FIELD
TYPE
DESCRIPTION
p15
validators_elected_for: Float, elections_start_before: Float, elections_end_before: Float, stake_held_for: Float
validators_elected_for - period of time in ms validators are elected for. elections_start_before - how much time in ms before utime_until (p34) elections start. elections_end_before - how much time in ms before utime_until (p34) elections end. stake_held_for - for how much time in ms after utime_until (p34) stake is frozen in elector contract
p16
max_validators: int, min_validators: int
max_validators - maximum possible number of active validators. min_validators - minimum number of validators required for consensus