What It Takes to Run a Canton MainNet Validator

Running a validator on the Canton Network's MainNet is less like staking on a public chain and more like operating permissioned infrastructure: you need approval from a committee, a sponsor, a static egress IP on an allowlist, and a node that keeps pace with network-wide upgrades. InfoDive Labs is a validator operator on the Canton Network, running a MainNet node on the Global Synchronizer with the Splice Docker Compose setup. This guide is for CTOs and engineers deciding whether to run a node themselves or have someone run it. Everything below is checked against the Splice documentation, the Canton Foundation and the Splice source repository, as retrieved on 21 September 2026.

What a validator is on Canton

On most public chains, a validator orders blocks and votes on consensus. On Canton, that job belongs to others. The Splice overview describes the Global Synchronizer as "a decentrally operated service, using a 2/3 majority Byzantine Fault Tolerant (BFT) consensus protocol for message ordering and confirmation". Its infrastructure is run by Super Validators (SVs), who sequence transactions, validate Canton Coin transactions and take part in governance.

A validator is a participant node. The same page lists its roles as validating transactions, recording activity, connecting users and applications to the network, and coordinating upgrades and migrations. Validators "receive and confirm encrypted messages", and the Canton Network is described as a "network of networks" where "each node stores only the data it needs".

That last point is the real difference. Your node does not replicate a global ledger. The Canton Network states that "only stakeholders see, validate and record their parts of a transaction". The Docker Compose guide spells out the consequence for recovery: "Super Validators do not retain transaction details from applications they are not involved in." If your node hosts parties for an application, your backups are the only copy of that application's data you can count on.

The MainNet onboarding path

MainNet is gated. The onboarding page says joining TestNet already requires approval to join MainNet "by the Tokenomics Committee of the Global Synchronizer Foundation", and MainNet "requires everything TestNet requires". The Global Synchronizer Foundation renamed itself the Canton Foundation on 22 September 2025, and the request link in the docs now redirects to the Foundation's validator request form.

The form is "only for those who wish to be their own validator operator", it asks why you would "prefer to do this yourself instead of using one of the existing operators", it rejects personal or alias email addresses, and it requires the name and email of a contact at a Super Validator who will sponsor your onboarding. Submissions go to a public mailing list.

Step	Who acts	What the docs say
1. Request approval	You, then the Tokenomics Committee	Apply via the Canton Foundation form with an SV sponsor contact. No approval timeline is published.
2. Submit egress IP	You, to your sponsoring SV	One IP per network, distinct from the IP used on DevNet or TestNet.
3. Allowlist rollout	All SVs	"This usually takes between 2-7 days."
4. Verify reachability	You, from the node's egress IP	Query every SV's Scan and sequencer endpoints. The default config needs at least 2/3 of SVs reachable.
5. Get onboarding secret	Your sponsoring SV, manually	One-time use, valid for 48 hours.
6. Deploy and onboard	You	Docker Compose or Kubernetes, with all SV-bound traffic leaving from the allowlisted IP.

The onboarding secret expires, so request it only when the node is ready to start. The docs also ask you to confirm that the terminal you test from really uses the allowlisted address:

curl -sSL http://checkip.amazonaws.com

Then loop over the Scan instances returned by any SV's /api/scan/v0/scans endpoint and call /api/scan/version on each. A timeout means that SV has not added your IP yet. The same page gives a grpcurl health check for sequencers, which should return "status": "SERVING".

The networking page keeps the firewall story short: validators need no ingress, and need egress on port 443 to all SVs.

Rehearse on the lower networks first. DevNet is open to any node with an allowlisted IP and resets every 3 months. TestNet sits between DevNet and MainNet for upgrades. MainNet "never gets reset".

The Docker Compose deployment and what it runs

The Compose guide needs a Linux or macOS host with Docker Compose 2.26.0 or newer, curl and jq, on AMD64 or ARM64. You download a release bundle, then start the node from the bundle's splice-node/docker-compose/validator directory:

export IMAGE_TAG=0.8.0
./start.sh -s "<SPONSOR_SV_URL>" -o "<ONBOARDING_SECRET>" -p "<party_hint>" -m "<MIGRATION_ID>" -w

The party hint becomes the prefix of your validator operator's party ID and "cannot be changed over time". The docs require the format organization, function, enumerator, for example myCompany-myWallet-1.

The compose file in the Splice repository shows what actually runs:

postgres-splice: one Postgres instance holding the validator app and participant databases
participant: the Canton participant node
validator: the validator app, which runs the wallet backend, traffic top-ups and reward automation
wallet-web-ui and ans-web-ui: the wallet and name service UIs
nginx: routes the .localhost hostnames, such as wallet.localhost and json-ledger-api.localhost

The docs warn that "the default deployment is highly insecure": it uses self-signed tokens, so anyone who can reach the wallet UI can log in as any user. There is no TLS and no support for ingress from outside the machine. It "does not include monitoring". Before production, configure an OIDC provider in .env (AUTH_URL, VALIDATOR_AUTH_CLIENT_ID, WALLET_ADMIN_USER and the rest) and restart with the -a flag. The Canton Admin API is not exposed by default because it "does not yet support auth". Keep it that way.

Two more Compose constraints matter. The security hardening page says external KMS for participant keys is "not currently supported for Docker Compose-based deployments", and an existing participant cannot be migrated to KMS later. You would need a fresh validator. And start.sh runs docker compose up detached, so a systemd unit needs RemainAfterExit=true.

Sizing, from the hardware requirements page:

Usage	CPUs	Memory	DB CPUs	DB memory	DB size
Experiments, laptop or minimal VM	1	6GB	1	1GB	1GB
Production, little activity	2	8GB	2	4GB	10GB
Production, app provider, moderate activity	2	16GB	2	4GB	100GB

These are reference values. The docs also warn that components are "relatively sensitive to database latency". Host hygiene from our Docker production guide still applies.

Operational duties

Version upgrades on the network's schedule

Upgrades roll out DevNet first, then TestNet, then MainNet. You can see the stagger in the docs themselves today: the DevNet Compose guide references bundle 0.8.3, TestNet's 0.8.1, and the MainNet docs 0.8.0.

The upgrades page sets the rules. Each node upgrades independently. You "must not delete or uninstall any Postgres database, change migration IDs or secrets". For Compose, "you must update the full bundle including the docker compose file and the start.sh script": bumping IMAGE_TAG alone "is insufficient".

The 0.6.4 and 0.6.5 release notes both carry the same warning: validators must upgrade before any logical synchronizer upgrade, or "your node will be unable to receive or submit transactions until you upgrade".

Major upgrades, migration IDs and LSUs

Older Splice releases moved the network to a new protocol version through hard domain migrations, "Synchronizer Upgrades with Downtime" in the release notes, and each one moved the network, and every validator, to a new migration ID. Splice 0.6.2 ended that. Its release notes say hard domain migrations "are no longer supported" and that "Logical synchronizer upgrades (LSU) are now the only supported mechanism for protocol upgrades and network-wide disaster recovery". The same release clarifies that MIGRATION_ID "will not change in the future".

The docs and the script differ slightly here. The MainNet Compose guide still asks for MIGRATION_ID and calls it "frozen", taken from the Canton Foundation's SV network page. The start.sh script in current 0.8.x bundles marks -m optional: the validator resolves it at start-up, and the flag only names the participant database (participant-<id>) for existing nodes. If you deployed with a value, keep passing that value.

The LSU page describes the new flow as having "no operational overhead for validator operators". Validators upgrade to a release that supports both protocol versions ahead of the scheduled time. At the upgrade time, "participants automatically connect to the successor synchronizer". The page still carries a warning that LSU instructions are "a preview" that "will likely change in minor ways". Your job is to be on the right version in time.

Backups and disaster recovery

The backups page asks for two things.

First, a node identities backup, taken once the node is onboarded and again after any reset. It contains the participant's private keys, so it belongs in a secret manager, outside the host:

curl "http://wallet.localhost/api/validator/v0/admin/participant/identities" -H "authorization: Bearer <token>"

Second, Postgres backups "at least every 4 hours", with a strict order: the validator app database must be dumped before the participant database starts. The docs give the Compose commands:

docker exec -i splice-validator-postgres-splice-1 pg_dump -U cnadmin validator > "${backup_dir}"/validator-"$(date -u +"%Y-%m-%dT%H:%M:%S%:z")".dump
active_participant_db=$(docker exec splice-validator-participant-1 bash -c 'echo $CANTON_PARTICIPANT_POSTGRES_DB')
docker exec splice-validator-postgres-splice-1 pg_dump -U cnadmin "${active_participant_db}" > "${backup_dir}"/"${active_participant_db}"-"$(date -u +"%Y-%m-%dT%H:%M:%S%:z")".dump

The disaster recovery page sets the clock. A full restore needs a database backup "less than 30 days old", because "due to sequencer pruning, a participant that is more than 30 days behind will be unable to catch up". Without a usable backup, an identities file lets you re-onboard a new participant with the same party IDs and recover Canton Coin balances and name service entries from the SVs. Without either, and without KMS-held keys, "it is not possible to recover the relevant participant secret keys to prove asset ownership". Put a restore drill on the calendar. Our cloud disaster recovery guide covers the general discipline.

Monitoring

Compose ships no monitoring stack, but it exposes the data. Metrics are on by default at http://validator.localhost/metrics and http://participant.localhost/metrics in Prometheus format (metrics page), and since 0.6.5 the bundle includes a Grafana dashboard folder for validator operators. The apps expose /readyz and /livez endpoints.

The single most useful signal is splice_store_last_ingested_record_time_ms. The validator health page says that for a validator collecting liveness rewards, ingestion happens every round, so "you should expect your lag to never go above 20min". Alert on it, and on traffic balance and disk. For wiring this up, see our observability guide.

How rewards and traffic work

The docs describe mechanics, not earnings; so does this section. Rewards are computed in rounds. According to the tokenomics overview, "A round starts every 10 minutes", and each round records activity records whose weight sets the share of minting. Three kinds matter to a validator operator:

Validator liveness. "In each round, each live validator records its liveness activity" with a ValidatorLivenessActivityRecord, rewarding it "for being available to validate and confirm transactions" (validator liveness). The Compose guide warns that downtime means "losing out on rewards".
Validator reward coupons. A ValidatorRewardCoupon is created for Canton Coin transfers through AmuletRules_Transfer and when coin is burned, including for traffic purchases.
App rewards. Since CIP-0078, "only featured applications get a reward". Featured status is requested from the Tokenomics Committee.

For parties hosted on your node, the validator app mints these automatically.

Traffic is the cost side. The traffic fees page says sequencers track each validator participant's traffic. There is a free base rate that refills over a window, then paid extra traffic, bought by burning Canton Coin at a USD per MB price. When both run out, "attempted writes are denied by the sequencer". Traffic is per participant, so every party on your node shares one balance, and background work such as reward collection and ACS commitments consumes it too. The Compose deployment tops up automatically, tuned with:

export TARGET_TRAFFIC_THROUGHPUT=20000 # target throughput in bytes/second
export MIN_TRAFFIC_TOPUP_INTERVAL="1m" # minimum interval between top-ups

If you exhaust even the free allowance, the docs' remedy is to pause the validator app and participant for about twenty minutes so it refills.

Run it yourself or have it run

The Canton Foundation's own form asks the right question: why run it yourself rather than use an existing operator? The decision is closer to build versus buy than to "spin up a node".

Running it yourself makes sense when:

you are an application provider and want your own participant, with your own backups of your application's data
you need direct control of keys, KMS placement or data residency
you already run 24/7 on-call for Postgres and containers

Having it run makes sense when:

you need a hosted party or wallet, not an institution-grade node
nobody on the team will own upgrade dates, restore drills and a 20-minute lag alert
the approval and sponsorship process is a distraction from your product

Whoever runs it, this is the checklist to hold them to:

Tokenomics Committee approval and a named SV sponsor
One static egress IP per network, verified against every SV's Scan and sequencer
DevNet or TestNet node used to rehearse each upgrade before MainNet
OIDC authentication enabled; Admin API not exposed
Party hint chosen deliberately (it is permanent)
Identities backup in a secret manager, refreshed after any reset
Postgres dumps at least every 4 hours, validator app before participant
A tested restore, well inside the 30-day pruning window
Alerts on ingestion lag over 20 minutes, readiness, traffic balance and disk
Subscriptions to the validator-announce and tokenomics-announce lists, plus the #validator-operations Slack channel, for upgrade and LSU dates
A documented upgrade path that replaces the full bundle, never only IMAGE_TAG
A decision on KMS before first deployment, since it cannot be added later

InfoDive Labs has operated a validator on the Canton Network MainNet since July 2026, with the Docker Compose deployment described here; the short version of this post, with its sources, is on our validator page. If you are weighing this for your own team, we are happy to compare notes: get in touch.