The broadcasting service submits your signed transactions to the blockchain and makes sure each one reaches the network or fails with a clear reason.
What the service does
After a transaction is approved and signed, Fireblocks submits it to the blockchain network through a blockchain node. The broadcasting service handles that submission. It runs automatically, so you do not need to turn anything on.
The service is designed so that each transaction either reaches the blockchain node or fails with an explicit error. When a node is unresponsive or returns a temporary error, the service resubmits the transaction for you. When a node rejects a transaction with an error that retrying cannot fix, the service fails the transaction and reports the reason.
How broadcasting works
A transaction in the Broadcasting status moves through these steps. Not every transaction goes through every step.
- Fireblocks receives your signed transaction and queues it for submission. The substatus is QUEUED_FOR_BROADCAST.
- Fireblocks sends the transaction to the blockchain node. The substatus is SENDING_TO_NODE.
- If the node accepts the transaction, the transaction moves on Confirming, or to a final state, i.e. Completed, or Failed, and Fireblocks tracks it on the blockchain.
- If the node returns a temporary error, Fireblocks retries automatically. The substatus is TRANSIENT_NODE_ERROR_RETRY, and the API shows the error and an estimated retry deadline.
- At any point, if the node rejects the transaction with an error that retrying cannot fix, the transaction moves to Failed. A Failed substatus explains the reason.
- If Fireblocks runs out of retries after reaching the estimatedRetryDeadline, the substatus is RETRY_LIMIT_EXCEEDED, and the transaction does not progress on its own. To move it forward, submit a Replace-by-Fee (RBF) transaction. For details, see the Boost or drop a stuck EVM-based transaction article.
Errors Fireblocks retries and errors that fail right away
Errors Fireblocks retries
Fireblocks retries when the node cannot be reached or returns a temporary error. The estimatedRetryDeadline field in the broadcastingStatusInfo object of the Get Transaction by ID response shows the estimated time of the final retry attempt. The object also includes the errorType and errorCode fields. For the full field reference, see the Broadcasting substatuses article.
Errors that fail right away
Fireblocks fails the transaction as soon as the node rejects it for a reason that retrying cannot fix. Examples include:
- The contract call would revert.
- The nonce is already used by an earlier transaction.
- The gas limit or gas price is below the network minimum.
- The transaction type is not supported on the blockchain.
- The transaction is malformed, or its chain ID does not match the blockchain.
The Failed substatus shows the reason. For the full list, see the Failed substatuses article.
What you can see
In the Fireblocks Console, the Broadcasting status appears in Transaction History and in the Recent activity panel. A transaction typically stays in Broadcasting for no longer than one minute, depending on the load and response from the blockchain/nodes.
Broadcasting substatuses are available through the Get Transaction by ID API endpoint. Webhook notifications do not include them at this time. For the full list and API examples, see the Broadcasting substatuses article.
If a transaction stays in Broadcasting
- If a transaction stays in Broadcasting for longer than one minute, check the Fireblocks Status page for service disruptions. If there are none, check the node error in the broadcastingStatusInfo object of the Get Transaction by ID API response. If the transaction is still stuck, submit a Replace-by-Fee (RBF) transaction. To catch stuck transactions without checking manually, use Account Traffic Control (ATC), the Fireblocks proactive detection feature. You cannot cancel a transaction in the Broadcasting status, because Fireblocks has already sent it to the blockchain and no longer controls it. If the substatus is RETRY_LIMIT_EXCEEDED, submit a Replace-by-Fee (RBF) transaction with the same nonce. In the Recent activity panel, select Boost on the transaction. For details, see the Boost or drop a stuck EVM-based transaction article.
- A stuck transaction blocks the transactions behind it from the same account, because EVM blockchains require transactions from one account to be confirmed in order.
- Fireblocks monitors transactions in the Broadcasting status for all workspaces. If your workspace uses Account Traffic Control, you receive alerts about stuck transactions.
Where the service applies
The broadcasting service handles transactions on all EVM-based blockchains that Fireblocks supports. Fireblocks also uses the broadcasting service for Solana, Tron, and Stellar transactions. Some behavior in this article applies only to EVM-based blockchains, such as in-order confirmation and Replace-by-Fee (RBF).