Notes

result: true only means the broadcast node accepted the transaction and placed it in the local mempool. It does not mean the transaction has been included in a block, and it does not mean execution succeeded. When final state is required, confirm the result with a solidified-state API such as /walletsolidity/gettransactioninfobyid.

• Do not treat the broadcast response alone as business success.
• If the transaction is not included before expiration, you can rebroadcast the same signed transaction to another synchronized node. TRON de-duplicates by txID, so rebroadcasting the same transaction is idempotent.
• If the transaction has expired, do not reuse the old transaction body. Rebuild, re-sign, and broadcast again.
• If you only have the hex-encoded signed transaction, use BroadcastHex.
• For CONTRACT_VALIDATE_ERROR, BANDWITH_ERROR, TAPOS_ERROR, and related errors, see Broadcast and RPC errors.

Related resources

• GetTransactionSign — node-side signing; use only in test environments, not production
• BroadcastHex — broadcast a hex-encoded signed transaction
• API signature and broadcast flow — end-to-end signing and broadcast workflow
• Confirmation semantics — distinguish broadcast acceptance, inclusion, execution receipt, and solidified state
• Transaction protocol — TAPOS, expiration, and raw_data structure