CIP-TBD: Cap Per-Round Featured App Reward Share - Anthony Merriman
CIP-XXX1: Cap Per-Round Featured App Reward Share
[Draft CIP]
CIP: XXXX
Title: Cap Per-Round Featured App Reward Share
Author: Anthony Merriman
Status: Draft
Type: Tokenomics
Created: 2026-03-20
License: CC0-1.0(Note for consideration: This CIP is intended to be considered as part of a larger batch of ~7 CIPs that attempt to improve various aspects of token issuance related to the Featured App program. We will submit additional CIPs in the coming weeks as we continue to refine the implementation recommendations from ongoing discussions.)Abstract
This CIP introduces a cap on the share of featured application rewards that any single featured app may receive in a single round. Under the current model, featured app rewards are allocated pro-rata based on featured app activity, and after CIP-0078 both featured CC transfers and FeaturedAppActivityMarkers produce the same featured app activity records, with markers remaining the preferred mechanism today.
This proposal introduces an initial per-round cap as a percentage of total rewards equal to: target_cap_constant / featured_app_count_r where featured_app_count_r is the number of featured apps at round open and target_cap_constant is a variable determined via governance. Using an initial recommended target cap_parameter of 15, and assuming 113 featured apps, the initial cap is ~13.2743% of the featured app reward pool, rounded to approximately 13.27%. Assuming 112,000 CC are issued to featured apps per round, the implied initial maximum is approximately ~14,867.26 CC per featured app per round.
This proposal is intended to be additive with CIP-0104. It does not replace or delay traffic-based app rewards. Instead, it establishes a round-level concentration limit that can apply under the current activity-marker model and continue to apply after the transition to traffic-based accounting. CIP-0104 specifically removes FeaturedAppActivityMarkers and AppRewardCoupons from the reward path and replaces them with traffic-based activity records derived from sequencer and mediator data.
Motivation
Under the current reward distribution model, the ~112,000 tokens issued per round are allocated to featured apps on an individually uncapped, pro-rata basis. Because there is no upper limit on the rewards a single app can capture, the reward pool is highly vulnerable to disproportionate capture by a single application generating significant spikes in activity whether that activity is organic or artificially generated.
Additionally, featured apps are expected to charge their users directly for transactions submitted on the network. This implies that organic application usage should be observed to be first-order inelastic with respect to application rewards. Organic activity will remain elevated independent of any caps on application rewards received by the respective Featured App.
By introducing a percentage-based per-round reward cap for individual Featured Apps, this proposal creates a more robust, resilient, and distributed ecosystem. A round-level cap improves incentives by:
Incentivizing consistent traffic usage over time rather than volatile, short-lived spikes in activity.
Incentivizing traffic optimization rather than traffic maximization.
Incentivizing featured apps to charge users the direct traffic cost upfront instead of relying entirely on uncapped backend network emission subsidies.
Incentivizing featured apps to measure traffic usage per round to optimize their operations and token flow against the established cap.
Disincentivizing user or application farming behavior by strictly limiting the maximum reward yield an app's users can artificially generate per round.
Limiting passive accumulation of markers achieved via repetitive, high-velocity wrapped token transfers.
Rationale
The proposed formula sets the cap at 15 times an equal-share baseline. With 113 featured apps, an equal share is approximately 0.885% of the pool, and the proposed cap is approximately 13.2764%. This allows successful apps to materially outperform the median while preventing any single app from dominating an entire round.
A direct cap on final round rewards is preferable to a pure marker-only cap because it remains valid after CIP-0104 replaces markers with traffic-based accounting. The cap therefore becomes a stable policy layer that can sit above either reward measurement system.
This CIP is complementary to CIP-0098. CIP-0098 approved a $1.50 maximum per-transaction application reward; this proposal adds a separate per-round concentration cap rather than a per-transaction cap. Together, the two controls bound both per-transaction excess and per-round concentration.
This structure also better aligns incentives for featured apps to internalize and price traffic costs. CIP-0104’s rationale explicitly moves app rewards toward actual traffic burned and emphasizes that validator operators should be able to charge users for network access costs. This CIP is consistent with that direction because it reduces the viability of relying on occasional outsized round payouts to subsidize user activity.
Specification & Implementation
The proposed cap will be enforced mathematically during the round-end calculation phase by limiting the number of eligible activity markers a single app can claim relative to the total network activity.
Definitions
featured_reward_pool_r: total CC allocated to featured apps in round r
target_cap_constant: numerator for calculating individual party cap
featured_app_count_r: number of featured apps with an active FeaturedAppRight at round open for round r
cap_percentage = target_cap_constant / featured_app_count_r
per_app_cap_r = featured_reward_pool_r × cap_percentage
provider_party: the featured app provider party associated with the app’s FeaturedAppRight; the cap applies at the provider-party level, not per beneficiary
Parameters
featured_reward_pool_r = ~112,000 tokens
featured_app_count_r = 113 apps
target_cap_constant = 15
cap_percentage = ~13.27% (target_cap_constant / N_featured_apps)
Implementation Logic
To enforce this limit, the protocol's reward distribution algorithm will execute the following specific sequence of operations at the conclusion of each round:
Fetch: Fetch all activity markers for the round for featured apps.
Initial Sum: Sum the activity markers for all featured apps to establish the uncapped total for the round.
Calculate Cap: Calculate the pro-rata marker cap (approximately ~13.27% * total markers in round).
Apply Cap: Iterate through all featured apps. If any apps have submitted more markers in the round than the calculated cap, set those apps' markers to be equal to the cap.
Recalculate Final Sum: Recalculate the sum of all activity markers for the round using the newly capped values.
Calculate Rewards: use the existing reward issuance logic with the new markers for each party.
Following step 6, the ~112,000 round tokens are then distributed pro-rata based on each app's share of this finalized, recalculated marker sum.
Example Spreadsheet Math
This is a stylized example of potential impact in a given round:Backwards Compatibility
This proposal is backward compatible in economic structure: it changes only the way the featured-app pool is split among featured apps. It does not require changes to featured-app approval, beneficiary handling, or the validator, super-validator, or development-fund reward pools.
Before CIP-0104 is fully activated, the cap can be applied on top of the current activity-based featured-app reward calculation. After CIP-0104 activation, the exact same cap can be applied to traffic-based provisional rewards.
Considerations Out of Scope
This CIP does not:
change the total round issuance allocated to featured apps
replace CIP-0104’s traffic-based activity measurement
define app categories or differentiated reward buckets
change organic network behavior or traffic costs
Future Considerations
As the Canton network matures and the number of featured apps scales beyond the current 113, a uniform percentage cap applied across all applications may require further refinement to account for different application architectures.
Recommended improvements for future considerations and additional CIPs include:
Creating featured app categories to fine-tune the distribution of app rewards: Segmenting apps into distinct categories (e.g. wallets, oracles, token issuers, DEXes, etc.) would allow the protocol to apply different cap parameters, budgets, or reward weights tailored to the natural resource demands and traffic profiles of specific application types.
Copyright
This CIP is licensed under CC0-1.0.
Changelog
2026-03-20: Initial draft.
- hi AnthonyThank you very much for being a dedicated builder in the network and thinking deeply about how things can improve. Always appreciate people taking the time to propose adjustments, especially ones as thoughtful as thisThat said, I am generally opposed to this idea. In this particular instance, I feel quite nervous about capping the success of anything in the network. I think back to all the apps that did great over the years in other ecosystems and they went through periods of time where they dominated the network activity (eg Crypto kitties ddosing ETH to its knees for days). Limiting upside isn't something that I think is a good idea in general.I've seen / discussed similar things like this over the past 18 months and my stance is the following:1. I generally am supportive of the idea of different FA reward weights BUT2. I am quite allergic to a committee or DAO or the like determining / managing those weights3. I think a market mechanism would likely be the scalable way to govern dynamic FA weights (eg bonding) but the complexity far outweighs the benefit at this time4. We have CIP-0104 and (maybe) FA Locking in the pipeline and I would like to see the effects of those adjustments before making any larger changesId be happy to discuss what market mechanics would help improve FA reward structures but really only after we get some time with CIP-0104 and maybe FA Locking firstOn Fri, Mar 20, 2026 at 11:28 AM Anthony Merriman via lists.sync.global <anthony=modulo.finance@...> wrote:
CIP-XXX1: Cap Per-Round Featured App Reward Share
[Draft CIP]
CIP: XXXX
Title: Cap Per-Round Featured App Reward Share
Author: Anthony Merriman
Status: Draft
Type: Tokenomics
Created: 2026-03-20
License: CC0-1.0(Note for consideration: This CIP is intended to be considered as part of a larger batch of ~7 CIPs that attempt to improve various aspects of token issuance related to the Featured App program. We will submit additional CIPs in the coming weeks as we continue to refine the implementation recommendations from ongoing discussions.)Abstract
This CIP introduces a cap on the share of featured application rewards that any single featured app may receive in a single round. Under the current model, featured app rewards are allocated pro-rata based on featured app activity, and after CIP-0078 both featured CC transfers and FeaturedAppActivityMarkers produce the same featured app activity records, with markers remaining the preferred mechanism today.
This proposal introduces an initial per-round cap as a percentage of total rewards equal to: target_cap_constant / featured_app_count_r where featured_app_count_r is the number of featured apps at round open and target_cap_constant is a variable determined via governance. Using an initial recommended target cap_parameter of 15, and assuming 113 featured apps, the initial cap is ~13.2743% of the featured app reward pool, rounded to approximately 13.27%. Assuming 112,000 CC are issued to featured apps per round, the implied initial maximum is approximately ~14,867.26 CC per featured app per round.
This proposal is intended to be additive with CIP-0104. It does not replace or delay traffic-based app rewards. Instead, it establishes a round-level concentration limit that can apply under the current activity-marker model and continue to apply after the transition to traffic-based accounting. CIP-0104 specifically removes FeaturedAppActivityMarkers and AppRewardCoupons from the reward path and replaces them with traffic-based activity records derived from sequencer and mediator data.
Motivation
Under the current reward distribution model, the ~112,000 tokens issued per round are allocated to featured apps on an individually uncapped, pro-rata basis. Because there is no upper limit on the rewards a single app can capture, the reward pool is highly vulnerable to disproportionate capture by a single application generating significant spikes in activity whether that activity is organic or artificially generated.
Additionally, featured apps are expected to charge their users directly for transactions submitted on the network. This implies that organic application usage should be observed to be first-order inelastic with respect to application rewards. Organic activity will remain elevated independent of any caps on application rewards received by the respective Featured App.
By introducing a percentage-based per-round reward cap for individual Featured Apps, this proposal creates a more robust, resilient, and distributed ecosystem. A round-level cap improves incentives by:
Incentivizing consistent traffic usage over time rather than volatile, short-lived spikes in activity.
Incentivizing traffic optimization rather than traffic maximization.
Incentivizing featured apps to charge users the direct traffic cost upfront instead of relying entirely on uncapped backend network emission subsidies.
Incentivizing featured apps to measure traffic usage per round to optimize their operations and token flow against the established cap.
Disincentivizing user or application farming behavior by strictly limiting the maximum reward yield an app's users can artificially generate per round.
Limiting passive accumulation of markers achieved via repetitive, high-velocity wrapped token transfers.
Rationale
The proposed formula sets the cap at 15 times an equal-share baseline. With 113 featured apps, an equal share is approximately 0.885% of the pool, and the proposed cap is approximately 13.2764%. This allows successful apps to materially outperform the median while preventing any single app from dominating an entire round.
A direct cap on final round rewards is preferable to a pure marker-only cap because it remains valid after CIP-0104 replaces markers with traffic-based accounting. The cap therefore becomes a stable policy layer that can sit above either reward measurement system.
This CIP is complementary to CIP-0098. CIP-0098 approved a $1.50 maximum per-transaction application reward; this proposal adds a separate per-round concentration cap rather than a per-transaction cap. Together, the two controls bound both per-transaction excess and per-round concentration.
This structure also better aligns incentives for featured apps to internalize and price traffic costs. CIP-0104’s rationale explicitly moves app rewards toward actual traffic burned and emphasizes that validator operators should be able to charge users for network access costs. This CIP is consistent with that direction because it reduces the viability of relying on occasional outsized round payouts to subsidize user activity.
Specification & Implementation
The proposed cap will be enforced mathematically during the round-end calculation phase by limiting the number of eligible activity markers a single app can claim relative to the total network activity.
Definitions
featured_reward_pool_r: total CC allocated to featured apps in round r
target_cap_constant: numerator for calculating individual party cap
featured_app_count_r: number of featured apps with an active FeaturedAppRight at round open for round r
cap_percentage = target_cap_constant / featured_app_count_r
per_app_cap_r = featured_reward_pool_r × cap_percentage
provider_party: the featured app provider party associated with the app’s FeaturedAppRight; the cap applies at the provider-party level, not per beneficiary
Parameters
featured_reward_pool_r = ~112,000 tokens
featured_app_count_r = 113 apps
target_cap_constant = 15
cap_percentage = ~13.27% (target_cap_constant / N_featured_apps)
Implementation Logic
To enforce this limit, the protocol's reward distribution algorithm will execute the following specific sequence of operations at the conclusion of each round:
Fetch: Fetch all activity markers for the round for featured apps.
Initial Sum: Sum the activity markers for all featured apps to establish the uncapped total for the round.
Calculate Cap: Calculate the pro-rata marker cap (approximately ~13.27% * total markers in round).
Apply Cap: Iterate through all featured apps. If any apps have submitted more markers in the round than the calculated cap, set those apps' markers to be equal to the cap.
Recalculate Final Sum: Recalculate the sum of all activity markers for the round using the newly capped values.
Calculate Rewards: use the existing reward issuance logic with the new markers for each party.
Following step 6, the ~112,000 round tokens are then distributed pro-rata based on each app's share of this finalized, recalculated marker sum.
Example Spreadsheet Math
This is a stylized example of potential impact in a given round:Backwards Compatibility
This proposal is backward compatible in economic structure: it changes only the way the featured-app pool is split among featured apps. It does not require changes to featured-app approval, beneficiary handling, or the validator, super-validator, or development-fund reward pools.
Before CIP-0104 is fully activated, the cap can be applied on top of the current activity-based featured-app reward calculation. After CIP-0104 activation, the exact same cap can be applied to traffic-based provisional rewards.
Considerations Out of Scope
This CIP does not:
change the total round issuance allocated to featured apps
replace CIP-0104’s traffic-based activity measurement
define app categories or differentiated reward buckets
change organic network behavior or traffic costs
Future Considerations
As the Canton network matures and the number of featured apps scales beyond the current 113, a uniform percentage cap applied across all applications may require further refinement to account for different application architectures.
Recommended improvements for future considerations and additional CIPs include:
Creating featured app categories to fine-tune the distribution of app rewards: Segmenting apps into distinct categories (e.g. wallets, oracles, token issuers, DEXes, etc.) would allow the protocol to apply different cap parameters, budgets, or reward weights tailored to the natural resource demands and traffic profiles of specific application types.
Copyright
This CIP is licensed under CC0-1.0.
Changelog
2026-03-20: Initial draft.
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.
