CNPY Is Collateral First: How Canopy's Security Model Works

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

Overview

CNPY is the native asset of Canopy. At the protocol level it has one primary function: it is the collateral that gives validator signatures economic weight. Every other role the token plays (fee asset, reward unit, governance weight, and the input to committee subsidization) is derived from that function.

This matters for how the token relates to the Canopy Stack. Developers use the Stack to build Nested Chains, which we refer to here as apps: application-specific blockchains whose state machine is defined by the developer and whose consensus is run by a committee of Canopy validators. An app does not bring its own validator set on day one. It borrows one from the Security Root, and the security of that borrowed validator set is a function of how much CNPY is bonded behind it and how that bond is directed.

The sections below describe that mechanism in detail: how CNPY is bonded (or staked), how bonded stake is restaked across app committees, how the protocol decides which committees receive issuance, how rewards and slashes are processed, and what the difference is between the BEP-20 representation of CNPY on BNB Smart Chain and the native asset on Canopy mainnet. The goal is to describe how the system works, including its trade-offs, rather than to make a case for any particular action.

Architecture: Security Root, Apps, and Committees

Canopy separates two concerns that most blockchain designs bundle together: who validates, and what is being validated. The Security Root is where validators register and bond collateral. Apps are independent state machines with their own block timing, execution environment, and block storage. A committee is the link between the two: the subset of Security Root validators that has opted in to run consensus for a specific app.

A validator that joins a committee runs a full instance of that app's node software, configured with the same validator key it uses on the Security Root so its identity is consistent across both. Committee members connect over a dedicated peer-to-peer channel and run NestBFT, which uses VRF-based sortition for leader election, BLS signature aggregation, and immediate finality. The app receives its validator set from the Security Root over a websocket subscription. If that set changes mid-round, consensus resets while preserving BFT locks.

After each app block is committed, the elected leader submits a Certificate Result transaction to the Security Root. This transaction is the accounting layer of the whole system. It carries the committee's quorum decision on who should be rewarded from the committee's reward pool, who should be slashed for provable misbehavior, the state of any cross-chain swap orders the committee is witnessing, an optional checkpoint for long-range attack protection, and a flag to retire the committee entirely. Because the certificate is also included in the app's own block, reward decisions are processed on both sides: CNPY is paid on the Security Root, and the app can pay the same recipients in its Native Token.

The interface an app must implement is intentionally small: accept validator updates, execute a quorum and return a certificate, and accept a change of Security Root. That last method is what allows an app to graduate. An app can point itself at a different Security Root, or at itself, through a governance transaction, retaining its full block history. The Security Root itself runs as a committee under the same rules as any app, so validators can secure apps without also validating the Security Root.

CNPY as Collateral

A stake transaction on Canopy moves CNPY out of an account and locks it as a surety bond. The staker sets five parameters: the amount, the list of committees the bond is restaked toward, whether the stake is a validator (active consensus participant) or a delegate (passive), whether rewards auto-compound, and an output address that receives withdrawn rewards and the bond itself on exit. Voting power in consensus is proportional to bonded amount, and so is exposure to slashing.

The key design choice is that the entire bond is reused in every committee it is directed toward. A validator with 10,000 CNPY bonded and three committees listed does not split that stake three ways. It participates in all three committees with 10,000 CNPY of voting power in each, and that full amount is at risk for misbehavior in any of them. This is restaking in the literal sense: the same collateral backs multiple independent consensus instances simultaneously. The number of committees a single stake can serve is bounded by a governance parameter on the Security Root, not by the size of the bond.

The consequence for apps is that joining the network requires no new capital from the app team. The economic security an app inherits is the bonded CNPY of whichever validators opt in to its committee. The consequence for validators is a change in the risk model. Capital efficiency improves because one bond earns across several committees, but correlated exposure also increases, because a fault in one committee can reduce the collateral backing all the others. The protocol addresses this with a per-committee slash cap and automatic ejection, covered in the validator section below.

Exit is deliberately slow. An unstake transaction starts a governance-defined unbonding period (unstaking_blocks), during which the bond remains slashable. This window exists to cover evidence of misbehavior that surfaces after the fact and to raise the cost of long-range attacks, where old keys that once held a supermajority are used to rewrite history after their stake has been withdrawn.

Committee Subsidization

Not every committee receives protocol issuance. A committee becomes subsidized when the stake directed toward it, counting both validators and delegates, reaches a governance-set share of all stake on the Security Root. The current threshold is 33%. The protocol evaluates this every block:

TotalStake = AllValidatorStake + AllDelegateStake CommitteeRestake = ValidatorStakeForApp + DelegateStakeForApp RestakePercentage = (CommitteeRestake / TotalStake) * 100 IsSubsidized = RestakePercentage >= SubsidizationThreshold

Three validators hold 100 CNPY of total stake: A with 10, B with 25, and C with 65. A restakes toward app 1. B restakes toward apps 1 and 2. C restakes toward app 3. App 1's committee holds 35 of 100 (35%) and qualifies. App 2 holds 25 of 100 (25%) and does not. App 3 holds 65 of 100 (65%) and qualifies. Note that B's 25 CNPY counts fully toward both apps 1 and 2. Because restaking does not divide stake, committee percentages can sum to more than 100%, and in principle many committees can qualify at once.

Two properties of this design are worth stating precisely. First, the threshold is a coordination signal, not a purchase. An app team cannot pay its way into subsidized status. It qualifies only if enough independent stakers choose to direct their bonds to its committee, which ties protocol issuance to demonstrated support from those who are putting collateral at risk. Second, the subsidy is shared. Each Security Root block, the committee portion of issuance is divided equally among all subsidized committees. As more committees qualify, each receives a smaller share, which gives existing stakers a reason to be selective and gives apps a reason to supplement protocol rewards with their own.

Outside of automatic subsidization, anyone can fund a committee directly through a subsidy transaction. This sends CNPY to the committee's reward pool along with an opcode field that can encode distribution rules, for example restricting payouts to validators who also stake the app's Native Token or who meet a defined quality-of-service bar. The committee distributes from its pool according to its quorum decisions in each Certificate Result.

Issuance and Reward Distribution

CNPY has a capped supply of 560,000,000. Of that, 504,000,000 is projected to come from block rewards and 56,000,000 from a one-time mint. Block rewards start at 80 CNPY per Security Root block, with blocks produced roughly every 20 seconds, and halve every 3,150,000 blocks. At that block time, one halving period is about 729 days, and the first period issues 252,000,000 CNPY (about 345,600 CNPY per day). Each subsequent period issues half the previous one, and the geometric series converges on the 504,000,000 figure. Live values for total, staked, delegated, and per-committee supply are tracked onchain by the protocol's supply tracker and should be read from the network rather than from documentation.

Each block reward is split in two stages. First, 70% goes to the DAO Treasury pool and 30% is divided equally among subsidized committees. At the initial rate, that is 56 CNPY to the treasury and 24 CNPY shared across committees per block. Second, each committee distributes its share according to its own software. The default split is below.

70% to the CNPY validator that produced the app block.
10% to a CNPY delegate, selected by stake weight from the delegates restaked to that app.
10% to a validator staking the app's Native Token, selected the same way.
10% to a delegate staking the app's Native Token, selected the same way.

Delegate rewards are not paid pro rata every block. A single delegate is drawn by stake-weighted lottery for each payout, so individual returns are lumpy over short periods and converge to a stake-proportional share over long ones. And because the Certificate Result is processed on both the Security Root and the app, the same four recipients can be paid in CNPY and in the app's Native Token. If multiple certificates land in a single Security Root block, rewards are normalized by the number of certificates.

Rewards compound into the bond by default. A staker can instead route rewards to the output address, in which case an early-withdrawal penalty is deducted and burned. Slashed amounts are also burned. These are the two sinks in the current design.

The issuance schedule is front-loaded by design and declines toward zero. The whitepaper is explicit that protocol issuance is meant to bootstrap security, not fund it indefinitely. Over time, committee compensation is expected to shift toward Native Token block rewards paid by apps, fees, and community subsidies. How well that transition works in practice is an open question.

Validators

A validator is a staker that has registered for active consensus participation. For each committee in its stake configuration, it runs the corresponding app node, joins the committee's peer-to-peer channel, and participates in NestBFT. Leader election in NestBFT is stake-weighted: each validator signs seed data (recent proposer addresses, height, and round) to produce a VRF output, and is a leader candidate if that output falls below a threshold scaled by its stake. Because the seed cannot be influenced by the current leader, the election resists grinding, and because candidates are not known until they announce, it resists targeted DDoS.

The validator lifecycle is managed through a small set of Security Root transactions. stake creates the bond. edit_stake changes the committee list, network address, output address, or compounding setting, and can increase but not decrease the bonded amount. pause temporarily removes the validator from all committees, for example during maintenance, and unpause restores it. A validator paused longer than MaxPauseBlocks is automatically unstaked. unstake begins the unbonding period. Both the operator key and the output key can sign on the validator's behalf, but only the output key can change the output address, which lets operators separate hot operational keys from the address that controls funds.

Slashing is narrow by default. There are two conditions: double-signing, which violates BFT safety, and non-signing, defined as missing more than MaxNonSign blocks within a NonSignWindow. Each has a parameterized penalty, and slashed tokens are burned. Slashes are processed only on the Security Root and are not normalized across certificates. To limit contagion across restaked committees, MaxSlashPerCommittee caps the number of slashes a single committee can apply per block. If that cap is hit, the offending validators are ejected from the committee, which removes them from both further participation and further slashing there.

Validators also hold governance authority. Parameter changes and DAO Treasury transfers are proposal transactions that finalize only with approval from more than two-thirds of the voting power of the Security Root committee. Each validator configures its node to accept or reject a given proposal hash, and that preference is enforced at both the mempool and BFT level. In practice this means operating a validator carries governance responsibility in addition to infrastructure responsibility.

Delegators

A delegator submits the same stake transaction as a validator with the delegate flag set. It bonds CNPY and lists the committees it is restaking toward, but it does not run app nodes or sign blocks. Its stake does not add to any validator's voting power. Instead, it has two effects: it makes the delegator eligible for the delegate share of each listed committee's rewards (10% by default, paid by stake-weighted lottery), and it counts toward each listed committee's subsidization percentage.

That second effect is the more structurally important one. Because the 33% threshold is computed over validator and delegate stake together, delegators directly influence which apps receive protocol issuance. The whitepaper describes delegators as the gatekeepers of subsidization for this reason. It is a different role from delegation on most proof-of-stake networks, where delegating mainly means choosing an operator. On Canopy, a delegator is also choosing which apps the protocol supports.

Under the current model, delegators are not exposed to validator slashing. The slashing conditions described above apply to validators that sign or fail to sign blocks, and delegators do neither. This is a property of the current parameters rather than a permanent guarantee, and like every parameter described here it can be changed by governance. Delegated stake is still subject to the same unbonding period on exit, and delegate rewards still follow the same compounding and early-withdrawal rules.

BEP-20 CNPY and Native CNPY

CNPY currently exists in two forms. The first is a BEP-20 token on BNB Smart Chain, which is where exchange and DEX liquidity is concentrated. The second is the native asset on the Canopy Security Root. They represent the same asset, but they are not functionally equivalent, and the difference follows directly from the architecture above. Before interacting with either form, verify the contract address against the official links page, which is the only place we publish it.

Everything described in this piece happens in the Security Root's state machine. Stake transactions, committee lists, the subsidization calculation, Certificate Result processing, reward pools, slashing, and governance proposals are all Security Root operations, and they only recognize native CNPY. A BEP-20 balance is a record in a contract on a different network. It can be transferred and traded, but it cannot be bonded, cannot be counted in TotalStake, cannot be directed to a committee, and cannot receive CNPY or Native Token rewards from a Certificate Result.

Capability by capability, only native CNPY can do any of the following, and BEP-20 CNPY can do none of them:

Bond as validator or delegate stake
Restake toward app committees
Count toward committee subsidization
Be eligible for committee rewards
Pay Security Root transaction fees
Fund a committee via subsidy transaction
Carry governance weight through validator voting power

One capability runs the other way. BEP-20 CNPY can be transferred and traded on BSC venues; native CNPY cannot, not directly.

One system-level implication follows. The security available to apps, and the distribution of subsidies among them, is determined only by native CNPY that is bonded. The share of total supply held on BSC does not contribute to either. Holders deciding where to keep their CNPY are also, in aggregate, determining how much collateral is available to back apps.

Fees, Swaps, and Governance

Fees. Transactions on the Security Root are paid in CNPY, priced by computational cost and network load. Fees serve as spam resistance and are recycled into participant rewards rather than creating new issuance. Apps define their own state machines and fee logic, so fees paid inside an app are a matter of that app's design. Some Security Root actions, such as starting an onchain poll, carry a higher governance-set fee specifically to deter spam.

Swaps. Committees act as oracles over the chains they observe, which lets the Security Root support swaps between CNPY and an external asset without changes to the external chain. A seller creates a sell order on the Security Root, moving CNPY into a committee-controlled escrow pool. A buyer reserves the order by embedding a lock instruction in a transaction on the buyer's chain (for example in a Bitcoin script field or an Ethereum data field). The committee observes that transaction, reaches a two-thirds quorum, and records the lock with a buyer deadline in the next Certificate Result. The buyer then pays the seller directly on the external chain, the committee observes the payment, and the escrowed CNPY is released to the buyer. Orders can be edited or cancelled until they are locked. Swap security reduces to the honesty of the committee's quorum, which is in turn backed by its bonded CNPY.

Governance. Canopy has two governance mechanisms. Polls are non-binding: any account or validator can start one or vote in one by encoding a structured message in a send transaction, and results are tallied deterministically and weighted by current balances and stake. Proposals are binding and come in two types, parameter changes (for example unstakingBlocks or fee levels) and DAO Treasury transfers. Proposals are created by anyone, circulated off-chain as signed JSON, and finalize only once more than two-thirds of Security Root committee voting power has configured its nodes to accept that proposal hash. A proposal cannot be submitted before its startHeight, which guarantees a window for validators to review it. The expected pattern is a poll to measure sentiment followed by a proposal to act on it.