USDT on Tron
One chain, one token, six decimals. Addresses are registered and confirmed before they can receive.
USDT on Tron (TRC-20) is the only chain and the only token this API moves. There is no Ethereum, no BSC, no other stablecoin.
Sending on the wrong chain loses the funds
A transfer of USDT on any other network, or of any other token on Tron, cannot be credited and cannot be returned. Check the network in your wallet before every send.
Precision
Six decimal places, exactly — Tron USDT's own precision. Every amount on the
wire is a decimal string with 6 places ("250.000000"), never a JSON number.
See Money.
Registering a wallet to receive USDT
This is for outbound USDT sends (POST /v1/usdt/sends) — moving USDT out of
your own balance to a destination you name — not for a buy order. A buy
order's own delivery is decided by your account's wallet kind
(credited to your USDT balance by default, or sent to a wallet OnLink
provisions for you); see Buy USDT with KES
for that. This section is the registration flow behind the send rail.
Two independent approvals make an address deliverable:
POST /v1/walletsregisters the address —pending_partner_approval.- A partner admin, registered first via
POST /v1/admins, confirms it with a 6-digit code we email them:POST /v1/wallets/{id}/confirm—pending_onlink_approval. - OnLink's own review clears it —
active. Onlyactivemay receive value.revokedis terminal.
Confirm an address once. Confirming it again, after it has reached
pending_onlink_approval or active, answers 409 WALLET_ALREADY_CONFIRMED
with the address's current details.status and a details.nextStep: your
approver's confirmation is already recorded, so do not register the address
again. A revoked address answers 409 WALLET_REVOKED. See
Errors.
An address that has not reached active cannot receive a send: it is refused
with USDT_SEND_DESTINATION_NOT_ALLOWLISTED. The two independent approvals
exist so that a typo'd address, or one nobody at your organisation actually
meant to register, is caught before value moves rather than after. See Send
USDT from your wallet for the full
send flow.
Sending USDT to us
Every partner has a long-lived Tron deposit address, published at GET /v1/funding. Where we hold your USDT for you, sending to it tops up your USDT
balance generally — it is not tied to any one order. Where your USDT is in
your own wallet, the address is that wallet. GET /v1/usdt/holding-wallet tells
you which applies and what a deposit to the address does (see Where your USDT is
held).
Your deposit address is long-lived and shared across your orders
The same address serves every purpose that needs one, so the address alone
cannot tell two deposits apart. Where we hold your USDT, an arrival credited
to your balance raises usdt_credit.received; an arrival held for review
raises nothing unless it is credited. Where your USDT is in your own wallet,
an arrival in that wallet raises usdt_credit.received. If a sell order's own
collection also matches this deposit to it, you also receive
order.funds_confirmed for that order. See Sell USDT, receive
KES for how a sell order's own USDT is
taken — it is a different flow from this general top-up.
Finality
A deposit is credited once it is confirmed on-chain. For a sell order created
against a wallet OnLink collects on your behalf, that confirmation is what
moves the order on and sends order.funds_confirmed.
Cut-off times
Which Kenyan rails observe a banking day and which never close, why we do not publish a clock time, and how to find the one that applies to your account.
FX
KES against USDT, quoted off a live rate, and USD to KES conversions on the collections product. When we cannot price, we decline rather than guess.