Notes

result: true means only that the broadcast call completed without a reported error. It does not prove that the transaction remains in the node's Pending Pool, has propagated to other nodes, has been included in a block, has executed successfully, or has become solidified. Use /walletsolidity/gettransactionbyid to confirm solidified inclusion. Query /walletsolidity/gettransactioninfobyid separately when receipt or execution details are required.

• Do not treat the broadcast response alone as business success.
• While the transaction remains valid, you can rebroadcast the exact signed payload to the original node or another reliable, synchronized node. Its txID remains unchanged, and deduplication prevents a second execution. The receiving node may return DUP_TRANSACTION_ERROR.
• If the transaction was never submitted to any node and expired before its first broadcast attempt, rebuild and re-sign it. If it was broadcast or the outcome is unknown, follow the safe rebroadcast and replacement flow and establish that the original txID is absent from the solidified chain before creating a replacement.
• 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 the broadcast response, inclusion, execution receipt, and solidified state
• Transaction protocol — TAPOS, expiration, and raw_data structure