Crypto networks halfin settles on, and how to pick one

An asset and a network are two different choices, and merchants conflate them constantly. "Accept USDT" is not one decision — USDT lives on Tron, on Ethereum, and on Solana, and the rail your customer picks changes the fee they pay, how fast the payment confirms, and which wallet they reach for. This page maps the networks halfin actually settles on, explains why the same stablecoin shows up on several of them, and gives you a way to think about which rail a given payment should take.

Asset and network are separate choices

When a customer says they want to pay in USDT, they have not told you enough to receive the money. USDT is a token contract deployed independently on multiple chains. The USDT a customer holds on Tron cannot be sent to an Ethereum address, and vice versa — same ticker, same dollar peg, different network, different address format, different fee market. If you treat "USDT" as a single rail, you will hand a customer the wrong address and the payment will not arrive.

halfin keeps these two axes explicit. An invoice is denominated in a fiat amount; the customer chooses an asset; and the asset resolves to a specific network with its own deposit address and confirmation rules. A USDT payment on Tron and a USDT payment on Ethereum settle the same dollar figure to your balance, but they travel over different rails and confirm under different thresholds. The dashboard, the API, and the webhook all carry the network alongside the asset so reconciliation is never ambiguous about where a payment landed.

The practical upshot: when you present payment options, you are presenting asset-on-network pairs, not bare assets. "USDT on Tron" and "USDC on Base" are the unit a customer actually pays with.

The networks halfin settles on

halfin runs a settlement gate per network — code that watches the chain, matches deposits to invoices and addresses, applies that chain's confirmation threshold, and credits your balance. A network is supported only when its gate exists; this is the real list, not an aspirational one. Crediting is reorg-aware everywhere: a deposit is not marked settled until it has held for the network-appropriate number of confirmations, and a chain reorganization that unwinds a transaction is reflected rather than ignored.

Networks group into families. Bitcoin and the XRP Ledger are their own protocols. Ethereum and its layer-2 rollups — Base, Arbitrum, Polygon — plus BNB Smart Chain are EVM chains that share Ethereum's account and address model but settle independently with their own fees and finality. Tron and Solana are non-EVM networks with their own token standards (TRC-20 and SPL respectively). The table below is the routing map: which assets ride each network, and how the rail tends to feel to a payer.

Why the same stablecoin lives on several networks

USDT and USDC are each issued as separate token contracts on each chain they support. The issuer mints USDT on Tron, on Ethereum, and on Solana as three distinct deployments that happen to redeem for the same dollar. None of them is the "real" one — they are parallel instances, and a holder's balance lives on whichever network they acquired it on. That is why a customer might say "I have USDT" and still be unable to pay an Ethereum address: their USDT is on Tron.

This multiplicity is a feature for a payment processor, because different networks suit different payers. A customer paying a small amount cares about transfer cost and will reach for the cheaper rail; a customer moving value they already hold on Ethereum mainnet will pay there to avoid a bridge. By accepting the same stablecoin across the networks where it actually circulates, you let each payer use the balance and wallet they already have instead of forcing a conversion or a bridge they may get wrong.

USDC is a dollar-denominated stablecoin; halfin settles it on Ethereum, Base, and Solana. USDT is the highest-volume stablecoin, and its Tron deployment in particular carries enormous payment volume — which is exactly why Tron USDT is often the lowest-friction option for a customer who simply wants to send dollars and move on.

• USDT settles on Tron (TRC-20), Ethereum (ERC-20), and Solana — three independent deployments of the same peg.
• USDC settles on Ethereum (ERC-20), Base, and Solana.
• Each deployment has its own address and its own network fees; a balance on one network cannot pay an address on another.
• Accepting a stablecoin across its real networks means payers use the wallet and balance they already hold.

How to reason about network choice

There is no single best network — the right rail depends on the payment and the payer. Three properties dominate the decision: how much the customer pays to send (network fees, which the payer bears, not a halfin charge), how long the payment takes to confirm under that chain's threshold, and which network the customer's wallet already holds value on. The last one usually wins in practice: customers pay from the balance they have, on the network it is on.

For stablecoin payments where the customer is rate-shopping the rail, the low-fee networks — Tron for USDT, Base and Solana for USDC, plus the EVM L2s for native assets — keep the customer's send cost down, which matters most on smaller amounts. For a customer paying from Bitcoin cold storage, BTC on Bitcoin is the only sensible rail regardless of fee, because that is where their value lives. For an EVM-native customer with funds on Ethereum mainnet, paying on mainnet avoids the friction and risk of bridging to an L2 just to save on fees.

You do not have to make this choice for the customer. Present the asset-on-network options you accept and let the payer settle from whatever they hold — the fiat amount you billed is fixed regardless of which rail clears it. What you should not do is assume "accept crypto" means one network: a merchant who only takes ERC-20 USDT turns away every customer whose stablecoin sits on Tron.

• Network fees are paid by the customer to the chain — they are a property of the rail, not a halfin rate.
• Confirmation time follows each chain's threshold; halfin waits for finality before crediting, and crediting is reorg-aware.
• Customers overwhelmingly pay from the network their wallet already holds — meet them there rather than forcing a bridge.
• Offering one stablecoin across multiple networks widens who can pay without adding fiat or conversion steps.

Networks in your integration

You do not select a network when you create an invoice. You bill a fiat amount; the customer chooses an asset; and halfin resolves the asset to its network, hands the customer the correct deposit address for that rail, and tracks confirmations against that chain's threshold. The network on which a payment settled comes back to you in the invoice record and in every webhook event, so your ledger always knows whether a given USDT payment arrived over Tron or Ethereum.

The create call below bills a flat fiat figure — it commits to no network. The customer's asset choice on the checkout determines 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": "120.00",
    "fiat_currency": "USD",
    "deferred": true,
    "description": "Annual plan",
    "idempotency_key": "00000000-0000-4000-8000-000000000010"
  }'

# The invoice commits to no network. The customer's asset choice on
# checkout resolves the rail (e.g. USDT on Tron vs USDT on Ethereum);
# the resolved asset and network come back on the invoice and on each
# signed webhook event. Field schemas live at docs.thehalfin.com.

Per-network detail is coming

This page is the map. Dedicated pages for individual networks — the confirmation model for Bitcoin, the ERC-20 mechanics of Ethereum, Tron's TRC-20 throughput, Solana's SPL settlement — are planned and will sit alongside this hub. Until they ship, the asset pages cover the same ground from the asset's side: how a given token settles, and on which rails. Start from the asset a customer wants to pay with, or from this network map, and the two views meet in the middle.