Wallet Pools

Wallet Pools let you group multiple vault accounts under a single logical source and use that group to send transactions. Each Wallet Pool is a protected tag of a new type, giving it all the approval and governance controls that protected tags carry, plus the ability to route transactions across the vault accounts it contains. Instead of routing all withdrawals through one vault account, Fireblocks distributes transactions across the vault accounts in your pool, selecting a healthy vault account for each transaction.

This is especially useful for high-volume operations such as retail withdrawals, where a single vault account can become a bottleneck under load.

Why use Wallet Pools

When a single vault account handles a high volume of outgoing transactions, it can run into nonce congestion on EVM chains. A stuck transaction blocks every subsequent transaction from that vault account until it resolves, which can cascade into significant delays.

Wallet Pools address this by:

• Distributing transactions across multiple vault accounts so no single vault account is overloaded
• Routing around congested vault accounts automatically
• Improving privacy by rotating across multiple on-chain addresses rather than always using the same wallet
• Eliminating the need to build custom vault rotation logic in your own infrastructure

How it works

When you submit a transaction using a Wallet Pool as the source, Fireblocks:

1. Identifies all vault accounts in the pool that hold the requested asset and have sufficient available balance.
2. Queries Account Traffic Control (ATC) to determine which vault account is healthiest at that moment.
3. Routes the transaction through the recommended vault account.
4. If ATC is unavailable, falls back to balance-based scoring: the vault account with the fewest locked transactions and the highest available balance is selected.

The transaction response includes both the pool identifier and the resolved vault account ID, so you always know exactly which vault account was used.

Health-aware routing

Fireblocks monitors vault account health in real time using Account Traffic Control (ATC). When a transaction is submitted through a Wallet Pool, ATC groups vault accounts by health state and selects from the best available tier. Healthy vault accounts are tried first; if none are available, degraded vault accounts are used; blocked vault accounts are used as a last resort.

Within each health tier, Fireblocks selects vault accounts by round-robin. Health-aware routing is currently supported for EVM chains. For non-EVM chains, vault account selection falls back to balance-based round-robin.

Setting up a Wallet Pool

Prerequisites

• Owner, Admin, Non-Signing Admin, or Editor role
• At least two vault accounts holding the asset you plan to use
• Protected Tags feature enabled in your workspace

Creating a pool

You can create a Wallet Pool from two places in the Console.

From the Tags page

1. In the Fireblocks Console, go to Settings > Tags in the Fireblocks Console (Utilities > Tags in some workspaces).
2. Select Create Tag.
3. Enter a name, optional description, and color for the tag.
4. Under tag type, select Wallet Pool.
5. Select Create. No approval is required to create a pool.

From the vault account view

1. In the Fireblocks Console, go to Accounts > Vault and find the vault account you want to add to the Wallet Pool.
2. In the Tags column, select +.
3. Enter the name you want to give the Wallet Pool tag, then select Create [name] tag.
4. Under tag type, select Wallet Pool.
5. Enter an optional description and select a color for the Wallet Pool tag.
6. Select Create tag. No approval is required to create a pool.

Pool names must be unique across your workspace. A name already in use by a protected tag is unavailable for a pool, and vice versa.

Adding vault accounts to a pool

You can add vault accounts to a pool from two places in the Console.

From the vault account view

1. In the Fireblocks Console, go to Accounts > Vault.
2. Find the vault account you want to add to the pool, then select + in the Tags column.
3. Select the Wallet Pool tag you want to use for the vault account.
4. Select Apply.

From the Tags page

1. In the Fireblocks Console, go to Settings > Tags (Utilities > Tags in some workspaces).
2. Locate the Wallet Pool tag and select + in the Attachments column.
3. Select the vault accounts you want to add.
4. Submit for approval. Adding vault accounts requires quorum approval from authorized signers.

Vault accounts are appended to the pool in the order they are added. The round-robin sequence follows this order.

Removing vault accounts from a pool

You can remove vault accounts from a pool from two places in the Console. Removing a vault account from a pool requires Owner, Admin, or Non-Signing Admin approval.

From the vault account view

1. In the Fireblocks Console, go to Accounts > Vault.
2. Find the vault account you want to remove from the pool, then hover your pointer over the Wallet Pool tag and select X to remove it.

From the Tags page

1. In the Fireblocks Console, go to Settings > Tags (Utilities > Tags in some workspaces).
2. Locate the Wallet Pool tag and then select + in the Attachments column.
3. Under Attached entities, select the X on a vault account to remove it from the pool.

When a vault account is removed, all vault account positions in the pool are recalculated and the routing pointer resets.

Renaming or deleting a pool

Renaming and deleting a pool both require quorum approval. A pool cannot be deleted while it still contains vault accounts. Remove all vault accounts first, then delete the pool.

Sending a transaction through a Wallet Pool

Via API

Send a POST request to /v1/transactions with the source type set to WALLET_POOL:

{
  "assetId": "ETH",
  "amount": "0.5",
  "source": {
    "type": "WALLET_POOL",
    "id": "<poolId>"
  },
  "destination": {
    "type": "ONE_TIME_ADDRESS",
    "oneTimeAddress": {
      "address": "0xRecipientAddress"
    }
  }
}

The response includes source.resolvedVaultId, the vault account that was used to send the transaction. Use this for reconciliation and auditing.

Testing vault account selection without sending a transaction

Use the dry-run endpoint to see which vault account would be selected for a given pool, asset, and amount, without creating a transaction. This is useful for validating your pool configuration before going live.

Send a POST request to /v1/wallet-pools/{poolId}/optimal-vault with the asset and amount:

{
  "assetId": "ETH",
  "amount": "0.5"
}

Vault account membership and approval flows

The following actions require quorum approval from authorized signers:

Approval requests appear in the Fireblocks mobile app and Console under Pending Approvals, the same as all other protected tag operations.

Using Wallet Pools in Policies

Because each Wallet Pool is backed by a protected tag, you can reference it directly in your Policy rules. At transaction submission time, Fireblocks evaluates the pool used as the source and applies any matching rules before the transaction proceeds. In the Policy rule builder, Wallet Pools appear as a distinct source type under Wallet Pools, separate from other protected tags.

Common patterns include:

• Require approval above a threshold. Allow transactions from a retail withdrawal pool to proceed automatically up to a set amount, and require 2-of-3 approval for anything above it.
• Restrict destinations by pool. Allow transactions from a given pool only to whitelisted external addresses, blocking any attempt to route funds to an unrecognized destination.
• Enforce signing requirements per pool. Require that transactions sourced from a treasury pool always carry a signature from a designated co-signer, regardless of amount.
• Separate operational pools from settlement pools. Apply different approval chains to your day-to-day operational pool and your end-of-day settlement pool without duplicating rules for individual vault accounts.

Example: tiered approval by pool

Create separate pools for retail withdrawals, institutional transfers, and treasury settlements. In your Policy rules, set the retail withdrawal pool to auto-approve transactions under a low threshold, the institutional pool to require 1-of-2 approval for any amount, and the treasury pool to require 2-of-3 approval with a designated co-signer. As your vault inventory grows, add new vault accounts to the relevant pool. The Policy rules stay fixed.

Why use pools instead of vault account IDs

Policy rules and transaction routing logic written around individual vault account IDs break as your vault inventory grows. Every time a vault account is added, removed, or rotated, you need to update both your rules and your routing code. With Wallet Pools, the pool is the stable reference. Add or remove vault accounts from the pool through the approval flow, and both routing and policy enforcement update automatically, with no rule edits required.

This also means your Policy rules remain auditable over time. The rule references a named pool with a governed membership, rather than a list of vault account IDs that can drift out of sync with what the rule was originally intended to cover.

Monitoring your pool

To see the health and composition of a pool, open any vault account in the Wallet Pools widget, select the more actions menu (⋮) next to the pool, and select Vault breakdown.

For transaction-level detail, use the transaction history and filter by pool. Each transaction record shows the pool and the resolved vault account, giving you a full distribution picture over time.

Considerations and limitations

• EVM chains only for health-aware routing. On non-EVM chains, vault account selection falls back to balance-based round-robin. Full health-aware routing for non-EVM chains will be added in a future release.
• A vault account can belong to multiple pools. If a vault account is shared across pools, its health state is shared as well. High transaction volume from one pool can affect vault account health as seen by another pool.
• Pool names are unique workspace-wide. Names are shared across pools and protected tags, so a name already in use by a protected tag is unavailable for a pool.
• Vault account removal resets routing. Removing a vault account recalculates all positions and resets the round-robin pointer to the first vault account.

Troubleshooting

Transaction rejected: insufficient balance

None of the vault accounts in the pool hold enough of the requested asset to cover the transaction amount. Top up vault account balances or reduce the transaction amount.

Transaction rejected: asset not found in pool

None of the vault accounts in the pool hold the requested asset. Verify that the vault accounts in your pool are set up with the correct asset and try again.

I don't know which vault account sent a transaction

Check the transaction detail in the Console or API response. The source.resolvedVaultId field in the API response and the vault account name shown in the Console activity panel both identify the vault account used.

Related articles

• Account Traffic Control
• Protected Tags
• Policies
• Manage Vault Accounts
• Gasless Transactions