Mailing Lists/CIP - 0066 - Mint Canton Coin from Unminted/Unclaimed PoolSource on lists.sync.global ↗

CIP - 0066 - Mint Canton Coin from Unminted/Unclaimed Pool

cip-discuss9 messagesstarted 19-06-2025
Also mentions:CIP-0058CIP-0066
  1. #1Jose Velasco19-06-2025source ↗

    Dear CIP community,

    I would like to propose a new Canton Improvement Proposal titled “Enable governance vote to mint Canton Coin from the unminted reward pool”, which aims to operationalize milestone-based rewards and support the delivery assurance mechanism defined in CIP-0058.

    The proposal introduces a new governance-controlled process allowing Super Validators to vote on minting escrowed Canton Coin from a shared unminted reward pool. This enables transparent, auditable reward issuance based on milestone completion and network approval.

    I welcome feedback, questions, and discussion from the community.

     

     

    CIP-00XX Mint Canton Coin from Unminted/Unclaimed Pool

      Title: Enable escrow mechanisms and governance votes to allow Canton Coin minting from the unminted pool
  Author:
    Jose Velasco
  Status: Draft
  Type: Tokenomics
  Created: 2025-06-18
  Approved: 
  License: CC-1.0

    Abstract

    This proposal introduces a new governance mechanism allowing Super Validators (SVs) to initiate a vote to authorize the minting of Canton Coin from an unclaimed (unminted) reward pool, helping to operationalize the milestone-based CIP rewards structure and aligning with the first deliverable of CIP-0058: Enable escrow mechanisms to ensure Super Validators deliver value in return for rewards.

    Copyright

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

    Specification

    This CIP introduces a new on-ledger voting-based governance flow that enables Super Validators (SVs) to propose the creation of UnallocatedUnclaimedActivityRecord contracts, representing authorized but not yet allocated Amulet rewards.

    Governance Specification

    • A new action requiring confirmation (SRARC_CreateUnallocatedUnclaimedActivityRecord) is added to DsoRules_ActionRequiringConfirmation.
    • A new choice DsoRules_CreateUnallocatedUnclaimedActivityRecord allows the DSO to propose a beneficiary, reward amount, and reason for the reward.
    • Upon successful vote confirmation, an UnallocatedUnclaimedActivityRecord contract is created. This contract has two expiry parameters:
      • expiresAt: Duration from creation, derived from the configurable DSO field unallocatedUnclaimedActivityRecordTimeout (defaulting to 24 hours).
      • unclaimedActivityRecordExpiresAt: Passed to the resulting activity record once allocation occurs.

    Allocation and Expiration

    • A new SV-App trigger, UnallocatedUnclaimedActivityRecordAllocatorTrigger, locates eligible UnclaimedReward contracts, archives them up to the specified amount, and creates an UnclaimedActivityRecord.
    • A second trigger, UnallocatedUnclaimedActivityRecordExpiryTrigger, expires unallocated records after their TTL.
    • A third trigger, UnclaimedActivityRecordExpiryTrigger, expires unused UnclaimedActivityRecord contracts.

    Minting Mechanism

    • UnclaimedActivityRecord is introduced as a new transferable on-ledger asset.
    • It is added as a new variant (InputUnclaimedActivityRecord) within the existing TransferInput type.
    • This input is consumed by AmuletRules_Transfer, which mints the corresponding Amulet during a self-transfer executed by automation in the Wallet App (CollectRewardsAndMergeAmuletsTrigger).

    Off-ledger Implementation Requirements

    • SV App

      • Implement and deploy the three new triggers listed above.
      • Extend the Treasury Service to support the new activity record lifecycle.

    • Wallet App

      • Extend the CollectRewardsAndMergeAmuletsTrigger to auto-collect UnclaimedActivityRecord using the new transfer input.

    • CLI App

      • Introduce a Python CLI utility to calculate minted and unclaimed rewards by party ID and time range, reusing logic from scan_txlog.py.

    • SV App Voting UI

      • Update the SV App voting UI to support proposals using DsoRules_CreateUnallocatedUnclaimedActivityRecord.

    • SV App Governance UI

      • Add support in the SV App for configuring unallocatedUnclaimedActivityRecordTimeout.

    Motivation

    This change is required to implement the reward distribution mechanism described in CIP-0058. The CIP defines a process whereby, upon successful milestone verification, the Tokenomics Working Group approves a reward amount and the Super Validators assign a portion of unclaimed rewards to be minted. This functionality leverages the standard voting process and introduces new ledger, off-ledger, and UI components to support reward calculation, archival of unclaimed rewards, and minting of the corresponding Amulet.

    This aligns with the first deliverable of CIP-0058: Enable escrow mechanisms to ensure Super Validators deliver value in return for rewards.

    Rationale

    This proposal introduces a governance-backed, automated reward allocation mechanism that ensures Super Validators (SVs) never act as direct issuers of Amulets. Instead, it relies on existing voting infrastructure, explicit reward tracking, and on-ledger automation. The design satisfies the CIP-0058 objective of enabling escrowed value transfer with network approval, while preserving clear separation of duties between reward authorization and execution.

    Super Validators need a way to reward parties for milestone-based work without directly issuing Amulets. To meet this goal, the system must:

    • Let SVs propose reward allocations through a formal vote.
    • Track and escrow those rewards in a verifiable, on-ledger structure.
    • Allow beneficiaries to receive their rewards without needing manual approval or signature from SVs.
    • Ensure archival of previous reward entitlements (UnclaimedReward contracts) during the minting process.

    The final design introduces UnallocatedUnclaimedActivityRecord as a bridge between governance and execution. It supports clear auditability by representing approved but not yet funded reward intents. Once funded, these result in the creation of an UnclaimedActivityRecord, which serves as a transferable representation of reward entitlement. The UnclaimedActivityRecord is then consumed during a self-transfer initiated by automation in the Wallet App, resulting in the minting of the corresponding Amulet.

    Alternatives Considered

    Approach 1 – Mint in One Step

    This approach involved exercising a single voting choice (AmuletRules_MintFromUnmintedPool) that would simultaneously archive UnclaimedReward contracts and mint the Amulet.

    Rejected due to:

    • Risk of stale contract references caused by background reward merging.
    • Inability to collect beneficiary signatures, which are required for minting.

    Approach 2 – Post-Vote Execution with Extra Consequences

    This design embedded additional side effects in the vote’s success path: archiving UnclaimedRewards and creating an AmuletMintOffer as part of the vote confirmation.

    Rejected due to:

    • Inflexibility in the current voting infrastructure, which expects one-to-one mapping between action and execution.
    • Implementation would be non-trivial and hard to maintain.

    Approach 3 – Parallel Offer and Burn Request Flow

    Upon a successful vote, two contracts would be created:

    1. An AmuletMintOffer for the beneficiary to accept.
    2. A BurnUnclaimedRewardsRequest for the DSO to handle archival.

    Rejected due to:

    • Lack of atomicity, leading to potential inconsistencies.

    Approach 4 – AmuletMintOffer Claimed Manually by Beneficiary

    This design introduced UnallocatedAmuletMintOffer, accepted by an SV trigger that creates an AmuletMintOffer. The beneficiary would manually accept the final offer.

    Rejected due to:

    • The design would violate a core requirement of CIP-0058: SVs must not act as issuers.

    Justification for the Final Design

    The chosen approach introduces a clean separation of concerns:

    • Voting captures intent and approval.
    • SVs allocate funding (UnclaimedRewards) without minting.
    • The UnclaimedActivityRecord encapsulates minting rights in a transferable, on-ledger structure.
    • Beneficiaries receive Amulets through a self-transfer initiated by automation in the Wallet App, maintaining signature and stakeholder integrity.
    • The model avoids redundant templates or triggers and fits well into Splice’s composable architecture.

    This design was refined through multiple iterations, peer reviews, and discussions across the engineering and product teams, converging on a solution that meets both technical constraints and governance objectives.

    Backwards compatibility

    All choices and backend code involved are backward compatible.

    Reference implementation

    The new implementation includes backend and Daml changes. An early version of the Daml code is available in the following forked Splice branch: https://github.com/jose-velasco-ieu/splice/tree/josevelasco/daml-minting-escrowed-canton-coin-2/cip-0058

     

     

    Best regards,

    Jose Velasco

    @jose.velasco@...

  2. #2Chris Matturri20-06-2025source ↗
    Thank you for sharing this- Proof Group happy to motion this to a vote 

    toggle quoted message Show quoted text

    On Thu, Jun 19, 2025 at 5:13 AM jose.velasco via lists.sync.global <jose.velasco=intellecteu.com@...> wrote:

    Dear CIP community,

    I would like to propose a new Canton Improvement Proposal titled “Enable governance vote to mint Canton Coin from the unminted reward pool”, which aims to operationalize milestone-based rewards and support the delivery assurance mechanism defined in CIP-0058.

    The proposal introduces a new governance-controlled process allowing Super Validators to vote on minting escrowed Canton Coin from a shared unminted reward pool. This enables transparent, auditable reward issuance based on milestone completion and network approval.

    I welcome feedback, questions, and discussion from the community.

     

     

    CIP-00XX Mint Canton Coin from Unminted/Unclaimed Pool

      Title: Enable escrow mechanisms and governance votes to allow Canton Coin minting from the unminted pool
  Author:
    Jose Velasco
  Status: Draft
  Type: Tokenomics
  Created: 2025-06-18
  Approved: 
  License: CC-1.0

    Abstract

    This proposal introduces a new governance mechanism allowing Super Validators (SVs) to initiate a vote to authorize the minting of Canton Coin from an unclaimed (unminted) reward pool, helping to operationalize the milestone-based CIP rewards structure and aligning with the first deliverable of CIP-0058: Enable escrow mechanisms to ensure Super Validators deliver value in return for rewards.

    Copyright

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

    Specification

    This CIP introduces a new on-ledger voting-based governance flow that enables Super Validators (SVs) to propose the creation of UnallocatedUnclaimedActivityRecord contracts, representing authorized but not yet allocated Amulet rewards.

    Governance Specification

    • A new action requiring confirmation (SRARC_CreateUnallocatedUnclaimedActivityRecord) is added to DsoRules_ActionRequiringConfirmation.
    • A new choice DsoRules_CreateUnallocatedUnclaimedActivityRecord allows the DSO to propose a beneficiary, reward amount, and reason for the reward.
    • Upon successful vote confirmation, an UnallocatedUnclaimedActivityRecord contract is created. This contract has two expiry parameters:
      • expiresAt: Duration from creation, derived from the configurable DSO field unallocatedUnclaimedActivityRecordTimeout (defaulting to 24 hours).
      • unclaimedActivityRecordExpiresAt: Passed to the resulting activity record once allocation occurs.

    Allocation and Expiration

    • A new SV-App trigger, UnallocatedUnclaimedActivityRecordAllocatorTrigger, locates eligible UnclaimedReward contracts, archives them up to the specified amount, and creates an UnclaimedActivityRecord.
    • A second trigger, UnallocatedUnclaimedActivityRecordExpiryTrigger, expires unallocated records after their TTL.
    • A third trigger, UnclaimedActivityRecordExpiryTrigger, expires unused UnclaimedActivityRecord contracts.

    Minting Mechanism

    • UnclaimedActivityRecord is introduced as a new transferable on-ledger asset.
    • It is added as a new variant (InputUnclaimedActivityRecord) within the existing TransferInput type.
    • This input is consumed by AmuletRules_Transfer, which mints the corresponding Amulet during a self-transfer executed by automation in the Wallet App (CollectRewardsAndMergeAmuletsTrigger).

    Off-ledger Implementation Requirements

    • SV App

      • Implement and deploy the three new triggers listed above.
      • Extend the Treasury Service to support the new activity record lifecycle.

    • Wallet App

      • Extend the CollectRewardsAndMergeAmuletsTrigger to auto-collect UnclaimedActivityRecord using the new transfer input.

    • CLI App

      • Introduce a Python CLI utility to calculate minted and unclaimed rewards by party ID and time range, reusing logic from scan_txlog.py.

    • SV App Voting UI

      • Update the SV App voting UI to support proposals using DsoRules_CreateUnallocatedUnclaimedActivityRecord.

    • SV App Governance UI

      • Add support in the SV App for configuring unallocatedUnclaimedActivityRecordTimeout.

    Motivation

    This change is required to implement the reward distribution mechanism described in CIP-0058. The CIP defines a process whereby, upon successful milestone verification, the Tokenomics Working Group approves a reward amount and the Super Validators assign a portion of unclaimed rewards to be minted. This functionality leverages the standard voting process and introduces new ledger, off-ledger, and UI components to support reward calculation, archival of unclaimed rewards, and minting of the corresponding Amulet.

    This aligns with the first deliverable of CIP-0058: Enable escrow mechanisms to ensure Super Validators deliver value in return for rewards.

    Rationale

    This proposal introduces a governance-backed, automated reward allocation mechanism that ensures Super Validators (SVs) never act as direct issuers of Amulets. Instead, it relies on existing voting infrastructure, explicit reward tracking, and on-ledger automation. The design satisfies the CIP-0058 objective of enabling escrowed value transfer with network approval, while preserving clear separation of duties between reward authorization and execution.

    Super Validators need a way to reward parties for milestone-based work without directly issuing Amulets. To meet this goal, the system must:

    • Let SVs propose reward allocations through a formal vote.
    • Track and escrow those rewards in a verifiable, on-ledger structure.
    • Allow beneficiaries to receive their rewards without needing manual approval or signature from SVs.
    • Ensure archival of previous reward entitlements (UnclaimedReward contracts) during the minting process.

    The final design introduces UnallocatedUnclaimedActivityRecord as a bridge between governance and execution. It supports clear auditability by representing approved but not yet funded reward intents. Once funded, these result in the creation of an UnclaimedActivityRecord, which serves as a transferable representation of reward entitlement. The UnclaimedActivityRecord is then consumed during a self-transfer initiated by automation in the Wallet App, resulting in the minting of the corresponding Amulet.

    Alternatives Considered

    Approach 1 – Mint in One Step

    This approach involved exercising a single voting choice (AmuletRules_MintFromUnmintedPool) that would simultaneously archive UnclaimedReward contracts and mint the Amulet.

    Rejected due to:

    • Risk of stale contract references caused by background reward merging.
    • Inability to collect beneficiary signatures, which are required for minting.

    Approach 2 – Post-Vote Execution with Extra Consequences

    This design embedded additional side effects in the vote’s success path: archiving UnclaimedRewards and creating an AmuletMintOffer as part of the vote confirmation.

    Rejected due to:

    • Inflexibility in the current voting infrastructure, which expects one-to-one mapping between action and execution.
    • Implementation would be non-trivial and hard to maintain.

    Approach 3 – Parallel Offer and Burn Request Flow

    Upon a successful vote, two contracts would be created:

    1. An AmuletMintOffer for the beneficiary to accept.
    2. A BurnUnclaimedRewardsRequest for the DSO to handle archival.

    Rejected due to:

    • Lack of atomicity, leading to potential inconsistencies.

    Approach 4 – AmuletMintOffer Claimed Manually by Beneficiary

    This design introduced UnallocatedAmuletMintOffer, accepted by an SV trigger that creates an AmuletMintOffer. The beneficiary would manually accept the final offer.

    Rejected due to:

    • The design would violate a core requirement of CIP-0058: SVs must not act as issuers.

    Justification for the Final Design

    The chosen approach introduces a clean separation of concerns:

    • Voting captures intent and approval.
    • SVs allocate funding (UnclaimedRewards) without minting.
    • The UnclaimedActivityRecord encapsulates minting rights in a transferable, on-ledger structure.
    • Beneficiaries receive Amulets through a self-transfer initiated by automation in the Wallet App, maintaining signature and stakeholder integrity.
    • The model avoids redundant templates or triggers and fits well into Splice’s composable architecture.

    This design was refined through multiple iterations, peer reviews, and discussions across the engineering and product teams, converging on a solution that meets both technical constraints and governance objectives.

    Backwards compatibility

    All choices and backend code involved are backward compatible.

    Reference implementation

    The new implementation includes backend and Daml changes. An early version of the Daml code is available in the following forked Splice branch: https://github.com/jose-velasco-ieu/splice/tree/josevelasco/daml-minting-escrowed-canton-coin-2/cip-0058

     

     

    Best regards,

    Jose Velasco

    @jose.velasco@...

  3. #3Yiannis Varelas20-06-2025source ↗
    Same for Five North. Let’s move it to vote. 

    toggle quoted message Show quoted text

    On Fri, Jun 20, 2025 at 16:14 Chris Matturri <chris@...> wrote:
    Thank you for sharing this- Proof Group happy to motion this to a vote 

    On Thu, Jun 19, 2025 at 5:13 AM jose.velasco via lists.sync.global <jose.velasco=intellecteu.com@...> wrote:

    Dear CIP community,

    I would like to propose a new Canton Improvement Proposal titled “Enable governance vote to mint Canton Coin from the unminted reward pool”, which aims to operationalize milestone-based rewards and support the delivery assurance mechanism defined in CIP-0058.

    The proposal introduces a new governance-controlled process allowing Super Validators to vote on minting escrowed Canton Coin from a shared unminted reward pool. This enables transparent, auditable reward issuance based on milestone completion and network approval.

    I welcome feedback, questions, and discussion from the community.

     

     

    CIP-00XX Mint Canton Coin from Unminted/Unclaimed Pool

      Title: Enable escrow mechanisms and governance votes to allow Canton Coin minting from the unminted pool
  Author:
    Jose Velasco
  Status: Draft
  Type: Tokenomics
  Created: 2025-06-18
  Approved: 
  License: CC-1.0

    Abstract

    This proposal introduces a new governance mechanism allowing Super Validators (SVs) to initiate a vote to authorize the minting of Canton Coin from an unclaimed (unminted) reward pool, helping to operationalize the milestone-based CIP rewards structure and aligning with the first deliverable of CIP-0058: Enable escrow mechanisms to ensure Super Validators deliver value in return for rewards.

    Copyright

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

    Specification

    This CIP introduces a new on-ledger voting-based governance flow that enables Super Validators (SVs) to propose the creation of UnallocatedUnclaimedActivityRecord contracts, representing authorized but not yet allocated Amulet rewards.

    Governance Specification

    • A new action requiring confirmation (SRARC_CreateUnallocatedUnclaimedActivityRecord) is added to DsoRules_ActionRequiringConfirmation.
    • A new choice DsoRules_CreateUnallocatedUnclaimedActivityRecord allows the DSO to propose a beneficiary, reward amount, and reason for the reward.
    • Upon successful vote confirmation, an UnallocatedUnclaimedActivityRecord contract is created. This contract has two expiry parameters:
      • expiresAt: Duration from creation, derived from the configurable DSO field unallocatedUnclaimedActivityRecordTimeout (defaulting to 24 hours).
      • unclaimedActivityRecordExpiresAt: Passed to the resulting activity record once allocation occurs.

    Allocation and Expiration

    • A new SV-App trigger, UnallocatedUnclaimedActivityRecordAllocatorTrigger, locates eligible UnclaimedReward contracts, archives them up to the specified amount, and creates an UnclaimedActivityRecord.
    • A second trigger, UnallocatedUnclaimedActivityRecordExpiryTrigger, expires unallocated records after their TTL.
    • A third trigger, UnclaimedActivityRecordExpiryTrigger, expires unused UnclaimedActivityRecord contracts.

    Minting Mechanism

    • UnclaimedActivityRecord is introduced as a new transferable on-ledger asset.
    • It is added as a new variant (InputUnclaimedActivityRecord) within the existing TransferInput type.
    • This input is consumed by AmuletRules_Transfer, which mints the corresponding Amulet during a self-transfer executed by automation in the Wallet App (CollectRewardsAndMergeAmuletsTrigger).

    Off-ledger Implementation Requirements

    • SV App

      • Implement and deploy the three new triggers listed above.
      • Extend the Treasury Service to support the new activity record lifecycle.

    • Wallet App

      • Extend the CollectRewardsAndMergeAmuletsTrigger to auto-collect UnclaimedActivityRecord using the new transfer input.

    • CLI App

      • Introduce a Python CLI utility to calculate minted and unclaimed rewards by party ID and time range, reusing logic from scan_txlog.py.

    • SV App Voting UI

      • Update the SV App voting UI to support proposals using DsoRules_CreateUnallocatedUnclaimedActivityRecord.

    • SV App Governance UI

      • Add support in the SV App for configuring unallocatedUnclaimedActivityRecordTimeout.

    Motivation

    This change is required to implement the reward distribution mechanism described in CIP-0058. The CIP defines a process whereby, upon successful milestone verification, the Tokenomics Working Group approves a reward amount and the Super Validators assign a portion of unclaimed rewards to be minted. This functionality leverages the standard voting process and introduces new ledger, off-ledger, and UI components to support reward calculation, archival of unclaimed rewards, and minting of the corresponding Amulet.

    This aligns with the first deliverable of CIP-0058: Enable escrow mechanisms to ensure Super Validators deliver value in return for rewards.

    Rationale

    This proposal introduces a governance-backed, automated reward allocation mechanism that ensures Super Validators (SVs) never act as direct issuers of Amulets. Instead, it relies on existing voting infrastructure, explicit reward tracking, and on-ledger automation. The design satisfies the CIP-0058 objective of enabling escrowed value transfer with network approval, while preserving clear separation of duties between reward authorization and execution.

    Super Validators need a way to reward parties for milestone-based work without directly issuing Amulets. To meet this goal, the system must:

    • Let SVs propose reward allocations through a formal vote.
    • Track and escrow those rewards in a verifiable, on-ledger structure.
    • Allow beneficiaries to receive their rewards without needing manual approval or signature from SVs.
    • Ensure archival of previous reward entitlements (UnclaimedReward contracts) during the minting process.

    The final design introduces UnallocatedUnclaimedActivityRecord as a bridge between governance and execution. It supports clear auditability by representing approved but not yet funded reward intents. Once funded, these result in the creation of an UnclaimedActivityRecord, which serves as a transferable representation of reward entitlement. The UnclaimedActivityRecord is then consumed during a self-transfer initiated by automation in the Wallet App, resulting in the minting of the corresponding Amulet.

    Alternatives Considered

    Approach 1 – Mint in One Step

    This approach involved exercising a single voting choice (AmuletRules_MintFromUnmintedPool) that would simultaneously archive UnclaimedReward contracts and mint the Amulet.

    Rejected due to:

    • Risk of stale contract references caused by background reward merging.
    • Inability to collect beneficiary signatures, which are required for minting.

    Approach 2 – Post-Vote Execution with Extra Consequences

    This design embedded additional side effects in the vote’s success path: archiving UnclaimedRewards and creating an AmuletMintOffer as part of the vote confirmation.

    Rejected due to:

    • Inflexibility in the current voting infrastructure, which expects one-to-one mapping between action and execution.
    • Implementation would be non-trivial and hard to maintain.

    Approach 3 – Parallel Offer and Burn Request Flow

    Upon a successful vote, two contracts would be created:

    1. An AmuletMintOffer for the beneficiary to accept.
    2. A BurnUnclaimedRewardsRequest for the DSO to handle archival.

    Rejected due to:

    • Lack of atomicity, leading to potential inconsistencies.

    Approach 4 – AmuletMintOffer Claimed Manually by Beneficiary

    This design introduced UnallocatedAmuletMintOffer, accepted by an SV trigger that creates an AmuletMintOffer. The beneficiary would manually accept the final offer.

    Rejected due to:

    • The design would violate a core requirement of CIP-0058: SVs must not act as issuers.

    Justification for the Final Design

    The chosen approach introduces a clean separation of concerns:

    • Voting captures intent and approval.
    • SVs allocate funding (UnclaimedRewards) without minting.
    • The UnclaimedActivityRecord encapsulates minting rights in a transferable, on-ledger structure.
    • Beneficiaries receive Amulets through a self-transfer initiated by automation in the Wallet App, maintaining signature and stakeholder integrity.
    • The model avoids redundant templates or triggers and fits well into Splice’s composable architecture.

    This design was refined through multiple iterations, peer reviews, and discussions across the engineering and product teams, converging on a solution that meets both technical constraints and governance objectives.

    Backwards compatibility

    All choices and backend code involved are backward compatible.

    Reference implementation

    The new implementation includes backend and Daml changes. An early version of the Daml code is available in the following forked Splice branch: https://github.com/jose-velasco-ieu/splice/tree/josevelasco/daml-minting-escrowed-canton-coin-2/cip-0058

     

     

    Best regards,

    Jose Velasco

    @jose.velasco@...

  4. #4Chris Zuehlke22-06-2025source ↗

    Agreed, Cumberland DRW is also supportive of this and ready to move it to vote. 

     

    Our one request is supplement the CIP with a description of the “in practice” workflow.  This is a fairly technical CIP and I think a plain English workflow would be helpful for everyone to understand the technical/operational/governance steps that need to take place--including where things like Party IDs, etc. need to be determined.  We’d be happy to review it/provide feedback.

     

    Perhaps one general workflow, one specific to SV award escrow/unclaimed, one for Application awards that go unclaimed, and one for Validator awards that go unclaimed.

     

     

    toggle quoted message Show quoted text

    From: cip-discuss@... <cip-discuss@...> On Behalf Of Yiannis Varelas
    Sent: Friday, June 20, 2025 1:27 PM
    To: cip-discuss@...
    Subject: [ext] Re: [cip-discuss] CIP - 00XX - Mint Canton Coin from Unminted/Unclaimed Pool

     

    Same for Five North. Let’s move it to vote. On Fri, Jun 20, 2025 at 16: 14 Chris Matturri <chris@ proofgroup. xyz> wrote: Thank you for sharing this- Proof Group happy to motion this to a vote On Thu, Jun 19, 2025 at 5: 13 AM jose. velasco

    Same for Five North. Let’s move it to vote. 

     

    On Fri, Jun 20, 2025 at 16:14 Chris Matturri <chris@...> wrote:

    Thank you for sharing this- Proof Group happy to motion this to a vote 

     

    On Thu, Jun 19, 2025 at 5:13 AM jose.velasco via lists.sync.global <jose.velasco=intellecteu.com@...> wrote:

    Dear CIP community,

    I would like to propose a new Canton Improvement Proposal titled “Enable governance vote to mint Canton Coin from the unminted reward pool”, which aims to operationalize milestone-based rewards and support the delivery assurance mechanism defined in CIP-0058.

    The proposal introduces a new governance-controlled process allowing Super Validators to vote on minting escrowed Canton Coin from a shared unminted reward pool. This enables transparent, auditable reward issuance based on milestone completion and network approval.

    I welcome feedback, questions, and discussion from the community.

     

     

    CIP-00XX Mint Canton Coin from Unminted/Unclaimed Pool

      Title: Enable escrow mechanisms and governance votes to allow Canton Coin minting from the unminted pool
      Author:
        Jose Velasco
      Status: Draft
      Type: Tokenomics
      Created: 2025-06-18
      Approved: 
      License: CC-1.0

    Abstract

    This proposal introduces a new governance mechanism allowing Super Validators (SVs) to initiate a vote to authorize the minting of Canton Coin from an unclaimed (unminted) reward pool, helping to operationalize the milestone-based CIP rewards structure and aligning with the first deliverable of CIP-0058: Enable escrow mechanisms to ensure Super Validators deliver value in return for rewards.

    Copyright

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

    Specification

    This CIP introduces a new on-ledger voting-based governance flow that enables Super Validators (SVs) to propose the creation of UnallocatedUnclaimedActivityRecord contracts, representing authorized but not yet allocated Amulet rewards.

    Governance Specification

    • A new action requiring confirmation (SRARC_CreateUnallocatedUnclaimedActivityRecord) is added to DsoRules_ActionRequiringConfirmation.
    • A new choice DsoRules_CreateUnallocatedUnclaimedActivityRecord allows the DSO to propose a beneficiary, reward amount, and reason for the reward.
    • Upon successful vote confirmation, an UnallocatedUnclaimedActivityRecord contract is created. This contract has two expiry parameters:
      • expiresAt: Duration from creation, derived from the configurable DSO field unallocatedUnclaimedActivityRecordTimeout (defaulting to 24 hours).
      • unclaimedActivityRecordExpiresAt: Passed to the resulting activity record once allocation occurs.

    Allocation and Expiration

    • A new SV-App trigger, UnallocatedUnclaimedActivityRecordAllocatorTrigger, locates eligible UnclaimedReward contracts, archives them up to the specified amount, and creates an UnclaimedActivityRecord.
    • A second trigger, UnallocatedUnclaimedActivityRecordExpiryTrigger, expires unallocated records after their TTL.
    • A third trigger, UnclaimedActivityRecordExpiryTrigger, expires unused UnclaimedActivityRecord contracts.

    Minting Mechanism

    • UnclaimedActivityRecord is introduced as a new transferable on-ledger asset.
    • It is added as a new variant (InputUnclaimedActivityRecord) within the existing TransferInput type.
    • This input is consumed by AmuletRules_Transfer, which mints the corresponding Amulet during a self-transfer executed by automation in the Wallet App (CollectRewardsAndMergeAmuletsTrigger).

    Off-ledger Implementation Requirements

    • SV App
      • Implement and deploy the three new triggers listed above.
      • Extend the Treasury Service to support the new activity record lifecycle.
    • Wallet App
      • Extend the CollectRewardsAndMergeAmuletsTrigger to auto-collect UnclaimedActivityRecord using the new transfer input.
    • CLI App
      • Introduce a Python CLI utility to calculate minted and unclaimed rewards by party ID and time range, reusing logic from scan_txlog.py.
    • SV App Voting UI
      • Update the SV App voting UI to support proposals using DsoRules_CreateUnallocatedUnclaimedActivityRecord.
    • SV App Governance UI
      • Add support in the SV App for configuring unallocatedUnclaimedActivityRecordTimeout.

    Motivation

    This change is required to implement the reward distribution mechanism described in CIP-0058. The CIP defines a process whereby, upon successful milestone verification, the Tokenomics Working Group approves a reward amount and the Super Validators assign a portion of unclaimed rewards to be minted. This functionality leverages the standard voting process and introduces new ledger, off-ledger, and UI components to support reward calculation, archival of unclaimed rewards, and minting of the corresponding Amulet.

    This aligns with the first deliverable of CIP-0058: Enable escrow mechanisms to ensure Super Validators deliver value in return for rewards.

    Rationale

    This proposal introduces a governance-backed, automated reward allocation mechanism that ensures Super Validators (SVs) never act as direct issuers of Amulets. Instead, it relies on existing voting infrastructure, explicit reward tracking, and on-ledger automation. The design satisfies the CIP-0058 objective of enabling escrowed value transfer with network approval, while preserving clear separation of duties between reward authorization and execution.

    Super Validators need a way to reward parties for milestone-based work without directly issuing Amulets. To meet this goal, the system must:

    • Let SVs propose reward allocations through a formal vote.
    • Track and escrow those rewards in a verifiable, on-ledger structure.
    • Allow beneficiaries to receive their rewards without needing manual approval or signature from SVs.
    • Ensure archival of previous reward entitlements (UnclaimedReward contracts) during the minting process.

    The final design introduces UnallocatedUnclaimedActivityRecord as a bridge between governance and execution. It supports clear auditability by representing approved but not yet funded reward intents. Once funded, these result in the creation of an UnclaimedActivityRecord, which serves as a transferable representation of reward entitlement. The UnclaimedActivityRecord is then consumed during a self-transfer initiated by automation in the Wallet App, resulting in the minting of the corresponding Amulet.

    Alternatives Considered

    Approach 1 – Mint in One Step

    This approach involved exercising a single voting choice (AmuletRules_MintFromUnmintedPool) that would simultaneously archive UnclaimedReward contracts and mint the Amulet.

    Rejected due to:

    • Risk of stale contract references caused by background reward merging.
    • Inability to collect beneficiary signatures, which are required for minting.

    Approach 2 – Post-Vote Execution with Extra Consequences

    This design embedded additional side effects in the vote’s success path: archiving UnclaimedRewards and creating an AmuletMintOffer as part of the vote confirmation.

    Rejected due to:

    • Inflexibility in the current voting infrastructure, which expects one-to-one mapping between action and execution.
    • Implementation would be non-trivial and hard to maintain.

    Approach 3 – Parallel Offer and Burn Request Flow

    Upon a successful vote, two contracts would be created:

    1. An AmuletMintOffer for the beneficiary to accept.
    2. A BurnUnclaimedRewardsRequest for the DSO to handle archival.

    Rejected due to:

    • Lack of atomicity, leading to potential inconsistencies.

    Approach 4 – AmuletMintOffer Claimed Manually by Beneficiary

    This design introduced UnallocatedAmuletMintOffer, accepted by an SV trigger that creates an AmuletMintOffer. The beneficiary would manually accept the final offer.

    Rejected due to:

    • The design would violate a core requirement of CIP-0058: SVs must not act as issuers.

    Justification for the Final Design

    The chosen approach introduces a clean separation of concerns:

    • Voting captures intent and approval.
    • SVs allocate funding (UnclaimedRewards) without minting.
    • The UnclaimedActivityRecord encapsulates minting rights in a transferable, on-ledger structure.
    • Beneficiaries receive Amulets through a self-transfer initiated by automation in the Wallet App, maintaining signature and stakeholder integrity.
    • The model avoids redundant templates or triggers and fits well into Splice’s composable architecture.

    This design was refined through multiple iterations, peer reviews, and discussions across the engineering and product teams, converging on a solution that meets both technical constraints and governance objectives.

    Backwards compatibility

    All choices and backend code involved are backward compatible.

    Reference implementation

    The new implementation includes backend and Daml changes. An early version of the Daml code is available in the following forked Splice branch: https://github.com/jose-velasco-ieu/splice/tree/josevelasco/daml-minting-escrowed-canton-coin-2/cip-0058

     

     

    Best regards,

    Jose Velasco

    @jose.velasco@...


    This e-mail and any attachments may contain information that is confidential and proprietary and otherwise protected from disclosure. If you are not the intended recipient of this e-mail, do not read, duplicate or redistribute it by any means. Please immediately delete it and any attachments and notify the sender that you have received it by mistake. Unintended recipients are prohibited from taking action on the basis of information in this e-mail or any attachments. The DRW Companies make no representations that this e-mail or any attachments are free of computer viruses or other defects.
  5. #5Jose Velasco23-06-2025source ↗
    Hello, 
     
    I've made some adjustments to the proposal for your review.
     
    - Fix UnclaimedActivityRecord description
    - Enhance Motivation: The proposed mechanism is more general and allows the SVs to mint any kind of unclaimed reward for any reason not just escrowed super validator rewards
    - Improve Rationale
    - Add general/specific flows
    - Typos 
     
     
     

    CIP-00XX Mint Canton Coin from Unminted/Unclaimed Pool

      Title: Enable escrow mechanisms and governance votes to allow Canton Coin minting from the unminted pool
  Author:
    Jose Velasco
  Status: Draft
  Type: Tokenomics
  Created: 2025-06-18
  Approved: 
  License: CC-1.0

    Abstract

    This proposal introduces a new governance mechanism allowing Super Validators (SVs) to initiate a vote to authorize the minting of Canton Coin from an unclaimed (unminted) reward pool, helping to operationalize the milestone-based CIP rewards structure and aligning with the first deliverable of CIP-0058: Enable escrow mechanisms to ensure Super Validators deliver value in return for rewards.

    Copyright

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

    Specification

    This CIP introduces a new on-ledger voting-based governance flow that enables Super Validators (SVs) to propose the creation of UnallocatedUnclaimedActivityRecord contracts, representing authorized but not yet allocated Amulet rewards.

    High-level overview

    To contextualize the protocol and governance changes introduced by this CIP, we outline both a generalized workflow and a specific escrow-based scenario. These flows illustrate how unminted rewards transition through governance-controlled minting, and how this mechanism enables milestone-based issuance of Canton Coin while preserving decentralization, auditability, and escrow guarantees.

    General Flow

    • Weighted activity records are assigned to a party based on their contributions within a round.

    • If the assigned party fails to mint their rewards before the round concludes, those rewards are moved into the unminted pool.

    • At a later stage—following an off-chain agreement—someone may propose that a specified party should receive a portion of the unminted pool.

    • An on-chain vote is initiated to authorize the minting. Super Validators review and either approve or reject the proposal.

    Specific Flow

    • The GSF node hosts an SV weight on behalf of an SV in an escrow agreement.
    • The GSF hosts a party for that SV on a separate GSF operated Validator, and names that party as the beneficiary of the SV weight.
    • The SVs, in each round, credit the GSF SV node for work/activity, and create a weighted activity records assigned coupon, which the GSF node splits among all the SV rights hosted on that node.
    • The GSF specifically disables the final minting action for all escrowed SV parties.
    • All the coin earned by escrowed parties goes into the unminted pool and loses all connection to any party.
    • When the SV passes a milestone, it then searches all the history to find weighted activity records assigned coupons that had been assigned to it, normalized / trimmed down to the weight it wants to claim.
    • The SV presents these records, and the resulting escrow claim, to the GSF.
    • GSF does its own calculation and makes a recommendation via an onchain vote.
    • SVs accept or reject the vote.

    Governance Specification

    • A new action requiring confirmation (SRARC_CreateUnallocatedUnclaimedActivityRecord) is added to DsoRules_ActionRequiringConfirmation.
    • A new choice DsoRules_CreateUnallocatedUnclaimedActivityRecord allows the DSO to propose a beneficiary, reward amount, and reason for the reward.
    • Upon successful vote confirmation, an UnallocatedUnclaimedActivityRecord contract is created. This contract has two expiry parameters:
      • expiresAt: Duration from creation, derived from the configurable DSO field unallocatedUnclaimedActivityRecordTimeout (defaulting to 24 hours).
      • unclaimedActivityRecordExpiresAt: Passed to the resulting activity record once allocation occurs.

    Allocation and Expiration

    • A new SV-App trigger, UnallocatedUnclaimedActivityRecordAllocatorTrigger, locates eligible UnclaimedReward contracts, archives them up to the specified amount, and creates an UnclaimedActivityRecord.
    • A second trigger, UnallocatedUnclaimedActivityRecordExpiryTrigger, expires unallocated records after their TTL.
    • A third trigger, UnclaimedActivityRecordExpiryTrigger, expires unused UnclaimedActivityRecord contracts.

    Minting Mechanism

    • UnclaimedActivityRecord is introduced as a new type of activity record that can be minted.
    • It is added as a new variant (InputUnclaimedActivityRecord) within the existing TransferInput type.
    • This input is consumed by AmuletRules_Transfer, which mints the corresponding Amulet during a self-transfer executed by automation in the Wallet App (CollectRewardsAndMergeAmuletsTrigger).

    Off-ledger Implementation Requirements

    • SV App

      • Implement and deploy the three new triggers listed above.
      • Extend the Treasury Service to support the new activity record lifecycle.

    • Wallet App

      • Extend the CollectRewardsAndMergeAmuletsTrigger to auto-collect UnclaimedActivityRecord using the new transfer input.

    • CLI App

      • Introduce a Python CLI utility to calculate minted and unclaimed rewards by party ID and time range, reusing logic from scan_txlog.py.

    • SV App Voting UI

      • Update the SV App voting UI to support proposals using DsoRules_CreateUnallocatedUnclaimedActivityRecord.

    • SV App Governance UI

      • Add support in the SV App for configuring unallocatedUnclaimedActivityRecordTimeout.

    Motivation

    This change is required to implement the reward distribution mechanism described in CIP-0058. The CIP defines a process whereby, upon successful milestone verification, the Tokenomics Working Group approves a reward amount and the Super Validators assign a portion of unclaimed rewards to be minted. This functionality leverages the standard voting process and introduces new ledger, off-ledger, and UI components to support reward calculation, archival of unclaimed rewards, and minting of the corresponding Amulet. While motivated by the need to support milestone-based escrowed rewards, the proposed mechanism is more general. It enables Super Validators to mint any type of unclaimed reward for any reason, not limited to escrowed incentives. This flexibility supports future governance decisions and additional reward use cases beyond the scope of CIP-0058.

    This aligns with the first deliverable of CIP-0058: Enable escrow mechanisms to ensure Super Validators deliver value in return for rewards.

    Rationale

    This proposal introduces a governance-backed, automated reward allocation mechanism that ensures Super Validators (SVs) never act as direct issuers of Amulets. Instead, it relies on existing voting infrastructure, explicit reward tracking, and on-ledger automation. The design satisfies the CIP-0058 objective of enabling escrowed value transfer with network approval, while preserving clear separation of duties between reward authorization and execution.

    Super Validators need a way to reward parties for milestone-based work without directly issuing Amulets. The proposed CIP process allows:

    • Proposing reward allocations through a formal vote explicitly approving the proposal.
    • Tracking and escrowing those rewards in a verifiable, on-ledger structure.
    • Allowing beneficiaries to receive their rewards without needing manual approval or signature from SVs.
    • Ensuring archival of previous reward entitlements (UnclaimedReward contracts) during the minting process.

    The final design introduces UnallocatedUnclaimedActivityRecord as a bridge between governance and execution. It supports clear auditability by representing approved but not yet funded reward intents. Once funded, these result in the creation of an UnclaimedActivityRecord, which serves as a transferable representation of reward entitlement. The UnclaimedActivityRecord is then consumed during a self-transfer initiated by automation in the Wallet App, resulting in the minting of the corresponding Amulet.

    Alternatives Considered

    Approach 1 – Mint in One Step

    This approach involved exercising a single voting choice (AmuletRules_MintFromUnmintedPool) that would simultaneously archive UnclaimedReward contracts and mint the Amulet.

    Rejected due to:

    • Risk of stale contract references caused by background reward merging.
    • Inability to collect beneficiary signatures, which are required for minting.

    Approach 2 – Post-Vote Execution with Extra Consequences

    This design embedded additional side effects in the vote’s success path: archiving UnclaimedRewards and creating an AmuletMintOffer as part of the vote confirmation.

    Rejected due to:

    • Inflexibility in the current voting infrastructure, which expects one-to-one mapping between action and execution.
    • Implementation would be non-trivial and hard to maintain.

    Approach 3 – Parallel Offer and Burn Request Flow

    Upon a successful vote, two contracts would be created:

    1. An AmuletMintOffer for the beneficiary to accept.
    2. A BurnUnclaimedRewardsRequest for the DSO to handle archival.

    Rejected due to:

    • Lack of atomicity, leading to potential inconsistencies.

    Approach 4 – AmuletMintOffer Claimed Manually by Beneficiary

    This design introduced UnallocatedAmuletMintOffer, accepted by an SV trigger that creates an AmuletMintOffer. The beneficiary would manually accept the final offer.

    Rejected due to:

    • The design would violate a core requirement of CIP-0058: SVs must not act as issuers.

    Justification for the Final Design

    The chosen approach introduces a clean separation of concerns:

    • Voting captures intent and approval.
    • SVs allocate funding (UnclaimedReward contracts) without minting.
    • The UnclaimedActivityRecord encapsulates minting rights in a transferable, on-ledger structure.
    • Beneficiaries receive Amulet through a self-transfer initiated by automation in the Wallet App, maintaining signature and stakeholder integrity.
    • The model avoids redundant templates or triggers and fits well into Splice’s composable architecture.

    This design was refined through multiple iterations, peer reviews, and discussions across the engineering and product teams, converging on a solution that meets both technical constraints and governance objectives.

    Backwards compatibility

    All choices and backend code involved are backward compatible.

    Reference implementation

    The new implementation includes backend and Daml changes. An early version of the Daml code is available in the following forked Splice branch: https://github.com/jose-velasco-ieu/splice/tree/josevelasco/daml-minting-escrowed-canton-coin-2/cip-0058

  6. #6Wayne Collier23-06-2025source ↗
    Hi, Jose
     
    Would it be feasible to add the general and specific flows into the CIP as diagrams? 
  7. #7Jose Velasco23-06-2025source ↗
    Hi Wayne,
    Sure, I'll add it. 


    José Velasco

    Software Engineer

    IntellectEU

    intellecteu.com

    Accelerating the Evolution of Global Markets

    jose.velasco@...

    IMPORTANT! This message (including any attachments) contains confidential information intended for a specific individual and purpose and is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited.




    toggle quoted message Show quoted text


    On Mon, Jun 23, 2025 at 4:26 PM Wayne Collier via lists.sync.global <wayne.collier=digitalasset.com@...> wrote:
    Hi, Jose
     
    Would it be feasible to add the general and specific flows into the CIP as diagrams? 

  8. #8Jose Velasco24-06-2025source ↗
    Hello, 
     
    Here’s the latest version of the CIP — sharing it for your review.
     
     

    CIP-0066 Mint Canton Coin from Unminted/Unclaimed Pool

      Title: Enable escrow mechanisms and governance votes to allow Canton Coin minting from the unminted pool
  Author:
    Jose Velasco
  Status: Proposed
  Type: Tokenomics
  Created: 2025-06-18
  Approved: 
  License: CC-1.0

    Abstract

    This proposal introduces a new governance mechanism allowing Super Validators (SVs) to initiate a vote to authorize the minting of Canton Coin from an unclaimed (unminted) reward pool, helping to operationalize the milestone-based CIP rewards structure and aligning with the first deliverable of CIP-0058: Enable escrow mechanisms to ensure Super Validators deliver value in return for rewards.

    Copyright

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

    Specification

    This CIP introduces a new on-ledger voting-based governance flow that enables Super Validators (SVs) to propose the creation of UnallocatedUnclaimedActivityRecord contracts, representing authorized but not yet allocated Amulet rewards.

    High-level overview

    To contextualize the protocol and governance changes introduced by this CIP, we outline both a generalized workflow and a specific escrow-based scenario. These flows illustrate how unminted rewards transition through governance-controlled minting, and how this mechanism enables milestone-based issuance of Canton Coin while preserving decentralization, auditability, and escrow guarantees.

    General Flow

    • Weighted activity records are assigned to a party based on their contributions within a round.

    • If the assigned party fails to mint their rewards before the round concludes, those rewards are moved into the unminted pool.

    • At a later stage—following an off-chain agreement—someone may propose that a specified party should receive a portion of the unminted pool.

    • An on-chain vote is initiated to authorize the minting. Super Validators review and either approve or reject the proposal.

    alt_text

    Escrow Flow

    • The GSF node hosts an SV weight on behalf of an SV in an escrow agreement.
    • The GSF hosts a party for that SV on a separate GSF operated Validator, and names that party as the beneficiary of the SV weight.
    • The SVs, in each round, credit the GSF SV node for work/activity, and create a weighted activity records assigned coupon, which the GSF node splits among all the SV rights hosted on that node.
    • The GSF specifically disables the final minting action for all escrowed SV parties.
    • All the coin earned by escrowed parties goes into the unminted pool and loses all connection to any party.
    • When the SV passes a milestone, it then searches all the history to find weighted activity records assigned coupons that had been assigned to it, normalized / trimmed down to the weight it wants to claim.
    • The SV presents these records, and the resulting escrow claim, to the GSF.
    • GSF does its own calculation and makes a recommendation via an onchain vote.
    • SVs accept or reject the vote.

    alt_text

    Governance Specification

    • A new action requiring confirmation (SRARC_CreateUnallocatedUnclaimedActivityRecord) is added to DsoRules_ActionRequiringConfirmation.
    • A new choice DsoRules_CreateUnallocatedUnclaimedActivityRecord allows the DSO to propose a beneficiary, reward amount, and reason for the reward.
    • Upon successful vote confirmation, an UnallocatedUnclaimedActivityRecord contract is created. This contract has two expiry parameters:
      • expiresAt: Duration from creation, derived from the configurable DSO field unallocatedUnclaimedActivityRecordTimeout (defaulting to 24 hours).
      • unclaimedActivityRecordExpiresAt: Passed to the resulting activity record once allocation occurs.

    Allocation and Expiration

    • A new SV-App trigger, UnallocatedUnclaimedActivityRecordAllocatorTrigger, locates eligible UnclaimedReward contracts, archives them up to the specified amount, and creates an UnclaimedActivityRecord.
    • A second trigger, UnallocatedUnclaimedActivityRecordExpiryTrigger, expires unallocated records after their TTL.
    • A third trigger, UnclaimedActivityRecordExpiryTrigger, expires unused UnclaimedActivityRecord contracts.

    Minting Mechanism

    • UnclaimedActivityRecord is introduced as a new type of activity record that can be minted.
    • It is added as a new variant (InputUnclaimedActivityRecord) within the existing TransferInput type.
    • This input is consumed by AmuletRules_Transfer, which mints the corresponding Amulet during a self-transfer executed by automation in the Wallet App (CollectRewardsAndMergeAmuletsTrigger).

    Off-ledger Implementation Requirements

    • SV App

      • Implement and deploy the three new triggers listed above.
      • Extend the Treasury Service to support the new activity record lifecycle.

    • Wallet App

      • Extend the CollectRewardsAndMergeAmuletsTrigger to auto-collect UnclaimedActivityRecord using the new transfer input.

    • CLI App

      • Introduce a Python CLI utility to calculate minted and unclaimed rewards by party ID and time range, reusing logic from scan_txlog.py.

    • SV App Voting UI

      • Update the SV App voting UI to support proposals using DsoRules_CreateUnallocatedUnclaimedActivityRecord.

    • SV App Governance UI

      • Add support in the SV App for configuring unallocatedUnclaimedActivityRecordTimeout.

    Motivation

    This change is required to implement the reward distribution mechanism described in CIP-0058. The CIP defines a process whereby, upon successful milestone verification, the Tokenomics Working Group approves a reward amount and the Super Validators assign a portion of unclaimed rewards to be minted. This functionality leverages the standard voting process and introduces new ledger, off-ledger, and UI components to support reward calculation, archival of unclaimed rewards, and minting of the corresponding Amulet. While motivated by the need to support milestone-based escrowed rewards, the proposed mechanism is more general. It enables Super Validators to mint any type of unclaimed reward for any reason, not limited to escrowed incentives. This flexibility supports future governance decisions and additional reward use cases beyond the scope of CIP-0058.

    This aligns with the first deliverable of CIP-0058: Enable escrow mechanisms to ensure Super Validators deliver value in return for rewards.

    Rationale

    This proposal introduces a governance-backed, automated reward allocation mechanism that ensures Super Validators (SVs) never act as direct issuers of Amulets. Instead, it relies on existing voting infrastructure, explicit reward tracking, and on-ledger automation. The design satisfies the CIP-0058 objective of enabling escrowed value transfer with network approval, while preserving clear separation of duties between reward authorization and execution.

    Super Validators need a way to reward parties for milestone-based work without directly issuing Amulets. The proposed CIP process allows:

    • Proposing reward allocations through a formal vote explicitly approving the proposal.
    • Tracking and escrowing those rewards in a verifiable, on-ledger structure.
    • Allowing beneficiaries to receive their rewards without needing manual approval or signature from SVs.
    • Ensuring archival of previous reward entitlements (UnclaimedReward contracts) during the minting process.

    The final design introduces UnallocatedUnclaimedActivityRecord as a bridge between governance and execution. It supports clear auditability by representing approved but not yet funded reward intents. Once funded, these result in the creation of an UnclaimedActivityRecord, which serves as a transferable representation of reward entitlement. The UnclaimedActivityRecord is then consumed during a self-transfer initiated by automation in the Wallet App, resulting in the minting of the corresponding Amulet.

    Alternatives Considered

    Approach 1 – Mint in One Step

    This approach involved exercising a single voting choice (AmuletRules_MintFromUnmintedPool) that would simultaneously archive UnclaimedReward contracts and mint the Amulet.

    Rejected due to:

    • Risk of stale contract references caused by background reward merging.
    • Inability to collect beneficiary signatures, which are required for minting.

    Approach 2 – Post-Vote Execution with Extra Consequences

    This design embedded additional side effects in the vote’s success path: archiving UnclaimedRewards and creating an AmuletMintOffer as part of the vote confirmation.

    Rejected due to:

    • Inflexibility in the current voting infrastructure, which expects one-to-one mapping between action and execution.
    • Implementation would be non-trivial and hard to maintain.

    Approach 3 – Parallel Offer and Burn Request Flow

    Upon a successful vote, two contracts would be created:

    1. An AmuletMintOffer for the beneficiary to accept.
    2. A BurnUnclaimedRewardsRequest for the DSO to handle archival.

    Rejected due to:

    • Lack of atomicity, leading to potential inconsistencies.

    Approach 4 – AmuletMintOffer Claimed Manually by Beneficiary

    This design introduced UnallocatedAmuletMintOffer, accepted by an SV trigger that creates an AmuletMintOffer. The beneficiary would manually accept the final offer.

    Rejected due to:

    • The design would violate a core requirement of CIP-0058: SVs must not act as issuers.

    Justification for the Final Design

    The chosen approach introduces a clean separation of concerns:

    • Voting captures intent and approval.
    • SVs allocate funding (UnclaimedReward contracts) without minting.
    • The UnclaimedActivityRecord encapsulates minting rights in a transferable, on-ledger structure.
    • Beneficiaries receive Amulet through a self-transfer initiated by automation in the Wallet App, maintaining signature and stakeholder integrity.
    • The model avoids redundant templates or triggers and fits well into Splice’s composable architecture.

    This design was refined through multiple iterations, peer reviews, and discussions across the engineering and product teams, converging on a solution that meets both technical constraints and governance objectives.

    Backwards compatibility

    All choices and backend code involved are backward compatible.

    Reference implementation

    The new implementation includes backend and Daml changes. An early version of the Daml code is available in the following forked Splice branch: https://github.com/jose-velasco-ieu/splice/tree/josevelasco/daml-minting-escrowed-canton-coin-2/cip-0058

  9. #9Jose Velasco24-06-2025source ↗
    Hello,
     
    Please ignore the previous email — there was an issue with one of the images.
     

    CIP-0066 Mint Canton Coin from Unminted/Unclaimed Pool

      Title: Enable escrow mechanisms and governance votes to allow Canton Coin minting from the unminted pool
  Author:
    Jose Velasco
  Status: Proposed
  Type: Tokenomics
  Created: 2025-06-18
  Approved: 
  License: CC-1.0

    Abstract

    This proposal introduces a new governance mechanism allowing Super Validators (SVs) to initiate a vote to authorize the minting of Canton Coin from an unclaimed (unminted) reward pool, helping to operationalize the milestone-based CIP rewards structure and aligning with the first deliverable of CIP-0058: Enable escrow mechanisms to ensure Super Validators deliver value in return for rewards.

    Copyright

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

    Specification

    This CIP introduces a new on-ledger voting-based governance flow that enables Super Validators (SVs) to propose the creation of UnallocatedUnclaimedActivityRecord contracts, representing authorized but not yet allocated Amulet rewards.

    High-level overview

    To contextualize the protocol and governance changes introduced by this CIP, we outline both a generalized workflow and a specific escrow-based scenario. These flows illustrate how unminted rewards transition through governance-controlled minting, and how this mechanism enables milestone-based issuance of Canton Coin while preserving decentralization, auditability, and escrow guarantees.

    General Flow

    • Weighted activity records are assigned to a party based on their contributions within a round.

    • If the assigned party fails to mint their rewards before the round concludes, those rewards are moved into the unminted pool.

    • At a later stage—following an off-chain agreement—someone may propose that a specified party should receive a portion of the unminted pool.

    • An on-chain vote is initiated to authorize the minting. Super Validators review and either approve or reject the proposal.

    alt_text

    Escrow Flow

    • The GSF node hosts an SV weight on behalf of an SV in an escrow agreement.
    • The GSF hosts a party for that SV on a separate GSF operated Validator, and names that party as the beneficiary of the SV weight.
    • The SVs, in each round, credit the GSF SV node for work/activity, and create a weighted activity records assigned coupon, which the GSF node splits among all the SV rights hosted on that node.
    • The GSF specifically disables the final minting action for all escrowed SV parties.
    • All the coin earned by escrowed parties goes into the unminted pool and loses all connection to any party.
    • When the SV passes a milestone, it then searches all the history to find weighted activity records assigned coupons that had been assigned to it, normalized / trimmed down to the weight it wants to claim.
    • The SV presents these records, and the resulting escrow claim, to the GSF.
    • GSF does its own calculation and makes a recommendation via an onchain vote.
    • SVs accept or reject the vote.

    alt_text

    Governance Specification

    • A new action requiring confirmation (SRARC_CreateUnallocatedUnclaimedActivityRecord) is added to DsoRules_ActionRequiringConfirmation.
    • A new choice DsoRules_CreateUnallocatedUnclaimedActivityRecord allows the DSO to propose a beneficiary, reward amount, and reason for the reward.
    • Upon successful vote confirmation, an UnallocatedUnclaimedActivityRecord contract is created. This contract has two expiry parameters:
      • expiresAt: Duration from creation, derived from the configurable DSO field unallocatedUnclaimedActivityRecordTimeout (defaulting to 24 hours).
      • unclaimedActivityRecordExpiresAt: Passed to the resulting activity record once allocation occurs.

    Allocation and Expiration

    • A new SV-App trigger, UnallocatedUnclaimedActivityRecordAllocatorTrigger, locates eligible UnclaimedReward contracts, archives them up to the specified amount, and creates an UnclaimedActivityRecord.
    • A second trigger, UnallocatedUnclaimedActivityRecordExpiryTrigger, expires unallocated records after their TTL.
    • A third trigger, UnclaimedActivityRecordExpiryTrigger, expires unused UnclaimedActivityRecord contracts.

    Minting Mechanism

    • UnclaimedActivityRecord is introduced as a new type of activity record that can be minted.
    • It is added as a new variant (InputUnclaimedActivityRecord) within the existing TransferInput type.
    • This input is consumed by AmuletRules_Transfer, which mints the corresponding Amulet during a self-transfer executed by automation in the Wallet App (CollectRewardsAndMergeAmuletsTrigger).

    Off-ledger Implementation Requirements

    • SV App

      • Implement and deploy the three new triggers listed above.
      • Extend the Treasury Service to support the new activity record lifecycle.

    • Wallet App

      • Extend the CollectRewardsAndMergeAmuletsTrigger to auto-collect UnclaimedActivityRecord using the new transfer input.

    • CLI App

      • Introduce a Python CLI utility to calculate minted and unclaimed rewards by party ID and time range, reusing logic from scan_txlog.py.

    • SV App Voting UI

      • Update the SV App voting UI to support proposals using DsoRules_CreateUnallocatedUnclaimedActivityRecord.

    • SV App Governance UI

      • Add support in the SV App for configuring unallocatedUnclaimedActivityRecordTimeout.

    Motivation

    This change is required to implement the reward distribution mechanism described in CIP-0058. The CIP defines a process whereby, upon successful milestone verification, the Tokenomics Working Group approves a reward amount and the Super Validators assign a portion of unclaimed rewards to be minted. This functionality leverages the standard voting process and introduces new ledger, off-ledger, and UI components to support reward calculation, archival of unclaimed rewards, and minting of the corresponding Amulet. While motivated by the need to support milestone-based escrowed rewards, the proposed mechanism is more general. It enables Super Validators to mint any type of unclaimed reward for any reason, not limited to escrowed incentives. This flexibility supports future governance decisions and additional reward use cases beyond the scope of CIP-0058.

    This aligns with the first deliverable of CIP-0058: Enable escrow mechanisms to ensure Super Validators deliver value in return for rewards.

    Rationale

    This proposal introduces a governance-backed, automated reward allocation mechanism that ensures Super Validators (SVs) never act as direct issuers of Amulets. Instead, it relies on existing voting infrastructure, explicit reward tracking, and on-ledger automation. The design satisfies the CIP-0058 objective of enabling escrowed value transfer with network approval, while preserving clear separation of duties between reward authorization and execution.

    Super Validators need a way to reward parties for milestone-based work without directly issuing Amulets. The proposed CIP process allows:

    • Proposing reward allocations through a formal vote explicitly approving the proposal.
    • Tracking and escrowing those rewards in a verifiable, on-ledger structure.
    • Allowing beneficiaries to receive their rewards without needing manual approval or signature from SVs.
    • Ensuring archival of previous reward entitlements (UnclaimedReward contracts) during the minting process.

    The final design introduces UnallocatedUnclaimedActivityRecord as a bridge between governance and execution. It supports clear auditability by representing approved but not yet funded reward intents. Once funded, these result in the creation of an UnclaimedActivityRecord, which serves as a transferable representation of reward entitlement. The UnclaimedActivityRecord is then consumed during a self-transfer initiated by automation in the Wallet App, resulting in the minting of the corresponding Amulet.

    Alternatives Considered

    Approach 1 – Mint in One Step

    This approach involved exercising a single voting choice (AmuletRules_MintFromUnmintedPool) that would simultaneously archive UnclaimedReward contracts and mint the Amulet.

    Rejected due to:

    • Risk of stale contract references caused by background reward merging.
    • Inability to collect beneficiary signatures, which are required for minting.

    Approach 2 – Post-Vote Execution with Extra Consequences

    This design embedded additional side effects in the vote’s success path: archiving UnclaimedRewards and creating an AmuletMintOffer as part of the vote confirmation.

    Rejected due to:

    • Inflexibility in the current voting infrastructure, which expects one-to-one mapping between action and execution.
    • Implementation would be non-trivial and hard to maintain.

    Approach 3 – Parallel Offer and Burn Request Flow

    Upon a successful vote, two contracts would be created:

    1. An AmuletMintOffer for the beneficiary to accept.
    2. A BurnUnclaimedRewardsRequest for the DSO to handle archival.

    Rejected due to:

    • Lack of atomicity, leading to potential inconsistencies.

    Approach 4 – AmuletMintOffer Claimed Manually by Beneficiary

    This design introduced UnallocatedAmuletMintOffer, accepted by an SV trigger that creates an AmuletMintOffer. The beneficiary would manually accept the final offer.

    Rejected due to:

    • The design would violate a core requirement of CIP-0058: SVs must not act as issuers.

    Justification for the Final Design

    The chosen approach introduces a clean separation of concerns:

    • Voting captures intent and approval.
    • SVs allocate funding (UnclaimedReward contracts) without minting.
    • The UnclaimedActivityRecord encapsulates minting rights in a transferable, on-ledger structure.
    • Beneficiaries receive Amulet through a self-transfer initiated by automation in the Wallet App, maintaining signature and stakeholder integrity.
    • The model avoids redundant templates or triggers and fits well into Splice’s composable architecture.

    This design was refined through multiple iterations, peer reviews, and discussions across the engineering and product teams, converging on a solution that meets both technical constraints and governance objectives.

    Backwards compatibility

    All choices and backend code involved are backward compatible.

    Reference implementation

    The new implementation includes backend and Daml changes. An early version of the Daml code is available in the following forked Splice branch: https://github.com/jose-velasco-ieu/splice/tree/josevelasco/daml-minting-escrowed-canton-coin-2/cip-0058