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

# Supported networks tokens

# Supported Networks And Tokens

PayChain support is network-based. Every invoice, payout route, dynamic payout recipient, withdrawal, balance, and transaction should carry the correct `chain`, `networkId`, and `token`.

<Info>
  **Catalog note:** Treat supported networks as an expanding list, not a fixed promise frozen into your code. Your integration should discover the current catalog from the API or dashboard.
</Info>

## Current catalog source

Use these surfaces to confirm what is currently available:

| Surface                            | Best for                                   |
| ---------------------------------- | ------------------------------------------ |
| Dashboard network/token selectors  | Visual confirmation of enabled rails.      |
| `GET /api/v1/networks`             | Developer discovery of active networks.    |
| `GET /api/v1/networks/supported`   | Public supported-network list.             |
| `GET /api/v1/tokens`               | Token discovery across supported networks. |
| `GET /api/v1/tokens?networkId=...` | Token discovery for one network.           |

<Warning>
  **Do not hardcode:** Network availability, token availability, and sponsored gas behavior can change. Cache the catalog if needed, but refresh it regularly.
</Warning>

## Network list format

Use this format when reviewing or documenting supported rails. The rows below are examples of how to read the catalog, not an exhaustive permanent list.

| Network                 | `chain`   | `networkId`       | Environment  | Common assets   | Notes                                                                           |
| ----------------------- | --------- | ----------------- | ------------ | --------------- | ------------------------------------------------------------------------------- |
| Base Mainnet            | `evm`     | `base-mainnet`    | Live         | ETH, USDC       | Common stablecoin checkout rail.                                                |
| BNB Smart Chain Mainnet | `evm`     | `bnb-mainnet`     | Live         | BNB, USDT, USDC | Common emerging-market payment rail.                                            |
| Ethereum Mainnet        | `evm`     | `eth-mainnet`     | Live         | ETH, USDC, USDT | Higher-cost settlement rail; confirm economics before using for small invoices. |
| Solana Mainnet          | `sol`     | `sol-mainnet`     | Live         | SOL, USDC       | Fast settlement rail; token account behavior can affect gas usage.              |
| Stellar Mainnet         | `stellar` | `stellar-mainnet` | Live         | XLM, USDC, USDT | Stellar payments require the returned Memo ID by default.                       |
| Base Sepolia            | `evm`     | `base-sepolia`    | Sandbox/test | Test assets     | Use for EVM testing.                                                            |
| Ethereum Sepolia        | `evm`     | `eth-sepolia`     | Sandbox/test | Test assets     | Use for EVM testing.                                                            |
| Solana Devnet           | `sol`     | `sol-devnet`      | Sandbox/test | Test assets     | Use for Solana testing.                                                         |

The table above is a human-readable guide. The API and dashboard remain the source of truth for the current production catalog.

## Token matching rules

Invoice and payout routing asset fields must match exactly:

* `chain`
* `networkId`
* `token`

For Stellar issued assets, `token` is display-friendly only. Matching requires the registered `canonicalAssetId` in the form `stellar:{assetCode}:{issuerAddress}`. Native XLM uses `stellar:XLM:native`. PayChain does not auto-discover arbitrary Stellar assets.

If a customer sends the wrong asset or uses the wrong network, do not treat the transfer as a valid invoice payment unless PayChain marks the invoice settled.

## Choosing a network

Choose a network based on:

* Customer payment behavior.
* Stablecoin availability.
* Network cost.
* Settlement speed.
* Payout destination support.
* Gas-credit impact for sponsored outbound operations.
* Your compliance and operational policy.

## Developer discovery example

### SDK

```ts theme={null}
const networks = await paychain.networks.list();
const tokens = await paychain.tokens.list();
const baseTokens = await paychain.tokens.forNetwork('base-mainnet');
```

### REST

```bash theme={null}
curl "$PAYCHAIN_API_URL/networks" \
  -H "x-api-key: $PAYCHAIN_API_KEY"

curl "$PAYCHAIN_API_URL/tokens?networkId=base-mainnet" \
  -H "x-api-key: $PAYCHAIN_API_KEY"
```

REST integrations can use the equivalent network and token endpoints from the [OpenAPI reference](openapi-reference).

## When PayChain adds a new network

When PayChain adds support for a new network, it appears in the dashboard and network/token APIs after provisioning. Merchants do not need to manually provision the network inside PayChain.

Your team only needs to decide whether your own checkout, app, or backend flow should display that rail to customers. The safest integration pattern is to read the catalog, display only the networks and tokens your product supports, and avoid assuming that every token exists on every network.

## Common mistakes

* Hardcoding one network and assuming all customers can use it.
* Treating `chain: evm` as enough without checking `networkId`.
* Creating an invoice on one network and routing payout recipients on another.
* Assuming all tokens exist on all networks.
* Assuming sponsored gas behavior is identical across every rail.