The chain registry

Fifteen chains across four virtual machines are compiled in, not configured. DEX_CHAIN_STATIC — a table in dex/utils/chains.ts keyed by numeric chain id — supplies the id, the VM, the slug, the ecosystem key, the native token, the wrapped native, the explorer, the default confirmation depth and the minimum gas reserve. The dexChain table holds only the operator's half of a row: the switch, the fee recipient, both RPC fields, the confirmation override and the zero-fee acknowledgement.

Identity, and the two environment variables each chain derives

slug is what APP_DEX_RPC_<SLUG> is built from. key is the ecosystem ChainSymbol, which is what the <KEY>_<NETWORK>_RPC fallback and the boot chain-id cross-check both join on — null means neither applies.

Avalanche and Linea carry key: null because the ecosystem addon has no entry for either. That is deliberate rather than an omission — a plausible-looking "AVAX" would make the boot cross-check look up a symbol that does not exist, find nothing and skip, which is a safety check that silently checks nothing. The cost is one required variable: on those two chains, APP_DEX_RPC_<SLUG> or a row override is the only way to give the chain an endpoint.

Confirmations, gas reserve and explorer

The seeded depth is the default. The chain console can override it per row, whole numbers 1–200, and the override is what the confirmation sweep uses.

Why the depths differ

The gas reserve is in base units, and the units are not the same

minGasReserve is what Max must leave behind when a user is selling the chain's native token and the live gas estimate comes back implausibly low. The client takes max(2 × estimate, this). It is stored as a decimal string because JSON has no bigint and Number loses the low digits of an 18-decimal value.

Three of the four VMs mean something different by it:

• EVM — wei. A plain gas reserve.
• Solana — lamports, and it is gas plus rent. A fee is trivial (5,000 lamports per signature plus priority); what dominates is that buying a token the user has never held creates an associated token account, and an account must hold about 0.00204 SOL to exist at all. A Jupiter route can create more than one. Reserving only the fee lets a user spend to the last lamport and then watch the swap fail with the fee already paid.
• TRON — SUN. TRON charges bandwidth and energy, which staked TRX provides for free; a user with no stake pays by burning TRX, and a contract call burns far more than a transfer. The 100 TRX floor covers the burn case.
• TON — nanotons, and it is not a gas reserve at all. TON charges per message, a swap fans out into several, and each message carries an attached value that is largely refunded. What strands a user is having too little TON to attach; STON.fi's own forward_gas for a simple swap measured 0.185 TON.

Polygon is POL here and MATIC in the ecosystem

The native asset was renamed MATIC to POL on chain in 2024. This registry follows the network, because the symbol is a user-facing swap label. The ecosystem addon's chainConfigs still says currency: "MATIC", because its currency codes are wallet symbols — the code a custodial balance is held under, which cannot be renamed without rewriting every historic row.

Both are correct in their own table and they are never compared. What follows from it operationally is only this: a Polygon deposit in the ecosystem is labelled MATIC, the same asset in the swap terminal is labelled POL, and the ecosystem's mainnet network name is matic — so the fallback variable is POLYGON_MATIC_RPC, not POLYGON_MAINNET_RPC.

Wrapped native, per chain

On EVM the native token has no contract, so the addon uses a sentinel address and routes through the wrapped form. Three entries are exceptions worth knowing before somebody "corrects" one.

• Celo has no "wrapped CELO". Its native token is an ERC-20 — the same asset, at a real contract, is both the gas token and a transferable token. The native-to-wrapped translation every other EVM chain performs is an identity here, and a pool of CELO against anything is a pool of that address.
• Native TON is the zero address. There is no wrapped TON to route through; the routers use a proxy (pTON) internally and the API takes the zero address. STON.fi's asset list contains a different entry symbolled "TON" that looks like the answer and returns "could not find pool address" on every router.
• Wrapped SOL is a real mint that aggregators quote directly, so it is not a translation target — it is the address you ask for a price with.

Which venue covers which chain

Chain coverage is a property of the adapter, checked before a dexProvider row is even consulted. A provider switched on for a chain its adapter does not carry simply never enters the race.

Read that table before you switch a chain on:

• Cronos, Rootstock and Celo quote only through LI.FI. Switch LI.FI off on Admin → Swap → Providers and all three go dark with nothing else to fall back to.
• Solana, TRON and TON have exactly one adapter each — Jupiter, SunSwap and STON.fi. Each is also the only adapter for its VM, so there is no second opinion on price and no fallback during a vendor outage.
• Fantom Opera has no aggregator at all. It is quotable only through the direct-pool venue, which means it is quotable only while dexDirectPoolsEnabled is on and a verified pool is bound — see Direct pools.
• Odos reaches four chains only: Ethereum, Optimism, BNB Smart Chain and Arbitrum One. Its integrator fee is an on-chain referral code registered per chain, so it also refuses to quote on any chain whose code is unverified while a platform fee is set — see The Chains console.
• The four chains with a direct venue and thin aggregator coverage — Cronos, Rootstock, Fantom and Celo — carry one because of it. Every address in those four deployments was verified against the live chain: eth_chainId matches, the router's own factory() returns the factory claimed, and that factory returns a real pool for a major pair.

Optimism, Polygon, Avalanche and Linea have no direct-pool deployment in the registry, deliberately: the direct venue exists for pairs no aggregator will quote, and these four are the best-covered chains in the table — five aggregators on Optimism, four each on Polygon and Avalanche, three on Linea.

An operator who has verified a deployment adds it as an entry in dexChain.metadata.extraAmmDeployments[], which is a different key from extraRouters on the same blob — that one is the router allowlist, the list checked against a quote's to and approval spender. Neither has a field on the chain console and no admin route writes dexChain.metadata at all: the chain PUT accepts six columns and nothing else, so in this build both are a direct database edit. See The Chains console.

The list exists in three places, and a test holds them together

DEX_CHAIN_STATIC (backend) and DEX_WALLET_CHAIN_IDS in frontend/config/dex-chain-ids.ts carry all fifteen ids. The networks array in frontend/config/wallet.tsx carries thirteen: TON and TRON are deliberately absent, because AppKit has no TON or TRON namespace — TON is reached through TON Connect and TRON through the injected TronLink provider, neither of which is a WalletConnect session. chain-registry.test.ts encodes exactly that: every registry chain must be reachable by some wallet layer, every AppKit network must have a registry entry, and DEX_WALLET_CHAIN_IDS must equal networks plus those two named exceptions.

That matters to you when you upgrade: the server cannot answer "can a wallet reach this chain", because the answer lives in the frontend bundle that was built and shipped. An install whose backend is newer than its frontend bundle has exactly that disagreement, and the readiness console reports such a chain as unreachable rather than as ready. If a chain looks configured and the terminal will not switch to it, rebuild the frontend before changing anything else.

Where the operator's half lives

Everything above is a protocol fact. What you actually set is on The Chains console, and what a chain still needs before it can serve a swap is reported by Requirements. The endpoint resolution order and every variable name are in Environment variables.