The 33% Rule: How Stakers Decide Which Apps Get Secured

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

The Allocation Problem

Any network that offers shared security has to answer an allocation question: when there is a fixed budget of issuance and many applications that could use it, who decides which applications receive it? The answer shapes the ecosystem more than almost any other parameter. It determines what an application has to do to launch securely, who holds influence over the network's direction, and whether security spending tracks real support or simply tracks capital.

Existing designs have answered it in several ways. Some auction access, so applications that can raise and lock the most capital win. Some leave it to a governance vote on the base chain. Some leave it entirely to a market in which each application pays operators directly out of its own treasury. Each approach has costs. Auctions favor well-funded teams. Governance votes are slow and political. Pure markets leave new applications with nothing to offer until they already have value.

Canopy answers it with a single onchain rule. An app's committee receives protocol issuance if, and only if, at least a governance-defined share of all stake on the Security Root is directed toward it. That share is currently set at 33%. This piece explains exactly how the rule is computed, why restaking changes its character, what subsidized status is worth, and where the design's limits are.

The Rule

Every stake on the Security Root carries a list of committees it is directed toward. The protocol aggregates those lists and, each block, evaluates every committee against the threshold:

// total stake on the Security Root, validators and delegates combined
TotalStake = AllValidatorStake + AllDelegateStake

// stake directed toward this app's committee
CommitteeRestake = ValidatorStakeForApp + DelegateStakeForApp

RestakePercentage = (CommitteeRestake / TotalStake) * 100
IsSubsidized      = RestakePercentage >= SubsidizationThreshold

Three details in this formula matter.

The denominator is total stake, not total supply. Unbonded CNPY, including every token held as a BEP-20 balance on BNB Smart Chain, is excluded from both sides of the ratio. The rule measures the preferences of those who have put collateral at risk, and nobody else.

The numerator counts validators and delegates equally. A delegate contributes no voting power to consensus, but its stake counts toward the subsidy calculation exactly as a validator's does. This is a deliberate choice, and it is what gives delegators a direct role in allocation.

The threshold is a governance parameter, SubsidizationThreshold, changeable through a parameter-change proposal approved by more than two-thirds of Security Root committee voting power. The 33% figure is the current configuration, not a constant. The protocol also exposes the inputs publicly: the supply tracker reports staked and delegated totals per committee, so any committee's position relative to the threshold can be read directly from chain state.

Why Restaking Makes the Threshold Non-Exclusive

If stake could be directed to only one committee, a 33% threshold would be a hard ceiling on the ecosystem. At most three committees could qualify at once, and every new app would be competing for a share of a fixed pie. Canopy does not work that way, because stake is restaked rather than split. A bond directed toward four committees counts in full toward each of the four.

An example: Total stake is 200 CNPY: validator V1 holds 50, V2 holds 50, and V3 holds 100. V1 and V2 both restake toward committee C1, and V1 also restakes toward C2. V3 restakes toward C3. C1 holds 100 of 200 (50%) and qualifies. C2 holds 50 of 200 (25%) and does not. C3 holds 100 of 200 (50%) and qualifies. V1's 50 CNPY is counted in both C1 and C2, and committee percentages across the system sum to 125%.

Taken to its limit, if every staker listed every committee, every committee would sit at 100% and all would qualify. The real constraints are elsewhere. First, the number of committees a single stake can list is bounded by a Security Root governance parameter. Second, for validators, each additional committee has a real cost: another app node to operate, and the full bond exposed to slashing in one more consensus instance. Third, as the next section shows, each additional subsidized committee dilutes the reward for all the others. The threshold therefore does not ration a fixed number of slots. It filters for apps that a large enough share of bonded stake is willing to back, given those costs.

This also changes what 33% means in practice. It is not a claim that one-third of the network is exclusively devoted to an app. It is a claim that stakers controlling one-third of total bonded collateral have each chosen to include that app among the committees they support.

What Subsidized Status Pays

Each Security Root block reward is split in two. 70% goes to the DAO Treasury and 30% is divided equally among all subsidized committees. During the first halving period, with a block reward of 80 CNPY and roughly 4,320 blocks per day, that committee allocation is 24 CNPY per block. The per-committee share depends only on how many committees qualify:

• 1 subsidized committee: 24.0 CNPY per committee per block, 103,680 per day
• 2 subsidized committees: 12.0 CNPY per committee per block, 51,840 per day
• 3 subsidized committees: 8.0 CNPY per committee per block, 34,560 per day
• 5 subsidized committees: 4.8 CNPY per committee per block, 20,736 per day
• 10 subsidized committees: 2.4 CNPY per committee per block, 10,368 per day
• 20 subsidized committees: 1.2 CNPY per committee per block, 5,184 per day

Figures assume the initial 80 CNPY block reward and a 20-second block time, and halve with each halving period.

The split is equal, not proportional to stake. A committee at 34% receives the same protocol allocation as one at 90%. Stake above the threshold adds collateral behind the app, which raises the cost of attacking it, but it does not increase the app's share of issuance. That separates two things that are often conflated: the threshold decides who receives issuance, while total committed stake decides how secure each app is.

Within a committee, the default distribution sends 70% to the validator that produced the app block, 10% to a CNPY delegate, and 10% each to a validator and a delegate staking the app's Native Token. Delegate and Native Token recipients are chosen by stake-weighted random selection per payout rather than paid pro rata, so individual outcomes vary over short periods. Apps can change this split in their own software.

The dilution in the list above is intended. As more apps qualify, protocol issuance alone becomes a thinner basis for any single committee's economics, which pushes apps to fund their own committees rather than rely indefinitely on the Security Root.

Who Decides

The allocation decision is made by two groups, and they face different costs when making it.

Validators decide by joining committees. Joining means running the app's node software, participating in its consensus, and accepting that the validator's full bond is slashable for double-signing or sustained non-signing in that committee. A validator's committee list is therefore a statement backed by operational work and collateral at risk. Validators also have information advantages. They run the software, see its behavior under consensus, and experience directly whether an app is stable enough to secure.

Delegators decide by listing committees on a delegated stake. They do not run nodes, and under the current model they are not exposed to validator slashing. Their stake still counts fully toward each listed committee's percentage. This makes delegators the lower-cost signal in the system: their choices move committees toward or away from the threshold without adding operational load. The whitepaper describes delegators as the community-driven gatekeepers of subsidization for this reason.

Both groups make and change their decisions through the same transaction. edit_stake updates a stake's committee list at any time, so allocation is continuous rather than periodic. A committee can cross the threshold, or fall below it, in any block as stakers adjust their lists or as total stake changes. There is no auction window and no voting period. The allocation at any height is simply the aggregate of every staker's current configuration.

App teams are notably absent from this list. A team cannot buy subsidized status, lock capital to reserve it, or petition governance for it. What a team can do is build something that validators are willing to run and that stakers are willing to back, and it can add incentives of its own (covered below) to make backing it more attractive.

How This Compares

The 33% rule is easier to evaluate against the allocation mechanisms it was designed as an alternative to. The descriptions below are simplified and focus only on how each design decides which applications receive security.

Slot auctions. Polkadot originally allocated parachain slots through periodic auctions in which projects, or their communities through crowdloans, bonded DOT for the lease period. Allocation tracked the capital a project could lock up. Polkadot has since moved toward purchased blockspace (coretime), which is a market mechanism rather than an auction, but in both cases the application is the buyer.

Validator markets. In Avalanche's model, an application runs its own validator set and must attract and pay those validators, typically in its own token. Allocation is a bilateral market between each application and operators, with no shared issuance directing security toward new applications.

Opt-in restaking markets. EigenLayer lets Ethereum stakers restake toward services that choose to use them. Operators opt in to services based on the rewards those services offer. The restaking mechanic is similar to Canopy's, but there is no protocol-level issuance that the aggregate of restaking decisions allocates. Each service funds its own rewards.

Canopy. Canopy combines restaking with a shared issuance pool and lets the aggregate restaking decision allocate that pool. An app does not need to pay for security up front, and it does not need governance approval. It needs enough independent stakers to include it. The trade-off is that apps without existing traction depend on stakers' willingness to back them early, which the next section addresses.

Beyond the Threshold

Protocol issuance is one of three funding sources for a committee, and for most apps over the long run it is not meant to be the main one.

Subsidy transactions. Anyone can send CNPY directly into a committee's reward pool with a subsidy transaction. The transaction includes an opcode field that can carry distribution instructions: a payout schedule over a defined period, eligibility rules such as a minimum stake in the app's Native Token, or quality-of-service criteria that the committee can verify from app data. This works whether or not the committee is above the threshold. An app below 33% can still have a funded committee if its team or community chooses to fund one, and an app above it can supplement protocol issuance to compete for validator attention.

Native Token rewards. Because the Certificate Result is processed on both the Security Root and the app, an app can pay the same recipients in its own token every block. This is the traditional model of paying validators in the network's native asset, applied inside a committee. It is also what gives apps a way to become attractive to stakers before they reach the threshold, and a way to retain them after protocol issuance declines.

The interaction between the three sources is where the design's incentives become clear. The 33% rule decides who gets the shared protocol budget. Subsidies and Native Token rewards let apps pay for support directly. Over time, as CNPY issuance halves roughly every two years, the balance is expected to shift from the first toward the other two.

Sources

• State Machine: Subsidization, Rewards, Slashes
• Canopy Economics
• Capital Efficient Restaking
• Utility
• Canopy whitepaper v2.0 (June 2026), sections 1.5 to 1.8, 9.3, 9.5, 9.10