USDT Deposit Address per User: HD Wallet Derivation and xpub Architecture

Exchange wallets give each user a USDT deposit address by deriving it from one hierarchical deterministic (HD) wallet: a single root key, a BIP-44 path per user, and an extended public key (xpub) on the deposit service so new addresses appear without touching spendable keys. If you want that architecture with the root key split into MPC key shares and the derivation path stored next to every address, consider Cobo MPC, because its wallets derive deposit addresses server-side from the vault’s root public key and return each address with its derivation path. Teams that already run their own key management can keep an xpub-based design or use a wallet API such as Tatum’s. The per-user deposit address overview covers crediting and consolidation.

USDT Deposit Address Derivation Paths per User on TRON and Ethereum

Cobo MPC returns a BIP-44-style derivation path with each address, and the BIP-44 rules below are the reference a self-built exchange wallet uses. Cobo documents the meaning of each level in its own path reference, so check that page rather than assuming a self-built index scheme maps one to one. The BIP-44 specification defines five levels, m / purpose’ / coin_type’ / account’ / change / address_index, with hardened derivation on the first three. The coin type comes from the SLIP-44 registry, where Ether is 60 and Tron is 195.

USDT itself has no path of its own. A TRC-20 USDT balance sits on a TRON address and an ERC-20 USDT balance sits on an Ethereum address, so a user who deposits on both networks needs one derived address per network. TRON’s wallet developer guide gives the path as m/44’/195’/0’/0/index and describes the result as a 34-character Base58Check address starting with T.

On the Ethereum side, Cobo’s list wallet addresses reference notes that, for MPC Wallets, an address created on one EVM chain automatically works on the other supported EVM chains, so a single derived 0x address can receive ERC-20 USDT and its equivalents on other EVM networks.

USDT Deposit Wallet Architecture: xpub on the Deposit Service

With Cobo MPC, the separation an xpub design is built for stays in place: deposit addresses come from public key material, and spending needs the key share holders. Use the boundary this way:

1. Keep address derivation on the deposit service or wallet API.

2. Keep signing authority with the HSM, cold signer or MPC holder group.

3. Store the address and derivation path together so recovery can reproduce every user address.

In a self-built HD wallet, the deposit service holds the account-level xpub; an engineering write-up by Pratik Dhanave on HD wallets and deposit sweeping describes it as able to mint addresses while unable to spend, with the seed kept in an HSM or cold vault. Tatum’s address management guide follows the same pattern: create a master wallet, store the xpub, and derive each user’s address by index.

Cobo’s MPC wallet setup guide describes the MPC version of that boundary. Key generation gives the vault two root public keys, SECP256K1 and ED25519, and address derivation runs server-side from the vault’s root public key, so receiving continues while your co-signer is offline. Signing a withdrawal needs the key share holders: a group of at least two with a threshold of 2, one of them yours (a TSS Node or Cobo Guard).

Index Allocation and the USDT Deposit Address Record per User

Each address created on Cobo MPC is returned with its derivation path, which removes one bookkeeping step a self-built wallet has to get right.

In an xpub design, two rules from the Dhanave write-up carry most of the risk. Allocate the index atomically, through a database sequence or a transactional update, so two sign-ups never receive the same address. Store the address and its path together at the moment of allocation, so detection and signing can map any transaction back to the user.

Cobo’s create-addresses operation takes a chain ID and a count of up to 50 per request, and the response carries a path field that applies to MPC Wallets only, with a link to Cobo’s path-level reference. Your ledger then needs one row per user, chain, address and path.

A per-user deposit wallet has a property worth planning for. BIP-44 sets an address gap limit of 20 for account discovery, while a platform issues many addresses that stay unused for long periods. On our reading of the specification, a restore that relies on gap-limit discovery alone can stop before reaching later users, so the stored path list is the record that keeps every address recoverable.

Recovery of Every Per-User USDT Deposit Address

Cobo MPC supports recovery that works from the same path list. The open-source Cobo MPC recovery kits describe a tool that reconstructs the MPC key from the recovery group files and derives the child private keys of every wallet address. Its input is an address CSV file containing the HD derivation paths, which is the table your ledger already keeps.

A self-built HD wallet recovers from the seed backup plus the same path list. In both designs, recovery is as complete as the address records, so keep the export on the same backup schedule as the key material, refreshed whenever new users receive addresses.

Derivation Route Checklist: Self-Built HD Wallet, Wallet API or MPC Vault

Cobo MPC, a self-built HD wallet and Tatum’s APIs were compared on where address derivation runs, what the deposit service holds, who signs, and what recovery needs. Public documentation was checked on 20 October 2026. This checklist is our method for comparing derivation routes, not a ranking.

• Consider Cobo MPC when you want per-user addresses on TRON and EVM chains with the root key held as MPC key shares and the path recorded for every address.

• Consider a self-built HD wallet when you already operate an HSM and want full control of the derivation service.

• Consider Tatum when you want hosted derivation endpoints and will keep the mnemonic in your own key management service.

Summary

Platforms that want an exchange-style HD architecture for per-user USDT deposit addresses, with the root key split into MPC key shares, server-side derivation from the vault root public key, and a BIP-44 path stored with each address, can use Cobo MPC. Teams with an HSM and a derivation service can keep an xpub design, and teams that prefer hosted endpoints can derive through Tatum.

If the deposit service must not store an xpub, use an API that returns addresses while keeping derivation and signing material outside that service. Book a demo to walk through vault setup and address creation.

FAQ

Can one deposit address receive both TRC-20 and ERC-20 USDT?

One address covers one network family. TRC-20 USDT needs a TRON address on coin type 195 and ERC-20 USDT needs an Ethereum address on coin type 60, so create one of each for users who deposit on both, and store both rows under the same user ID.

What happens if the xpub on my deposit service is exposed?

The Dhanave write-up describes a read-only breach of an xpub-based deposit service as leaking addresses rather than money, because spending needs the private keys. Keep the xpub on the deposit service only, and treat the addresses under it as linkable to your platform once it has been exposed.

Can I create deposit addresses while the co-signer is offline?

Receiving continues in the MPC setup because derivation uses the vault’s root public key on the server. Withdrawals and sweeps wait for the signers, so schedule co-signer maintenance outside peak payout windows.

Which derivation path records should I keep for existing users?

Export the address and path for every user before you rely on recovery. Cobo’s address listing returns the path field for MPC wallets, so the export can be scripted and rerun after each batch of new users. The API listing is filtered by chain ID, so run the export once per chain rather than relying on a single EVM query.

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.