More chains

What one more chain costs, what is already chain-agnostic, and the order worth doing.

Nothing in the design ties Panofx to Base: the relay, the node and the web app all take their chains from configuration, and Solana already runs beside Base from the same relay. Adding a chain is a deployment and a few settings, not a rewrite.

Where the naira is

A corridor is only worth opening where the tokens exist and someone wants to trade them. cNGN supply by chain, read on 11 September 2026:

Chain	cNGN supply	Value	Venue today
Base	2.78B	~$2.0M	Panofx
BNB Chain	760M	~$555k	Textile cNGN/USDT, its deepest
Celo	326M	~$238k	Textile cNGN/USDT, Mento
Solana	60M	~$44k	none
Ethereum	137k	~$100	none
Polygon	12.7k	~$9	none

So the order is BNB Chain, then Celo, with Polygon and Arbitrum waiting for a reason: either cNGN issued there in size, or a different corridor on them.

What one more EVM chain costs

1. Contracts. PanofxValidation, PanofxFeeController and PanofxExecutor, plus a LimitOrderReactor. Permit2 is already at the same address on every EVM chain. The deploy script takes its addresses from the environment; the result goes to contracts/deployments/<chain>.json.
2. An entry in the relay’s CHAINS. One more object with its contracts, tokens, gas-fee token and reference corridor. The keeper holds a lease per chain, and the indexer runs a loop per chain in one process. See Relay environment.
3. A keeper key, funded with that chain’s gas token.
4. Reference rates. The band is per corridor. cNGN corridors reuse the existing sources; a rand or peso corridor needs its own.
5. Nodes. An operator adds an entry under chains: and runs panofx-node approve once.
6. The web app. NEXT_PUBLIC_NETWORKS lists the chains and the header becomes a switcher.

What is already chain-agnostic

• The relay reads its chains, contracts and tokens from configuration; the indexer follows whatever it is pointed at; the oracle’s sources are named, not hard-coded.
• The node takes chain id, contracts and corridors from its policy. The app keeps a catalogue of networks, and the operator picks one during setup.
• The web app resolves the relay and RPC per call, so switching chains never needs a rebuild.
• The contracts carry no chain assumption beyond Permit2’s canonical address.

What a second chain would still need

• Per-chain keeper funding and monitoring.
• Several chains in the app: the command-line node and the container already run several from one policy; the app manages one network per data directory.
• A chain column in the explorer.
• Corridor-aware minimums and fees: a minimum that makes sense in naira does not in rand.

Order of work

1. Finish the open testnet items on Base: external resolvers, the runbook timing, an MPC-signed fill.
2. Base mainnet, with the contract review and the multisig owner.
3. BNB Chain testnet, then mainnet.
4. Solana: the program is deployed and the hosted relay and web app route devnet swaps. Next is a house node quoting it continuously, then mainnet-beta.
5. Celo, once BNB shows whether competing on an existing venue works.
6. Polygon and Arbitrum only with a corridor that has liquidity on them.