A pending TRON transaction is one that a wallet or swap service has not yet shown as completed. The key condition is whether its transaction ID has entered a block and whether that block has become solidified; a “submitted” message alone proves neither.
Pending is a wallet status, not a single protocol state. A signed transaction may be waiting in a node’s pending pool, already included in a recent block, absent from the node that the wallet queried, or included but not yet reflected by an indexer.
TRON produces blocks about every three seconds, while solidification typically takes about a minute. A transaction in a recent, non-solidified block may still appear unsettled even though its contract call has run. For an ordinary swap, wait for solidification before treating the token balance or received amount as final.
Keep the transaction ID (txID) from the broadcast. A response such as result: true confirms only that the broadcast call returned without an error; it does not prove propagation, inclusion, successful contract execution, or finality. A TRON swap may call a router and token contracts, so the wallet’s summary can lag behind the actual on-chain state.
A transaction’s raw_data.expiration is its inclusion deadline, in Unix milliseconds. The usual default is 60 seconds beyond the latest block timestamp, and the protocol permits up to 24 hours. The reference block fields (ref_block_bytes and ref_block_hash) also tie the signed transaction to recent chain history; they must refer to a block within the latest 65,536 blocks.
If a transaction has not appeared by expiration, it cannot later be included as signed. A slow signing flow, stale wallet data, or delayed broadcast can consume much of the usual one-minute window. This is why a transaction that was prepared earlier can fail validation even if the wallet still displays it as pending.
TRX transfers and contract swaps also draw on different resources. Bandwidth covers the serialized transaction bytes; Energy pays for smart-contract execution. Insufficient Bandwidth can prevent broadcast, while a contract call that exhausts its fee_limit can be included and then fail with OUT_OF_ENERGY. That failed call may still consume resources, so “pending” should not be used to describe every unsuccessful swap.
First look up the txID on a reliable TRON explorer or through a synchronized node. If it appears in a block, inspect the transaction information and receipt, then check whether the block is solidified. If it does not appear, compare the latest solidified block’s timestamp with the transaction’s expiration before deciding whether to wait or retry.
When a transaction remains valid but a node may have missed it, rebroadcasting the exact same signed transaction is generally safer than signing a replacement: the unchanged txID cannot execute twice. If the transaction is absent after its deadline has passed on the solidified chain, it has expired without inclusion; only then consider creating a new transaction. Avoid submitting a second swap while the first could still land, since both calls might execute.
For someone using a TRON swap platform to exchange TRX or TRC-20 tokens such as USDT, this distinction makes the next step clearer: check whether the swap call exists on-chain before initiating another one. A TRON swap that is included but has a receipt result such as REVERT or OUT_OF_ENERGY is a failed execution, not a transaction waiting in a queue. Check the receipt’s result and any error details; a successful broadcast response is not a substitute.
Suppose a wallet shows a USDT swap as pending after broadcast. Before, the user sees no updated balance and is tempted to submit again. After looking up the txID, they find it in a recent block with no solidified result yet; waiting for solidification is the right move. If instead it is absent after expiration, they can treat that signed transaction as expired and decide whether to submit a new one.
JST or another TRC-20 token follows the same transaction-state logic: the token name does not change broadcast, inclusion, execution, or solidification. The contract’s behavior and the transaction receipt determine whether the swap succeeded. When a transaction is included, check the receipt result and token transfer logs rather than relying only on a wallet’s pending label.
Before acting, check the txID, its inclusion status, the receipt result, and whether its expiration has passed on the solidified chain. If it is included, wait for finality or diagnose the receipt; if it is still valid and absent, wait or rebroadcast that exact signed transaction; if it is expired and absent, consider a new swap only after confirming those facts.