A Delegator's Checklist: Evaluating an App Before You Stake

Part of a series on how Canopy works underneath the apps.

Delegating on Canopy is not delegated proof of stake. A delegator does not choose a validator, does not add to any validator's voting power, and does not share a validator's penalties. A delegation is a stake transaction marked as a delegation, with a list of app committees attached. That stake counts toward each listed committee's subsidization threshold and makes the delegator eligible for the delegate share of those committees' rewards.

The decision a delegator makes is therefore not which operator to trust. It is which apps the network should support. This guide explains how that differs from delegation on other networks, what delegators are and are not exposed to, and what to check about an app before directing stake toward it.

How Delegation Differs From DPoS

On most delegated proof-of-stake networks, a delegator lends stake to a specific validator. The delegation adds to that validator's voting power, the delegator shares in its rewards and often its slashing, and the main decision is about operator quality.

Canopy separates those roles. Consensus for each app is run by validators who bond their own stake and opt in to its committee. Delegated stake never enters the validator set. It cannot affect an app's liveness, it does not sign blocks, and under the current model it is not exposed to slashing.

What delegated stake does affect is allocation. Each block, the protocol checks every committee against the subsidization threshold, currently 33% of total stake, and that calculation counts validator and delegate stake equally. A delegation that lists an app's committee moves that app toward protocol issuance. This is why the whitepaper calls delegators the gatekeepers of subsidization, and why The 33% Rule is the companion to this guide.

Delegators are paid for that role through the committees they list. By default, 10% of each committee's reward for an app block goes to a CNPY delegate restaked to that app, chosen by stake-weighted random selection. Apps can add Native Token rewards or subsidies on top.

Native Token rewards do not depend on subsidized status. An app below the threshold receives no protocol issuance, but it can still pay both validators and delegators in its own Native Token from its first block. Apps that do this give stakers a reason to support them before they qualify, which is often when that support matters most.

Canopy Delegators in a Nutshell

The most noticeable difference from delegation elsewhere is that delegators on Canopy are not exposed to slashing, at least under the current model. It helps to start with what slashing is meant to do. Canopy penalizes two provable faults, a validator going offline for too much of a moving window and a validator signing two conflicting blocks at the same height, and in both cases the penalty exists to make a specific kind of misbehavior expensive for the party who committed it. A delegator cannot commit either fault. Its stake never joins the validator set, it never signs anything, and it has no way to affect whether an app keeps producing blocks, so there is nothing for a slash to correct. Exempting delegators also fits what the protocol wants from them. The whitepaper describes delegation as the way non-technical holders participate, and because those holders help decide which apps receive protocol issuance, the design keeps the cost of taking part low. That choice is not free of trade-offs, since support that carries no risk of loss says less about a delegator's conviction than a validator's support does, and readers evaluating the allocation process should keep that in mind.

Delegations do have an unbonding period, though at seven days it is considerably shorter than the roughly one month a validator waits. For validators, the long window keeps stake slashable after an exit is requested, which means misbehavior that comes to light late can still be punished, and it closes off attacks in which keys that once controlled a supermajority are used to rewrite history after their stake is withdrawn. Stake that cannot be slashed does not need that protection, which is why a delegation can unbond faster. Some waiting period still serves a purpose, because subsidized status is recalculated against total stake every block, and if stake could arrive and leave instantly it would be easier to push a committee over the threshold for a short window and then withdraw.

To reduce chain bloat, rewards reach delegators in a less obvious way than most people expect. Rather than dividing the delegate share among every eligible delegator on every block, the protocol picks one delegate per payout, weighted by stake, so that a delegator holding twice as much stake is twice as likely to be chosen. Over a long enough period, each delegator ends up with roughly the same share a pro-rata split would have produced. The reason for doing it this way is practical: every app block produces a Certificate Result recording who gets paid, and listing every delegator across every committee in each one would make those records large and expensive to process, whereas a single recipient keeps them compact. What a delegator gives up in exchange is smoothness, since results over a week or two can look uneven even when the long-run expectation is fair.

Once a stake is created as a delegation or as a validation, that choice is permanent. The two roles carry different obligations, with validator stake being slashable and carrying voting power while delegated stake is neither, and allowing a stake to switch between them in place would open an obvious gap: a validator facing a penalty that has not yet been processed could convert to a delegation and avoid it. Requiring a full unstake and a new stake keeps the roles cleanly separated without preventing anyone from changing roles, since a delegator who later wants to validate simply starts over with a new stake.

Finally, rewards are added back into the bond automatically unless the delegator chooses otherwise. The whitepaper gives two reasons for making compounding the default, namely that it spares participants the routine work of claiming and restaking, and that it keeps rewards committed to the network's security rather than leaving it after each payout. Delegators who prefer to receive rewards directly can send them to an output address, but an early-withdrawal penalty is deducted first and burned, permanently removing those tokens from circulation instead of redistributing them to other participants.

The Checklist

These are the questions worth answering about an app before staking for its committee. Most can be checked from onchain data in the explorer or from the app's own documentation.

• Is the app live and producing blocks? Delegate rewards come from the blocks a committee certifies. An app that halts or stalls produces nothing to distribute.
• How healthy is its committee? Look at how many validators serve it and how concentrated its stake is. A committee that depends on a handful of operators is more exposed to downtime. Delegators cannot fix that, but they can see it.
• Where does it stand against the threshold? An app well below 33% will not receive CNPY issuance unless more stake follows, though it may still pay Native Token rewards. An app near the line is where a delegation makes the most difference, and also where subsidized status is least stable. An app far above the line receives the same protocol share as one just above it, because the subsidy is split equally.
• How many committees are already subsidized? The committee share of issuance is divided equally among all subsidized committees, so each additional qualifying app reduces the share for the rest.
• Does the app add its own rewards? Check whether it distributes its Native Token to committee members or funds its committee through subsidy transactions, and on what terms.
• Has the app disclosed its token design? Look for its supply, allocations, vesting, any minting authority, and how upgrades happen. An app that is clear about these is easier to evaluate.
• What are its plans for independence? An app that becomes independent moves its consensus to its own validator set. Check what the app has said about timing and what it means for its committee.
• Do you want this app to exist? A delegation is a public, onchain signal of support. It is reasonable to treat it as one.

Spreading Stake Across Apps

A single delegation can stake for multiple committees, up to a governance-set limit. Staking more apps does not divide your stake's weight among them. It does, however, help more apps toward the threshold, and every app that qualifies reduces the protocol share for every other subsidized committee. Choosing fewer apps concentrates support. The staking selection is not permanent - an edit-stake transaction updates it at any time without unbonding, so delegators can move support as apps launch, mature, or stall.

_{Nothing in this guide is financial advice.}

Sources

• Manage: Validator Transactions and Slashing
• State Machine
• Canopy Economics