Overview

The Fireblocks platform consists of workspaces, vault accounts, asset wallets, and deposit addresses. This diagram shows the overall account structure in Fireblocks and the underlying wallet structure.

At the top level, your various Fireblocks workspaces are contained within the logical group called the Customer Domain. These workspaces may be "hot" (online) or "cold" (offline).

In your Fireblocks workspace, you can create and manage multiple vault accounts. These vault accounts contain your asset wallets. Each vault account can have a single wallet per base asset (e.g., BTC, ETH, SOL), but each wallet can have one or more deposit addresses.

📘

You don't need separate wallets per token for EVM chains

For EVM chains, one wallet covers all tokens on that chain. You do not need separate wallets for each token on the chain. Asset wallets for individual tokens are created automatically, as described below.

For UTXO-based assets, such as Bitcoin, a single wallet may generate one or more deposit addresses. For account-based assets, there are two options:

• Account-based assets without tag/memo support, such as ETH, can only generate one deposit address.
• Account-based assets with tag/memo support, such as XRP, can generate one or more deposit addresses. Each deposit address has the same on-chain address. However, they differ by their tag/memo.

Automatically generated asset wallets

EVM

• On EVM chains, a single deposit address is shared across all EVM asset wallets in the vault account, regardless of chain or token.
• Asset wallets are auto-created when an asset is transferred to a deposit address in a vault account that doesn't yet contain that asset wallet. Applies to all globally listed EVM assets.
• For non-globally-listed assets: user must first add the asset via the Add Asset API endpoint, after which auto-creation applies.

Solana

• Each token requires its own on-chain token account in addition to the Fireblocks asset wallet.
• The vault account uses the base Solana address as deposit address.
• When a token wallet is created via API or Console, Fireblocks creates an internal representation only. No on-chain transaction at that point.
• Token account is created on-chain on the first incoming transaction; sender covers the rent cost.
• When the asset wallet is created due to an incoming transfer, the token account already exists on-chain.

Types of vault structures

Fireblocks recommends structuring your vault accounts using one of two methods: omnibus or segregated. The diagram below describes the advantages and disadvantages of each structure.

Omnibus structure

The omnibus structure consists of a central vault account, deposits vault account for UTXO and Tag/Memo based assets and vault accounts for each end-client for account based assets.

Funds are deposited into the individual vault accounts or to the deposits vault account, depending on the asset type, and then swept to the central vault account, where the funds can be invested.

Address creation flows

For extended documentation, see Best Practices for Structuring Your Fireblocks Vault . Some notes on the information presented in the Help Center article:

• Omnibus and segregated account structures are independent of whether you have a hot or cold workspace. Both account structures can be implemented in either workspace type.
• Workspaces can contain both an omnibus and segregated account models. There is no limitation for a workspace to contain one specific account model.

Omnibus address creation (UTXO)

• The end user, Alice, asks to deposit a UTXO asset, such as Bitcoin (BTC).
• The customer’s front-end application creates a new deposit address in the Omnibus vault account.
• This deposit address is assigned to Alice and mapped accordingly within the customer’s private ledger.
• Alice receives a notification from the front-end system with her assigned deposit address, where she can start depositing funds.

Omnibus address creation (account-based with tag/memo support)

• The end user, Alice, asks to deposit an account-based asset that supports tag/memo fields, such as Ripple (XRP).
• The customer’s front-end application creates a new deposit address in the Omnibus vault account.
• This deposit address is assigned to Alice and mapped accordingly within the customer’s private ledger.
• Alice receives a notification from the front-end system with her assigned deposit address, where she can start depositing funds.

Omnibus address Creation (account-based)

• The end user, Alice, asks to deposit an account-based asset, such as Ethereum (ETH).
• The customer’s front-end application creates a new intermediate vault account and a wallet with a deposit address within it.
• This deposit address is assigned to Alice and mapped accordingly within the customer’s private ledger.
• Once mapped and credited, Alice receives a notification from the front-end system with her assigned deposit address, where she can start depositing funds.

📘

A single EVM address covers all tokens

For EVM assets, the vault account's single EVM address covers all tokens. You only need to create the vault account, not an individual asset wallet per token.

Segregated structure

The segregated structure consists of individual vault accounts for each end client. Funds are stored in and invested from these individual accounts.

Address creation flows

There’s no difference between UTXO and account-based assets when dealing with the segregated account structure. For both, the process is as follows:

• The end user, Alice, asks to deposit some assets.
• The customer’s front-end application creates a new vault account if it does not exist or reuses an existing vault account dedicated to Alice. For EVM and Solana assets, there is no need to create a wallet; it will be created automatically when Alice's first deposit is detected.
• Alice receives a notification from the front-end system with her assigned deposit address, where she can start depositing funds.

Hiding vault accounts

When you create intermediate vault accounts for end users, your workspace can quickly accumulate a large number of them. Sometimes tens of thousands, sometimes millions.

Having all of these accounts visible in the Fireblocks Console creates two problems. First, it degrades console performance. Second, every transaction to or from these accounts appears in the Recent activity panel, which can flood the interface with notifications when deposits are frequent. Since intermediate vault accounts are managed through the API anyway, it makes sense to hide them from the Console.

You have two ways to do this, both through the Fireblocks API:

• Hide a vault account at creation. Pass the optional hiddenOnUI parameter when calling the Create a new vault accounta endpoint.
• Hide an existing vault account. Use the Hide a vault account in the Console endpoint for any account that wasn't hidden at creation.

Hidden vault accounts are not gone. All transactions and balances remain fully accessible through the API.