USDT onboarding, without the parts that lose money
Most lost stablecoin deposits are not technical failures. They are a correct transfer of the right ticker on the wrong network, or to an address that was never a deposit address. This page describes what has to happen for a deposit to become a usable balance, and what HyperMatch does at each step.
1. The same ticker is several different tokens
USDT and USDC are names, not single objects. Each network carries its own contract, issued under its own arrangement, and those contracts are not interchangeable even when the ticker on your screen is identical.
HyperMatch holds custody balances on one Ethereum L2 network only, in two assets: USDT and native USDC, both six decimals. The USDT there is not Ethereum-mainnet USDT, and native USDC is not a bridged copy of USDC. Each is tracked as its own balance; nothing is renamed one-for-one in the ledger. The exact network, the token contracts and your address are shown only on the deposit page after sign-in: send exactly as shown there, because a transfer on the wrong network may not be recoverable.
- A token contract address identifies an asset. It is never a deposit address, and sending funds to one does not credit anything.
- The network you send on is part of the address’s meaning. The same characters can be a valid address on several chains and a deposit on only one of them.
- Deposits on TRON are not supported as a custody rail. A TRON address may appear in a cross-chain refund path, which is a different thing entirely.
2. A deposit address is issued, not guessed
Each account is given a personal deposit address, derived and provisioned by an isolated custody service, permanently bound to that account and never reassigned to anyone else. It is shown only once the funding rail reports that it is ready.
Readiness is measured rather than declared. A configuration flag alone cannot make the rail ready; the service has to be reachable, reconciled, funded for gas and consistent with the observed on-chain balance.
- Blocking conditions are named explicitly, including reconciliation required, custody signer unavailable, stale or unhealthy worker, gas funding required, and stale or mismatched custody balance.
- Because the state is measured, the answer can legitimately be that no address can be issued right now. Your account page is the authority on that, not this page.
3. Credit waits for finality, not for a number of blocks
A balance is credited only after an independently verified, canonical, finalized token transfer receipt for that exact address and asset. A fixed confirmation count is not used as a substitute, and no confirmation number is published here, because on this network a block count is not what finality means.
Crediting and sweeping are separate. Moving a received deposit from the personal address into a hot wallet requires its own finalized proof and creates no additional customer credit. If reorganisation evidence appears, the rail freezes rather than silently rewriting balances that were already credited.
4. Somebody has to pay gas
A plain token transfer is a transaction on a chain, and the sender pays that chain’s native fee. Holding only stablecoins and no native token is the most common reason a first deposit cannot be sent at all.
There is a second route for supported wallets. A signed authorization under the token standard for transfer authorizations lets a wallet approve one exact transfer, to one exact recipient, with a short expiry and a single-use nonce, and HyperMatch submits it and pays the network fee.
- That route is available for specific verified combinations of token, chain and wallet type, for externally owned accounts, within a per-transfer range of 1 to 50 tokens and a daily budget. It is not a general property of stablecoins.
- Ethereum-mainnet USDT does not implement that authorization standard at all, so the route does not exist there.
- The authorization is bound to an amount, a recipient and an expiry. It is not an open spending approval and it cannot be reused.
5. Arriving from another chain is a swap, not a transfer
Funds coming from a different network do not travel; they are exchanged. A provider receives an asset on the origin network and delivers a different asset on the destination network, at a rate quoted for a moment in time. The destination here is always native USDC on the platform’s custody network, at the customer’s own custody address.
Quotes are bounded on purpose: a size range, a decimal limit, a slippage tolerance, a maximum acceptable quoted loss, and a short quote lifetime after which the quote is refused rather than silently re-priced. A deposit address is only issued against an accepted quote, bound to that customer and that network.
- A quote is not an offer. An address left open can re-price when funds actually arrive, so an earlier minimum does not bind a late or repeated deposit.
- A provider reporting success cannot create a balance. Credit still comes only from the ordinary finalized on-chain check, which is what stops a provider message from minting money.
- Refunds are returned to a recovery address held for that customer, never to an exchange hot wallet, and are shown as requiring recovery rather than as a completed withdrawal.
6. Converting one stablecoin into the other
The USDT balance can be converted into native USDC on the same network. The conversion is an exact-input swap on a pinned decentralised exchange deployment, on the lowest fee tier, with a guard that rejects the trade if the two stablecoins have drifted from parity by more than one percent, and a minimum-received floor set just under the quoted amount.
Conversion is an explicit action with a quoted result you accept. The two balances stay distinct until you do it; nothing is quietly relabelled.
7. Withdrawal is a sequence, and the order matters
A withdrawal is quoted with a short fixed lifetime, then confirmed with a signature or passkey bound to the exact amount, asset and recipient, then reserved against your balance, then broadcast exactly once, then confirmed against the chain.
Exactly one transaction identifier is committed before anything is sent externally. A duplicate acknowledgement is idempotent, a replacement identifier is rejected, and a send with an unknown outcome holds reservations and blocks further dispatch instead of trying again. Retrying a possibly-completed payment is how one withdrawal becomes two.
- Destinations must be external. A managed custody address is rejected as a withdrawal target.
- A withdrawal needs both an available customer balance and swept hot-wallet liquidity. Those are different constraints and either can block it.
- A request being accepted is not the same as funds arriving. Paid status requires a fresh, independently verified, finalized transfer that matches the request.
8. Custody, stated plainly
The funding account is platform custody. HyperMatch holds the keys to the deposit and hot wallets, and withdrawals depend on HyperMatch’s signing and settlement services being available. This is not a self-custody arrangement and should not be read as one.
A block explorer can show what a particular address holds. It cannot show total obligations to all customers, so an address balance is not a solvency proof.
Where the funding rails stand today
Availability is measured by the service and can differ from this summary. Your account page is the authority.