Withdrawal Flow

Withdrawals are one of the most critical and active functions in any retail-facing crypto business. Users depend on the withdrawal process to move funds quickly and securely. Designing an efficient, secure withdrawal flow is essential to delivering a reliable platform.

Automate the withdrawal flow

Setup

Automation is essential for ensuring a smooth, uninterrupted 24/7 withdrawal service. Relying on manual transaction signing is not scalable and introduces significant security risks. To address these challenges, implement a Fireblocks Co-Signer component. This approach guarantees continuous operation and enhances the overall security of your withdrawal process.

Highly available setup

One best practice for automation is setting up a highly available system by implementing the Co-signer in active/active mode. In this configuration, systems can take over from one another without downtime, ensuring that failover capability is always in place. For more information, see Fireblocks Co-signer High Availability setup.

Co-Signer logging and monitoring

Comprehensive monitoring and alerting are vital for maintaining a secure and reliable automated signing process. Setting up these systems lets you track transaction status in real time and detect anomalies that may indicate potential issues. Configure alerts to notify relevant personnel immediately when transactions are stuck or suspicious activity is detected, enabling prompt intervention.

For more information, see API Co-signer Maintenance.

Implementing multiple withdrawal wallets

Withdrawal pool

Using multiple withdrawal vault accounts can help reduce the impact of stuck transactions and enable higher throughput. Distribute user withdrawal requests across several withdrawal vault accounts using a round-robin mechanism (a circular execution pattern between wallets) to reduce the risk of transaction queues.

While multiple withdrawal vault accounts offer clear throughput benefits, they also introduce operational complexity. Keep the following in mind:

• Balance monitoring: Regularly monitor the balance of each wallet to ensure sufficient liquidity.
• Automated refills: Implement automated refill mechanisms to transfer funds between wallets as needed.

Multiple withdrawal wallets are particularly beneficial for Ethereum, which uses the nonce mechanism and therefore processes transactions sequentially, and for UTXO-based assets like Bitcoin. In the UTXO model, an unconfirmed output from a previous transaction can be used as input for a new one. This can result in a chain of stuck transactions if the first is not confirmed.

Although mechanisms like Replace By Fee (RBF) and Child Pays For Parent (CPFP) exist to release stuck transactions, relying on them is not ideal. The Bitcoin protocol also has a built-in mechanism that rejects transactions using an unconfirmed output from a transaction with more than 25 predecessors. This can create a queue of withdrawals and, in some cases, cause withdrawal failures.

Number of withdrawal wallets

A typical ECDSA-based chain transaction takes 6–7 seconds from initiation to broadcast. EdDSA-based chain transactions are slightly faster by about a second. On chains other than Solana and Tron (where parallel processing is not supported), Fireblocks serializes and signs transactions only after observing the previous transaction on the chain or node (TAP evaluation is still performed in parallel). In some cases, there is an additional delay of approximately 2 seconds before the transaction or its artifact is observed after submission.

For each sustained 1 TPS, we recommend using 5–6 withdrawal wallets and routing each new withdrawal to the next wallet in round-robin order. This guidance applies to steady-state throughput rather than short-term peaks. Queued transactions are acceptable as long as the queue continues to clear.

🚧

Pay close attention to transaction queues

Rapid growth may indicate that the Co-Signer is not signing transactions fast enough — this can be caused by slow callbacks, underpowered machines, or insufficient Co-Signers. If transactions remain queued for more than two hours, cancel and resubmit them, as they are likely to fail due to a timeout.

For wallets that support parallel processing (specifically Solana and Tron), enable parallel processing for up to four transactions. This configuration typically requires two withdrawal wallets per 1 TPS.

Blockchain-specific guidance

EVMs

Fireblocks supports advanced nonce management for EVMs to improve transaction latency and throughput. If a transaction fails and is not mined, its nonce can be reused by the next transaction from the same wallet, preventing the transaction chain from getting blocked.

Monitor transactions closely and identify any stuck in a confirming state from the same wallet. This is usually caused by a stuck low-fee transaction. Boosting or replacing the transaction via RBF allows the next transaction to be pushed to the chain. Identifying such situations early is critical; otherwise, you may submit multiple transactions with low fees, causing a backlog.

🚧

Watch for delays due to fee spikes

Some node implementations enforce per-address submission limits when transactions have low fees, long nonce chains, or unconfirmed dependencies. Although the Fireblocks framework can retry dropped transactions, delays during fee spikes can cause low fees and additional stuck transactions.

We recommend having several withdrawal accounts and routing withdrawals uniformly across them. Using five to six wallets enables approximately 1 TPS throughput.

UTXOs

Under the current design, a UTXO wallet can serialize a single transaction at a time. In some cases, unconfirmed change outputs are reused in subsequent transactions, which can result in a stuck wallet if:

• A transaction is not mined due to low fees.
• The dependency chain reaches the maximum chain length of 25 unconfirmed transactions (common in Bitcoin nodes), causing new transactions to be rejected.

To avoid this situation, use one or more of the following methods:

• Batch withdrawals using multi-destination transactions. Creating a batch every 30 seconds results in 20 transactions over 10 minutes, staying below the 25-transaction limit.
• Schedule sweeping or funding to withdrawal wallets to obtain multiple confirmed UTXOs, reducing reliance on unconfirmed change outputs.
• Use CPFP to release transactions stuck due to low fees. Apply CPFP before reaching the 25-transaction chain limit. (RBF support is planned for the future.)
• Use multiple withdrawal wallets, as described earlier.

In general, aim to balance the number of UTXOs. Too many UTXOs are harder to reconcile; too few can cause mempool congestion and unconfirmed transactions.

For Bitcoin, we recommend holding two to three withdrawal wallets and batching withdrawals in 30-second windows.

For additional details on UTXO selection logic and filtering, see Select UTXOs.

Solana and Tron

On Solana, Fireblocks supports parallel transaction serialization per wallet using durable nonces, with up to 1,000 concurrent transactions in non-finalized states. Fee payer transactions and support for transactions without durable nonces are planned for the future.

For Tron, parallel serialization of transactions per wallet is planned by EOQ2, with support for up to 600 concurrent non-finalized transactions.

🚧

You need multiple Co-signers for high-throughput setups

High-throughput setups require multiple Co-signers that can handle parallel traffic. Additional Co-signers can be configured as needed.

Stellar

Stellar uses sequence numbers and allows only one transaction per account per ledger (created every 5 seconds). As a result, throughput from a single wallet is limited. We recommend creating approximately 10 Stellar withdrawal wallets per 1 TPS. Fireblocks is considering support for channel accounts to enable better throughput and latency.

Confirmation policy

Blockchain confirmations verify transactions while preventing fraud and double-spending. However, the confirmation threshold directly affects how quickly funds become available: the higher the threshold, the longer the delay.

For internal operations like sweeping or reconciliation, you can define a low confirmation requirement. Setting confirmations to 0 means:

• On Bitcoin-based chains and EVMs: the transaction is considered complete once it enters the mempool.
• On other chains: the transaction is considered complete immediately once included in a block.

On Bitcoin-based UTXO chains, setting confirmations to 0 also allows the resulting UTXOs to be immediately used in subsequent transactions.

For more information, see Deposit Control & Confirmation Policy.

Transaction batching

Transaction batching lets you consolidate multiple withdrawal requests into a single transaction with multiple destinations, minimizing fees. Because a batched transaction carries a single set of metadata, it is more cost-effective than multiple individual transactions. Fireblocks supports transaction batching for UTXO-based assets, Solana, and SPL20 tokens.

Batching does require collecting multiple user requests over a set period (for example, every X minutes) before processing them together. This approach reduces fees but may introduce slight delays for users expecting immediate withdrawals. The right batching interval depends on your withdrawal volume and user experience requirements.

Fireblocks supports creating a single transaction with multiple destinations using the Create a new transaction endpoint by passing the destinations array, which contains separate destination objects. For more information, see Multiple destination transfer.

Working with One-Time Addresses

By default, outgoing transactions in Fireblocks can only be made to whitelisted addresses approved by the Workspace's Admin Approval Quorum. For businesses looking to scale their withdrawal flows and eliminate manual processes, this can become cumbersome.

To address this, Fireblocks introduced the One-Time Address (OTA) feature. OTA allows you to interact with non-whitelisted addresses, streamlining the withdrawal process. For more information, including security considerations, see Work with One-Time Addresses.

Idempotent transactions

In RESTful APIs, idempotency means that making the same API call multiple times produces the same result as making it once. For financial operations like withdrawals, this is critical; without it, repeated requests can result in duplicate transactions and cause significant discrepancies.

Fireblocks provides idempotency for transaction creation through the externalTxId parameter. When you include externalTxId in a Create a new transaction request, Fireblocks rejects any subsequent request using the same value with an HTTP 400 error:

{
  "message": "The external tx id that was provided in the request, already exists",
  "code": 1438
}

Unlike the Idempotency-Key header (which expires after 24 hours), externalTxId is stored permanently. Fireblocks rejects duplicate values even if the follow-up request is made more than 24 hours after the original.

For more information, see externalTxId and API Idempotency.