Best network for stablecoin payments: Stellar, Ethereum, Polygon, Tron

The best network for a stablecoin payment is the one the other side of the corridor already uses, because a token that has to be swapped, bridged or converted before the counterparty will take it costs more than any difference in network fees. Stellar, Ethereum, Polygon and Tron each carry USDC, USDT or both, and each is the right answer for some corridors and the wrong answer for others.

This post is written for the operator who has to pick a default and then override it per flow. It compares the four networks on the questions that decide a routing rule: which token lives where, what a transfer costs and how long it takes to be final, where the liquidity is on each side of a Latin American corridor, and what the failure looks like when the choice is wrong. It ends with a routing table by corridor and with the cases where none of the four is the point. If the tokens themselves are new, the USDC explainer and the USDT explainer come first.

The decision is made by the counterparty, not by the sender

A business paying out chooses a network in the sense that it chooses which address it sends to. In practice the address was chosen by whoever will receive the money, and that party chose it by where its own liquidity, exchange or provider lives. A supplier in Asia who holds USDT on Tron will not accept USDC on Base and convert it as a favour. An institutional desk redeeming dollars in size wants Ethereum, where the deepest USDC liquidity is. A Brazilian company converting reais to USDC through a local on-ramp may never see the network at all.

So the routing rule is written from the outside in. Start with the counterparty's side of the corridor, find the token and network that side already holds, and work back to what the sending side has to do to deliver it. The fee comparison comes last, and it only matters between networks that both sides accept.

Where each token lives, with the supply to prove it

USDC in circulation per network, from Circle's issuance API on September 24, 2026, rounded to one decimal; networks below 0.5 billion omitted except the four compared here.

Two thirds of all USDC sits on Ethereum, per Circle's issuance API, out of roughly 75 billion in circulation on the day of writing. The same API lists USDC as natively issued on 39 networks as of September 25, 2026; the table keeps the four this post compares plus the three others above half a billion, for scale. Tron is the striking row: almost no USDC lives there, because Circle stopped minting USDC on Tron in February 2024, and Stellar carries a modest balance that matters for one specific corridor below.

USDT is the mirror image. Tether's supported protocols page lists USDT on Ethereum, Tron, Solana, Avalanche, Celo, Kaia, Near, Ton and a long tail, and Polygon is absent from that list on the day of writing; Tether's transparency reporting has shown for years that roughly half of all USDT is on Tron and most of the rest on Ethereum. The USDT explainer carries the per-network table with its date.

The routing consequence is blunt. If the corridor is in USDC, the candidate networks are Ethereum, Base, Polygon and Stellar. If it is in USDT, they are Tron and Ethereum, with Polygon absent from Tether's current list even though USDT is still transferred there. Choosing a network before choosing the token is choosing in the wrong order.

The four networks on one table

Stellar, Ethereum, Polygon and Tron compared on the questions that decide a payment routing rule, as of September 24, 2026.

Two answers did not vary enough to earn a row. The fee is always paid in the network's own asset, held by the sender, with one wrinkle on Tron, where the sender can cover it with staked resources instead. And a transfer sent to an address on a network the receiver does not credit fails the same way on all four: recovery depends on the receiver.

The cost row is written as orders of magnitude on purpose. Network fees move with demand and with the price of the fee asset, and a number quoted today is wrong next month. Stellar's minimum is the one figure that is set by protocol rather than by market: the network's own documentation fixes the inclusion fee at no less than 100 stroops per operation, where a stroop is one ten-millionth of a lumen. Ethereum's fee floats with demand for block space and is the only one of the four that can turn a payroll's network cost into something a finance team notices.

Ethereum, Polygon and Base: the USDC networks, by size and by fee

Ethereum is the settlement layer of last resort for both tokens. Redemptions with the issuer, OTC trades in size, and any counterparty that wants the most conservative choice will ask for Ethereum. The cost of that is a fee that is small most of the time and not small when the network is busy, and a payroll of hundreds of payouts on a congested day can pay more in network fees than in FX spread.

The rule that follows: route large, infrequent amounts through Ethereum, and route frequent small amounts elsewhere. A treasury moving a month of working capital in one transfer is on Ethereum. A platform paying five hundred sellers on Friday is not.

Polygon and Base exist, for a payments operator, to make USDC cheap to move. Fees are cents, finality is fast, and USDC on both is issued by Circle rather than bridged, which means the token a payout delivers is the same token the receiver can redeem. Polygon's USDC supply is small next to Base's, but the payment use is the same: many transfers, low value each, where the fee on Ethereum would be a line item.

The limit is the counterparty. A receiver whose exchange or provider does not credit Polygon or Base cannot take a payout there, and the sender finds that out when the funds do not appear. The Lumx vs Bridge page shows how a provider's network list shapes what a client can do, which is the same question in a different frame.

Tron: where USDT lives, and why that settles the argument

Tron carries about half of all USDT, and that fact shapes Latin American payments more than any technical property of the network. Exchanges, OTC desks and remittance counterparties in Argentina, Colombia and parts of Mexico settle in USDT on Tron because that is where their liquidity is, and a Brazilian exporter paying a supplier in Asia who will not take a wire is paying in USDT on Tron for the same reason. Transfers cost cents and are final in seconds. USDC has almost no presence there.

So the Tron decision is rarely about Tron. It is about whether the counterparty holds USDT, and if it does, Tron is usually where. Forcing USDC into that leg adds a conversion the counterparty will price into the deal. The USDT-on-Tron mechanics, from address format to the resource model that replaces a fee, are covered in the TRC20 payouts explainer; this post only decides when to route there.

I was against adding Tron, and the argument I made was the reserve table in the USDT explainer: why route client money over the network of the token with the messier balance sheet when USDC on Polygon did the job. The clients answered that for me, because their counterparties held USDT on Tron and no argument about reserves changed what those counterparties would accept. The position I hold now is that the network is a property of the corridor, chosen by the side that already has the liquidity, and that a provider which lets its own preferences pick the network is asking the client to pay the conversion. We support the networks our clients' counterparties use, and we say which token runs on which one rather than pretending every network carries everything.

Stellar: one corridor, done well

Stellar is not a general-purpose answer in this comparison. Its USDC supply is a fraction of Ethereum's, and most payment counterparties do not hold balances there. What Stellar has is a fee fixed by protocol at a fraction of a cent, finality in seconds, and one corridor where that combination was worth building: the BRL to USDC corridor on Stellar, launched for institutional payment settlement in Brazil, where a reais deposit over Pix (Brazil's instant payment system, run by the Central Bank) becomes USDC on Stellar. The BRL to USDC page shows the live rate and the networks available for that pair.

The rule: use Stellar when the receiving institution settles on Stellar, for the BRL on-ramp. Do not route a payout to a counterparty that holds USDT there, because it does not.

The routing table by corridor

A default network per corridor and token, for a payments operator in Latin America, as of September 24, 2026. Override it whenever the counterparty's address says otherwise.

Three of the seven rows do not depend on the network at all, and that is the second lesson of the table: when both ends of the corridor are local currency over local rails, the network is an implementation detail the provider picks for cost, and the recipient never sees it.

When the network is the wrong thing to be deciding

When both legs are local currency. A reais-to-pesos payment where neither party holds tokens should be routed for cost by the provider, and the operator who insists on choosing the network is optimising a variable the recipient cannot see.

When the counterparty has already chosen. An address on a network is a decision made. The only routing question left is whether the sender can deliver there, and if not, whether the conversion is worth the deal.

When the amounts are small and rare. Every network in the table is cheap enough that the choice does not change the economics of ten transfers a month. Onboarding and integration do.

When the question is really custody. Which network to hold on is downstream of who holds the keys, and the custodial wallet decision comes first.

How routing works on Lumx

Lumx is stablecoin payments infrastructure for businesses that move money between Latin America and the rest of the world: one API to collect, hold, convert, and pay out in BRL, MXN, COP, USD, EUR, and GBP or in USDC and USDT, over local rails such as PIX, SPEI, PSE, ACH, FEDWIRE, SEPA, and Faster Payments, with SWIFT and on-behalf-of payments and collections (POBO and COBO) in USD, EUR, and GBP, plus named virtual accounts, custodial wallets, and KYB/KYC built in.

Every onboarded customer gets a wallet on each supported network, and the token list per network is stated rather than implied: USDC and USDT on Ethereum and Polygon, USDC on Base, USDT on Tron, and USDC on Stellar for the BRL on-ramp only. A project sets a default network, and a client overrides it per request by passing the network on an on-ramp, an exchange rate or a payout, so the routing table above becomes a field in the call rather than a policy document. The wallet address is a real address on that network, so a client's counterparty can send to it directly, and the address is issued per network to make the wrong-network deposit harder to commit. The corridor explainer describes how the local legs on each side are stitched to the token leg in the middle.

Methodology and sources

USDC supply per network is from Circle's public issuance API, queried on September 24, 2026, and rounded to one decimal; the network count is from the same API, queried on September 25, 2026. The Tron decision follows Circle's blog post of February 21, 2024. USDT network coverage is from Tether's supported protocols page, read on September 24, 2026; the share of USDT on Tron is as reported in the USDT explainer, dated there. Stellar's minimum inclusion fee is from the Stellar developer documentation on fees and resource limits, read on the same date. Ethereum, Polygon and Tron fees are given as orders of magnitude because they float with demand and with the price of each network's fee asset, and a figure quoted here would not survive the month. Lumx network and token support is from the Stablecoin Wallets and Coverage pages at docs.lumx.io, read on September 24, 2026.

Verified on September 25, 2026. Operational context, not legal, tax, or investment advice.

Cover photo: Johannes Plenio on Unsplash.