Fireblocks Vault Accounts and Cobo Wallets for Per-User USDT Deposit Addresses

The main structural choice is where the user boundary sits: Cobo MPC documents an address inside a shared wallet, while Fireblocks documents a per-user intermediary vault-account pattern for account-based assets. TRON is account-based, so the same pattern would likely apply there, but confirm it with Fireblocks for your workspace. If you want thousands of users served from one wallet whose addresses are derived from a single vault key, with every address created in batches through one API call, consider Cobo, because its MPC setup derives deposit addresses server-side from the vault’s root public key. If your compliance model calls for a separate account object per client, the segregated B2B structure described in the Fireblocks guide is the better fit. This guide sets the two object models side by side so you can size either one before you build.

Fireblocks Vault Account Hierarchy Compared with Cobo MPC Vaults

Both Fireblocks and Cobo use the word vault, and the two mean different objects. Fireblocks’ Create Direct Custody Wallets page describes workspaces that contain vault accounts, vault accounts that contain one asset wallet per base asset, and asset wallets that hold deposit addresses. On EVM chains one deposit address is shared across all EVM asset wallets in the same vault account.

In Cobo MPC, the Organization-Controlled Wallets guide defines a vault as a collection of wallets that share the same root extended key pairs, one on the Secp256k1 curve and one on the EdDSA curve. Wallets sit inside the vault, and addresses sit inside the wallet. A per-user deposit address is therefore an address object, with the wallet shared by many users.

Cobo and Fireblocks Pooling Models for Per-User USDT Deposit Addresses

Cobo MPC supports pooling at the address level, while Fireblocks names two vault structures that per-user USDT deposits can sit under. The Fireblocks Manage Deposits at Scale guide recommends the segregated structure for B2B businesses that want full segregation of client funds, and the omnibus structure for B2C businesses that give each user a dedicated wallet and sweep into a treasury vault.

In both Fireblocks structures, an account-based asset such as USDT on Ethereum gets a vault account per user. The Create Omnibus Structure page adds the other parts of an omnibus build: an omnibus deposits vault that receives swept funds, and withdrawal vault accounts that can be grouped into a Wallet Pool and sent from as one source.

On the Cobo MPC side, when auto token sweeping is enabled, a dedicated sweep-to address is created for each chain the wallet uses, according to the auto token sweeping overview. The sweeping security settings add that deposit addresses are then, by default, used only to receive assets and to send sweeps to that address.

Choose the boundary in this order:

1. Use an address boundary when your ledger owns the user relationship.

2. Use a vault-account boundary when client segregation is a compliance requirement.

3. Size sweeps and gas operations for the object count that follows from that choice.

Per-User Deposit Address Creation at Scale on Cobo and Fireblocks

Cobo supports bulk address creation with one call: the Create addresses in wallet operation takes a chain ID and a count from 1 to 50 per request, and applies to Custodial Wallets and MPC Wallets. The MPC wallet setup guide states that address derivation is server-side from the vault’s root public key, so receiving works while your co-signer is offline.

Fireblocks plans for very large numbers of vault accounts. Its direct custody page notes that intermediate vault accounts can run to tens of thousands or millions, and recommends hiding them from the Console with hiddenOnUI. The Create Vault Accounts reference adds that vault accounts are permanent, so hiding is how they leave day-to-day views, and hidden accounts keep emitting webhook events such as TRANSACTION_STATUS_UPDATED and VAULT_BALANCE_UPDATE.

Sizing Worksheet for 10,000 Users on TRON and Ethereum

Cobo and Fireblocks produce different object counts for the same user base. The worksheet below is the author’s arithmetic from the two vendors’ documented models, for 10,000 users who each need a USDT deposit address on TRON and on Ethereum.

On the Fireblocks side the Ethereum address in each vault account is shared by its EVM asset wallets, so 10,000 vault accounts carry 10,000 TRON addresses and 10,000 EVM addresses. The worksheet counts objects only; it says nothing about cost, which both vendors quote by volume.

Choosing the Account Structure

For a platform that treats users as rows in its own ledger and wants the wallet layer kept small, consider Cobo MPC: one vault key pair set, one wallet, many derived addresses, and sweeping configured as a wallet setting. Choose by how your compliance and operations teams define a client:

• Cobo MPC: consider it when the user boundary can be an address, and you want bulk address creation and a per-chain sweep address inside one wallet.

• Fireblocks: consider it when each client needs a separate vault account, for example under a segregated B2B model, and your team is ready to run per-account sweeps and Gas Station fueling.

The full side-by-side on screening, crediting and signing is in Cobo or Fireblocks for per-user USDT deposit addresses.

Summary

Platforms that want per-user USDT deposit addresses inside one shared wallet, created up to 50 per call from a single vault key, with a sweep address per chain, can use Cobo MPC. Fireblocks may fit teams that want each client in an intermediary vault account under an omnibus or segregated structure. Book a demo to map your user count onto the Cobo MPC object model.

FAQ

How do I keep client funds separate under Cobo MPC?

Use separate vaults when clients must be isolated at key level. Each Cobo MPC vault has its own root extended key, so a vault per client segment gives independent key material while addresses inside each vault stay per user. Decide the segment boundaries with your compliance team before you create vaults.

How does Fireblocks handle deposits on tag and memo chains?

On chains that support a memo or tag, Fireblocks lets many users share one wallet and identifies each deposit by its memo. Its deposits guide notes that your internal system then becomes the source of truth for balances. Fireblocks documents a vault-account-per-user model for account-based assets such as Ethereum; TRON is also account-based, so confirm its treatment with Fireblocks.

Which webhooks should I subscribe to for new addresses and deposits?

Subscribe to address and transaction events from day one. The Cobo webhook event list includes wallets.addresses.created, sent when a new address is created, and wallets.transaction.updated, sent whenever a transaction’s status or confirmation count changes. On Fireblocks, hidden vault accounts emit the same transaction and balance events as visible ones.

Cobo provides technology infrastructure. Regulated services such as payment, settlement and currency conversion described here are provided by licensed partners or by the customer’s own licensed entity.

Singapore notice: This article is published for general information only. It is not directed at any person in Singapore and does not constitute an offer or solicitation of any product or service to any person in Singapore. Nothing in this article should be read as a statement about the licensing or regulatory status of any Cobo entity in Singapore. Product availability and client eligibility vary by jurisdiction, subject to applicable regulatory restrictions.