Skip to main content
From 0.6.0 one node quotes every chain its policy lists. Put each network under 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:
Fund the address it prints with the Solana corridor tokens and a little SOL, then open its token accounts. There are no approvals to send on Solana; approve opens the accounts instead, and needs the SOL for rent:
On Solana a taker’s network fee is paid by the Panofx keeper, never by you.

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_seconds at 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 where solana_signer.keyfile should point.
  • Executor overrides. With two EVM chains in one policy, PANOFX_EXECUTOR is ambiguous; set PANOFX_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.
The relay side of Solana settlement is under Solana settlement.