Transactions are cryptographically signed instructions from accounts. An account will initiate a transaction to update the state of the TRON network. The simplest transaction is transferring TRX from one account to another.
Transactions, which change the state of the chain, need to be broadcast to the whole network. Any node can broadcast a request for a transaction. After the super node receives the transaction, it executes the transaction and includes it in a block, then propagates the block to the whole network.
Only after the transaction is packed into a block by the super node, and the block is confirmed, the transaction is finally confirmed.
The format of a transaction is as below:
A submitted transaction mainly includes the following fields:
raw_data.contract` - The main content of the transaction,`
contract` is a list, but only one element is used at present. Different types of transactions have different contract contents. For example, for a TRX transfer type transaction, the contract will include the transfer amount, receiver address and other information. TRON supports multiple types of contracts , please refer to the [Types of Transaction](🔗) section below for details.
raw_data.ref_block_bytes` - The height of the transaction reference block, using the 6th to 8th (exclusive) bytes of the reference block height, a total of 2 bytes. The reference block is used in the TRON TAPOS mechanism, which can prevent a replay of a transaction on forks that do not include the referenced block. Generally the latest solidified block is used as the reference block.
raw_data.ref_block_hash` - The hash of the transaction reference block, using the 8th to 16th (exclusive) bytes of the reference block hash, a total of 8 bytes. The reference block is used in the TRON TAPOS mechanism, which can prevent a replay of a transaction on forks that do not include the referenced block. Generally the latest solidified block is used as the reference block.
raw_data.expiration` - Transaction expiration time, beyond which the transaction will no longer be packed. If the transaction is created by calling the java-tron API, its expiration time will be automatically set by node to the value of adding 60 seconds to the timestamp of the node's latest block. The expiration time interval can be modified in the node's configuration file, the maximum value cannot exceed 24 hours.
raw_data.timestamp` - Transaction timestamp, set as the transaction creation time.
raw_data.fee_limit` - The maximum energy cost allowed for the execution of smart contract transaction. Only deploying and triggering smart contract transactions need to be set, others not.
signature` - The sender's signature for the transaction. This proves that the transaction could only have come from the sender and was not sent fraudulently.
# Types of Transaction
On TRON there are many different types of transactions, such as TRX transfer transactions, TRC10 transfer transactions, deploying smart contract transactions, triggering smart contract transactions, staking TRX transactions, and so on.
To create different types of transactions, you need to call different APIs. For example, the type of smart contract deployment transaction is `
CreateSmartContract`, you need to call the `
wallet/deploycontract` API to create a transaction, and the type of the staking TRX transaction is `
FreezeBalanceContract`, you need to call `
wallet/freezebalance` API to create transactions.
For more transaction types, please refer to：[Types of transactions on TRON](🔗)，For more HTTP APIs, please refer to：[HTTP API](🔗)
# Transaction Lifecycle
A transaction goes through the following stages in its life cycle:
Transaction's creation and signature.
The transaction is broadcast to the TRON network, it will be included in a transaction pool after passing the verification and execution by node.
The block producing node takes the transaction from the transaction pool, includes it in a new block, and then broadcasts the block to the TRON network.
The transaction will be "confirmed". Whether a transaction is confirmed depends on whether the block in which the transaction is included is confirmed. TRON's block confirmation mechanism is that after a block is produced, 19 different super nodes produce subsequent blocks based on this block, then the block is confirmed.
## Create Transaction
A variety of libraries and tools are available to create transactions. The following takes tronweb to create a TRX transfer transaction as an example to illustrate how to create a transaction:
## Sign Transaction
A transaction needs to be signed using the sender's private key before sending it.
**Transaction signature generating process**
Calculate the hash of the transaction.
Sign the transaction hash with the sender's private key.
Add the generated signature to the transaction instance.
Most SDKs implement the above transaction signature generating process and encapsulate them into an interface for developers to call. Taking tronweb as an example, users can directly call the sign method to complete the transaction signature.
**Example of signature using tronweb** Use tronweb to sign the transaction created above:
## Broadcast Transaction
After the node receives a transaction sent by a user, it will try to verify and execute the transaction locally, and broadcasts valid transactions to other nodes, discards invalid transactions, which will effectively prevent spam transactions from invalid broadcast in the network.
To broadcast a signed transaction using tronweb:
## Transaction confirmation
Whether a transaction is confirmed depends on whether the block in which the transaction is included is confirmed. TRON's block confirmation mechanism is that after a block is produced, 19 different super nodes produce subsequent blocks based on this block, then the block is confirmed.
java-tron node provides `
/walletsolidty/*` API, which is convenient for users to query confirmed transactions. The difference between `
/walletsolidty/*` and `
/wallet/*` is that the transaction queried by `
/wallet/*` indicates that it has been on the chain but not necessarily confirmed. The transaction queried by `
/walletsolidty/*` indicates that it has been on the chain and solidified, that is, the transaction has been confirmed.
For different transactions，there are different ways to determine whether it is confirmed:
**System Contract Transaction** All types of transactions other than creating smart contract types and triggering smart contract types are system contract transactions. System contract transaction confirmation method:
As long as the transaction can be queried through `
/walletsolidity/gettransactioninfobyid` or `
/walletsolidity/gettransactionbyid` API, it is confirmmed.
**Smart Contract Transaction** Including creating smart contract and triggering smart contract transactions. Because they need to be executed in TRON virtual machine, some exceptions may be thrown during the execution. These transactions are on the chain, but it does not mean that the transactions are successfully executed. And there are two ways to determine whether the smart contract transaction is successfully executed:
transactionInfo.receipt.result` equals `
success` via calling the /walletsolidity/gettransactioninfobyid API
success` via calling `
**Internal Transaction** An internal transaction is a transaction that transfers tokens to other external addresses or contract addresses in a contract. First, the internal transactions can be queried through `
/walletsolidity/gettransactioninfobyid` API, and the `
rejected` field in the internal transaction is used to determine whether the internal transaction is confirmed, but differs for HTTP and GRPC API:
HTTP API：For successful transactions, the `
rejected` field is not returned by default. For failed transactions, `
rejected` equals true.
GRPC API：For successful transactions, `
rejected` equals false, indicating that the current internalTransaction has not been discarded, For failed transactions, `
rejected` equals true.