Per-User USDT Deposit Addresses (2026): Cobo Payments Top-Up Mode

USDT transfers on TRON and Ethereum carry no memo field, so a shared address cannot tell you which user paid; the exchange-style wallet architecture, a dedicated deposit address per user, is the attribution model that credits reliably at scale. If you want that model with automatic crediting, screening before the credit, and no key management to build yourself, Cobo Payments fits because its top-up mode issues a fixed address per payer, links each incoming transfer to that payer, and pushes a webhook when the funds are confirmed. Teams with their own key management and an engineering budget can instead derive addresses from an HD wallet and build the listener, ledger and sweep themselves, or use a wallet API such as Tatum’s. The steps below describe how the Cobo flow works and where the self-built path differs.

USDT Deposit Address Architecture: HD Wallet Derivation and Attribution Models

Cobo Payments uses the per-payer address model because it is the one that works with how USDT moves. LightningPay’s analysis of deposit attribution states that on TRON, Ethereum and Polygon a USDT transfer has three meaningful parameters, sender, recipient and amount, with no protocol-level reference field, so shared-address models depend on fragile off-chain matching. Its table rates a dedicated derived address per user as the model with the highest auto-credit reliability, rotating pools as good until reuse windows overlap, and shared address plus reference as weak on TRC-20 and ERC-20.

WARMKEY’s architecture note reaches the same conclusion from the reconciliation side: when the address itself is the payment identity, the ledger gets a direct link between user, address, chain, token and transaction hash, and support stops chasing missing remarks and screenshots.

Per-User Address Issuance in Cobo Payments Top-Up Mode

Cobo Payments generates one fixed address per payer and returns the same address on repeat calls, according to Cobo’s Payments documentation. A payer can deposit any amount at any time to that address. Addresses can be created in batches of up to 50 payers per request, and an address can be created for the same payer on another network so one user can deposit on more than one chain.

The Cobo Payments overview places this top-up mode alongside an order mode (a temporary address per order with a fixed amount and expiry) and a subscription mode. Two details save support tickets later. A payer’s address can be rotated, up to ten times per payer, and Cobo keeps listening on the old address with the old mapping intact. And only stablecoins on the supported list are credited automatically; other tokens sent to a top-up address raise an unexpected-deposit event and, once screened, go to your developer balance rather than the payer’s account, so your deposit page should state which tokens and networks are accepted.

Crediting Flow for Each User’s Deposit: Confirmation, Screening and Webhooks

With Cobo KYT or the Screening app enabled, Cobo Payments credits a deposit only after it has cleared screening, which is the step most self-built flows add last. According to the Payments documentation, incoming funds pass integrated AML/KYT screening first; a transfer that fails screening raises a failed-transaction event, and it is either credited after manual review or held and left uncredited. A transfer that passes triggers a completed-transaction event on your webhook carrying the payer, amount, token and transaction hash, which is all your ledger needs to credit the right account.

One threshold and one token rule are set by the product. Each token has a minimum deposit threshold (0.05 in Cobo’s example); deposits at or below it are not credited and send no webhook, which keeps dust out of the ledger. Supported stablecoins on supported networks are credited automatically; USDT on TRON and Ethereum are among them, and the live list is maintained in the Payments documentation.

Fireblocks’ deposits guide recommends the same webhook-driven credit and adds a caution that applies to any provider: validate the incoming balance before crediting the user, and keep an internal ledger, because deposited funds are often swept to another account soon after arrival.

Consolidation and Withdrawals After Credit

Cobo Payments consolidates the funds sitting on many payer addresses when you pay out. The documentation states that at withdrawal time Cobo automatically gathers the required funds from the dispersed addresses, so your team does not run a separate sweeping job for the top-up addresses. Withdrawals go out on-chain to an external wallet, in a Bulk Send to many addresses, or through an off-ramp partner to a bank account, each subject to the approval flows and transaction policies you configure in Cobo Portal.

Gas is handled at the same step. Billing Center (formerly Fee Station) pays gas in stablecoins and, on TRON, uses energy rental that Cobo states cuts gas costs by up to 80 percent, so a withdrawal does not stall because a payout wallet ran out of TRX.

Deposit Address Options Compared: Self-Built, Wallet API or Payments Product

Cobo Payments, a self-built HD wallet, Fireblocks and Tatum were compared on who issues the address, who credits the user, where screening sits, and who runs consolidation. Public pages were checked on 16 October 2026.

Choose Cobo Payments when you want issuance, screening, crediting and consolidation handled in one product and do not want to build your own key management for deposit addresses. Choose a self-built HD wallet or Tatum when you already run key management and want full control of the indexer. Choose Fireblocks when you are standardising on its workspace and will build the ledger and sweep logic its guide describes.

Frequently Asked Questions

Address reuse across chains

One payer gets one fixed address per network. The same payer can be given an address on another supported network, so multi-chain deposits stay attributed to the same account.

Deposits sent to the wrong network

Only stablecoins on the supported list for a given network are credited automatically. Publish the accepted token and network pairs on the deposit page and handle the unexpected-deposit webhook events for anything that arrives outside that list.

Address rotation and old balances

A payer’s address can be rotated up to ten times. Cobo continues to monitor the old address and keeps its link to the merchant, so a late deposit to a rotated address still credits correctly.

Testing before launch

Cobo’s documentation recommends subscribing to the transaction created and completed events, handling the failed event for screening exceptions, and testing the full flow on the development environment before going live, where no real fiat conversion takes place.

Summary

Cobo Payments suits platforms that want each user to have a fixed USDT deposit address with automatic crediting, screening before the credit, and consolidation handled at withdrawal, without building their own key management for deposit addresses. Teams that run their own key management can build the same model on an HD wallet or a wallet API such as Tatum’s, and Fireblocks users can follow its vault-per-user guide while building the ledger themselves. Book a demo to see the top-up flow on the development environment.

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.