Canton Network Validator Node: Requirements, Operations, and Economics After CIP-0096

Once the validator is on MainNet, the job is to keep it healthy, and there’s no shortage of ways for that to go wrong: a slow database, a dropped connection, a missed upgrade, a credential nobody noticed had expired. Backups and recovery procedures need to work when they are actually needed. And since CIP-0096 removed liveness rewards, simply keeping the node online no longer earns CC.

What follows covers what it actually takes to run one: the requirements, the onboarding process, what it costs, and what changed under CIP-0096.

What a Canton Network validator node actually does

The word validator can be misleading if you come to Canton from proof-of-stake networks. It does not stake tokens for the right to produce blocks, nor does it compete to produce blocks or validate every transaction on a shared global ledger. A Canton Network validator node hosts parties and processes the transactions that affect them. Each participant sees and stores only the data relevant to the parties it hosts, which is a core part of Canton’s privacy model.

Applications interact with Canton through a participant node. It stores contract and identity data required to process Daml transactions and provides access to the Ledger API used by applications. Network-specific tasks are handled by a validator application, which manages the validator’s interactions with the Global Synchronizer, including registration, traffic, participant distribution, and wallet automation. Both components store their state in PostgreSQL.

A validator also includes the Splice application layer. This provides the wallet functionality used for Canton Coin (CC), traffic purchases, and related automation. The validator connects outward to the Global Synchronizer through sequencer endpoints and receives only the transaction data relevant to its hosted parties. This relationship between the participant, validator application, and Global Synchronizer is central to how Canton Network works.

Validator vs Super Validator

A standard validator and a Canton Super Validator participate in the same network, but their responsibilities are very different.

When does running your own validator make sense?

Operating a dedicated validator is most relevant when your organization needs direct control over how its parties and applications participate in Canton. Typical cases include:

• Running a Daml application that generates transactions on the network
• Hosting parties for your own organization or customers
• Controlling node operations, access, security, and recovery procedures internally
• Integrating Canton activity with the existing enterprise infrastructure
• Supporting use cases such as Canton smart contract development or tokenizing real-world assets on Canton

When you may not need your own validator

If your company only needs access to the existing Canton application, has no reason to manage the validator environment directly, or expects relatively low activity, partnering with another validator operator is the simpler path.

Canton validator requirements before you deploy

Sizing the hardware is the easy part. Before you deploy anything, you still need to pick a network environment and a deployment model — decisions that matter more than the spec sheet.

Hardware and database requirements

Canton provides three starting configurations for validator and participant containers. These figures do not include Kubernetes or ingress overhead.

• Experiments: 1 CPU and 6 GB of memory; database with 1 CPU, 1 GB of memory, and 1 GB of storage.
• Production with little activity: 2 CPUs and 8 GB of memory; database with 2 CPUs, 4 GB of memory, and 10 GB of storage.
• Production for an app provider with moderate activity: 2 CPUs and 16 GB of memory; database with 2 CPUs, 4 GB of memory, and 100 GB of storage.

These are starting points, not fixed sizing rules. Monitor CPU, memory, and storage against the validator’s actual workload.

Database latency can become a bottleneck even when compute is sufficient. For managed PostgreSQL, the documentation recommends placing it in the same region and zone as the cluster. A remote database can slow the validator even when CPU and memory are sufficient.

DevNet, TestNet, and MainNet

Canton has three network environments: DevNet, TestNet, and MainNet. Application providers typically use all three, moving changes through DevNet and TestNet before MainNet. Teams that use DevNet only to practice validator operations do not necessarily need to pass through TestNet before joining MainNet. DevNet receives upgrades first, followed by TestNet and then MainNet.

How to run a Canton validator: the onboarding process

Infrastructure is ready long before MainNet access actually is. The validator request still goes through the Tokenomics Committee review, which takes about two weeks. You can submit the Canton Foundation form before you have a sponsor, but a Canton Super Validator is required for the technical onboarding that follows.

Validator onboarding steps and timing

Plan MainNet onboarding with extra lead time. The 2–7 day estimate applies only to egress IP allowlisting. Request the onboarding secret shortly before deployment: it’s single-use and expires after 48 hours.

Authentication also needs to be ready before a production node goes live. Canton validator components use JSON Web Tokens (JWTs) issued by an external OIDC provider to authenticate services and UI users. Unauthenticated deployments are supported, but the official documentation strongly discourages them for production.

Common causes of early incidents

A new validator can fail before application traffic ever reaches it. Some of the first things to check are:

• An onboarding secret that has expired or has already been used
• Traffic leaving through an IP address different from the one on the allowlist
• Reusing an egress IP across network environments
• Incorrect OIDC audience, user, or client configuration
• Database or connectivity problems discovered only after deployment

The safest way to schedule onboarding is therefore to work backward from the intended deployment date. Approval and allowlisting can take days or weeks, while the final onboarding credential has a much shorter lifetime.

What a Canton validator node actually costs

The total depends less on any single line item and more on how much you’re running in-house versus offloading, and how active the validator actually is. Any Canton validator node cost estimate should cover both infrastructure and the work required to keep the service usable over time. If the validator supports a custom application, what Canton development costs are a separate budget question from running the node itself?

Canton validator TCO

DevNet and TestNet resets are an easy line item to miss — each one means redeploying the node, which makes test environments a recurring engineering cost, not just an infrastructure one.

Traffic is part of the operating model

Traffic isn’t free past a point, and that point arrives faster than most teams expect. Each validator receives a free base-rate traffic allowance that replenishes over time, and all parties hosted by that validator use the same balance. Once the allowance is exhausted, messages use purchased additional traffic. If no additional balance is available, new messages are rejected until the base-rate allowance replenishes or more traffic is purchased.

Extra traffic is purchased by burning Canton Coin (CC). The extraTrafficPrice defines the USD price per megabyte, while the amount of CC required for a purchase depends on the current USD-to-CC conversion rate. Canton also supports automatic traffic purchases, so the validator does not have to rely on manual top-ups.

What affects traffic cost and consumption

• Size of the data being submitted
• The number of recipients who receive a message
• Available base-rate traffic
• Current extraTrafficPrice
• Frequency and shape of application transactions

This is why transaction count alone is a weak basis for forecasting network cost. Canton charges according to sequenced traffic, including the data sent and the cost of delivering it to recipients. Some protocol activity outside ordinary application transactions also consumes traffic.

What Canton validators earn after CIP-0096

Under CIP-0096, validatorFaucetCap fell to $0 on April 30, 2026, ending liveness rewards. Activity rewards remain the validator earning mechanism, while how Canton Coin rewards are distributed also distinguishes app rewards and other protocol allocations.

Canton validator rewards after CIP-0096

The current Canton validator rewards model centers on activity rather than uptime.

App rewards belong to Canton’s application economy and apply only to featured apps; Development Fund allocations are separate from validator rewards.

How activity turns into validator rewards

The mechanism is worth restating because people still expect uptime alone to pay — since CIP-0096, it hasn’t. Validator activity rewards depend on the qualifying CC activity associated with the node.

When a qualifying activity burns CC, Canton creates a ValidatorRewardCoupon for the associated validator. Its weight reflects the CC burned and contributes to the validator’s share of issuance.

Coupons have no fixed CC value. Rounds start roughly every 10 minutes, about 52,560 times per year, and the CC-USD rate for each round is the median of the rates published by Super Validators.

Running a Canton validator in production

Key access needs real controls, not a shared credential nobody rotates. Backups need to actually be tested, not just scheduled — and upgrades should follow a process the team has already run, not one it’s improvising under pressure. Good reporting also matters when something goes wrong, and you need to trace what changed. If you use a key management system (KMS), it becomes part of that routine as well.

What your team should monitor

• Node and Global Synchronizer connectivity: alert when the validator loses its expected connection.
• PostgreSQL health and latency: Watch for degradation that can affect node performance.
• Traffic balance: Identify unusual consumption before available traffic becomes a constraint.
• Failed transactions: Investigate sustained increases rather than isolated failures.
• CPU, memory, and storage: Track capacity against the node’s normal workload.
• Backups and credentials: Flag failed backups and approaching credential or certificate expiration.

CC Suite can support monitoring and operational management across the Canton infrastructure.

Self-hosted, Node-as-a-Service, or partner-operated?

Which model fits comes down to how fast you need to launch, whether your team already knows how to run infrastructure like this, and what compliance requires.

Self-hosted

Running the validator yourself gives your team direct control over infrastructure, security, upgrades, monitoring, and recovery. This model makes the most sense when those responsibilities need to remain in-house or when the validator is tightly integrated with your own applications and enterprise systems.

Node-as-a-Service

A Canton Node-as-a-Service lets you run a validator without building an internal team to manage it 24/7. An approved provider takes care of the infrastructure and day-to-day operations, while your organization retains its own identity and permissions on Canton. The Canton Foundation maintains a list of approved Node-as-a-Service providers.

Partner-operated

If your organization only needs access to an existing Canton application, there’s often little reason to operate the validator yourself. Another operator can host the infrastructure, while your team focuses on how users connect, authenticate, and interact with the application, including any requirements around Canton wallet development.

How PixelPlex can support the validator and the application

A validator without an application behind it is infrastructure with nothing to do, which is why most engagements start with defining what the node will actually process, not just standing it up. PixelPlex can handle the infrastructure and build the Daml application that runs through it. In projects involving Canton for financial institutions, this also means fitting the validator into existing systems, controls, and operating processes.

Our work can cover:

• Validator setup and onboarding: Environment preparation, network access, configuration, and MainNet readiness.
• Infrastructure hardening: Security controls, key management, backups, recovery, and deployment automation.
• Node operations and monitoring: Ongoing maintenance, upgrades, incident handling, and operational visibility.
• Daml development services: Smart contracts and application logic built for Canton workflows. For application providers, Daml development defines the contract logic and workflows behind that activity.
• Canton smart contract development: Designing and implementing contract logic for applications running on Canton.
• Application integration: Connecting Canton applications with enterprise systems, APIs, and existing business processes.
• Canton wallet development: Wallet and user-access flows for applications running on the network.
• Audit and security work: Reviewing Daml logic, access controls, integrations, and deployment architecture before production use.
• CC Suite — Canton Network solutions: Tooling for monitoring and managing Canton infrastructure and activity.

Since CIP-0096, a validator’s economics rise or fall with what runs through it, not with how long it’s been online. PixelPlex can support both the infrastructure and the application layer that creates that activity.

Conclusion

Running a Canton Network validator node in 2026 is less about meeting hardware specifications and more about deciding what role the node will play in your application and operating model. None of that — connectivity, traffic, security, monitoring, recovery — is a one-time setup cost. Those responsibilities continue for as long as the node runs.

After CIP-0096, the business case is even more closely tied to actual network activity. A validator makes the most sense when it supports applications, users, or hosted parties with a clear reason to operate on Canton. If you are planning a validator deployment or building an application around it, explore our Canton Network development services.