config.toml
Copyconfig.template.toml to config.toml and fill in your values.
[node]
[keys]
Choose one provisioning pattern.
Option 1 — direct hex
config.toml.
Option 2 — key file
./keystore/p2p_<peerID>.json, so mount the whole ./keystore directory into the container if you run Docker. Keep both files at 0600 permissions.
Option 3 — AWS KMS for the onchain key
ECC_SECG_P256K1. In production, authorize only the validator runtime role to call kms:Sign. Keep admin principals able to manage the key, but do not grant them signing rights unless they also operate the validator. This keeps operational administration separate from report-signing authority.
[p2p]
announce_addresses if your node listens on one address but other validators must dial a different public endpoint.
Do not front the P2P port with Cloudflare or any HTTP proxy. ragep2p expects direct TCP reachability.
[database]
[monitoring]
[ocr2]
config_sync_chain_id defaults to Ethereum mainnet (1). This is the chain where SuperGovernor emits validator config updates, so every node must watch the same source chain.
All nodes must use the same config_version. A mismatch produces a different config digest and prevents consensus.
chain_config_path
chains.yaml
chains.yaml maps chain ID to the chain configuration your node should observe.
Field reference
RPC requirements
- HTTPS is required on every configured chain.
- WSS is required for event subscriptions.
- Public rate-limited endpoints are not suitable for production.
Scope rules
Only include chains that Superform assigned to your validator deployment and for which you have reliable RPC access. A broken chain config creates observation errors for every strategy on that chain. Typical supported deployments include Ethereum, Base, Arbitrum, Optimism, and Polygon, but only configure the chains Superform assigned to your validator.OCR2 timing presets
The versionedconfig/vN.json files define the OCR2 timing profile. Every validator in the network must use the same version.
v2 — high-frequency testing
v3 — hourly production default
Freshness controls
For the production
v3 profile, that contract-side maxStaleness window is designed around a 24-hour safety boundary even though rounds attempt far more frequently.
Switching versions
Updateconfig_version on all nodes and restart them in a coordinated window. Mixed versions split the network until every validator converges on the same config digest.