The Deposit Control & Confirmation Policy lets you specify how many blockchain network confirmations are required for an incoming transaction to clear so its funds can be credited to a wallet. Until an incoming transaction clears, its deposit amount is locked in either inflow or outflow state. Learn more about balance states.
After it clears, its deposit amount is accounted for in the wallet’s currently available balance. Additionally, for UTXO-based blockchain networks, the transaction’s outputs become immediately spendable.
Your workspace uses the default Deposit Control & Confirmation Policy automatically. The default policy requires:
- 372 confirmations for all transactions made on the Ethereum Classic blockchain network. As this blockchain network is subject to a 51% risk of attack, we recommend a high amount of confirmations.
- These blockchain networks have a finality property and don't rely on a variable number of confirmations. The default policy contains the correct value for these blockchain networks and can't be changed.
- Algorand: 1
- Astar: 2
- Base: 1
- Berachain: 1
- Celestia: 1
- Chiliz 2.0: 1
- EOS: 2
- Hedera: 1
- Kusama: 2
- Kava: 2
- NEAR: 1
- Osmosis: 1
- Polkadot: 2
- Ripple: 1
- Solana: 1
- Stellar: 1
- Terra: 2
- Terra Classic: 2
- WeMix: 1
- For all other blockchain networks, all deposits, including transfers between Vaults, require 1 confirmation.
- Contract call operations require 3 confirmations.
You cannot specify a custom number of confirmations for blockchain networks with a finality property, as listed above. If you list and modify the value set for them, Fireblocks Support will require you to submit a revised policy that does not include these blockchain networks.
You can override the default Deposit Control & Confirmation Policy by creating your own policy. Download the Deposit Control & Confirmation Policy template, then modify it according to your organization’s business needs and risk models. For example:
- You can enter zero or a small number if you want faster confirmations for known and trusted sources.
- You can enter a higher number if you want to help mitigate risks for unknown or untrusted sources.
When setting custom rules for your confirmation policy, please note the restrictions on the minimum, maximum, or fixed number of confirmations that Fireblocks allows for certain blockchain networks.
The Deposit Control & Confirmation Policy operates on a first-match basis rule set using the following parameters:
|Source||This parameter defines the type of venue from which the transaction originates. This can be specific, such as a vault account; groups of accounts, such as all your Binance accounts; or general, such as all exchanges, all Fireblocks Network connections, and so on.|
|Destination||This parameter defines the type of venue where the transaction transfers its specified amount. This parameter uses the same values as the Source parameter.|
|Amount||This parameter defines the minimum or maximum amount a transaction must be before the rule applies to it. This parameter can be set to:
This parameter defines the type of asset sent in a transaction. This parameter can be set to a specific asset or to include any asset supported by Fireblocks.
Asset can be set to Any. However, if a specific asset is listed, a blockchain must be specified for the asset.
Asset can be listed in one of the following formats:
Many assets have similar symbols and names. The asset ID or contract address is recommended if your confirmation policy includes different rules for many specific assets.
This parameter defines the blockchain network where any specified asset is transferred. For example, you must define whether a rule applies to USDC transactions on Avalanche, Ethereum, or any other relevant blockchain.
You can only enter blockchain networks currently supported by Fireblocks in this field, including testnet blockchain networks.
|# of Confirmations||
This parameter defines the number of confirmations required for a transaction to clear and for funds to be credited to a wallet.
This parameter can be set to:
The table below contains some generic examples of Deposit Control & Confirmation Policy rules. It takes a few of the recommended confirmation numbers above and applies them to the policy template, along with a brief explanation of each rule below the table.
|Rule #||Source||Destination||Amount||Asset||Blockchain Network||# of Confirmations|
- Incoming ETH transactions of any amount on the Ethereum Classic blockchain network require 500 confirmations. As this blockchain network is subject to a 51% risk of attack, we recommend a high amount of confirmations.
- Transferring any amount between vaults within this Fireblocks workspace on any blockchain network requires 0 confirmations.
- Litecoin withdrawal transactions from the connected Coinbase Exchange third-party account into the Fireblocks vault require the minimum allowed confirmations, which is 6 confirmations.
- Incoming BTC transactions above $10,000 on the Bitcoin blockchain network require 6 confirmations.
- Incoming BTC transactions up to $10,000 on the Bitcoin blockchain network require 3 confirmations.
- Incoming USDC transactions of any amount on the Avalanche blockchain network require 7 confirmations.
- Incoming USDC transactions of any amount on the Ethereum blockchain network require 6 confirmations.
- Incoming transactions from any source to any destination in your Vault of any amount on any blockchain network require 1 confirmation.
Blockchain confirmation limitations
Certain blockchain networks require a minimum number of confirmations. You cannot enter 0 confirmations for these blockchain networks.
- All EVM-compatible blockchain networks require a minimum of 1 confirmation.
Certain blockchain networks have a maximum number of confirmations.
- 30 confirmations maximum: Arbitrum, Arbitrum Testnet, Astar, Avalanche, Avalanche Testnet, Berachain, Binance Smart Chain, Binance Smart Chain Testnet, CELO, CELO Testnet ALF, CELO Testnet BAK, Chiliz, Chiliz 2.0, Coinbase, eCredits Testnet, Ethereum Testnet Goerli, Ethereum Testnet Sepolia, EthereumPoW, Fantom, HOM Testnet, HT Chain, HT Chain Testnet, Kava, KUB Bitkub, KUB Bitkub Testnet, Moonbeam, Moonriver, Optimistic Ethereum, Ronin, RSK Smart Bitcoin, RSK Smart Bitcoin Testnet, Smart BCH Testnet, Songbird, Songbird Legacy, WeMix, XinFin
- 100 confirmations maximum: Cosmos Hub, Ethereum
- 300 confirmations maximum: Polygon, Polygon Mumbai, Polygon zkEVM
- 1200 confirmations maximum: Ethereum Classic, Ethereum Classic Testnet
If you're an advanced user, we recommend you modify the based on your organization's requirements for its overall safety strategy and faster, efficient trading. For example:
- For transfers between your Fireblocks vault accounts, apply 0 confirmations to all assets where applicable, since your vaults are under your close management, and you are therefore likely to submit the correct amounts.
- For deposits from external wallets to your Fireblocks vault, apply a high number of confirmations for all assets, in order to establish a higher level of certainty about the transaction, while the trade-off is more time for reaching transaction completion status. In addition, you can choose to apply a strategy of higher confirmation values for select assets of a particular blockchain. Some examples of higher-than-default values that align with some blockchain networks' confirmation behavior are:
- All assets on Bitcoin Cash (BCH): 6
- All assets on Bitcoin SV (BSV): 30
- All assets on Bitcoin (BTC): 3
- All assets on Dash (DASH): 3
- All assets on Ethereum Classic (ETC): 500
- All assets on Ethereum (Ethereum Proof-Of-Stake or ETH): 60 (ETH PoS 60 confirmations pertain to the number of blocks registered in the chain within a 2-epoch timeframe, which is the chain's finality time period)
- All assets on Ethereum Proof-Of-Work (ETHW): 30
- All assets on Litecoin (LTC): 6
- USDC asset on Avalanche (AVAX): 7
- USDC asset Ethereum (ETH): 6
- All assets on ZCash (ZEC): 12
- All assets on XDC Network (XDC, formerly XINFIN): 30
- ETH PoS 60 confirmations pertain to the number of blocks registered in the chain within a 2-epoch timeframe, which is the chain's finality time period.
- As a general rule, we recommend setting a higher-than-default number of confirmations in order to afford higher certainty about the transaction but bear in mind that the trade-off is more time for reaching transaction completion status.
Overriding the policy for specific transactions
If you attempt to set a transaction's confirmation threshold outside the limitations described above via the API you will receive the following error code:
400 1444 TRANSACTION_CONFIRMATIONS_NOT_COORDINATED_WITH_FIREBLOCKS_RESTRICTIONS