Mailing Lists/CIP-TBD: Featured App Reward Locking and Review MechanismSource on lists.sync.global ↗

CIP-TBD: Featured App Reward Locking and Review Mechanism

cip-discuss5 messagesstarted 15-05-2026
Also mentions:CIP-0116
  1. #1reborntaichi@gmail.com15-05-2026source ↗

    Dear Community,

    As a member of the Canton community, I would like to share an idea for discussion regarding the Featured App reward mechanism.

    The intent of CIP-0116 is understandable and important. Featured App status carries network recognition, ecosystem visibility, and access to incentives. It is reasonable for the network to expect Featured Apps to demonstrate stronger commitment, better quality, and a higher cost of misconduct.

    At the same time, there may be a lighter way to achieve the same risk-control objective without requiring every genuine application team to meet a large upfront CC staking threshold. This proposal introduces a reward locking and review mechanism that places the control point before reward release rather than before application participation.

    The goal is to preserve strong safeguards against abnormal Marker behavior while keeping the Featured App program accessible to real builders, early-stage teams, and smaller applications contributing genuine activity to the Canton Network.

    Feedback, suggestions, and improvements from the community, the Foundation, and the relevant committees are welcome.

    Number: CIP-TBD
    Title: Featured App Reward Locking and Review Mechanism
    Author(s): Thomas V. Turner
    Type: Tokenomics
    Status: Draft
    Created: 2026-05-11
    License: CC0-1.0

    Featured App Reward Locking and Review Mechanism

    Summary

    This proposal introduces a reward locking and review mechanism for Featured App rewards on the Canton Network.

    The mechanism does not change how Featured App Activity Markers are submitted, does not change the existing reward calculation logic, and does not change the basic path through which applications earn rewards from genuine on-chain activity. It only adds a reward-round-based lock, check, review, and release process after Featured App rewards are calculated and before they are released to the App Provider PartyId.

    Under this mechanism, each Featured App reward first enters a locked state. Each locked reward is associated with the corresponding reward round, App Provider PartyId, reward amount, and unlock round. When the lock period ends, the reward may be released if the application’s data during the observation window remains within the expected range. If abnormal conditions are triggered, the reward enters a review state and remains locked until the review is resolved.

    This proposal is designed to:

    1. Preserve the incentive effect of Featured App rewards for genuine applications;
    2. Provide the Foundation and the Tokenomics Committee with a review window before rewards are released;
    3. Prevent abnormal Marker behavior from quickly becoming immediately spendable rewards;
    4. Reduce upfront capital pressure on early-stage teams and smaller genuine developers;
    5. Keep newly generated Featured App rewards locked for a defined period, reducing immediate circulating supply impact;
    6. Improve auditability and governance of reward releases without rebuilding the existing Featured App reward mechanism.

    This proposal can serve as a lighter alternative or complement to Featured App Staking. CIP-0116 addresses a valid concern by increasing application commitment and misconduct cost through upfront CC staking. This proposal addresses the same concern by locking unreleased rewards and reviewing them before release, which may be easier to implement and less restrictive for early-stage ecosystem growth.

    Motivation

    The core purpose of the Featured App reward mechanism is to encourage applications to create genuine, valuable, and verifiable on-chain activity on the Canton Network. Featured App status represents network recognition, ecosystem visibility, and reward eligibility. Applications should therefore be held to a higher standard regarding Marker submission logic and the quality of their on-chain activity.

    As the scale of Featured App rewards grows, the network needs stronger governance tools to handle abnormal behavior. If an application submits incorrect Markers, excessive Markers, duplicate Markers, or marks activity that does not comply with the rules as Maker activity, rewards may be released before the issue is detected. Suspending an application after the fact can stop future risk, but handling rewards that have already been released is more difficult.

    CIP-0116 proposes Featured App Staking as a way to raise application responsibility and increase the cost of misconduct. This direction is reasonable. Featured Apps should have stronger economic alignment with the network, and applications that benefit from network incentives should not be able to abuse the reward system without consequence.

    However, a high upfront CC stake may also create a significant participation barrier. Early-stage applications and smaller teams may have real products, real users, and long-term commitment, but may not be able to meet a large staking requirement at an early stage. If Featured App eligibility relies mainly on upfront capital, Canton may become less accessible to new applications and innovative teams.

    This proposal offers another path. Instead of requiring every application to provide a large stake before participation, the control point is placed before reward release.

    As long as rewards remain locked, the Foundation can pause release, initiate review, and decide whether to release, partially release, extend the lock, or cancel release based on the review outcome. This increases the cost of non-compliant behavior without requiring genuine developers to bear excessive upfront capital pressure.

    Reward locking also has a tokenomics benefit. Newly generated Featured App rewards do not immediately enter circulation. They remain locked during the observation period, reducing short-term circulating supply pressure and making the reward release schedule smoother, more predictable, and more governable.

    Specification

    1. Scope

    This proposal only adds governance logic to the Featured App reward release layer.

    It does not modify:

    1. The submission method of Featured App Activity Markers;
    2. Canton’s existing transaction, fee, or reward round mechanism;
    3. The Featured App reward calculation formula;
    4. The basic use of App Provider PartyId;
    5. Application business contracts;
    6. A requirement for every application to provide a large upfront CC stake;
    7. Any default retroactive treatment of historical rewards already released to application addresses.

    The mechanism introduced by this proposal only applies to Featured App rewards that have been calculated but not yet released.

    2. Core Mechanism

    After each Featured App reward is generated, it is not released to the application immediately. Instead, it enters an auditable lock record.

    This lock record may be implemented as an on-ledger contract state, a Foundation-managed reward release ledger, or a combination of both. The first version can use a minimum viable implementation with an independent Reward Lock Record to track reward status, with the Foundation or the Tokenomics Committee authorized to execute release, review, and cancellation actions.

    Each lock record can be represented as:

    FeaturedAppRewardLock

    This record only manages reward release status. It does not participate in application business logic and does not modify existing application contracts.

    3. FeaturedAppRewardLock Data Structure

    Each FeaturedAppRewardLock should contain at least the following fields:

    Field Description
    lockId Unique ID of the lock record
    appProviderPartyId PartyId of the Featured App
    rewardRound Reward round in which the reward was generated
    amount Locked reward amount
    unlockRound Earliest reward round in which the reward can enter the release process
    status Current status
    reviewFlag Whether review has been triggered
    reasonCode Reason code for triggering review
    releasedAmount Amount already released
    cancelledAmount Amount cancelled from release
    createdAtRound Reward round in which the lock record was created
    updatedAtRound Most recent reward round in which the status was updated

    Optional fields may include:

    Field Description
    coverageRatio Coverage ratio calculated for the observation window
    markersSubmitted Marker amount submitted and counted during the observation window
    ccTransfersWithCoupons CC transfers with coupons during the observation window
    trafficCostUsd Traffic cost used for coverage ratio calculation during the observation window, denominated in USD
    reviewCaseId ID of the related review case
    adminPartyId Admin Party that executed the most recent status change
    resolutionNoteHash Hash or reference to the review resolution note

    4. Reward Status

    To keep the mechanism simple, the first version may use the following statuses:

    Status Meaning
    Locked Reward is locked and has not reached the unlock round
    PendingRelease Reward has reached the unlock round and is waiting for checks or batch release
    UnderReview Abnormal conditions have been triggered and the reward is waiting for review
    Released Reward has been released to the application
    PartiallyReleased Part of the reward has been released, while part has been cancelled or remains locked
    Cancelled Reward has been cancelled from release and moved to a Foundation-defined handling path

    The Cancelled status serves as the practical implementation of clawback for the first version. To reduce technical complexity, the base mechanism focuses on unreleased rewards and does not default to recovering rewards that have already been released to an application address.

    In this proposal, clawback should therefore be understood as:

    Cancelling, partially cancelling, or reallocating abnormal rewards that remain locked and have not yet been released.

    If the Foundation wishes to extend the mechanism to already released rewards in the future, that can be handled through a separate governance rule or a later version.

    5. Reward Round and Lock Period

    Each reward is locked based on reward rounds.

    The mechanism is:

    1. Reward generation round: R
    2. Lock period: N reward rounds
    3. Earliest unlock round: R + N
    4. Observation window: R through R + N - 1

    N is a system parameter set by the Foundation or the Tokenomics Committee.

    The initial version can use a simple, unified N, such as the number of reward rounds corresponding to 7 days.

    If each reward round is approximately 15 minutes:

    7 days × 24 hours × 60 minutes ÷ 15 minutes = 672 reward rounds

    Therefore, lockRounds = 672 can be used as an initial reference parameter.

    To keep implementation simple, the first version does not need application-specific lock periods. A unified lock period can be used first. Later versions may shorten the lock period for long-term compliant applications or extend it for higher-risk applications.

    6. Coverage Ratio Calculation

    The unlock check can reference the existing coverage ratio standard in the official Featured App Marker Guidance. This can serve as an important indicator for determining whether an application’s Marker behavior during the observation window remains within a reasonable range.

    The formula is:

    Coverage Ratio = (markers submitted + CC transfers with coupons) / traffic cost (USD)

    Where:

    1. markers submitted means Markers submitted and counted for the Featured App during the observation window;
    2. CC transfers with coupons means CC transfers with coupons during the observation window;
    3. traffic cost (USD) means the traffic cost used for this calculation during the observation window, denominated in USD;
    4. Marker submission cost is not included in traffic cost.

    That is:

    marker submission cost excluded from traffic

    To avoid future implementation rigidity, the coverage ratio formula, data source, and threshold should be treated as configurable governance parameters or external calculation rules, rather than being hard-coded into the core contract.

    The system only needs to record the calculation result, data-source reference, and observation window so the Foundation or the Tokenomics Committee can review them.

    7. Unlock Check

    When the current reward round is greater than or equal to unlockRound, the locked reward enters PendingRelease.

    The system or the Foundation checks the data of the relevant appProviderPartyId during the observation window.

    7.1 Minimum Check Items

    The first version only needs to check clear, calculable, and auditable indicators:

    1. markersSubmitted
    2. ccTransfersWithCoupons
    3. trafficCostUsd
    4. coverageRatio
    5. Whether a manual review flag exists
    6. Whether the App Provider PartyId is under Featured App suspension

    7.2 Basic Release Rule

    A reward may be released if all of the following conditions are met:

    1. currentRound >= unlockRound
    2. coverageRatio <= maxCoverageRatio during the observation window
    3. The reward has not been manually marked as UnderReview
    4. The appProviderPartyId is not under Featured App suspension
    5. There are no confirmed duplicate Marker records or invalid Marker records

    If any condition is not met, the reward enters UnderReview.

    7.3 Initial Threshold

    The Foundation may set an initial coverage ratio threshold such as:

    maxCoverageRatio = 1.15

    This value is a governance parameter. The Foundation or the Tokenomics Committee may adjust it based on actual network conditions.

    8. Review Triggers

    To keep the mechanism implementable, the first version should only use clear, calculable, and auditable review triggers.

    A reward may enter UnderReview if any of the following conditions occurs:

    1. coverageRatio > maxCoverageRatio during the observation window
    2. The same activity is used for duplicate Marker submissions
    3. The activity corresponding to a Marker cannot be matched to a valid on-chain transaction or contract event
    4. The App Provider PartyId is under Featured App suspension
    5. The Foundation or the Tokenomics Committee manually sets a review flag
    6. There is material data loss or a calculation-method conflict during the observation window, making it impossible to determine whether the reward should be released

    The first version should avoid using overly subjective automatic triggers such as “low-quality activity” or “insufficient ecosystem value.” These may be considered as background information during manual review, but should not be used as core automatic triggers.

    9. Review Process

    Once a reward enters UnderReview, the system does not release it.

    The review process is:

    1. The Foundation creates a review case;
    2. The system records the trigger reason, reward round, observation window, and related data;
    3. The application submits structured explanatory materials;
    4. The Foundation or the Tokenomics Committee reviews the case;
    5. The reward status is updated based on the review result.

    9.1 Materials Submitted by the Application

    Applications should submit structured materials rather than relying on informal communication.

    Recommended materials include:

    1. Relevant reward round range;
    2. Marker submission logic;
    3. On-chain transactions or contract events corresponding to the Markers;
    4. Traffic cost calculation method;
    5. Statistical basis for markers submitted and CC transfers with coupons;
    6. Explanation for abnormal coverage ratio;
    7. Whether there was a system error or configuration error;
    8. Remediation measures;
    9. Measures to prevent recurrence.

    9.2 Review Outcomes

    After review, the mechanism should keep four possible outcomes:

    Outcome Status Change Description
    Full release UnderReview → Released Data is reasonable and the reward is released
    Partial release UnderReview → PartiallyReleased Part of the reward is valid and part is cancelled
    Extended lock UnderReview → Locked Information is insufficient and further observation is needed
    Cancel release UnderReview → Cancelled The reward is confirmed not to be releasable

    Cancelled rewards do not enter the application address. They are moved to a Foundation-designated treasury, ecosystem fund, or other governance-approved address.

    10. Example

    Assume a Featured App generates 100 CC in Featured App rewards at reward round 10,000.

    The Foundation has set the following parameters:

    Parameter Value
    lockRounds 672
    maxCoverageRatio 1.15
    Reward generation round 10,000
    Earliest unlock round 10,672
    Observation window 10,000 to 10,671

    At reward round 10,000, the system creates a FeaturedAppRewardLock record:

    Field Value
    appProviderPartyId App A PartyId
    rewardRound 10,000
    amount 100 CC
    unlockRound 10,672
    status Locked

    When the network reaches reward round 10,672, the reward enters PendingRelease. The system or the Foundation calculates the coverage ratio for the observation window from reward round 10,000 to reward round 10,671.

    Case 1: Normal Release

    Assume the observation window data is:

    Indicator Value
    markers submitted 900
    CC transfers with coupons 50
    traffic cost (USD) 1,000
    coverageRatio (900 + 50) / 1,000 = 0.95

    Because 0.95 <= 1.15, and there is no manual review flag, duplicate Marker record, or suspension status, the reward can be released.

    Status change:

    Locked → PendingRelease → Released

    The 100 CC is released to App A’s App Provider PartyId.

    Case 2: Review Triggered

    Assume the observation window data is:

    Indicator Value
    markers submitted 1,300
    CC transfers with coupons 100
    traffic cost (USD) 1,000
    coverageRatio (1,300 + 100) / 1,000 = 1.40

    Because 1.40 > 1.15, the reward is not released immediately and enters UnderReview.

    Status change:

    Locked → PendingRelease → UnderReview

    The Foundation or the Tokenomics Committee may require App A to provide its Marker submission logic, corresponding on-chain activity, traffic cost calculation method, and explanation for the abnormal ratio.

    If the review confirms that the data is reasonable, the reward can be released.

    If the review confirms that only part of the Marker activity is valid, the valid part can be released and the invalid part can be cancelled.

    For example:

    Result Amount
    Released 60 CC
    Cancelled 40 CC

    Status change:

    UnderReview → PartiallyReleased

    The cancelled 40 CC does not enter App A’s PartyId. It is moved to a Foundation-designated treasury or ecosystem fund.

    If the review confirms that the reward was entirely generated from non-compliant activity, the status changes to:

    UnderReview → Cancelled

    The full 100 CC is not released to App A and is handled according to Foundation governance rules.

    11. Technical Implementation

    This mechanism can be implemented as an independent reward release state machine. It does not require changes to application business contracts.

    11.1 Roles

    Role Description
    RewardAllocator Existing reward calculation or allocation module
    RewardLockController New reward locking and release-control module
    FoundationAdminParty Foundation administrative Party
    TokenomicsCommitteeParty Tokenomics Committee or authorized review Party
    AppProviderParty Featured App Party
    FoundationTreasuryParty Receiver Party for cancelled rewards

    11.2 Core State Object

    A simple Daml contract or equivalent state object may be introduced:

    FeaturedAppRewardLock

    This object only records reward status and does not participate in application business logic.

    It may support the following operations:

    Operation Executor Purpose
    CreateLock RewardAllocator / FoundationAdminParty Create a reward lock record
    MarkPendingRelease RewardLockController Mark reward as pending release after unlock round
    Release RewardLockController / FoundationAdminParty Release reward to AppProviderParty
    FlagReview FoundationAdminParty / TokenomicsCommitteeParty Move reward into review
    ResolveReviewRelease TokenomicsCommitteeParty Release after review
    ResolveReviewPartialRelease TokenomicsCommitteeParty Partially release after review
    ExtendLock TokenomicsCommitteeParty Extend the lock
    CancelRelease TokenomicsCommitteeParty Cancel release and move reward to a designated Party

    11.3 Reward Fund Flow

    The recommended reward fund flow is:

    1. Featured App reward calculation is completed;
    2. Reward enters a locked state or locked address controlled by RewardLockController;
    3. The system creates a FeaturedAppRewardLock;
    4. When unlockRound is reached, the unlock check is executed;
    5. If the reward passes the check, it is released to AppProviderParty;
    6. If it fails the check, it enters UnderReview;
    7. Cancelled rewards are moved to FoundationTreasuryParty or another governance-designated address.

    This path avoids the need to recover funds from application addresses after release. It is simpler to implement and has a clearer enforcement boundary.

    12. Minimum Viable Version

    The first version only needs to implement:

    1. Create reward lock records by reward round;
    2. Set a unified lockRounds parameter;
    3. Calculate observation-window metrics using the coverage ratio standard in the official Featured App Marker Guidance;
    4. Determine release based on maxCoverageRatio after the lock period ends;
    5. Allow the Foundation to manually set UnderReview;
    6. Support four review outcomes: release, partial release, extended lock, and cancelled release;
    7. Move cancelled rewards to a Foundation-designated address;
    8. Produce complete status-change records for audit.

    The first version does not need to implement:

    1. Complex risk scoring;
    2. Application-specific lock periods;
    3. Fully automated penalties;
    4. On-chain recovery of already released rewards;
    5. Complex activity-quality scoring;
    6. A complex appeal system.

    These can be added in later versions.

    13. Parameters

    The first version only needs a small number of configurable parameters:

    Parameter Description
    lockRounds Reward lock period
    maxCoverageRatio Coverage ratio threshold
    reviewTimeoutRounds Maximum review duration
    partialReleaseAllowed Whether partial release is allowed
    manualReviewEnabled Whether manual review flags are allowed
    treasuryPartyId Receiver Party for cancelled rewards

    These parameters should be managed by the Foundation or the Tokenomics Committee and communicated to the community in advance.

    14. Relationship With CIP-0116

    CIP-0116 proposes Featured App Staking as a way to improve Featured App quality, create stronger economic alignment, and increase the cost of misconduct. This proposal agrees with those objectives.

    The difference is the enforcement point.

    Featured App Staking places the control point before application participation by requiring an upfront stake. This proposal places the control point before reward release by locking newly generated rewards and reviewing them before they become spendable.

    Item Featured App Staking Reward Locking and Review
    Control point Before application participation Before reward release
    Capital requirement Requires upfront stake Does not require large upfront stake
    Risk-control method Stake constraint Locked unreleased rewards
    Impact on early-stage teams Higher Lower
    Technical focus Stake lock / unlock Reward lock / release
    Impact on reward calculation Not necessarily None
    Can prevent abnormal rewards from flowing out quickly Yes Yes

    This proposal can be implemented independently or combined with Featured App Staking. For example, the Foundation may apply staking requirements to larger mature applications, reward locking to early-stage applications, or allow both mechanisms as alternative paths for satisfying Featured App risk-control requirements.

    15. Backward Compatibility

    This proposal does not change the Featured App application process, the use of App Provider PartyId, or the Marker submission path.

    For existing Featured Apps:

    1. Already released rewards are not affected;
    2. Newly generated rewards may enter the locking and review process;
    3. Normal applications are only affected by the release timing;
    4. Unreleased rewards of abnormal applications may be paused;
    5. The Foundation may define a transition period based on actual conditions.

    For new Featured Apps:

    1. A unified lock period applies by default;
    2. Rewards are released normally after the observation window if compliant;
    3. Long-term compliant applications may later be eligible for a shorter lock period.

    16. Security and Governance Considerations

    The security boundary of this mechanism should remain clear:

    1. The system only controls unreleased rewards;
    2. Automatic rules only trigger review and do not automatically determine misconduct;
    3. Final handling is executed by the Foundation or the Tokenomics Committee;
    4. All status changes should leave on-ledger or auditable records;
    5. Parameter changes should be communicated in advance;
    6. Cancelled rewards must move to a publicly designated address;
    7. Applications should have the opportunity to submit structured explanatory materials;
    8. Administrative authority should be limited to Parties authorized by the Foundation or the Tokenomics Committee;
    9. Any manual status change should record the executing Party, execution time, reason code, and final outcome.

    This design avoids excessive automated punishment while ensuring abnormal rewards do not flow out before review.

    17. Expected Effects

    This proposal is expected to:

    1. Improve control over Featured App reward release;
    2. Reduce the risk of reward outflows caused by abnormal Marker behavior;
    3. Preserve a more developer-friendly entry path for genuine applications;
    4. Provide the Foundation with a clear reward review window;
    5. Create a natural short-term lock for unreleased rewards;
    6. Reduce immediate circulating supply impact from newly generated rewards;
    7. Improve auditability of the Featured App reward system;
    8. Remain compatible with Canton’s existing reward round, PartyId, and Marker mechanisms.

    18. Alternatives Considered

    Approach Advantages Disadvantages Decision
    Immediate reward release Simplest implementation Abnormal rewards may flow out quickly Not suitable as the only long-term approach
    Large upfront stake Increases misconduct cost High barrier for early-stage genuine developers Can be one path, but may not be the only path
    Reward locking and review Simple implementation, lower entry barrier, controls abnormal reward outflow Requires a new reward state machine Recommended as a base governance mechanism
    Fully automated penalties Fast response May incorrectly penalize normal applications Not recommended for the first version
    Manual review of all rewards Flexible Costly and difficult to scale Suitable only for abnormal cases

    Copyright

    This CIP is licensed under CC0-1.0: Creative Commons CC0 1.0 Universal.

  2. #2Eric Saraniecki15-05-2026source ↗
    thanks Thomas - this approach was examined at length and the SVs were ultimately deterred for a number of reasons 

    1. Revenue / Tax accounting - becomes a nightmare with the delays 
    2. Centralizes release of funds into the Foundation and puts tremendous legal and regulatory overhead on the Foundation
    3. Complexity - introduced a lot of complexity and harder to understand

    Right now, apps like Acme, Alpend, Haven, and various OTC venues have good lending of CC for any credible app. You can borrow good size CC well under 5% and this is by far the easiest approach



    On Fri, May 15, 2026 at 8:29 AM reborntaichi via lists.sync.global <reborntaichi=gmail.com@...> wrote:

    Dear Community,

    As a member of the Canton community, I would like to share an idea for discussion regarding the Featured App reward mechanism.

    The intent of CIP-0116 is understandable and important. Featured App status carries network recognition, ecosystem visibility, and access to incentives. It is reasonable for the network to expect Featured Apps to demonstrate stronger commitment, better quality, and a higher cost of misconduct.

    At the same time, there may be a lighter way to achieve the same risk-control objective without requiring every genuine application team to meet a large upfront CC staking threshold. This proposal introduces a reward locking and review mechanism that places the control point before reward release rather than before application participation.

    The goal is to preserve strong safeguards against abnormal Marker behavior while keeping the Featured App program accessible to real builders, early-stage teams, and smaller applications contributing genuine activity to the Canton Network.

    Feedback, suggestions, and improvements from the community, the Foundation, and the relevant committees are welcome.

    Number: CIP-TBD
    Title: Featured App Reward Locking and Review Mechanism
    Author(s): Thomas V. Turner
    Type: Tokenomics
    Status: Draft
    Created: 2026-05-11
    License: CC0-1.0

    Featured App Reward Locking and Review Mechanism

    Summary

    This proposal introduces a reward locking and review mechanism for Featured App rewards on the Canton Network.

    The mechanism does not change how Featured App Activity Markers are submitted, does not change the existing reward calculation logic, and does not change the basic path through which applications earn rewards from genuine on-chain activity. It only adds a reward-round-based lock, check, review, and release process after Featured App rewards are calculated and before they are released to the App Provider PartyId.

    Under this mechanism, each Featured App reward first enters a locked state. Each locked reward is associated with the corresponding reward round, App Provider PartyId, reward amount, and unlock round. When the lock period ends, the reward may be released if the application’s data during the observation window remains within the expected range. If abnormal conditions are triggered, the reward enters a review state and remains locked until the review is resolved.

    This proposal is designed to:

    1. Preserve the incentive effect of Featured App rewards for genuine applications;
    2. Provide the Foundation and the Tokenomics Committee with a review window before rewards are released;
    3. Prevent abnormal Marker behavior from quickly becoming immediately spendable rewards;
    4. Reduce upfront capital pressure on early-stage teams and smaller genuine developers;
    5. Keep newly generated Featured App rewards locked for a defined period, reducing immediate circulating supply impact;
    6. Improve auditability and governance of reward releases without rebuilding the existing Featured App reward mechanism.

    This proposal can serve as a lighter alternative or complement to Featured App Staking. CIP-0116 addresses a valid concern by increasing application commitment and misconduct cost through upfront CC staking. This proposal addresses the same concern by locking unreleased rewards and reviewing them before release, which may be easier to implement and less restrictive for early-stage ecosystem growth.

    Motivation

    The core purpose of the Featured App reward mechanism is to encourage applications to create genuine, valuable, and verifiable on-chain activity on the Canton Network. Featured App status represents network recognition, ecosystem visibility, and reward eligibility. Applications should therefore be held to a higher standard regarding Marker submission logic and the quality of their on-chain activity.

    As the scale of Featured App rewards grows, the network needs stronger governance tools to handle abnormal behavior. If an application submits incorrect Markers, excessive Markers, duplicate Markers, or marks activity that does not comply with the rules as Maker activity, rewards may be released before the issue is detected. Suspending an application after the fact can stop future risk, but handling rewards that have already been released is more difficult.

    CIP-0116 proposes Featured App Staking as a way to raise application responsibility and increase the cost of misconduct. This direction is reasonable. Featured Apps should have stronger economic alignment with the network, and applications that benefit from network incentives should not be able to abuse the reward system without consequence.

    However, a high upfront CC stake may also create a significant participation barrier. Early-stage applications and smaller teams may have real products, real users, and long-term commitment, but may not be able to meet a large staking requirement at an early stage. If Featured App eligibility relies mainly on upfront capital, Canton may become less accessible to new applications and innovative teams.

    This proposal offers another path. Instead of requiring every application to provide a large stake before participation, the control point is placed before reward release.

    As long as rewards remain locked, the Foundation can pause release, initiate review, and decide whether to release, partially release, extend the lock, or cancel release based on the review outcome. This increases the cost of non-compliant behavior without requiring genuine developers to bear excessive upfront capital pressure.

    Reward locking also has a tokenomics benefit. Newly generated Featured App rewards do not immediately enter circulation. They remain locked during the observation period, reducing short-term circulating supply pressure and making the reward release schedule smoother, more predictable, and more governable.

    Specification

    1. Scope

    This proposal only adds governance logic to the Featured App reward release layer.

    It does not modify:

    1. The submission method of Featured App Activity Markers;
    2. Canton’s existing transaction, fee, or reward round mechanism;
    3. The Featured App reward calculation formula;
    4. The basic use of App Provider PartyId;
    5. Application business contracts;
    6. A requirement for every application to provide a large upfront CC stake;
    7. Any default retroactive treatment of historical rewards already released to application addresses.

    The mechanism introduced by this proposal only applies to Featured App rewards that have been calculated but not yet released.

    2. Core Mechanism

    After each Featured App reward is generated, it is not released to the application immediately. Instead, it enters an auditable lock record.

    This lock record may be implemented as an on-ledger contract state, a Foundation-managed reward release ledger, or a combination of both. The first version can use a minimum viable implementation with an independent Reward Lock Record to track reward status, with the Foundation or the Tokenomics Committee authorized to execute release, review, and cancellation actions.

    Each lock record can be represented as:

    FeaturedAppRewardLock

    This record only manages reward release status. It does not participate in application business logic and does not modify existing application contracts.

    3. FeaturedAppRewardLock Data Structure

    Each FeaturedAppRewardLock should contain at least the following fields:

    Field Description
    lockId Unique ID of the lock record
    appProviderPartyId PartyId of the Featured App
    rewardRound Reward round in which the reward was generated
    amount Locked reward amount
    unlockRound Earliest reward round in which the reward can enter the release process
    status Current status
    reviewFlag Whether review has been triggered
    reasonCode Reason code for triggering review
    releasedAmount Amount already released
    cancelledAmount Amount cancelled from release
    createdAtRound Reward round in which the lock record was created
    updatedAtRound Most recent reward round in which the status was updated

    Optional fields may include:

    Field Description
    coverageRatio Coverage ratio calculated for the observation window
    markersSubmitted Marker amount submitted and counted during the observation window
    ccTransfersWithCoupons CC transfers with coupons during the observation window
    trafficCostUsd Traffic cost used for coverage ratio calculation during the observation window, denominated in USD
    reviewCaseId ID of the related review case
    adminPartyId Admin Party that executed the most recent status change
    resolutionNoteHash Hash or reference to the review resolution note

    4. Reward Status

    To keep the mechanism simple, the first version may use the following statuses:

    Status Meaning
    Locked Reward is locked and has not reached the unlock round
    PendingRelease Reward has reached the unlock round and is waiting for checks or batch release
    UnderReview Abnormal conditions have been triggered and the reward is waiting for review
    Released Reward has been released to the application
    PartiallyReleased Part of the reward has been released, while part has been cancelled or remains locked
    Cancelled Reward has been cancelled from release and moved to a Foundation-defined handling path

    The Cancelled status serves as the practical implementation of clawback for the first version. To reduce technical complexity, the base mechanism focuses on unreleased rewards and does not default to recovering rewards that have already been released to an application address.

    In this proposal, clawback should therefore be understood as:

    Cancelling, partially cancelling, or reallocating abnormal rewards that remain locked and have not yet been released.

    If the Foundation wishes to extend the mechanism to already released rewards in the future, that can be handled through a separate governance rule or a later version.

    5. Reward Round and Lock Period

    Each reward is locked based on reward rounds.

    The mechanism is:

    1. Reward generation round: R
    2. Lock period: N reward rounds
    3. Earliest unlock round: R + N
    4. Observation window: R through R + N - 1

    N is a system parameter set by the Foundation or the Tokenomics Committee.

    The initial version can use a simple, unified N, such as the number of reward rounds corresponding to 7 days.

    If each reward round is approximately 15 minutes:

    7 days × 24 hours × 60 minutes ÷ 15 minutes = 672 reward rounds

    Therefore, lockRounds = 672 can be used as an initial reference parameter.

    To keep implementation simple, the first version does not need application-specific lock periods. A unified lock period can be used first. Later versions may shorten the lock period for long-term compliant applications or extend it for higher-risk applications.

    6. Coverage Ratio Calculation

    The unlock check can reference the existing coverage ratio standard in the official Featured App Marker Guidance. This can serve as an important indicator for determining whether an application’s Marker behavior during the observation window remains within a reasonable range.

    The formula is:

    Coverage Ratio = (markers submitted + CC transfers with coupons) / traffic cost (USD)

    Where:

    1. markers submitted means Markers submitted and counted for the Featured App during the observation window;
    2. CC transfers with coupons means CC transfers with coupons during the observation window;
    3. traffic cost (USD) means the traffic cost used for this calculation during the observation window, denominated in USD;
    4. Marker submission cost is not included in traffic cost.

    That is:

    marker submission cost excluded from traffic

    To avoid future implementation rigidity, the coverage ratio formula, data source, and threshold should be treated as configurable governance parameters or external calculation rules, rather than being hard-coded into the core contract.

    The system only needs to record the calculation result, data-source reference, and observation window so the Foundation or the Tokenomics Committee can review them.

    7. Unlock Check

    When the current reward round is greater than or equal to unlockRound, the locked reward enters PendingRelease.

    The system or the Foundation checks the data of the relevant appProviderPartyId during the observation window.

    7.1 Minimum Check Items

    The first version only needs to check clear, calculable, and auditable indicators:

    1. markersSubmitted
    2. ccTransfersWithCoupons
    3. trafficCostUsd
    4. coverageRatio
    5. Whether a manual review flag exists
    6. Whether the App Provider PartyId is under Featured App suspension

    7.2 Basic Release Rule

    A reward may be released if all of the following conditions are met:

    1. currentRound >= unlockRound
    2. coverageRatio <= maxCoverageRatio during the observation window
    3. The reward has not been manually marked as UnderReview
    4. The appProviderPartyId is not under Featured App suspension
    5. There are no confirmed duplicate Marker records or invalid Marker records

    If any condition is not met, the reward enters UnderReview.

    7.3 Initial Threshold

    The Foundation may set an initial coverage ratio threshold such as:

    maxCoverageRatio = 1.15

    This value is a governance parameter. The Foundation or the Tokenomics Committee may adjust it based on actual network conditions.

    8. Review Triggers

    To keep the mechanism implementable, the first version should only use clear, calculable, and auditable review triggers.

    A reward may enter UnderReview if any of the following conditions occurs:

    1. coverageRatio > maxCoverageRatio during the observation window
    2. The same activity is used for duplicate Marker submissions
    3. The activity corresponding to a Marker cannot be matched to a valid on-chain transaction or contract event
    4. The App Provider PartyId is under Featured App suspension
    5. The Foundation or the Tokenomics Committee manually sets a review flag
    6. There is material data loss or a calculation-method conflict during the observation window, making it impossible to determine whether the reward should be released

    The first version should avoid using overly subjective automatic triggers such as “low-quality activity” or “insufficient ecosystem value.” These may be considered as background information during manual review, but should not be used as core automatic triggers.

    9. Review Process

    Once a reward enters UnderReview, the system does not release it.

    The review process is:

    1. The Foundation creates a review case;
    2. The system records the trigger reason, reward round, observation window, and related data;
    3. The application submits structured explanatory materials;
    4. The Foundation or the Tokenomics Committee reviews the case;
    5. The reward status is updated based on the review result.

    9.1 Materials Submitted by the Application

    Applications should submit structured materials rather than relying on informal communication.

    Recommended materials include:

    1. Relevant reward round range;
    2. Marker submission logic;
    3. On-chain transactions or contract events corresponding to the Markers;
    4. Traffic cost calculation method;
    5. Statistical basis for markers submitted and CC transfers with coupons;
    6. Explanation for abnormal coverage ratio;
    7. Whether there was a system error or configuration error;
    8. Remediation measures;
    9. Measures to prevent recurrence.

    9.2 Review Outcomes

    After review, the mechanism should keep four possible outcomes:

    Outcome Status Change Description
    Full release UnderReview → Released Data is reasonable and the reward is released
    Partial release UnderReview → PartiallyReleased Part of the reward is valid and part is cancelled
    Extended lock UnderReview → Locked Information is insufficient and further observation is needed
    Cancel release UnderReview → Cancelled The reward is confirmed not to be releasable

    Cancelled rewards do not enter the application address. They are moved to a Foundation-designated treasury, ecosystem fund, or other governance-approved address.

    10. Example

    Assume a Featured App generates 100 CC in Featured App rewards at reward round 10,000.

    The Foundation has set the following parameters:

    Parameter Value
    lockRounds 672
    maxCoverageRatio 1.15
    Reward generation round 10,000
    Earliest unlock round 10,672
    Observation window 10,000 to 10,671

    At reward round 10,000, the system creates a FeaturedAppRewardLock record:

    Field Value
    appProviderPartyId App A PartyId
    rewardRound 10,000
    amount 100 CC
    unlockRound 10,672
    status Locked

    When the network reaches reward round 10,672, the reward enters PendingRelease. The system or the Foundation calculates the coverage ratio for the observation window from reward round 10,000 to reward round 10,671.

    Case 1: Normal Release

    Assume the observation window data is:

    Indicator Value
    markers submitted 900
    CC transfers with coupons 50
    traffic cost (USD) 1,000
    coverageRatio (900 + 50) / 1,000 = 0.95

    Because 0.95 <= 1.15, and there is no manual review flag, duplicate Marker record, or suspension status, the reward can be released.

    Status change:

    Locked → PendingRelease → Released

    The 100 CC is released to App A’s App Provider PartyId.

    Case 2: Review Triggered

    Assume the observation window data is:

    Indicator Value
    markers submitted 1,300
    CC transfers with coupons 100
    traffic cost (USD) 1,000
    coverageRatio (1,300 + 100) / 1,000 = 1.40

    Because 1.40 > 1.15, the reward is not released immediately and enters UnderReview.

    Status change:

    Locked → PendingRelease → UnderReview

    The Foundation or the Tokenomics Committee may require App A to provide its Marker submission logic, corresponding on-chain activity, traffic cost calculation method, and explanation for the abnormal ratio.

    If the review confirms that the data is reasonable, the reward can be released.

    If the review confirms that only part of the Marker activity is valid, the valid part can be released and the invalid part can be cancelled.

    For example:

    Result Amount
    Released 60 CC
    Cancelled 40 CC

    Status change:

    UnderReview → PartiallyReleased

    The cancelled 40 CC does not enter App A’s PartyId. It is moved to a Foundation-designated treasury or ecosystem fund.

    If the review confirms that the reward was entirely generated from non-compliant activity, the status changes to:

    UnderReview → Cancelled

    The full 100 CC is not released to App A and is handled according to Foundation governance rules.

    11. Technical Implementation

    This mechanism can be implemented as an independent reward release state machine. It does not require changes to application business contracts.

    11.1 Roles

    Role Description
    RewardAllocator Existing reward calculation or allocation module
    RewardLockController New reward locking and release-control module
    FoundationAdminParty Foundation administrative Party
    TokenomicsCommitteeParty Tokenomics Committee or authorized review Party
    AppProviderParty Featured App Party
    FoundationTreasuryParty Receiver Party for cancelled rewards

    11.2 Core State Object

    A simple Daml contract or equivalent state object may be introduced:

    FeaturedAppRewardLock

    This object only records reward status and does not participate in application business logic.

    It may support the following operations:

    Operation Executor Purpose
    CreateLock RewardAllocator / FoundationAdminParty Create a reward lock record
    MarkPendingRelease RewardLockController Mark reward as pending release after unlock round
    Release RewardLockController / FoundationAdminParty Release reward to AppProviderParty
    FlagReview FoundationAdminParty / TokenomicsCommitteeParty Move reward into review
    ResolveReviewRelease TokenomicsCommitteeParty Release after review
    ResolveReviewPartialRelease TokenomicsCommitteeParty Partially release after review
    ExtendLock TokenomicsCommitteeParty Extend the lock
    CancelRelease TokenomicsCommitteeParty Cancel release and move reward to a designated Party

    11.3 Reward Fund Flow

    The recommended reward fund flow is:

    1. Featured App reward calculation is completed;
    2. Reward enters a locked state or locked address controlled by RewardLockController;
    3. The system creates a FeaturedAppRewardLock;
    4. When unlockRound is reached, the unlock check is executed;
    5. If the reward passes the check, it is released to AppProviderParty;
    6. If it fails the check, it enters UnderReview;
    7. Cancelled rewards are moved to FoundationTreasuryParty or another governance-designated address.

    This path avoids the need to recover funds from application addresses after release. It is simpler to implement and has a clearer enforcement boundary.

    12. Minimum Viable Version

    The first version only needs to implement:

    1. Create reward lock records by reward round;
    2. Set a unified lockRounds parameter;
    3. Calculate observation-window metrics using the coverage ratio standard in the official Featured App Marker Guidance;
    4. Determine release based on maxCoverageRatio after the lock period ends;
    5. Allow the Foundation to manually set UnderReview;
    6. Support four review outcomes: release, partial release, extended lock, and cancelled release;
    7. Move cancelled rewards to a Foundation-designated address;
    8. Produce complete status-change records for audit.

    The first version does not need to implement:

    1. Complex risk scoring;
    2. Application-specific lock periods;
    3. Fully automated penalties;
    4. On-chain recovery of already released rewards;
    5. Complex activity-quality scoring;
    6. A complex appeal system.

    These can be added in later versions.

    13. Parameters

    The first version only needs a small number of configurable parameters:

    Parameter Description
    lockRounds Reward lock period
    maxCoverageRatio Coverage ratio threshold
    reviewTimeoutRounds Maximum review duration
    partialReleaseAllowed Whether partial release is allowed
    manualReviewEnabled Whether manual review flags are allowed
    treasuryPartyId Receiver Party for cancelled rewards

    These parameters should be managed by the Foundation or the Tokenomics Committee and communicated to the community in advance.

    14. Relationship With CIP-0116

    CIP-0116 proposes Featured App Staking as a way to improve Featured App quality, create stronger economic alignment, and increase the cost of misconduct. This proposal agrees with those objectives.

    The difference is the enforcement point.

    Featured App Staking places the control point before application participation by requiring an upfront stake. This proposal places the control point before reward release by locking newly generated rewards and reviewing them before they become spendable.

    Item Featured App Staking Reward Locking and Review
    Control point Before application participation Before reward release
    Capital requirement Requires upfront stake Does not require large upfront stake
    Risk-control method Stake constraint Locked unreleased rewards
    Impact on early-stage teams Higher Lower
    Technical focus Stake lock / unlock Reward lock / release
    Impact on reward calculation Not necessarily None
    Can prevent abnormal rewards from flowing out quickly Yes Yes

    This proposal can be implemented independently or combined with Featured App Staking. For example, the Foundation may apply staking requirements to larger mature applications, reward locking to early-stage applications, or allow both mechanisms as alternative paths for satisfying Featured App risk-control requirements.

    15. Backward Compatibility

    This proposal does not change the Featured App application process, the use of App Provider PartyId, or the Marker submission path.

    For existing Featured Apps:

    1. Already released rewards are not affected;
    2. Newly generated rewards may enter the locking and review process;
    3. Normal applications are only affected by the release timing;
    4. Unreleased rewards of abnormal applications may be paused;
    5. The Foundation may define a transition period based on actual conditions.

    For new Featured Apps:

    1. A unified lock period applies by default;
    2. Rewards are released normally after the observation window if compliant;
    3. Long-term compliant applications may later be eligible for a shorter lock period.

    16. Security and Governance Considerations

    The security boundary of this mechanism should remain clear:

    1. The system only controls unreleased rewards;
    2. Automatic rules only trigger review and do not automatically determine misconduct;
    3. Final handling is executed by the Foundation or the Tokenomics Committee;
    4. All status changes should leave on-ledger or auditable records;
    5. Parameter changes should be communicated in advance;
    6. Cancelled rewards must move to a publicly designated address;
    7. Applications should have the opportunity to submit structured explanatory materials;
    8. Administrative authority should be limited to Parties authorized by the Foundation or the Tokenomics Committee;
    9. Any manual status change should record the executing Party, execution time, reason code, and final outcome.

    This design avoids excessive automated punishment while ensuring abnormal rewards do not flow out before review.

    17. Expected Effects

    This proposal is expected to:

    1. Improve control over Featured App reward release;
    2. Reduce the risk of reward outflows caused by abnormal Marker behavior;
    3. Preserve a more developer-friendly entry path for genuine applications;
    4. Provide the Foundation with a clear reward review window;
    5. Create a natural short-term lock for unreleased rewards;
    6. Reduce immediate circulating supply impact from newly generated rewards;
    7. Improve auditability of the Featured App reward system;
    8. Remain compatible with Canton’s existing reward round, PartyId, and Marker mechanisms.

    18. Alternatives Considered

    Approach Advantages Disadvantages Decision
    Immediate reward release Simplest implementation Abnormal rewards may flow out quickly Not suitable as the only long-term approach
    Large upfront stake Increases misconduct cost High barrier for early-stage genuine developers Can be one path, but may not be the only path
    Reward locking and review Simple implementation, lower entry barrier, controls abnormal reward outflow Requires a new reward state machine Recommended as a base governance mechanism
    Fully automated penalties Fast response May incorrectly penalize normal applications Not recommended for the first version
    Manual review of all rewards Flexible Costly and difficult to scale Suitable only for abnormal cases

    Copyright

    This CIP is licensed under CC0-1.0: Creative Commons CC0 1.0 Universal.


    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.
  3. #3Mark Wendland15-05-2026source ↗
    I will add, Canton Strategic is happy to engage in conversations on locking/sourcing of CC for Canton ecosystem participants. Feel free to reach out if any interest.

    Mark Wendland
    toggle quoted message Show quoted text

    From: cip-discuss@... <cip-discuss@...> on behalf of Eric Saraniecki via lists.sync.global <eric=digitalasset.com@...>
    Sent: Friday, May 15, 2026 8:29 AM
    To: cip-discuss@... <cip-discuss@...>
    Subject: Re: [cip-discuss] CIP-TBD: Featured App Reward Locking and Review Mechanism
     
    thanks Thomas - this approach was examined at length and the SVs were ultimately deterred for a number of reasons 

    1. Revenue / Tax accounting - becomes a nightmare with the delays 
    2. Centralizes release of funds into the Foundation and puts tremendous legal and regulatory overhead on the Foundation
    3. Complexity - introduced a lot of complexity and harder to understand

    Right now, apps like Acme, Alpend, Haven, and various OTC venues have good lending of CC for any credible app. You can borrow good size CC well under 5% and this is by far the easiest approach



    On Fri, May 15, 2026 at 8:29 AM reborntaichi via lists.sync.global <reborntaichi=gmail.com@...> wrote:

    Dear Community,

    As a member of the Canton community, I would like to share an idea for discussion regarding the Featured App reward mechanism.

    The intent of CIP-0116 is understandable and important. Featured App status carries network recognition, ecosystem visibility, and access to incentives. It is reasonable for the network to expect Featured Apps to demonstrate stronger commitment, better quality, and a higher cost of misconduct.

    At the same time, there may be a lighter way to achieve the same risk-control objective without requiring every genuine application team to meet a large upfront CC staking threshold. This proposal introduces a reward locking and review mechanism that places the control point before reward release rather than before application participation.

    The goal is to preserve strong safeguards against abnormal Marker behavior while keeping the Featured App program accessible to real builders, early-stage teams, and smaller applications contributing genuine activity to the Canton Network.

    Feedback, suggestions, and improvements from the community, the Foundation, and the relevant committees are welcome.

    Number: CIP-TBD
    Title: Featured App Reward Locking and Review Mechanism
    Author(s): Thomas V. Turner
    Type: Tokenomics
    Status: Draft
    Created: 2026-05-11
    License: CC0-1.0

    Featured App Reward Locking and Review Mechanism

    Summary

    This proposal introduces a reward locking and review mechanism for Featured App rewards on the Canton Network.

    The mechanism does not change how Featured App Activity Markers are submitted, does not change the existing reward calculation logic, and does not change the basic path through which applications earn rewards from genuine on-chain activity. It only adds a reward-round-based lock, check, review, and release process after Featured App rewards are calculated and before they are released to the App Provider PartyId.

    Under this mechanism, each Featured App reward first enters a locked state. Each locked reward is associated with the corresponding reward round, App Provider PartyId, reward amount, and unlock round. When the lock period ends, the reward may be released if the application’s data during the observation window remains within the expected range. If abnormal conditions are triggered, the reward enters a review state and remains locked until the review is resolved.

    This proposal is designed to:

    1. Preserve the incentive effect of Featured App rewards for genuine applications;
    2. Provide the Foundation and the Tokenomics Committee with a review window before rewards are released;
    3. Prevent abnormal Marker behavior from quickly becoming immediately spendable rewards;
    4. Reduce upfront capital pressure on early-stage teams and smaller genuine developers;
    5. Keep newly generated Featured App rewards locked for a defined period, reducing immediate circulating supply impact;
    6. Improve auditability and governance of reward releases without rebuilding the existing Featured App reward mechanism.

    This proposal can serve as a lighter alternative or complement to Featured App Staking. CIP-0116 addresses a valid concern by increasing application commitment and misconduct cost through upfront CC staking. This proposal addresses the same concern by locking unreleased rewards and reviewing them before release, which may be easier to implement and less restrictive for early-stage ecosystem growth.

    Motivation

    The core purpose of the Featured App reward mechanism is to encourage applications to create genuine, valuable, and verifiable on-chain activity on the Canton Network. Featured App status represents network recognition, ecosystem visibility, and reward eligibility. Applications should therefore be held to a higher standard regarding Marker submission logic and the quality of their on-chain activity.

    As the scale of Featured App rewards grows, the network needs stronger governance tools to handle abnormal behavior. If an application submits incorrect Markers, excessive Markers, duplicate Markers, or marks activity that does not comply with the rules as Maker activity, rewards may be released before the issue is detected. Suspending an application after the fact can stop future risk, but handling rewards that have already been released is more difficult.

    CIP-0116 proposes Featured App Staking as a way to raise application responsibility and increase the cost of misconduct. This direction is reasonable. Featured Apps should have stronger economic alignment with the network, and applications that benefit from network incentives should not be able to abuse the reward system without consequence.

    However, a high upfront CC stake may also create a significant participation barrier. Early-stage applications and smaller teams may have real products, real users, and long-term commitment, but may not be able to meet a large staking requirement at an early stage. If Featured App eligibility relies mainly on upfront capital, Canton may become less accessible to new applications and innovative teams.

    This proposal offers another path. Instead of requiring every application to provide a large stake before participation, the control point is placed before reward release.

    As long as rewards remain locked, the Foundation can pause release, initiate review, and decide whether to release, partially release, extend the lock, or cancel release based on the review outcome. This increases the cost of non-compliant behavior without requiring genuine developers to bear excessive upfront capital pressure.

    Reward locking also has a tokenomics benefit. Newly generated Featured App rewards do not immediately enter circulation. They remain locked during the observation period, reducing short-term circulating supply pressure and making the reward release schedule smoother, more predictable, and more governable.

    Specification

    1. Scope

    This proposal only adds governance logic to the Featured App reward release layer.

    It does not modify:

    1. The submission method of Featured App Activity Markers;
    2. Canton’s existing transaction, fee, or reward round mechanism;
    3. The Featured App reward calculation formula;
    4. The basic use of App Provider PartyId;
    5. Application business contracts;
    6. A requirement for every application to provide a large upfront CC stake;
    7. Any default retroactive treatment of historical rewards already released to application addresses.

    The mechanism introduced by this proposal only applies to Featured App rewards that have been calculated but not yet released.

    2. Core Mechanism

    After each Featured App reward is generated, it is not released to the application immediately. Instead, it enters an auditable lock record.

    This lock record may be implemented as an on-ledger contract state, a Foundation-managed reward release ledger, or a combination of both. The first version can use a minimum viable implementation with an independent Reward Lock Record to track reward status, with the Foundation or the Tokenomics Committee authorized to execute release, review, and cancellation actions.

    Each lock record can be represented as:

    FeaturedAppRewardLock

    This record only manages reward release status. It does not participate in application business logic and does not modify existing application contracts.

    3. FeaturedAppRewardLock Data Structure

    Each FeaturedAppRewardLock should contain at least the following fields:

    Field
    Description
    lockId
    Unique ID of the lock record
    appProviderPartyId
    PartyId of the Featured App
    rewardRound
    Reward round in which the reward was generated
    amount
    Locked reward amount
    unlockRound
    Earliest reward round in which the reward can enter the release process
    status
    Current status
    reviewFlag
    Whether review has been triggered
    reasonCode
    Reason code for triggering review
    releasedAmount
    Amount already released
    cancelledAmount
    Amount cancelled from release
    createdAtRound
    Reward round in which the lock record was created
    updatedAtRound
    Most recent reward round in which the status was updated

    Optional fields may include:

    Field
    Description
    coverageRatio
    Coverage ratio calculated for the observation window
    markersSubmitted
    Marker amount submitted and counted during the observation window
    ccTransfersWithCoupons
    CC transfers with coupons during the observation window
    trafficCostUsd
    Traffic cost used for coverage ratio calculation during the observation window, denominated in USD
    reviewCaseId
    ID of the related review case
    adminPartyId
    Admin Party that executed the most recent status change
    resolutionNoteHash
    Hash or reference to the review resolution note

    4. Reward Status

    To keep the mechanism simple, the first version may use the following statuses:

    Status
    Meaning
    Locked
    Reward is locked and has not reached the unlock round
    PendingRelease
    Reward has reached the unlock round and is waiting for checks or batch release
    UnderReview
    Abnormal conditions have been triggered and the reward is waiting for review
    Released
    Reward has been released to the application
    PartiallyReleased
    Part of the reward has been released, while part has been cancelled or remains locked
    Cancelled
    Reward has been cancelled from release and moved to a Foundation-defined handling path

    The Cancelled status serves as the practical implementation of clawback for the first version. To reduce technical complexity, the base mechanism focuses on unreleased rewards and does not default to recovering rewards that have already been released to an application address.

    In this proposal, clawback should therefore be understood as:

    Cancelling, partially cancelling, or reallocating abnormal rewards that remain locked and have not yet been released.

    If the Foundation wishes to extend the mechanism to already released rewards in the future, that can be handled through a separate governance rule or a later version.

    5. Reward Round and Lock Period

    Each reward is locked based on reward rounds.

    The mechanism is:

    1. Reward generation round: R
    2. Lock period: N reward rounds
    3. Earliest unlock round: R + N
    4. Observation window: R through R + N - 1

    N is a system parameter set by the Foundation or the Tokenomics Committee.

    The initial version can use a simple, unified N, such as the number of reward rounds corresponding to 7 days.

    If each reward round is approximately 15 minutes:

    7 days × 24 hours × 60 minutes ÷ 15 minutes = 672 reward rounds

    Therefore, lockRounds = 672 can be used as an initial reference parameter.

    To keep implementation simple, the first version does not need application-specific lock periods. A unified lock period can be used first. Later versions may shorten the lock period for long-term compliant applications or extend it for higher-risk applications.

    6. Coverage Ratio Calculation

    The unlock check can reference the existing coverage ratio standard in the official Featured App Marker Guidance. This can serve as an important indicator for determining whether an application’s Marker behavior during the observation window remains within a reasonable range.

    The formula is:

    Coverage Ratio = (markers submitted + CC transfers with coupons) / traffic cost (USD)

    Where:

    1. markers submitted means Markers submitted and counted for the Featured App during the observation window;
    2. CC transfers with coupons means CC transfers with coupons during the observation window;
    3. traffic cost (USD) means the traffic cost used for this calculation during the observation window, denominated in USD;
    4. Marker submission cost is not included in traffic cost.

    That is:

    marker submission cost excluded from traffic

    To avoid future implementation rigidity, the coverage ratio formula, data source, and threshold should be treated as configurable governance parameters or external calculation rules, rather than being hard-coded into the core contract.

    The system only needs to record the calculation result, data-source reference, and observation window so the Foundation or the Tokenomics Committee can review them.

    7. Unlock Check

    When the current reward round is greater than or equal to unlockRound, the locked reward enters PendingRelease.

    The system or the Foundation checks the data of the relevant appProviderPartyId during the observation window.

    7.1 Minimum Check Items

    The first version only needs to check clear, calculable, and auditable indicators:

    1. markersSubmitted
    2. ccTransfersWithCoupons
    3. trafficCostUsd
    4. coverageRatio
    5. Whether a manual review flag exists
    6. Whether the App Provider PartyId is under Featured App suspension

    7.2 Basic Release Rule

    A reward may be released if all of the following conditions are met:

    1. currentRound >= unlockRound
    2. coverageRatio <= maxCoverageRatio during the observation window
    3. The reward has not been manually marked as UnderReview
    4. The appProviderPartyId is not under Featured App suspension
    5. There are no confirmed duplicate Marker records or invalid Marker records

    If any condition is not met, the reward enters UnderReview.

    7.3 Initial Threshold

    The Foundation may set an initial coverage ratio threshold such as:

    maxCoverageRatio = 1.15

    This value is a governance parameter. The Foundation or the Tokenomics Committee may adjust it based on actual network conditions.

    8. Review Triggers

    To keep the mechanism implementable, the first version should only use clear, calculable, and auditable review triggers.

    A reward may enter UnderReview if any of the following conditions occurs:

    1. coverageRatio > maxCoverageRatio during the observation window
    2. The same activity is used for duplicate Marker submissions
    3. The activity corresponding to a Marker cannot be matched to a valid on-chain transaction or contract event
    4. The App Provider PartyId is under Featured App suspension
    5. The Foundation or the Tokenomics Committee manually sets a review flag
    6. There is material data loss or a calculation-method conflict during the observation window, making it impossible to determine whether the reward should be released

    The first version should avoid using overly subjective automatic triggers such as “low-quality activity” or “insufficient ecosystem value.” These may be considered as background information during manual review, but should not be used as core automatic triggers.

    9. Review Process

    Once a reward enters UnderReview, the system does not release it.

    The review process is:

    1. The Foundation creates a review case;
    2. The system records the trigger reason, reward round, observation window, and related data;
    3. The application submits structured explanatory materials;
    4. The Foundation or the Tokenomics Committee reviews the case;
    5. The reward status is updated based on the review result.

    9.1 Materials Submitted by the Application

    Applications should submit structured materials rather than relying on informal communication.

    Recommended materials include:

    1. Relevant reward round range;
    2. Marker submission logic;
    3. On-chain transactions or contract events corresponding to the Markers;
    4. Traffic cost calculation method;
    5. Statistical basis for markers submitted and CC transfers with coupons;
    6. Explanation for abnormal coverage ratio;
    7. Whether there was a system error or configuration error;
    8. Remediation measures;
    9. Measures to prevent recurrence.

    9.2 Review Outcomes

    After review, the mechanism should keep four possible outcomes:

    Outcome
    Status Change
    Description
    Full release
    UnderReview → Released
    Data is reasonable and the reward is released
    Partial release
    UnderReview → PartiallyReleased
    Part of the reward is valid and part is cancelled
    Extended lock
    UnderReview → Locked
    Information is insufficient and further observation is needed
    Cancel release
    UnderReview → Cancelled
    The reward is confirmed not to be releasable

    Cancelled rewards do not enter the application address. They are moved to a Foundation-designated treasury, ecosystem fund, or other governance-approved address.

    10. Example

    Assume a Featured App generates 100 CC in Featured App rewards at reward round 10,000.

    The Foundation has set the following parameters:

    Parameter
    Value
    lockRounds
    672
    maxCoverageRatio
    1.15
    Reward generation round
    10,000
    Earliest unlock round
    10,672
    Observation window
    10,000 to 10,671

    At reward round 10,000, the system creates a FeaturedAppRewardLock record:

    Field
    Value
    appProviderPartyId
    App A PartyId
    rewardRound
    10,000
    amount
    100 CC
    unlockRound
    10,672
    status
    Locked

    When the network reaches reward round 10,672, the reward enters PendingRelease. The system or the Foundation calculates the coverage ratio for the observation window from reward round 10,000 to reward round 10,671.

    Case 1: Normal Release

    Assume the observation window data is:

    Indicator
    Value
    markers submitted
    900
    CC transfers with coupons
    50
    traffic cost (USD)
    1,000
    coverageRatio
    (900 + 50) / 1,000 = 0.95

    Because 0.95 <= 1.15, and there is no manual review flag, duplicate Marker record, or suspension status, the reward can be released.

    Status change:

    Locked → PendingRelease → Released

    The 100 CC is released to App A’s App Provider PartyId.

    Case 2: Review Triggered

    Assume the observation window data is:

    Indicator
    Value
    markers submitted
    1,300
    CC transfers with coupons
    100
    traffic cost (USD)
    1,000
    coverageRatio
    (1,300 + 100) / 1,000 = 1.40

    Because 1.40 > 1.15, the reward is not released immediately and enters UnderReview.

    Status change:

    Locked → PendingRelease → UnderReview

    The Foundation or the Tokenomics Committee may require App A to provide its Marker submission logic, corresponding on-chain activity, traffic cost calculation method, and explanation for the abnormal ratio.

    If the review confirms that the data is reasonable, the reward can be released.

    If the review confirms that only part of the Marker activity is valid, the valid part can be released and the invalid part can be cancelled.

    For example:

    Result
    Amount
    Released
    60 CC
    Cancelled
    40 CC

    Status change:

    UnderReview → PartiallyReleased

    The cancelled 40 CC does not enter App A’s PartyId. It is moved to a Foundation-designated treasury or ecosystem fund.

    If the review confirms that the reward was entirely generated from non-compliant activity, the status changes to:

    UnderReview → Cancelled

    The full 100 CC is not released to App A and is handled according to Foundation governance rules.

    11. Technical Implementation

    This mechanism can be implemented as an independent reward release state machine. It does not require changes to application business contracts.

    11.1 Roles

    Role
    Description
    RewardAllocator
    Existing reward calculation or allocation module
    RewardLockController
    New reward locking and release-control module
    FoundationAdminParty
    Foundation administrative Party
    TokenomicsCommitteeParty
    Tokenomics Committee or authorized review Party
    AppProviderParty
    Featured App Party
    FoundationTreasuryParty
    Receiver Party for cancelled rewards

    11.2 Core State Object

    A simple Daml contract or equivalent state object may be introduced:

    FeaturedAppRewardLock

    This object only records reward status and does not participate in application business logic.

    It may support the following operations:

    Operation
    Executor
    Purpose
    CreateLock
    RewardAllocator / FoundationAdminParty
    Create a reward lock record
    MarkPendingRelease
    RewardLockController
    Mark reward as pending release after unlock round
    Release
    RewardLockController / FoundationAdminParty
    Release reward to AppProviderParty
    FlagReview
    FoundationAdminParty / TokenomicsCommitteeParty
    Move reward into review
    ResolveReviewRelease
    TokenomicsCommitteeParty
    Release after review
    ResolveReviewPartialRelease
    TokenomicsCommitteeParty
    Partially release after review
    ExtendLock
    TokenomicsCommitteeParty
    Extend the lock
    CancelRelease
    TokenomicsCommitteeParty
    Cancel release and move reward to a designated Party

    11.3 Reward Fund Flow

    The recommended reward fund flow is:

    1. Featured App reward calculation is completed;
    2. Reward enters a locked state or locked address controlled by RewardLockController;
    3. The system creates a FeaturedAppRewardLock;
    4. When unlockRound is reached, the unlock check is executed;
    5. If the reward passes the check, it is released to AppProviderParty;
    6. If it fails the check, it enters UnderReview;
    7. Cancelled rewards are moved to FoundationTreasuryParty or another governance-designated address.

    This path avoids the need to recover funds from application addresses after release. It is simpler to implement and has a clearer enforcement boundary.

    12. Minimum Viable Version

    The first version only needs to implement:

    1. Create reward lock records by reward round;
    2. Set a unified lockRounds parameter;
    3. Calculate observation-window metrics using the coverage ratio standard in the official Featured App Marker Guidance;
    4. Determine release based on maxCoverageRatio after the lock period ends;
    5. Allow the Foundation to manually set UnderReview;
    6. Support four review outcomes: release, partial release, extended lock, and cancelled release;
    7. Move cancelled rewards to a Foundation-designated address;
    8. Produce complete status-change records for audit.

    The first version does not need to implement:

    1. Complex risk scoring;
    2. Application-specific lock periods;
    3. Fully automated penalties;
    4. On-chain recovery of already released rewards;
    5. Complex activity-quality scoring;
    6. A complex appeal system.

    These can be added in later versions.

    13. Parameters

    The first version only needs a small number of configurable parameters:

    Parameter
    Description
    lockRounds
    Reward lock period
    maxCoverageRatio
    Coverage ratio threshold
    reviewTimeoutRounds
    Maximum review duration
    partialReleaseAllowed
    Whether partial release is allowed
    manualReviewEnabled
    Whether manual review flags are allowed
    treasuryPartyId
    Receiver Party for cancelled rewards

    These parameters should be managed by the Foundation or the Tokenomics Committee and communicated to the community in advance.

    14. Relationship With CIP-0116

    CIP-0116 proposes Featured App Staking as a way to improve Featured App quality, create stronger economic alignment, and increase the cost of misconduct. This proposal agrees with those objectives.

    The difference is the enforcement point.

    Featured App Staking places the control point before application participation by requiring an upfront stake. This proposal places the control point before reward release by locking newly generated rewards and reviewing them before they become spendable.

    Item
    Featured App Staking
    Reward Locking and Review
    Control point
    Before application participation
    Before reward release
    Capital requirement
    Requires upfront stake
    Does not require large upfront stake
    Risk-control method
    Stake constraint
    Locked unreleased rewards
    Impact on early-stage teams
    Higher
    Lower
    Technical focus
    Stake lock / unlock
    Reward lock / release
    Impact on reward calculation
    Not necessarily
    None
    Can prevent abnormal rewards from flowing out quickly
    Yes
    Yes

    This proposal can be implemented independently or combined with Featured App Staking. For example, the Foundation may apply staking requirements to larger mature applications, reward locking to early-stage applications, or allow both mechanisms as alternative paths for satisfying Featured App risk-control requirements.

    15. Backward Compatibility

    This proposal does not change the Featured App application process, the use of App Provider PartyId, or the Marker submission path.

    For existing Featured Apps:

    1. Already released rewards are not affected;
    2. Newly generated rewards may enter the locking and review process;
    3. Normal applications are only affected by the release timing;
    4. Unreleased rewards of abnormal applications may be paused;
    5. The Foundation may define a transition period based on actual conditions.

    For new Featured Apps:

    1. A unified lock period applies by default;
    2. Rewards are released normally after the observation window if compliant;
    3. Long-term compliant applications may later be eligible for a shorter lock period.

    16. Security and Governance Considerations

    The security boundary of this mechanism should remain clear:

    1. The system only controls unreleased rewards;
    2. Automatic rules only trigger review and do not automatically determine misconduct;
    3. Final handling is executed by the Foundation or the Tokenomics Committee;
    4. All status changes should leave on-ledger or auditable records;
    5. Parameter changes should be communicated in advance;
    6. Cancelled rewards must move to a publicly designated address;
    7. Applications should have the opportunity to submit structured explanatory materials;
    8. Administrative authority should be limited to Parties authorized by the Foundation or the Tokenomics Committee;
    9. Any manual status change should record the executing Party, execution time, reason code, and final outcome.

    This design avoids excessive automated punishment while ensuring abnormal rewards do not flow out before review.

    17. Expected Effects

    This proposal is expected to:

    1. Improve control over Featured App reward release;
    2. Reduce the risk of reward outflows caused by abnormal Marker behavior;
    3. Preserve a more developer-friendly entry path for genuine applications;
    4. Provide the Foundation with a clear reward review window;
    5. Create a natural short-term lock for unreleased rewards;
    6. Reduce immediate circulating supply impact from newly generated rewards;
    7. Improve auditability of the Featured App reward system;
    8. Remain compatible with Canton’s existing reward round, PartyId, and Marker mechanisms.

    18. Alternatives Considered

    Approach
    Advantages
    Disadvantages
    Decision
    Immediate reward release
    Simplest implementation
    Abnormal rewards may flow out quickly
    Not suitable as the only long-term approach
    Large upfront stake
    Increases misconduct cost
    High barrier for early-stage genuine developers
    Can be one path, but may not be the only path
    Reward locking and review
    Simple implementation, lower entry barrier, controls abnormal reward outflow
    Requires a new reward state machine
    Recommended as a base governance mechanism
    Fully automated penalties
    Fast response
    May incorrectly penalize normal applications
    Not recommended for the first version
    Manual review of all rewards
    Flexible
    Costly and difficult to scale
    Suitable only for abnormal cases

    Copyright

    This CIP is licensed under CC0-1.0: Creative Commons CC0 1.0 Universal.


    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.
  4. #4reborntaichi@gmail.com18-05-2026source ↗

    Thanks Eric, this makes sense. I understand the concerns around deferred reward release, especially revenue and tax accounting, Foundation liability, and added complexity.

    Based on your feedback, I have been thinking about a different approach that does not touch reward release at all.

    One possible alternative could be a Bonded Marker Allowance model. Instead of delaying rewards or requiring every Featured App to meet one fixed large staking threshold upfront, an app could post a CC bond that determines how much Marker value it can submit within a defined period.

    For example:

    Marker Allowance = Bond Amount × Risk Multiplier

    Markers within the allowance can be counted normally under the existing Featured App Marker Guidance. Markers above the allowance would not count unless the app increases its bond or receives approval.

    This would keep reward release simple and avoid making the Foundation a central party in releasing funds. At the same time, it would still increase the cost of misconduct, because abnormal Marker behavior could lead to allowance reduction, temporary marker pause, manual review, or bond slashing in severe cases.

    The main difference from a fixed Featured App staking requirement is that the required bond scales with Marker activity. Smaller apps could start with a smaller allowance, while larger apps submitting more Markers would need stronger economic backing.

    This may preserve the simplicity of staking-style accountability while making the mechanism more proportional and accessible for early-stage builders. Would be interested to hear whether this direction avoids some of the concerns with deferred reward release.

  5. #5Eric Saraniecki18-05-2026source ↗
    Yes, explored bonding at length as well

    Again, the cheap and abundant loans of CC combined with its simplicity seems to be the preferred approach at this time 



    toggle quoted message Show quoted text

    On May 18, 2026, at 8:36 AM, reborntaichi via lists.sync.global <reborntaichi=gmail.com@...> wrote:

    

    Thanks Eric, this makes sense. I understand the concerns around deferred reward release, especially revenue and tax accounting, Foundation liability, and added complexity.

    Based on your feedback, I have been thinking about a different approach that does not touch reward release at all.

    One possible alternative could be a Bonded Marker Allowance model. Instead of delaying rewards or requiring every Featured App to meet one fixed large staking threshold upfront, an app could post a CC bond that determines how much Marker value it can submit within a defined period.

    For example:

    Marker Allowance = Bond Amount × Risk Multiplier

    Markers within the allowance can be counted normally under the existing Featured App Marker Guidance. Markers above the allowance would not count unless the app increases its bond or receives approval.

    This would keep reward release simple and avoid making the Foundation a central party in releasing funds. At the same time, it would still increase the cost of misconduct, because abnormal Marker behavior could lead to allowance reduction, temporary marker pause, manual review, or bond slashing in severe cases.

    The main difference from a fixed Featured App staking requirement is that the required bond scales with Marker activity. Smaller apps could start with a smaller allowance, while larger apps submitting more Markers would need stronger economic backing.

    This may preserve the simplicity of staking-style accountability while making the mechanism more proportional and accessible for early-stage builders. Would be interested to hear whether this direction avoids some of the concerns with deferred reward release.


    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.