After the Halvings: Who Pays for Security?

Every network pays for security. In Proof of Stake, validators bond capital, run infrastructure, and accept the risk of slashing, and they need a reason to keep doing it. In the early years, that reason is usually new token issuance: the protocol mints tokens and pays them to the people securing it.

Canopy follows that pattern, with one important commitment. Its issuance is capped and halves on a fixed schedule. Protocol rewards are designed to be large at the start and to shrink toward zero. That raises the question this essay tries to answer: once issuance is small, who pays for the security of the apps running on Canopy?

The short answer is that the design intends three sources to take over: transaction fees, native token rewards paid by apps, and app/community subsidies. The longer answer requires being clear about how that handoff is meant to work, what could prevent it, and what to watch in order to know whether it is happening.

The Issuance Schedule

CNPY has a capped supply of 560,000,000, of which 504,000,000 comes from block rewards and 56,000,000 from a one-time mint outside this schedule. Block rewards start at 80 CNPY per block, with a block about every 20 seconds, and halve every 3,150,000 blocks (or about 2 years).

The split of each block reward magnifies the effect for committees. At present, 70% of every block reward goes to the DAO Treasury, and 30% is shared among subsidized committees. In the first period, the committee pool is 24 CNPY per block. In the second it is 12, in the third 6, and in the fourth 3, shared across however many committees qualify. By the fourth period, protocol issuance alone is a small fraction of what it was at launch.

The Three Intended Successors

Transaction fees

Every transaction on the Security Root pays a fee in CNPY, priced by its computational cost and current network load. Fees are recycled into participant rewards rather than burned or sent to a treasury. As activity on the Security Root grows, fees become a larger share of what committee members receive. This is the same model Bitcoin relies on for its long-run security budget, and it carries the same dependency: fees only replace issuance if there is enough demand for blockspace.

Native token rewards

This is the source most specific to Canopy, and the one the architecture leans on most. Each app can pay the validators and delegators securing it in its own native token, through the same Certificate Result that distributes CNPY. It can do so whether or not its committee is subsidized, which lets apps attract support early and keep it as protocol issuance falls. The whitepaper describes this as "slowly weaning the ecosystem off of newly minted CNPY." The logic is straightforward: An app that captures value from its own users, through fees, product revenue, or token issuance it controls, has the means to pay for its own security. Under this model, security becomes a cost each app carries in proportion to its own success, rather than a subsidy paid by the Security Root to everyone.

Community subsidies

Anyone can fund an app's committee directly with a subsidy transaction, sending CNPY into the committee's reward pool with distribution rules attached. An app's team, its foundation, or its users can fund security for a defined period and set eligibility criteria, for example requiring validators to also stake the app's native token or meet a performance bar. The whitepaper describes this as a two-sided marketplace in which apps pay validators for block production.

The common thread is that all three shift the cost of security from the network as a whole to the apps and users who benefit from it. 

Addressing Key Transition Challenges

While the protocol design outlines a clear path for transitioning security responsibilities, navigating this handoff successfully will involve actively managing key operational dynamics:

First, fee revenue growth will naturally depend on sustained demand for blockspace. While fee markets across web3 are continuously evolving, growing activity on the Security Root will provide the foundation for fee revenue to smoothly complement and eventually replace block rewards over time.

Second, native token rewards present an opportunity for applications to align incentives directly with their validators. As app ecosystems mature and token liquidity deepens, successful applications will be well-positioned to offer compelling economic compensation to ensure robust and dedicated validator support.

Third, security risks becoming a function of raw popularity. While the subsidization threshold and community marketplace intentionally direct resources toward active applications, this dynamic can leave smaller or slower-growing projects struggling to maintain long-term validator interest.

Finally, balancing the fixed emission schedule with organic ecosystem adoption requires thoughtful pacing. With generous initial block rewards and roughly two years per halving period, the network provides a substantial runway for fee markets and app economies to fully develop and seamlessly bridge the security handoff.

Why the Design Still Makes Sense, and What to Watch

None of these risks are unique to Canopy. Every network with capped issuance faces some version of them, and the alternative, perpetual inflation, carries its own long-run cost in the form of continuous dilution for every holder. Canopy's choice is to accept a transition risk in exchange for a fixed supply, and to give apps the tools to carry their own security costs.

There are also reasons to think the transition is more tractable here than on a single-chain network. Apps on Canopy keep their own fee flows and economics instead of paying rent to a host chain. That is the core of the appchain thesis. An app that captures its own value is better placed to fund its committee than a smart contract whose fees go to someone else. The schedule also gives time: about two years per halving period, with half of all block-reward issuance in the first period alone. And the parameters that matter most, from reward splits to subsidy thresholds, are governable if the handoff needs adjusting.

Whether the transition works is ultimately an empirical question, and it can be tracked on-chain. The signals worth watching are:

• The share of committee rewards coming from sources other than protocol issuance.
• The number of apps distributing native token rewards to their committees.
• The volume and duration of community subsidies.
• Fee revenue on the Security Root over time.
• How evenly bonded stake is spread across committees.

As these metrics grow alongside decreasing issuance, they will affirm the strength and sustainability of the network design. Should adjustments ever be needed, Canopy’s robust governance framework ensures the community is fully equipped to adapt, supporting long-term growth and security.

Sources

• Canopy Economics
• State Machine: Subsidization and Rewards
• Canopy whitepaper v2.0, sections 9.2, 9.8 to 9.10, 11.1, 12.1