> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cryptocheckout.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Chains and tokens

> Where you can accept, what you can accept, and how to choose.

## Tokens

Three stablecoins, treated equally.

<Columns cols={3}>
  <Card title="USDC" icon="dollar-sign">
    Circle. Widest coverage across EVM chains.
  </Card>

  <Card title="USDT" icon="dollar-sign">
    Tether. Dominant on TRON and heavily used in Asia.
  </Card>

  <Card title="EURC" icon="euro-sign">
    Circle's euro stablecoin. Useful if you price and bank in euros.
  </Card>
</Columns>

You pick a **settlement token** — what you want to be paid in. Customers pay in any token you've enabled, on any chain you've enabled.

<Note>
  Phase 1 is stablecoin-only. Accepting volatile assets like ETH or BTC and converting at checkout is planned but not live. [Roadmap](/reference/roadmap).
</Note>

## Chains

<Tabs>
  <Tab title="EVM">
    | Chain         | Network fees   | Notes                                                              |
    | ------------- | -------------- | ------------------------------------------------------------------ |
    | **Base**      | Very low       | Good default. Cheap, fast, strong USDC liquidity.                  |
    | **Arbitrum**  | Very low       | Deep liquidity, mature ecosystem.                                  |
    | **Optimism**  | Very low       | Among the cheapest to claim from.                                  |
    | **Polygon**   | Very low       | Widely held, cheap.                                                |
    | **BNB Chain** | Low            | Large retail user base. Not yet offerable — see below.             |
    | **Avalanche** | Low            | Cheapest claims in our measurements.                               |
    | **Ethereum**  | High, variable | Highest trust and liquidity. Costs real money to deploy and claim. |
  </Tab>

  <Tab title="TRON">
    Where an enormous share of USDT actually moves, particularly outside Europe and North America.

    Worth knowing:

    * Network fees are a **chain parameter**, not an auction. Predictable, but not cheap, and they don't fall at 3am the way Ethereum's do.
    * Deploying a pool on TRON costs meaningfully more than on any EVM chain.
    * Deposit-rail payments carry a higher minimum here than anywhere else.
    * Addresses are base58 and start with `T`. They are **case-sensitive** — never normalise their case.

    If your customers are in markets where USDT-on-TRON is the default, this chain is not optional. If they're not, EVM chains will be cheaper for everyone.
  </Tab>
</Tabs>

## Choosing

<Columns cols={2}>
  <Card title="Start narrow" icon="filter">
    Two or three cheap chains — Base, Arbitrum, Polygon — covers most customers with minimal operational load.
  </Card>

  <Card title="Every chain has a cost" icon="weight-hanging">
    Each one you enable is another pool to deploy and another native-gas balance to keep topped up so you can claim.
  </Card>
</Columns>

<Warning>
  Enabling a chain you can't claim on is worse than not enabling it. Your money accumulates somewhere you can't withdraw from until you acquire that chain's native token.
</Warning>

## Two chain-specific notes

<AccordionGroup>
  <Accordion title="BNB Chain is not yet offerable" icon="triangle-exclamation">
    Stablecoins on BNB Chain are 18-decimal rather than the 6 used elsewhere, and our deposit path does not yet handle that consistently. Enabling it before the fix risks a decimal-scaling error, so it stays off until corrected. [Roadmap](/reference/roadmap).
  </Accordion>

  <Accordion title="USDT on Ethereum mainnet needs an approval fix" icon="triangle-exclamation">
    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](/reference/roadmap).
  </Accordion>
</AccordionGroup>

## Per-cell control

You control availability at the level of each **(token, chain)** pair, not just per chain — so you can accept USDC on Base but not USDT on Base, if that suits your treasury.

This is enforced server-side, so a crafted request can't use a combination you disabled.

## Cross-chain and cross-token tolerance

The deposit rail accepts **value**, not 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.

A payment in something you haven't enabled surfaces as `wrong_token` for you to handle rather than vanishing. [Edge cases](/money/edge-cases).

## Availability

<Warning>
  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.
</Warning>

Contract addresses for every chain are published at [/verify](https://www.cryptocheckout.ai/verify).