The Portfolio Effect: How Securing Apps Pays in Two Tokens

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

On most proof-of-stake networks, a validator is paid in one asset: the native token of the network it secures. Canopy's design is different. A committee member securing an app on Canopy can be paid in two assets at once, CNPY from the Security Root and the app's own Native Token. Over time, some of those apps can graduate and become Security Roots in their own right, which repeats the arrangement one level down.

The whitepaper calls the result a portfolio of tokens. This piece explains the mechanism behind that phrase: how Native Token rewards reach committee members, how graduation turns an app into a Security Root, and what the arrangement does and does not imply for the people securing apps.

How Native Token Rewards Reach Committee Members

Every app on Canopy is secured by a committee: the subset of Security Root validators that has opted in to run its consensus. After each app block, the committee's elected leader submits a Certificate Result to the Security Root. The certificate records the committee's quorum decision on who should be rewarded and who, if anyone, should be slashed.

The important detail is that the same Certificate Result is also included in the app's own block. Reward decisions are therefore processed on both the Security Root and the app. On the Security Root, recipients are paid CNPY from the committee's reward pool. On the app, the same recipients can be paid in the app's Native Token according to the app's own issuance rules.

The default distribution names four recipients for each app block:

• CNPY validator, the block producer. 70%. The validator that produced the app block.
• CNPY delegate. 10%. Stake-weighted random selection among CNPY delegates restaked to the app.
• Native Token validator. 10%. Stake-weighted random selection among validators staking the app's Native Token.
• Native Token delegate. 10%. Stake-weighted random selection among delegates staking the app's Native Token.

Apps can change this split in their own software, and they can add further incentives through subsidy transactions. Native Token rewards are also independent of subsidized status. An app below the 33% threshold receives no CNPY issuance, but it can still pay its validators and delegators in its own token, which gives stakers a reason to back it early. What they cannot change is the underlying structure: whoever secures an app is recorded as a reward recipient on both the Security Root and the app.

The last two recipients also reveal a design intention. Native Token stakers on the app are included from the start, even while the app's consensus is run by CNPY validators. Validators can stake an app's Native Token to be in position for the day that app runs its own validator set. The docs describe this as being "on-deck" for independence.

Graduation and Recursion

An app on Canopy is not permanently attached to the Security Root. Every app holds a reference to the network that supplies its validator set, and that reference can be changed with an onchain governance transaction. An app can point to a different Security Root or to itself. When it points to itself, it is independent: its own stakers form its validator set, and its full block history is retained. Checkpoints published while it was nested can be exported, so graduation does not require a re-genesis or a token migration.

The second half of the mechanism is what makes it recursive. Apps built from the Canopy template include the same Security Root functionality as Canopy itself. Once an app is independent, its Native Token can play the role CNPY plays today: it can be bonded, restaked toward committees, and used to secure new apps launched beneath it. Those new apps can in turn pay their committees in their own Native Tokens.

The whitepaper describes this as a self-reinforcing succession of Security Roots, in which mature apps shelter new ones the way the original Security Root sheltered them. For a staker, it means the set of assets that can be bonded, and the set of apps those assets can secure, can grow over time rather than stay fixed at CNPY and its direct apps.

What This Does and Does Not Imply

The portfolio effect is a structural property of the protocol: securing an app connects a staker to that app's Native Token through the same certificate that pays CNPY. It is worth being precise about what follows from that and what does not.

It does mean that committee participation produces exposure to the apps a staker chooses to secure, in the form of actual Native Token distributions rather than only indirect exposure through CNPY. It also means that a staker's committee choices determine which apps' tokens they receive, which makes committee selection a meaningful decision rather than a formality.

It does not mean that every committee pays Native Token rewards. An app decides its own issuance, and some may choose to pay little or nothing beyond protocol issuance and subsidies. It does not mean Native Tokens hold value. Young apps' tokens may have limited liquidity and may lose value entirely. And it does not mean recursion is automatic. Graduation is a governance decision by each app, and becoming a Security Root for other apps depends on that app attracting stake and committees of its own.

The accurate summary is narrower than the phrase "portfolio of tokens" might suggest. Canopy aligns the people who secure an app with the app itself, and gives successful apps a defined path to extend the same model to the next generation. How much that alignment is worth depends entirely on the apps.

_{Nothing in this post is financial advice.}

Sources

• State Machine: Rewards
• Utility
• Progressive Sovereignty
• Security and Governance Actors
• Configure
• Canopy whitepaper v2.0, sections 9.3, 9.6, 11.2, 12.1