The Tron network: how halfin settles TRC-20 payments

Tron is the network that carries an outsized share of the world's stablecoin payments, and TRC-20 USDT is the reason. This page is about the rail itself rather than the asset: how Tron produces blocks and reaches finality, what the TRC-20 standard is, why a transfer on it costs so little, and how halfin's Tron gate confirms an incoming payment and disburses one back out. If you already know you want to accept TRC-20 USDT, the question this page answers is what the network underneath that decision actually does.

Tron is a delegated proof-of-stake network

Tron does not mine blocks the way Bitcoin does, and it does not have the open validator set of a proof-of-stake chain like Ethereum. It runs delegated proof-of-stake: token holders vote for a fixed set of block producers — Tron calls them Super Representatives — and that elected set takes turns producing blocks in rotation. The producing set is small and known, which is the structural reason Tron blocks arrive quickly and at a steady cadence rather than at the variable intervals of a proof-of-work chain.

For a merchant, the consensus model matters only insofar as it shapes two things you feel at the checkout: how fast a payment shows up, and how confident you can be that it will stay. A small, rotating producer set gives Tron short, regular block times, so a customer's transfer is included in a block soon after they send it. halfin does not treat that first inclusion as final, though — a single block is a tentative observation, not a settled payment, and the gate waits past it before crediting your balance.

Because the producer set is elected by stake-weighted votes rather than open to anyone with hashpower, Tron's security and liveness rest on that set behaving honestly and staying online. That is a property of the network's design, not something halfin asserts or guarantees; what halfin does is apply a confirmation discipline on top of whatever the network delivers, so the amount you see as settled is an amount that has actually held.

Block production and how halfin treats finality

Tron produces blocks on a short, regular interval, and the elected Super Representatives confirm each other's blocks as the chain advances. In practice this gives Tron payments a fast, predictable confirmation feel: a transfer is visible in a block quickly, and the depth of confirmations behind it builds up at a steady rate. This is the property that makes Tron comfortable for the small, frequent payments stablecoins are used for — the payer is not left watching a spinner.

halfin does not credit a Tron deposit the instant it appears. The Tron gate watches your addresses, recognises an incoming transfer, and waits for Tron's confirmation threshold to pass before marking the invoice paid. Until that threshold is met the payment sits in a confirming state, surfaced to you as the invoice.confirming event, and only crosses to paid once it has held. This is the same confirm-then-credit discipline halfin applies on every chain it settles — the threshold is tuned per network, but the principle is identical across Bitcoin, the EVM chains, Solana, and Tron.

Crediting on Tron is reorg-aware. If the chain reorganises and unwinds a transaction the gate had tentatively seen, that is reflected rather than ignored — halfin does not leave a balance credited for a payment the network later dropped. The result is that a Tron payment you see as settled is one that reached the network's confirmation threshold and stayed there, which is what you want before you release goods or service against it.

TRC-20 is Tron's token standard

Most of the value that moves on Tron is not native TRX — it is tokens, and overwhelmingly the dollar-stablecoin USDT. TRC-20 is the token standard those assets follow: a common contract interface on Tron, comparable in role to ERC-20 on Ethereum, that defines how a token is transferred, how balances are read, and how approvals work. When you accept "USDT on Tron", you are accepting a TRC-20 token transfer that the Tron gate watches for and confirms like any other deposit.

The same dollar-denominated USDT also exists as an ERC-20 token on Ethereum and as an SPL token on Solana. These are independent deployments of the same peg on different networks: a customer's TRC-20 USDT balance cannot pay an Ethereum address, and vice versa. That is why "accept USDT" is incomplete until you name the network — and why Tron, as the network where a large share of USDT balances actually live, is so often the rail a customer reaches for.

halfin's Tron gate accepts native TRX as well as TRC-20 tokens, but the centre of gravity is the stablecoin. The table below is the real supported surface on this network — not an aspirational list — alongside how each settles.

Why a transfer on Tron costs so little

Tron does not price transactions with a single floating gas fee the way EVM chains do. Instead it has a resource model: accounts hold bandwidth and energy, and a transfer consumes those resources rather than charging a per-transaction fee directly. Bandwidth covers the basic cost of broadcasting a transaction; energy covers the computation a smart-contract call like a TRC-20 transfer requires. You can obtain these resources by staking TRX, which gives them back over time, or fall back to a small amount of TRX being burned when you have not staked.

The practical effect is the characteristic that makes Tron a stablecoin rail: a TRC-20 USDT transfer is cheap, often negligibly so, especially for an account that has staked for resources. That qualitative property — low transfer cost, paid in resources rather than a volatile fee — is what makes small-ticket and high-frequency payments economic on Tron when they would be uneconomic on a higher-fee chain. The network fee, whatever its form, is borne by the party sending the transaction; it is a property of the rail, not a halfin charge.

For a merchant accepting on Tron, the resource model is mostly invisible: the customer's wallet handles bandwidth and energy when they send you a TRC-20 USDT payment. It becomes relevant on the payout side, where halfin is the one sending TRC-20 transfers out to your recipients — and there the same low cost is what keeps disbursing to many recipients viable even at volume.

How halfin accepts and pays out on Tron

Accepting on Tron does not require a Tron-specific integration on your side. You create a fiat-anchored invoice the same way you would for any asset; the customer chooses to settle in TRC-20 USDT (or native TRX), and halfin presents the correct Tron address and amount. The Tron gate recognises the incoming transfer, waits for the network's confirmation threshold, and credits your balance — at which point a signed webhook tells your backend. Monetary amounts are strings end to end, never floats, and the network the payment settled on is recorded on the invoice so your reconciliation always knows it arrived over Tron rather than over Ethereum or Solana.

Tron is a payout rail as well as an acceptance rail. The same low transfer cost and fast confirmation that make it good for taking money make it good for sending it — affiliate commissions, creator earnings, gaming withdrawals, and other many-recipient operations are frequently paid in TRC-20 USDT precisely because recipients ask for it. halfin sends payouts over the Tron gate, so the chain you accept on is also one you can disburse on. Mass payouts fan out over the single-payout API, and each payout carries a caller-supplied idempotency_key field in the request body — so a timeout, a worker restart, or a re-run of a payout file never double-pays a recipient, which matters most on exactly this kind of high-volume rail.

The create call below commits to no network: it bills a flat fiat figure, and the customer's asset choice on checkout resolves the rail. The response and the subsequent signed webhook events carry the resolved asset and network. Verify the HMAC signature on any webhook before you act on it, and read the field schemas in the docs rather than guessing them.

curl -X POST https://api.thehalfin.com/api/v1/invoices \
  -H "X-API-Key: $HALFIN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "amount_fiat": "25.00",
    "fiat_currency": "USD",
    "deferred": true,
    "description": "Top-up — TRC-20 USDT",
    "idempotency_key": "00000000-0000-4000-8000-000000000001"
  }'

# The invoice commits to no network. If the customer settles in TRC-20
# USDT, halfin's Tron gate confirms the deposit against the network's
# threshold and credits your balance; the resolved asset and network
# come back on the invoice and on each signed webhook event.
# Field schemas live at docs.thehalfin.com.