chains: with its own RPC,
contracts and corridors. The single-chain policy from the runbook keeps
working and counts as one chain. Each chain keeps its own inventory, open offers, daily caps and health, so
an RPC outage on one never stops the others.
policy.yaml
policy.multichain.example.yaml in the panofx-node folder is this file, complete.
Add a Solana key
A Solana chain needs a Solana key as well. It is created under the same passphrase:approve opens the accounts instead, and needs the SOL for rent:
Solana notes
- Two corridors on devnet. cNGN/USDC and cNGN/USDT. Each pair’s protocol and network fees are charged in its own dollar token. To quote USDT, add the second corridor as above and open your USDT token account with
approve. - Offer lifetime. Keep
offer_ttl_secondsat 120 or less: the relay refuses longer offers, and a Solana transaction’s blockhash expires after about a minute anyway. 60 is a good value. - Test tokens. Devnet test cNGN and USDC come from the Panofx team.
- Containers. Pass the Solana keyfile as
PANOFX_SOLANA_KEYFILE_JSON: the entrypoint writes it to$PANOFX_RUNTIME_DIR/solana-keyfile.json(default/tmp/panofx), which is wheresolana_signer.keyfileshould point. - Executor overrides. With two EVM chains in one policy,
PANOFX_EXECUTORis ambiguous; setPANOFX_EXECUTOR_<chain id>instead. - Chain ids. 101 mainnet-beta, 102 testnet, 103 devnet, 104 and above for local validators. The node checks the RPC’s genesis hash against the id.

