So You Want to Run a Canopy Validator?

By Adam Liposky, co-founder. Part of a series on how Canopy works underneath the apps.

Why This Post Starts With Validators

Every app built with the Canopy Stack begins life the same way. It has its own state machine, its own block timing, and its own token, but it does not have its own validator set. It borrows one. The validators that secure it are Canopy validators who have chosen to join its committee, and the security it inherits is the CNPY those validators have bonded.

That makes validators the most direct link between the token and the product. When a builder ships an app on Canopy, the question of whether that app is secure, and whether it receives protocol issuance, is answered by the people who bond CNPY and decide where to direct it. There is no way to do any of that with a BEP-20 balance on BNB Smart Chain. Bonding, restaking, committee membership, rewards, slashing, and governance all happen in the Security Root's state machine, which only recognizes native CNPY.

This post is for operators considering whether to run a validator. The first half is a guide to what the job involves: hardware, committee selection, slashing, unbonding, and governance. The second half answers the questions we hear most often from people who are deciding. It describes the system as it works today, including the parts that carry real risk.

What a Validator Does on Canopy

On most proof-of-stake networks, a validator secures one chain. On Canopy, a validator bonds CNPY once on the Security Root and then chooses which committees to restake that bond toward. Each committee runs consensus for one app. The Security Root itself runs as a committee too, with chain ID 1, under the same rules as any app.

For every committee in its stake configuration, a validator runs that app's node software, configured with the same validator key it uses on the Security Root, and participates in NestBFT consensus with the other committee members. After each app block, the elected leader submits a Certificate Result to the Security Root. That transaction records who gets rewarded, who gets slashed, the state of any swap orders the committee is witnessing, and an optional checkpoint.

The practical consequence is that one bond does several jobs at once. A validator with 10,000 CNPY bonded and four committees listed has 10,000 CNPY of voting power in each of the four, and the full 10,000 is at risk in each of the four. That is the core trade-off of the role, and most of the decisions below follow from it.

Hardware

The baseline requirements are modest. The node repository offers two configurations, and the recommended one for production includes a monitoring stack of Prometheus, Grafana, and Loki behind a Caddy reverse proxy.

Validator only: 4 GB RAM, 2 vCPU, 25 GB storage minimum. 8 GB, 4 vCPU, and 100 GB recommended.
Validator plus monitoring stack, recommended: 8 GB RAM, 4 vCPU, 100 GB storage minimum. 16 GB, 8 vCPU, and 200 GB recommended.
Operating system and architecture: Ubuntu 26.04 LTS is recommended. Both x86_64 and 64-bit ARM are supported.
Swap: recommended on minimum configurations, since the monitoring containers can spike in memory use during alert storms.

These figures describe a single Security Root node. Every additional committee you join means running another app node, so plan headroom accordingly, and read each app's own node requirements before joining its committee.

Networking requirements apply to validators only; full nodes need no custom configuration. You need a public static IP or a domain with wildcard DNS, inbound TCP on 9001 for peer-to-peer traffic, and inbound 443 for HTTPS access to the wallet, explorer, and monitoring endpoints.

Committee Selection

Once you are staked on the Security Root, the most consequential ongoing decision is which app committees to add. Joining one is mechanically simple: run the app's node alongside your existing one using the same validator key, then submit edit_stake with the new chain ID added to your committee list. No new key, no new bond, no unstaking.

What is harder is deciding whether you should. Each committee you add changes your position in four ways.

What you can be paid increases. Each subsidized committee receives an equal share of the 30% of Security Root issuance set aside for committees. At the initial 80 CNPY block reward, that is 24 CNPY per block split across every subsidized committee. Within a committee, the default split sends 70% to the validator that produced the app block, so your expected share scales with how often you lead, which is weighted by stake. Apps can also pay the same recipients in their own token, because the Certificate Result is processed on both the Security Root and the app, and anyone can top up a committee's reward pool through a subsidy transaction.

Your slashing exposure increases. Your full bond is slashable in every committee you join. A fault in one app's consensus reduces the collateral backing all the others. This is correlated risk, and it is the price of capital efficiency.

Your operational load increases. Another node to run, update, and monitor. Another set of release notes to track.

You shape which apps get funded. A committee qualifies for protocol issuance only when at least 33% of all stake on the Security Root, validators and delegates combined, is directed toward it. Your committee list is a vote, backed by collateral, on which apps the network should support. The 33% Rule covers the arithmetic in detail.

In practice, operators evaluating a committee tend to ask a short set of questions. Is the app stable under consensus, which running its node on a test machine before joining is the best way to find out. Is the committee subsidized, or close to the threshold, and what does the app pay in its own token. Does the app define slashing conditions beyond the two defaults, because apps can add their own and you inherit them when you join. And how active is the team, and how quickly do they ship fixes.

Committee lists can be changed at any time with edit_stake, so allocation is continuous. You can add a committee when an app proves itself and remove one if it stops being worth the risk.

Slashing

By default, Canopy slashes for exactly two things.

Non-signing: missing 2,160 out of a moving window of 4,320 blocks. At a 20-second block time, that is roughly twelve hours of missed blocks within about a day. The penalty is 1% of bonded stake.

Double-signing: signing two different blocks at the same height for the same app, which violates BFT safety. The penalty is 10% of bonded stake.

Slashed tokens are burned, not redistributed. Slashes are processed only on the Security Root. Both the thresholds and the penalties are governance parameters, so read live values from the network rather than relying on these figures indefinitely.

Because one bond backs several committees, the protocol includes a circuit breaker. MaxSlashPerCommittee caps the number of slashes a single committee can apply per block. If the cap is hit, the offending validators are ejected from that committee, which stops both their participation and further slashing there. This is designed to prevent a bug or attack in one app from cascading into the collateral securing every other app.

The operational guidance follows from the two conditions. Non-signing is an uptime problem: use restart policies, run the bundled monitoring stack with alerts routed somewhere you will actually see them, and pause your validator before planned maintenance. Double-signing is almost always a failover problem, meaning two machines running the same validator key at the same time. Never run an active-active setup, and test any standby procedure carefully.

Unbonding and Pausing

Canopy gives validators two ways to step back.

Pause temporarily removes a validator from all of its committees, which is the right move before a server migration or extended maintenance. A validator can remain paused for up to MaxPauseBlocks, currently about a month, after which it is automatically unstaked. When you unpause, the protocol expects you to resume consensus on every committee immediately, so fix whatever caused the pause first.

Unstake begins a permanent exit. The bond is not returned right away. Validators wait through an unbonding period of about a month, and delegates about seven days, set by the governance parameter unstaking_blocks. During that window the bond remains slashable. This is intentional. It covers misbehavior that is discovered after the fact, and it raises the cost of long-range attacks, where keys that once held a supermajority try to rewrite history after their stake has been withdrawn.

One constraint catches people out: edit_stake can increase a bond but never lower it. There is no partial unstake. If you want to reduce your position, the path is a full unstake and a new stake.

Governance Duties

Running a validator on the Security Root committee comes with governance authority, and that authority is not ceremonial.

Canopy has two governance tools. Polls are non-binding sentiment checks that any account or validator can start or vote on. Proposals are binding and come in two forms: parameter changes, such as the subsidization threshold, the unbonding period, or fee levels, and transfers from the DAO Treasury, which receives 70% of every block reward. A proposal finalizes only when more than two-thirds of Security Root committee voting power has approved it.

The way validators approve is specific to Canopy. A proposal circulates as signed JSON, and each validator configures its node to accept or reject that proposal's hash. The node then enforces that choice at both the mempool and BFT level. A proposal cannot be submitted before its startHeight, which guarantees a review window. The expected pattern is a poll to gauge sentiment followed by a proposal to act on it.

In other words, validators collectively decide how the treasury is spent and how the protocol's economic parameters evolve. Operators who join the Security Root committee should expect to read proposals, form a view, and configure their nodes accordingly.

Q&A

Can I validate with the CNPY I bought on an exchange?

Not as-is. CNPY bought on an exchange or a DEX is a BEP-20 balance on BNB Smart Chain. It cannot be bonded, cannot count toward stake, and cannot be directed to a committee. You need to convert it to native CNPY first. Unwrapping CNPY walks through the process step by step.

Do I have to validate the Security Root to validate an app?

No. The Security Root runs as its own committee, and validators can secure app committees without joining it. The trade-off is governance: binding proposals are decided by Security Root committee voting power, so a validator that skips committee 1 has no direct vote on parameter changes or treasury transfers.

How many committees should I join?

There is no single right answer. Each committee adds potential rewards, another node to operate, and another consensus instance in which your full bond can be slashed. The number of committees a single stake can list is also capped by a governance parameter. A reasonable approach is to start with the Security Root, run an app's node on a test machine before adding its committee, and expand as you build confidence in each app's stability.

How am I paid, and in what?

Rewards come from each committee's reward pool, which can be funded three ways: protocol issuance if the committee is subsidized, subsidy transactions from anyone who wants to fund it, and the app's own Native Token rewards. Because the Certificate Result is processed on both the Security Root and the app, you can receive CNPY and the app's token from the same block. The default within-committee split gives 70% to the block producer and 10% each to a CNPY delegate, a Native Token validator, and a Native Token delegate, though apps can change it.

Should I auto-compound?

It is the default, and it is what most operators choose. Rewards are added to your bond automatically. If you route rewards to your output address instead, the protocol deducts an early-withdrawal penalty and burns it. Compounding also increases your voting power, and with it your exposure, so treat it as a risk decision and not only a reward one.

If my server goes down for an hour, will I be slashed?

Under current parameters, no. An hour is about 180 missed blocks, well short of the 2,160 out of 4,320 needed to trigger the non-signing slash. You will miss rewards during the outage. Extended downtime is a different story, and the protocol can auto-pause unhealthy validators, so get alerts in place before you need them.

Can I run a hot standby for redundancy?

Only if it is genuinely passive. Two machines signing with the same validator key at the same time is the most common route to a double-sign, which costs 10% of your bond. If you build a failover procedure, make sure it is impossible for both instances to be active at once, and test it before relying on it.

How do I migrate to a new server?

Pause the validator first. Then update DNS, stand up the new node, stop the old one, transfer keystore.json, validator_key.json, and .env, and start the new node from a snapshot. The docs include a full migration runbook that typically involves five to ten minutes of downtime.

Why run a validator instead of delegating?

Delegation is a real alternative. Delegates bond CNPY, list committees, count toward the 33% threshold, and are eligible for the delegate reward share, all without running infrastructure. Under the current model they are not exposed to validator slashing, and their unbonding period is about a week rather than a month. Validators take on operational work, slashing risk, and a longer exit in return for the larger block-producer reward share, direct participation in consensus, and governance authority on the Security Root committee. One detail to settle before you submit either one: a stake’s type is fixed when it is created, so moving between validating and delegating means unstaking and starting again.

What happens to my stake if an app I secure graduates?

An app uses Security Root validators' collateral only for as long as the Security Root is its designated source of security. When an app switches Security Roots, including switching to itself, it stops drawing on your bond. Your stake is unaffected, but that committee will no longer produce rewards for you, so revisit your committee list when an app announces a transition.

Is the software production-ready?

Mainnet is live and the client is under active development, with releases shipping frequently for consensus hardening, indexer improvements, and operator tooling. Operators are responsible for their own setups. Read the changelog for every release, watch the support channels, and do not stake more than you are prepared to put at risk.

‍Which keys do I need, and where do they live?

Two, and the separation is the point. The operator key sits on the server and signs the validator's consensus work. The output key is created separately, belongs off the server, and is the one that controls the bond and the rewards. If someone gets into the host they can pause or unstake the validator and impersonate it on the peer-to-peer layer, but they cannot move the funds, because only the output key can change the output address. Keep little or nothing in the operator account beyond what transaction fees need, and back the output key up offline.

Who Should Consider This

Validating on Canopy suits operators who are comfortable running production Linux infrastructure, who want to be paid for securing a growing set of apps rather than a single chain, and who are willing to take part in governance. It also suits teams that want a say in which apps the network funds, since validator committee lists are one of the inputs to that decision.

If that describes you, start with the Setup and Recommendations page, stand up a node from a snapshot, and introduce yourself in the support channel on Discord. If it does not, delegating native CNPY toward the apps you want to support does much of the same work for the network without the operational burden.

Nothing in this post is financial advice.

Sources