Skip to main content

​
Tokens

Three stablecoins, none of them privileged in pricing or positioning.

USDC

Circle. Widest coverage across EVM chains.

USDT

Tether. Dominant on TRON and heavily used in Asia.

EURC

Circle’s euro stablecoin. Useful if you price and bank in euros.
Coverage is not a full matrix — it differs sharply per chain. Across the eight live networks today: USDC is available on all seven EVM testnets but not on TRON; EURC only on Base Sepolia, Ethereum Sepolia and Avalanche Fuji; USDT only on TRON Nile. Any other (token, chain) pair is rejected server-side with Unsupported token/chain, so those cells are not a choice you can make — they don’t exist. USDT is deliberately never offered on Base, on testnet or mainnet, because there is no native Tether deployment there. On BNB testnet, “USDC” is our own open-mint test faucet token rather than Circle USDC. Your settlement token is the checkout’s default selection and the token orders are priced in — it is not a conversion target. There is no swap today: you are paid in whichever enabled token the customer actually sent, on the chain they sent it on. Enabling three stablecoins means your pool can hold all three, each distributed and claimed separately per chain and token — and a mix of USD- and EUR-pegged tokens leaves you carrying that FX exposure.
Checkout is stablecoin-only today. Accepting volatile assets like ETH and converting at checkout is not committed work and has no date — someone has to bear the price risk between payment and settlement, and that needs to be right rather than fast. Roadmap.

​
Chains

​
Choosing

Start narrow

Two or three cheap chains — Base, Arbitrum, Polygon — covers most customers with minimal operational load.

Every chain has a cost

Each one you enable is another pool that has to exist on that chain and another settlement path to watch. Enabling a network in your dashboard is free; activating it — deploying your pool there — is one more signature and one wallet-paid transaction, with a live fee estimate shown first. Nothing is fronted on your behalf and nothing comes back out of your share later for it.
You do not need to hold a chain’s native token for your money to arrive. Our keeper runs every few minutes, fronts and absorbs the network fee to settle your pool, and sends your share to your payout address — the contract always pays the credited owner, never whoever sent the transaction. Native gas becomes your concern in two places: activating a chain (deploying your pool there, once, from your own wallet), and pressing Claim yourself if you don’t want to wait — one signature, with a live fee estimate shown first. Claiming.

​
Two chain-specific notes

The problem is specific to BNB Smart Chain mainnet, where these stablecoins are 18-decimal rather than the 6 used elsewhere, and our deposit path does not yet handle that consistently.BNB testnet is unaffected and available today — it carries a deployed registry and a 6-decimal test USDC, and appears under “Available now” in your Tokens matrix like every other testnet. BNB mainnet is off today only because every mainnet is off; keeping it off after mainnet opens is a release decision we make, not a check enforced in code. Roadmap.
Mainnet USDT rejects changing a non-zero allowance to another non-zero value — a quirk of that specific contract. A repeat customer with a leftover allowance would have their wallet payment fail.Testnet is unaffected, and the fix is a mainnet go-live gate. Pay-by-address is unaffected either way. Roadmap.

​
Per-cell control

You control availability at the level of each (token, chain) pair, not just per chain — so you can accept USDC on a chain while leaving EURC on that same chain off, if that suits your treasury. Pairs where the token has no contract on that chain are shown as unavailable rather than as a choice: USDT on Base, for example, is not offered at all. Per-pair control is enforced server-side when a payment is created — a quote or payment link for a pair you disabled is rejected, so a crafted request can’t use a combination you turned off. Settlement of a pay-by-address payment is looser: an inbound transfer is credited if its token is one of your enabled stablecoins and exists on the chain it arrived on, matched by symbol rather than by pair. A payment sent by address in a token you enabled on some other chain can therefore still settle on a chain where you disabled that specific pair.

​
Cross-chain and cross-token tolerance

A payment sent to a pay-to address is matched on value, not on a specific token on a specific chain. A customer who pays the right value in a different enabled stablecoin, or on a different enabled chain, is detected and reconciled rather than rejected. Only the tokens in our per-chain watch list are monitored at a deposit address: USDC on every enabled EVM chain, EURC on Ethereum Sepolia, Base Sepolia and Avalanche Fuji, and USDT on TRON. A token in that set that you haven’t enabled surfaces as wrong_token in Needs attention for you to handle — no webhook is emitted for it. Anything outside that set — including USDT sent to an EVM deposit address — is not detected. The payment stays waiting until it expires, and the funds sit at the deposit address unreported until someone sweeps them manually. Contact us if that happens. Edge cases.

​
Availability

All chains are on testnet today. Mainnet is enabled per chain after a third-party audit, a public bug bounty, and legal sign-off. Nothing is deployed to any mainnet yet — deliberately.
Contract addresses for every chain are published at /verify.