Confirmation semantics
Distinguish broadcast acceptance, transaction inclusion, execution receipts, solidified blocks, and indexer delay so intermediate states are not treated as final results.
TRON APIs return different data at different stages. Before using a response as a final result, decide whether it represents broadcast acceptance, the transaction body, an execution receipt, solidified state, or indexed service data. Do not treat an intermediate state as final.
Prerequisites
State semantics quick reference
| Result you see | What it means | What it does not mean | Next step |
|---|---|---|---|
BroadcastTransaction returns result: true | The broadcast node accepted the transaction and tries to place it in the local mempool | The transaction is not necessarily included, executed successfully, or solidified | Continue querying the transaction body or receipt |
GetTransactionById returns a transaction object | The node can find the transaction body, including raw_data, signatures, and contract parameters | It does not prove contract execution succeeded and does not include fees, Events, or internal transactions | Query GetTransactionInfoById |
GetTransactionInfoById returns a receipt | The transaction has been executed and produced fees, Energy usage, Events, internal transactions, and other execution results | The FullNode version does not necessarily mean the result is solidified | Query the SolidityNode version when final state is required |
| SolidityNode returns a transaction or block | The data comes from a solidified block | It is not a complete historical index | Use it as the basis for final confirmation or reconciliation |
| TronGrid returns historical transactions or Events | The index service has processed the corresponding data | It is not the same as native node state and can be affected by pagination, rate limits, and index delay | Re-check critical state with a node or self-hosted indexer |
Broadcast acceptance is not execution success
The broadcast API only checks whether the node can accept the transaction. It does not tell you whether the contract executed successfully or whether the transaction has entered a solidified block.
A common mistake is treating this response as final success:
{ "result": true, "txid": "..." }The correct flow is to continue querying the receipt:
- Use GetTransactionById to query the transaction body and confirm that the node can find the transaction.
- Use GetTransactionInfoById to query the execution receipt.
- When final state is required, use GetTransactionInfoById, SolidityNode to query the solidified receipt.
Transaction body is not execution receipt
The transaction body describes what the requester submitted. The execution receipt describes what actually happened during on-chain execution.
| Data type | Recommended API | Contains |
|---|---|---|
| Transaction body | GetTransactionById | raw_data, signatures, and contract-call parameters |
| Execution receipt | GetTransactionInfoById | Fees, Energy usage, contract execution status, Events, and internal transactions |
| Solidified execution receipt | GetTransactionInfoById, SolidityNode | Execution receipt from a solidified block |
For plain TRX / TRC-10 top-level transfers, the transaction body usually contains the recipient and amount. For TriggerSmartContract, read the receipt to determine the actual execution result.
Latest head is not solidified state
FullNode returns the latest head seen by the node. This state has low latency but may not be solidified. SolidityNode returns state at the latest solidified block and usually lags the latest head by about 1 minute.
| Read target | Recommended API |
|---|---|
| Latest block display | GetNowBlock, FullNode |
| Latest solidified block | GetNowBlock, SolidityNode |
| Query latest-head view by block number | GetBlockByNum, FullNode |
| Confirm whether a block number is solidified | GetBlockByNum, SolidityNode |
If a flow requires final state, such as transaction confirmation, balance reconciliation, report generation, or block monitoring, base the decision on SolidityNode or a local solidified-block index.
Indexed data is not native node state
TronGrid V1 API and self-hosted indexers are useful for account history, TRC-20 transfer history, Events, internal transactions, and aggregate statistics. Index services are usually more convenient than scanning blocks directly, but pagination, rate limits, retries, and index delay still matter.
When complete state judgment is required, combine them as follows:
- Use TronGrid or a self-hosted indexer to discover candidate transactions, Events, or internal transactions.
- Use SolidityNode receipts or solidified block scanning to confirm final state.
- Store processed block numbers, transaction IDs, and log indexes locally so retries remain idempotent.
Related resources
- Sign and broadcast — the API workflow — full path for constructing, signing, broadcasting, and confirming transaction results
- Broadcast and RPC errors — troubleshooting broadcast failures, missing transactions after broadcast, and node rate limits
- Blocks — block structure, block ID, block number, and query API selection
- API task map — choose docs pages and reference APIs by task
Updated 7 days ago