Potential CIP - Tx Requirements for Validator Rewards
- All - We have been working with Proof Group to formalize the CIP on this topic. We are ready to present it to the group for discussion. Please see the below, we would like to discuss it during tomorrow's tokenomics call. Happy to walk through during the call for anyone that doesn't have time to review it beforehand.ThanksChris=========
Abstract
Create a new “Active” Validator classification to incentivize Validators participating in on-chain transactions in Canton Mainnet.
Specification
This CIP proposes a mechanism and implementation to establish “Participating” and “Passive” Validators on the Canton Network. This classification will be used to determine a Validator’s cap for Liveness Rewards such that Participating Validators will have a higher cap than Passive Validators.
This CIP also proposes a governance process by which the “Participating” and “Passive” designation will be made for a Validator on the Canton Network.
In the remainder of this specification we will provide the details necessary to understand the proposed implementation.
Participating and Passive Validator Definition and Details
-
A “Participating” Validator is a Validator on the Canton Network that demonstrates significant participation in the ecosystem by engaging in at least X transactions on average on on-chain per epoch. Initially, X should be equal to 2. Going forward, the value of X shall be determined by standard governance procedures.
-
A “Passive” Validator will be defined as a Validator on the Canton Network that does not demonstrate significant participation in the ecosystem via engaging in on-chain transactions. Any Validator that engages in less than X transactions on-chain on average per epoch will be deemed to be a Passive Validator.
-
For the avoidance of doubt, Validators can not be both a Participating and Passive validator at the same time, but it is possible for a single Validator to switch back and forth between Participating and Passive.
-
Participating and Passive Validators build on the framework for Validators earning liveness rewards, which was laid out in CIP 3.
-
The concept of a Participating Validator follows the precedent laid out for Featured Applications created in CIP 47
Participating and Passive Validator Liveness Rewards Caps
-
We propose Participating Validator’s Liveness Reward minting rights cap remain unchanged from $570 as established in CIP 48. For use later, we call this variable Y.
-
We propose decreasing the cap on Passive Validators minting rights associated with Liveness Rewards. The reduction will be defined as:
-
Passive Validator Liveness Rewards Cap = Y/Z.
-
We propose Z should initially equal 10. Going forward, the value of Z shall be determined by standard governance procedures.
Implementation
-
Follow the logic of CIP 48 to define the Participating & Passive Validators Liveness rewards cap such that:
-
Participating Validators will maintain their existing Liveness Rewards cap of $570.
-
Introduce a variable to define the divisor used to determine Passive Validator Liveness Rewards cap as a function of the Participating Validator Liveness Rewards cap as defined above.
-
Set this variable to equal 10.
-
Establish a Liveness Rewards computation process as follow:
-
As already exists, first allocate Validator Activity mint rewards.
-
For any remaining Validator reward mints, earmark them for Liveness Rewards.
-
Compute each Validator’s potential Liveness minting rewards earned, up to their cap.
-
Add up all potential Liveness minting rewards earned for all Validators:
-
If the total potential minting rewards is less than or equal to the rewards remaining to be allocated for Liveness, distribute them to the relevant Validators.
-
If the total potential minting rewards is greater than the remaining rewards to be allocated for Liveness:
-
Determine each Validator’s pro-rata share of the remaining rewards.
-
Distribute rewards based on this pro-rata allocation.
Approval Process
-
Grant the authority to determine if a Validator is a Participating or a Passive Validators to the Tokenomics Committee similar to what is outlined in CIP 21
-
Given the vast quantity of validators, the committee will make determinations for existing validators through a batched process based on the criteria listed below.
-
On a go-forward basis, Validators will be established as a Passive Validator at time of deployment. The owners of the Validators may then request a review by the tokenomics committee for a potential Participating classification.
Approval Criteria
-
Approval for Participating Validators should be measured objectively. To be granted Participating status, a Validator must demonstrate they:
-
Conduct at least 2 transactions with Featured Applications per epoch on average during the evaluation window.
-
Establish an evaluation period to be from 17 days prior to the evaluation day until 3 days prior to the evaluation day, where a day is defined by midnight eastern time to 11:59:59 PM eastern time the same day. The three day buffered between evaluation period and evaluation day is to give the GSF and Validator time to prepare the necessary data for evaluation.
-
A new framework for approving Featured Validators may be adopted by the Super Validators or Tokenomics Committee at a later date after initial deployment of this functionality and the subsequent batch reviews of existing Validators is complete.
Motivation
Early in the network’s existence CIP-0003 was raised as a way to incentivize potential network participants to operate a Validator as additional use cases went live. Since then, there has been and continues to be a material growth in applications and use cases available on the network, as a result we believe the incentives should shift towards Application/Use Case participation and away from Validatory Liveness in order to avoid free-rider problems.
While there are already mechanisms in place to do this already (e.g. Activity Rewards slowly reducing the Liveness Rewards pool) the belief is that mechanism is likely slower than the current state of the network merits.
Rationale
When researching potential implementations options two approaches were considered. The first is outlined in this CIP. The second contemplated splitting Liveness Rewards into two buckets–one that tied rewards to transaction activity and one that tied rewards to validator liveness, over time the % of Liveness Rewards allocated to the first bucket would go up and rewards allocated to the second bucket would go down such that the total % across the two always equaled 100.
The decision was made to take the approach outlined in the CIP as it was possible to reuse the Featured Application logic that already exists in the network allowing for a more efficient implementation of the CIP. It also has the benefit of reusing a concept that already exists within the network rather than introducing something entirely new.
Backwards Compatibility
Potential backwards compatibility issues will continue to be monitored throughout the CIP review and implementation process. Any discovered will be raised to the group for review and to agree on any subsequent changes or actions.
Reference Implementation
To be added once there is agreement to proceed with the CIP.
Copyright
CC0-1.0: Creative Commons CC0 1.0 Universal -
- toggle quoted message Show quoted textHi Chris,
Many thanks. I broadly agree with all of this. However, I would like to point out that participation in the network should also contemplate the active subscription to apps that are aligned with Canton. I propose we also consider running/ subscribing to apps as participation as it helps adoption.I would love to hear your thoughts.Best,Kinga
Get Outlook for iOS
From: cip-discuss@... <cip-discuss@...> on behalf of Chris Zuehlke via lists.sync.global <czuehlke=drwholdings.com@...>
Sent: Thursday, May 22, 2025 5:15:40 PM
To: cip-discuss@... <cip-discuss@...>
Subject: Re: [cip-discuss] Potential CIP - Tx Requirements for Validator RewardsAll - We have been working with Proof Group to formalize the CIP on this topic. We are ready to present it to the group for discussion. Please see the below, we would like to discuss it during tomorrow's tokenomics call. Happy to walk through during the call for anyone that doesn't have time to review it beforehand.ThanksChris=========Abstract
Create a new “Active” Validator classification to incentivize Validators participating in on-chain transactions in Canton Mainnet.
Specification
This CIP proposes a mechanism and implementation to establish “Participating” and “Passive” Validators on the Canton Network. This classification will be used to determine a Validator’s cap for Liveness Rewards such that Participating Validators will have a higher cap than Passive Validators.
This CIP also proposes a governance process by which the “Participating” and “Passive” designation will be made for a Validator on the Canton Network.
In the remainder of this specification we will provide the details necessary to understand the proposed implementation.
Participating and Passive Validator Definition and Details
-
A “Participating” Validator is a Validator on the Canton Network that demonstrates significant participation in the ecosystem by engaging in at least X transactions on average on on-chain per epoch. Initially, X should be equal to 2. Going forward, the value of X shall be determined by standard governance procedures.
-
A “Passive” Validator will be defined as a Validator on the Canton Network that does not demonstrate significant participation in the ecosystem via engaging in on-chain transactions. Any Validator that engages in less than X transactions on-chain on average per epoch will be deemed to be a Passive Validator.
-
For the avoidance of doubt, Validators can not be both a Participating and Passive validator at the same time, but it is possible for a single Validator to switch back and forth between Participating and Passive.
-
Participating and Passive Validators build on the framework for Validators earning liveness rewards, which was laid out in CIP 3.
-
The concept of a Participating Validator follows the precedent laid out for Featured Applications created in CIP 47
Participating and Passive Validator Liveness Rewards Caps
-
We propose Participating Validator’s Liveness Reward minting rights cap remain unchanged from $570 as established in CIP 48. For use later, we call this variable Y.
-
We propose decreasing the cap on Passive Validators minting rights associated with Liveness Rewards. The reduction will be defined as:
-
Passive Validator Liveness Rewards Cap = Y/Z.
-
We propose Z should initially equal 10. Going forward, the value of Z shall be determined by standard governance procedures.
Implementation
-
Follow the logic of CIP 48 to define the Participating & Passive Validators Liveness rewards cap such that:
-
Participating Validators will maintain their existing Liveness Rewards cap of $570.
-
Introduce a variable to define the divisor used to determine Passive Validator Liveness Rewards cap as a function of the Participating Validator Liveness Rewards cap as defined above.
-
Set this variable to equal 10.
-
Establish a Liveness Rewards computation process as follow:
-
As already exists, first allocate Validator Activity mint rewards.
-
For any remaining Validator reward mints, earmark them for Liveness Rewards.
-
Compute each Validator’s potential Liveness minting rewards earned, up to their cap.
-
Add up all potential Liveness minting rewards earned for all Validators:
-
If the total potential minting rewards is less than or equal to the rewards remaining to be allocated for Liveness, distribute them to the relevant Validators.
-
If the total potential minting rewards is greater than the remaining rewards to be allocated for Liveness:
-
Determine each Validator’s pro-rata share of the remaining rewards.
-
Distribute rewards based on this pro-rata allocation.
Approval Process
-
Grant the authority to determine if a Validator is a Participating or a Passive Validators to the Tokenomics Committee similar to what is outlined in CIP 21
-
Given the vast quantity of validators, the committee will make determinations for existing validators through a batched process based on the criteria listed below.
-
On a go-forward basis, Validators will be established as a Passive Validator at time of deployment. The owners of the Validators may then request a review by the tokenomics committee for a potential Participating classification.
Approval Criteria
-
Approval for Participating Validators should be measured objectively. To be granted Participating status, a Validator must demonstrate they:
-
Conduct at least 2 transactions with Featured Applications per epoch on average during the evaluation window.
-
Establish an evaluation period to be from 17 days prior to the evaluation day until 3 days prior to the evaluation day, where a day is defined by midnight eastern time to 11:59:59 PM eastern time the same day. The three day buffered between evaluation period and evaluation day is to give the GSF and Validator time to prepare the necessary data for evaluation.
-
A new framework for approving Featured Validators may be adopted by the Super Validators or Tokenomics Committee at a later date after initial deployment of this functionality and the subsequent batch reviews of existing Validators is complete.
Motivation
Early in the network’s existence CIP-0003 was raised as a way to incentivize potential network participants to operate a Validator as additional use cases went live. Since then, there has been and continues to be a material growth in applications and use cases available on the network, as a result we believe the incentives should shift towards Application/Use Case participation and away from Validatory Liveness in order to avoid free-rider problems.
While there are already mechanisms in place to do this already (e.g. Activity Rewards slowly reducing the Liveness Rewards pool) the belief is that mechanism is likely slower than the current state of the network merits.
Rationale
When researching potential implementations options two approaches were considered. The first is outlined in this CIP. The second contemplated splitting Liveness Rewards into two buckets–one that tied rewards to transaction activity and one that tied rewards to validator liveness, over time the % of Liveness Rewards allocated to the first bucket would go up and rewards allocated to the second bucket would go down such that the total % across the two always equaled 100.
The decision was made to take the approach outlined in the CIP as it was possible to reuse the Featured Application logic that already exists in the network allowing for a more efficient implementation of the CIP. It also has the benefit of reusing a concept that already exists within the network rather than introducing something entirely new.
Backwards Compatibility
Potential backwards compatibility issues will continue to be monitored throughout the CIP review and implementation process. Any discovered will be raised to the group for review and to agree on any subsequent changes or actions.
Reference Implementation
To be added once there is agreement to proceed with the CIP.
Copyright
CC0-1.0: Creative Commons CC0 1.0 Universal -
- toggle quoted message Show quoted textHi Kinga, thanks for taking a read!That would still fall under this current proposal as we are saying 2 tx/ epoch. The subscription to apps would count as such. We were debating if we should note those tx are with featured apps or not.On Thu, May 22, 2025 at 5:30 PM Kinga Bosse via lists.sync.global <kinga.bosse=mpch.com@...> wrote:Hi Chris,
Many thanks. I broadly agree with all of this. However, I would like to point out that participation in the network should also contemplate the active subscription to apps that are aligned with Canton. I propose we also consider running/ subscribing to apps as participation as it helps adoption.I would love to hear your thoughts.Best,Kinga
Get Outlook for iOS
From: cip-discuss@... <cip-discuss@...> on behalf of Chris Zuehlke via lists.sync.global <czuehlke=drwholdings.com@...>
Sent: Thursday, May 22, 2025 5:15:40 PM
To: cip-discuss@... <cip-discuss@...>
Subject: Re: [cip-discuss] Potential CIP - Tx Requirements for Validator RewardsAll - We have been working with Proof Group to formalize the CIP on this topic. We are ready to present it to the group for discussion. Please see the below, we would like to discuss it during tomorrow's tokenomics call. Happy to walk through during the call for anyone that doesn't have time to review it beforehand.ThanksChris=========Abstract
Create a new “Active” Validator classification to incentivize Validators participating in on-chain transactions in Canton Mainnet.
Specification
This CIP proposes a mechanism and implementation to establish “Participating” and “Passive” Validators on the Canton Network. This classification will be used to determine a Validator’s cap for Liveness Rewards such that Participating Validators will have a higher cap than Passive Validators.
This CIP also proposes a governance process by which the “Participating” and “Passive” designation will be made for a Validator on the Canton Network.
In the remainder of this specification we will provide the details necessary to understand the proposed implementation.
Participating and Passive Validator Definition and Details
-
A “Participating” Validator is a Validator on the Canton Network that demonstrates significant participation in the ecosystem by engaging in at least X transactions on average on on-chain per epoch. Initially, X should be equal to 2. Going forward, the value of X shall be determined by standard governance procedures.
-
A “Passive” Validator will be defined as a Validator on the Canton Network that does not demonstrate significant participation in the ecosystem via engaging in on-chain transactions. Any Validator that engages in less than X transactions on-chain on average per epoch will be deemed to be a Passive Validator.
-
For the avoidance of doubt, Validators can not be both a Participating and Passive validator at the same time, but it is possible for a single Validator to switch back and forth between Participating and Passive.
-
Participating and Passive Validators build on the framework for Validators earning liveness rewards, which was laid out in CIP 3.
-
The concept of a Participating Validator follows the precedent laid out for Featured Applications created in CIP 47
Participating and Passive Validator Liveness Rewards Caps
-
We propose Participating Validator’s Liveness Reward minting rights cap remain unchanged from $570 as established in CIP 48. For use later, we call this variable Y.
-
We propose decreasing the cap on Passive Validators minting rights associated with Liveness Rewards. The reduction will be defined as:
-
Passive Validator Liveness Rewards Cap = Y/Z.
-
We propose Z should initially equal 10. Going forward, the value of Z shall be determined by standard governance procedures.
Implementation
-
Follow the logic of CIP 48 to define the Participating & Passive Validators Liveness rewards cap such that:
-
Participating Validators will maintain their existing Liveness Rewards cap of $570.
-
Introduce a variable to define the divisor used to determine Passive Validator Liveness Rewards cap as a function of the Participating Validator Liveness Rewards cap as defined above.
-
Set this variable to equal 10.
-
Establish a Liveness Rewards computation process as follow:
-
As already exists, first allocate Validator Activity mint rewards.
-
For any remaining Validator reward mints, earmark them for Liveness Rewards.
-
Compute each Validator’s potential Liveness minting rewards earned, up to their cap.
-
Add up all potential Liveness minting rewards earned for all Validators:
-
If the total potential minting rewards is less than or equal to the rewards remaining to be allocated for Liveness, distribute them to the relevant Validators.
-
If the total potential minting rewards is greater than the remaining rewards to be allocated for Liveness:
-
Determine each Validator’s pro-rata share of the remaining rewards.
-
Distribute rewards based on this pro-rata allocation.
Approval Process
-
Grant the authority to determine if a Validator is a Participating or a Passive Validators to the Tokenomics Committee similar to what is outlined in CIP 21
-
Given the vast quantity of validators, the committee will make determinations for existing validators through a batched process based on the criteria listed below.
-
On a go-forward basis, Validators will be established as a Passive Validator at time of deployment. The owners of the Validators may then request a review by the tokenomics committee for a potential Participating classification.
Approval Criteria
-
Approval for Participating Validators should be measured objectively. To be granted Participating status, a Validator must demonstrate they:
-
Conduct at least 2 transactions with Featured Applications per epoch on average during the evaluation window.
-
Establish an evaluation period to be from 17 days prior to the evaluation day until 3 days prior to the evaluation day, where a day is defined by midnight eastern time to 11:59:59 PM eastern time the same day. The three day buffered between evaluation period and evaluation day is to give the GSF and Validator time to prepare the necessary data for evaluation.
-
A new framework for approving Featured Validators may be adopted by the Super Validators or Tokenomics Committee at a later date after initial deployment of this functionality and the subsequent batch reviews of existing Validators is complete.
Motivation
Early in the network’s existence CIP-0003 was raised as a way to incentivize potential network participants to operate a Validator as additional use cases went live. Since then, there has been and continues to be a material growth in applications and use cases available on the network, as a result we believe the incentives should shift towards Application/Use Case participation and away from Validatory Liveness in order to avoid free-rider problems.
While there are already mechanisms in place to do this already (e.g. Activity Rewards slowly reducing the Liveness Rewards pool) the belief is that mechanism is likely slower than the current state of the network merits.
Rationale
When researching potential implementations options two approaches were considered. The first is outlined in this CIP. The second contemplated splitting Liveness Rewards into two buckets–one that tied rewards to transaction activity and one that tied rewards to validator liveness, over time the % of Liveness Rewards allocated to the first bucket would go up and rewards allocated to the second bucket would go down such that the total % across the two always equaled 100.
The decision was made to take the approach outlined in the CIP as it was possible to reuse the Featured Application logic that already exists in the network allowing for a more efficient implementation of the CIP. It also has the benefit of reusing a concept that already exists within the network rather than introducing something entirely new.
Backwards Compatibility
Potential backwards compatibility issues will continue to be monitored throughout the CIP review and implementation process. Any discovered will be raised to the group for review and to agree on any subsequent changes or actions.
Reference Implementation
To be added once there is agreement to proceed with the CIP.
Copyright
CC0-1.0: Creative Commons CC0 1.0 Universal -
- toggle quoted message Show quoted textI echo Kinga’s point. I think that should be unrelated to whether the app/subscription is featured or not. Validators should be free to choose what apps they subscribe to.Y.On Fri, May 23, 2025 at 00:34 Chris Matturri <chris@...> wrote:Hi Kinga, thanks for taking a read!That would still fall under this current proposal as we are saying 2 tx/ epoch. The subscription to apps would count as such. We were debating if we should note those tx are with featured apps or not.On Thu, May 22, 2025 at 5:30 PM Kinga Bosse via lists.sync.global <kinga.bosse=mpch.com@...> wrote:Hi Chris,
Many thanks. I broadly agree with all of this. However, I would like to point out that participation in the network should also contemplate the active subscription to apps that are aligned with Canton. I propose we also consider running/ subscribing to apps as participation as it helps adoption.I would love to hear your thoughts.Best,Kinga
Get Outlook for iOS
From: cip-discuss@... <cip-discuss@...> on behalf of Chris Zuehlke via lists.sync.global <czuehlke=drwholdings.com@...>
Sent: Thursday, May 22, 2025 5:15:40 PM
To: cip-discuss@... <cip-discuss@...>
Subject: Re: [cip-discuss] Potential CIP - Tx Requirements for Validator RewardsAll - We have been working with Proof Group to formalize the CIP on this topic. We are ready to present it to the group for discussion. Please see the below, we would like to discuss it during tomorrow's tokenomics call. Happy to walk through during the call for anyone that doesn't have time to review it beforehand.ThanksChris=========Abstract
Create a new “Active” Validator classification to incentivize Validators participating in on-chain transactions in Canton Mainnet.
Specification
This CIP proposes a mechanism and implementation to establish “Participating” and “Passive” Validators on the Canton Network. This classification will be used to determine a Validator’s cap for Liveness Rewards such that Participating Validators will have a higher cap than Passive Validators.
This CIP also proposes a governance process by which the “Participating” and “Passive” designation will be made for a Validator on the Canton Network.
In the remainder of this specification we will provide the details necessary to understand the proposed implementation.
Participating and Passive Validator Definition and Details
-
A “Participating” Validator is a Validator on the Canton Network that demonstrates significant participation in the ecosystem by engaging in at least X transactions on average on on-chain per epoch. Initially, X should be equal to 2. Going forward, the value of X shall be determined by standard governance procedures.
-
A “Passive” Validator will be defined as a Validator on the Canton Network that does not demonstrate significant participation in the ecosystem via engaging in on-chain transactions. Any Validator that engages in less than X transactions on-chain on average per epoch will be deemed to be a Passive Validator.
-
For the avoidance of doubt, Validators can not be both a Participating and Passive validator at the same time, but it is possible for a single Validator to switch back and forth between Participating and Passive.
-
Participating and Passive Validators build on the framework for Validators earning liveness rewards, which was laid out in CIP 3.
-
The concept of a Participating Validator follows the precedent laid out for Featured Applications created in CIP 47
Participating and Passive Validator Liveness Rewards Caps
-
We propose Participating Validator’s Liveness Reward minting rights cap remain unchanged from $570 as established in CIP 48. For use later, we call this variable Y.
-
We propose decreasing the cap on Passive Validators minting rights associated with Liveness Rewards. The reduction will be defined as:
-
Passive Validator Liveness Rewards Cap = Y/Z.
-
We propose Z should initially equal 10. Going forward, the value of Z shall be determined by standard governance procedures.
Implementation
-
Follow the logic of CIP 48 to define the Participating & Passive Validators Liveness rewards cap such that:
-
Participating Validators will maintain their existing Liveness Rewards cap of $570.
-
Introduce a variable to define the divisor used to determine Passive Validator Liveness Rewards cap as a function of the Participating Validator Liveness Rewards cap as defined above.
-
Set this variable to equal 10.
-
Establish a Liveness Rewards computation process as follow:
-
As already exists, first allocate Validator Activity mint rewards.
-
For any remaining Validator reward mints, earmark them for Liveness Rewards.
-
Compute each Validator’s potential Liveness minting rewards earned, up to their cap.
-
Add up all potential Liveness minting rewards earned for all Validators:
-
If the total potential minting rewards is less than or equal to the rewards remaining to be allocated for Liveness, distribute them to the relevant Validators.
-
If the total potential minting rewards is greater than the remaining rewards to be allocated for Liveness:
-
Determine each Validator’s pro-rata share of the remaining rewards.
-
Distribute rewards based on this pro-rata allocation.
Approval Process
-
Grant the authority to determine if a Validator is a Participating or a Passive Validators to the Tokenomics Committee similar to what is outlined in CIP 21
-
Given the vast quantity of validators, the committee will make determinations for existing validators through a batched process based on the criteria listed below.
-
On a go-forward basis, Validators will be established as a Passive Validator at time of deployment. The owners of the Validators may then request a review by the tokenomics committee for a potential Participating classification.
Approval Criteria
-
Approval for Participating Validators should be measured objectively. To be granted Participating status, a Validator must demonstrate they:
-
Conduct at least 2 transactions with Featured Applications per epoch on average during the evaluation window.
-
Establish an evaluation period to be from 17 days prior to the evaluation day until 3 days prior to the evaluation day, where a day is defined by midnight eastern time to 11:59:59 PM eastern time the same day. The three day buffered between evaluation period and evaluation day is to give the GSF and Validator time to prepare the necessary data for evaluation.
-
A new framework for approving Featured Validators may be adopted by the Super Validators or Tokenomics Committee at a later date after initial deployment of this functionality and the subsequent batch reviews of existing Validators is complete.
Motivation
Early in the network’s existence CIP-0003 was raised as a way to incentivize potential network participants to operate a Validator as additional use cases went live. Since then, there has been and continues to be a material growth in applications and use cases available on the network, as a result we believe the incentives should shift towards Application/Use Case participation and away from Validatory Liveness in order to avoid free-rider problems.
While there are already mechanisms in place to do this already (e.g. Activity Rewards slowly reducing the Liveness Rewards pool) the belief is that mechanism is likely slower than the current state of the network merits.
Rationale
When researching potential implementations options two approaches were considered. The first is outlined in this CIP. The second contemplated splitting Liveness Rewards into two buckets–one that tied rewards to transaction activity and one that tied rewards to validator liveness, over time the % of Liveness Rewards allocated to the first bucket would go up and rewards allocated to the second bucket would go down such that the total % across the two always equaled 100.
The decision was made to take the approach outlined in the CIP as it was possible to reuse the Featured Application logic that already exists in the network allowing for a more efficient implementation of the CIP. It also has the benefit of reusing a concept that already exists within the network rather than introducing something entirely new.
Backwards Compatibility
Potential backwards compatibility issues will continue to be monitored throughout the CIP review and implementation process. Any discovered will be raised to the group for review and to agree on any subsequent changes or actions.
Reference Implementation
To be added once there is agreement to proceed with the CIP.
Copyright
CC0-1.0: Creative Commons CC0 1.0 Universal -
- Hi Chris and Chris,Could you elaborate and what the rationale for making the distinction below would be?
We were debating if we should note those tx are with featured apps or not.
On a different note, I noticed that this draft CIP was not added to today's agenda. Do you want to present it today or would you rather go through another round of discussion?Best regards,Fernando2025年5月23日(金) 14:34 Yiannis Varelas via lists.sync.global <y=fivenorth.io@...>:I echo Kinga’s point. I think that should be unrelated to whether the app/subscription is featured or not. Validators should be free to choose what apps they subscribe to.Y.On Fri, May 23, 2025 at 00:34 Chris Matturri <chris@...> wrote:Hi Kinga, thanks for taking a read!That would still fall under this current proposal as we are saying 2 tx/ epoch. The subscription to apps would count as such. We were debating if we should note those tx are with featured apps or not.On Thu, May 22, 2025 at 5:30 PM Kinga Bosse via lists.sync.global <kinga.bosse=mpch.com@...> wrote:Hi Chris,
Many thanks. I broadly agree with all of this. However, I would like to point out that participation in the network should also contemplate the active subscription to apps that are aligned with Canton. I propose we also consider running/ subscribing to apps as participation as it helps adoption.I would love to hear your thoughts.Best,Kinga
Get Outlook for iOS
From: cip-discuss@... <cip-discuss@...> on behalf of Chris Zuehlke via lists.sync.global <czuehlke=drwholdings.com@...>
Sent: Thursday, May 22, 2025 5:15:40 PM
To: cip-discuss@... <cip-discuss@...>
Subject: Re: [cip-discuss] Potential CIP - Tx Requirements for Validator RewardsAll - We have been working with Proof Group to formalize the CIP on this topic. We are ready to present it to the group for discussion. Please see the below, we would like to discuss it during tomorrow's tokenomics call. Happy to walk through during the call for anyone that doesn't have time to review it beforehand.ThanksChris=========Abstract
Create a new “Active” Validator classification to incentivize Validators participating in on-chain transactions in Canton Mainnet.
Specification
This CIP proposes a mechanism and implementation to establish “Participating” and “Passive” Validators on the Canton Network. This classification will be used to determine a Validator’s cap for Liveness Rewards such that Participating Validators will have a higher cap than Passive Validators.
This CIP also proposes a governance process by which the “Participating” and “Passive” designation will be made for a Validator on the Canton Network.
In the remainder of this specification we will provide the details necessary to understand the proposed implementation.
Participating and Passive Validator Definition and Details
-
A “Participating” Validator is a Validator on the Canton Network that demonstrates significant participation in the ecosystem by engaging in at least X transactions on average on on-chain per epoch. Initially, X should be equal to 2. Going forward, the value of X shall be determined by standard governance procedures.
-
A “Passive” Validator will be defined as a Validator on the Canton Network that does not demonstrate significant participation in the ecosystem via engaging in on-chain transactions. Any Validator that engages in less than X transactions on-chain on average per epoch will be deemed to be a Passive Validator.
-
For the avoidance of doubt, Validators can not be both a Participating and Passive validator at the same time, but it is possible for a single Validator to switch back and forth between Participating and Passive.
-
Participating and Passive Validators build on the framework for Validators earning liveness rewards, which was laid out in CIP 3.
-
The concept of a Participating Validator follows the precedent laid out for Featured Applications created in CIP 47
Participating and Passive Validator Liveness Rewards Caps
-
We propose Participating Validator’s Liveness Reward minting rights cap remain unchanged from $570 as established in CIP 48. For use later, we call this variable Y.
-
We propose decreasing the cap on Passive Validators minting rights associated with Liveness Rewards. The reduction will be defined as:
-
Passive Validator Liveness Rewards Cap = Y/Z.
-
We propose Z should initially equal 10. Going forward, the value of Z shall be determined by standard governance procedures.
Implementation
-
Follow the logic of CIP 48 to define the Participating & Passive Validators Liveness rewards cap such that:
-
Participating Validators will maintain their existing Liveness Rewards cap of $570.
-
Introduce a variable to define the divisor used to determine Passive Validator Liveness Rewards cap as a function of the Participating Validator Liveness Rewards cap as defined above.
-
Set this variable to equal 10.
-
Establish a Liveness Rewards computation process as follow:
-
As already exists, first allocate Validator Activity mint rewards.
-
For any remaining Validator reward mints, earmark them for Liveness Rewards.
-
Compute each Validator’s potential Liveness minting rewards earned, up to their cap.
-
Add up all potential Liveness minting rewards earned for all Validators:
-
If the total potential minting rewards is less than or equal to the rewards remaining to be allocated for Liveness, distribute them to the relevant Validators.
-
If the total potential minting rewards is greater than the remaining rewards to be allocated for Liveness:
-
Determine each Validator’s pro-rata share of the remaining rewards.
-
Distribute rewards based on this pro-rata allocation.
Approval Process
-
Grant the authority to determine if a Validator is a Participating or a Passive Validators to the Tokenomics Committee similar to what is outlined in CIP 21
-
Given the vast quantity of validators, the committee will make determinations for existing validators through a batched process based on the criteria listed below.
-
On a go-forward basis, Validators will be established as a Passive Validator at time of deployment. The owners of the Validators may then request a review by the tokenomics committee for a potential Participating classification.
Approval Criteria
-
Approval for Participating Validators should be measured objectively. To be granted Participating status, a Validator must demonstrate they:
-
Conduct at least 2 transactions with Featured Applications per epoch on average during the evaluation window.
-
Establish an evaluation period to be from 17 days prior to the evaluation day until 3 days prior to the evaluation day, where a day is defined by midnight eastern time to 11:59:59 PM eastern time the same day. The three day buffered between evaluation period and evaluation day is to give the GSF and Validator time to prepare the necessary data for evaluation.
-
A new framework for approving Featured Validators may be adopted by the Super Validators or Tokenomics Committee at a later date after initial deployment of this functionality and the subsequent batch reviews of existing Validators is complete.
Motivation
Early in the network’s existence CIP-0003 was raised as a way to incentivize potential network participants to operate a Validator as additional use cases went live. Since then, there has been and continues to be a material growth in applications and use cases available on the network, as a result we believe the incentives should shift towards Application/Use Case participation and away from Validatory Liveness in order to avoid free-rider problems.
While there are already mechanisms in place to do this already (e.g. Activity Rewards slowly reducing the Liveness Rewards pool) the belief is that mechanism is likely slower than the current state of the network merits.
Rationale
When researching potential implementations options two approaches were considered. The first is outlined in this CIP. The second contemplated splitting Liveness Rewards into two buckets–one that tied rewards to transaction activity and one that tied rewards to validator liveness, over time the % of Liveness Rewards allocated to the first bucket would go up and rewards allocated to the second bucket would go down such that the total % across the two always equaled 100.
The decision was made to take the approach outlined in the CIP as it was possible to reuse the Featured Application logic that already exists in the network allowing for a more efficient implementation of the CIP. It also has the benefit of reusing a concept that already exists within the network rather than introducing something entirely new.
Backwards Compatibility
Potential backwards compatibility issues will continue to be monitored throughout the CIP review and implementation process. Any discovered will be raised to the group for review and to agree on any subsequent changes or actions.
Reference Implementation
To be added once there is agreement to proceed with the CIP.
Copyright
CC0-1.0: Creative Commons CC0 1.0 Universal -
- We’d like to discuss it today during the call please.toggle quoted message Show quoted text
From my perspective, requiring the tx to be conducted with a featured app introduces a layer of protection from participants trying to game the construct.
For instance, could someone deploy an app to the network that effectively does nothing, and connect their validator to it to generate the transactions. Given the open and decentralized nature of Canton, I think this could eventually happen. Requiring the app to be designated as Featured would in theory prevent that. Open to other ideas though.
ChrisOn May 23, 2025, at 3:51 AM, Fernando Vazquez <fernando.vazquez@...> wrote:
Hi Chris and Chris, Could you elaborate and what the rationale for making the distinction below would be? We were debating if we should note those tx are with featured apps or not. On a different note, I noticed that this draft CIP was not added
Hi Chris and Chris,
Could you elaborate and what the rationale for making the distinction below would be?
We were debating if we should note those tx are with featured apps or not.
On a different note, I noticed that this draft CIP was not added to today's agenda. Do you want to present it today or would you rather go through another round of discussion?
Best regards,
Fernando
2025年5月23日(金) 14:34 Yiannis Varelas via lists.sync.global <y=fivenorth.io@...>:
I echo Kinga’s point. I think that should be unrelated to whether the app/subscription is featured or not. Validators should be free to choose what apps they subscribe to.
Y.
On Fri, May 23, 2025 at 00:34 Chris Matturri <chris@...<mailto:chris@...>> wrote:
Hi Kinga, thanks for taking a read!
That would still fall under this current proposal as we are saying 2 tx/ epoch. The subscription to apps would count as such. We were debating if we should note those tx are with featured apps or not.
On Thu, May 22, 2025 at 5:30 PM Kinga Bosse via lists.sync.global <kinga.bosse=mpch.com@...> wrote:
Hi Chris,
Many thanks. I broadly agree with all of this. However, I would like to point out that participation in the network should also contemplate the active subscription to apps that are aligned with Canton. I propose we also consider running/ subscribing to apps as participation as it helps adoption.
I would love to hear your thoughts.
Best,
Kinga
Get Outlook for iOS<https://urldefense.com/v3/__https://aka.ms/o0ukef__;!!EvhwMw!TyC8VLIy17z4u5qLndvOPAqtv7w6HAzin3hoDkoSqqul8eYEht3_axe032xHlrbm1hmBPtNH86J9ZLbhPIvErBp6nYKwym4Z$>
________________________________
From: cip-discuss@... <cip-discuss@...> on behalf of Chris Zuehlke via lists.sync.global <czuehlke=drwholdings.com@...>
Sent: Thursday, May 22, 2025 5:15:40 PM
To: cip-discuss@... <cip-discuss@...>
Subject: Re: [cip-discuss] Potential CIP - Tx Requirements for Validator Rewards
All - We have been working with Proof Group to formalize the CIP on this topic. We are ready to present it to the group for discussion. Please see the below, we would like to discuss it during tomorrow's tokenomics call. Happy to walk through during the call for anyone that doesn't have time to review it beforehand.
Thanks
Chris
=========
Abstract
Create a new “Active” Validator classification to incentivize Validators participating in on-chain transactions in Canton Mainnet.
Specification
This CIP proposes a mechanism and implementation to establish “Participating” and “Passive” Validators on the Canton Network. This classification will be used to determine a Validator’s cap for Liveness Rewards such that Participating Validators will have a higher cap than Passive Validators.
This CIP also proposes a governance process by which the “Participating” and “Passive” designation will be made for a Validator on the Canton Network.
In the remainder of this specification we will provide the details necessary to understand the proposed implementation.
Participating and Passive Validator Definition and Details
* A “Participating” Validator is a Validator on the Canton Network that demonstrates significant participation in the ecosystem by engaging in at least X transactions on average on on-chain per epoch. Initially, X should be equal to 2. Going forward, the value of X shall be determined by standard governance procedures.
* A “Passive” Validator will be defined as a Validator on the Canton Network that does not demonstrate significant participation in the ecosystem via engaging in on-chain transactions. Any Validator that engages in less than X transactions on-chain on average per epoch will be deemed to be a Passive Validator.
* For the avoidance of doubt, Validators can not be both a Participating and Passive validator at the same time, but it is possible for a single Validator to switch back and forth between Participating and Passive.
* Participating and Passive Validators build on the framework for Validators earning liveness rewards, which was laid out in CIP-0003<https://urldefense.com/v3/__https://github.com/global-synchronizer-foundation/cips/blob/87d443909f55fe16a0f2bb7fd2c0219b9905f2cf/cip-0003/CIP-0001-0002-0003.pdf__;!!EvhwMw!TyC8VLIy17z4u5qLndvOPAqtv7w6HAzin3hoDkoSqqul8eYEht3_axe032xHlrbm1hmBPtNH86J9ZLbhPIvErBp6naMMP_6I$>.
* The concept of a Participating Validator follows the precedent laid out for Featured Applications created in CIP-0047
<https://urldefense.com/v3/__https://github.com/global-synchronizer-foundation/cips/blob/87d443909f55fe16a0f2bb7fd2c0219b9905f2cf/cip-0047/cip-0047.md__;!!EvhwMw!TyC8VLIy17z4u5qLndvOPAqtv7w6HAzin3hoDkoSqqul8eYEht3_axe032xHlrbm1hmBPtNH86J9ZLbhPIvErBp6nTOzfJ1E$>
Participating and Passive Validator Liveness Rewards Caps
* We propose Participating Validator’s Liveness Reward minting rights cap remain unchanged from $570 as established in CIP-0048<https://urldefense.com/v3/__https://github.com/global-synchronizer-foundation/cips/blob/87d443909f55fe16a0f2bb7fd2c0219b9905f2cf/cip-0048/cip-0048.md__;!!EvhwMw!TyC8VLIy17z4u5qLndvOPAqtv7w6HAzin3hoDkoSqqul8eYEht3_axe032xHlrbm1hmBPtNH86J9ZLbhPIvErBp6nbxUy17n$>. For use later, we call this variable Y.
* We propose decreasing the cap on Passive Validators minting rights associated with Liveness Rewards. The reduction will be defined as:
* Passive Validator Liveness Rewards Cap = Y/Z.
* We propose Z should initially equal 10. Going forward, the value of Z shall be determined by standard governance procedures.
Implementation
* Follow the logic of CIP-0048 <https://urldefense.com/v3/__https://github.com/global-synchronizer-foundation/cips/blob/87d443909f55fe16a0f2bb7fd2c0219b9905f2cf/cip-0048/cip-0048.md__;!!EvhwMw!TyC8VLIy17z4u5qLndvOPAqtv7w6HAzin3hoDkoSqqul8eYEht3_axe032xHlrbm1hmBPtNH86J9ZLbhPIvErBp6nbxUy17n$> to define the Participating & Passive Validators Liveness rewards cap such that:
* Participating Validators will maintain their existing Liveness Rewards cap of $570.
* Introduce a variable to define the divisor used to determine Passive Validator Liveness Rewards cap as a function of the Participating Validator Liveness Rewards cap as defined above.
* Set this variable to equal 10.
* Establish a Liveness Rewards computation process as follow:
* As already exists, first allocate Validator Activity mint rewards.
* For any remaining Validator reward mints, earmark them for Liveness Rewards.
* Compute each Validator’s potential Liveness minting rewards earned, up to their cap.
* Add up all potential Liveness minting rewards earned for all Validators:
* If the total potential minting rewards is less than or equal to the rewards remaining to be allocated for Liveness, distribute them to the relevant Validators.
* If the total potential minting rewards is greater than the remaining rewards to be allocated for Liveness:
* Determine each Validator’s pro-rata share of the remaining rewards.
* Distribute rewards based on this pro-rata allocation.
Approval Process
* Grant the authority to determine if a Validator is a Participating or a Passive Validators to the Tokenomics Committee similar to what is outlined in CIP-0021<https://urldefense.com/v3/__https://github.com/global-synchronizer-foundation/cips/blob/87d443909f55fe16a0f2bb7fd2c0219b9905f2cf/cip-0021/cip-0021.pdf__;!!EvhwMw!TyC8VLIy17z4u5qLndvOPAqtv7w6HAzin3hoDkoSqqul8eYEht3_axe032xHlrbm1hmBPtNH86J9ZLbhPIvErBp6nWwZXbBQ$>
* Given the vast quantity of validators, the committee will make determinations for existing validators through a batched process based on the criteria listed below.
* On a go-forward basis, Validators will be established as a Passive Validator at time of deployment. The owners of the Validators may then request a review by the tokenomics committee for a potential Participating classification.
Approval Criteria
* Approval for Participating Validators should be measured objectively. To be granted Participating status, a Validator must demonstrate they:
* Conduct at least 2 transactions with Featured Applications per epoch on average during the evaluation window.
* Establish an evaluation period to be from 17 days prior to the evaluation day until 3 days prior to the evaluation day, where a day is defined by midnight eastern time to 11:59:59 PM eastern time the same day. The three day buffered between evaluation period and evaluation day is to give the GSF and Validator time to prepare the necessary data for evaluation.
* A new framework for approving Featured Validators may be adopted by the Super Validators or Tokenomics Committee at a later date after initial deployment of this functionality and the subsequent batch reviews of existing Validators is complete.
Motivation
Early in the network’s existence CIP-0003 was raised as a way to incentivize potential network participants to operate a Validator as additional use cases went live. Since then, there has been and continues to be a material growth in applications and use cases available on the network, as a result we believe the incentives should shift towards Application/Use Case participation and away from Validatory Liveness in order to avoid free-rider problems.
While there are already mechanisms in place to do this already (e.g. Activity Rewards slowly reducing the Liveness Rewards pool) the belief is that mechanism is likely slower than the current state of the network merits.
Rationale
When researching potential implementations options two approaches were considered. The first is outlined in this CIP. The second contemplated splitting Liveness Rewards into two buckets–one that tied rewards to transaction activity and one that tied rewards to validator liveness, over time the % of Liveness Rewards allocated to the first bucket would go up and rewards allocated to the second bucket would go down such that the total % across the two always equaled 100.
The decision was made to take the approach outlined in the CIP as it was possible to reuse the Featured Application logic that already exists in the network allowing for a more efficient implementation of the CIP. It also has the benefit of reusing a concept that already exists within the network rather than introducing something entirely new.
Backwards Compatibility
Potential backwards compatibility issues will continue to be monitored throughout the CIP review and implementation process. Any discovered will be raised to the group for review and to agree on any subsequent changes or actions.
Reference Implementation
To be added once there is agreement to proceed with the CIP.
Copyright
CC0-1.0: Creative Commons CC0 1.0 Universal<https://urldefense.com/v3/__https://creativecommons.org/publicdomain/zero/1.0/__;!!EvhwMw!TyC8VLIy17z4u5qLndvOPAqtv7w6HAzin3hoDkoSqqul8eYEht3_axe032xHlrbm1hmBPtNH86J9ZLbhPIvErBp6nfHb3tWK$>
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. - toggle quoted message Show quoted textDone. I just added it.2025年5月23日(金) 21:25 Chris Zuehlke via lists.sync.global <czuehlke=drwholdings.com@...>:
We’d like to discuss it today during the call please.
From my perspective, requiring the tx to be conducted with a featured app introduces a layer of protection from participants trying to game the construct.
For instance, could someone deploy an app to the network that effectively does nothing, and connect their validator to it to generate the transactions. Given the open and decentralized nature of Canton, I think this could eventually happen. Requiring the app to be designated as Featured would in theory prevent that. Open to other ideas though.
Chris
On May 23, 2025, at 3:51 AM, Fernando Vazquez <fernando.vazquez@...> wrote:
Hi Chris and Chris, Could you elaborate and what the rationale for making the distinction below would be? We were debating if we should note those tx are with featured apps or not. On a different note, I noticed that this draft CIP was not added
Hi Chris and Chris,
Could you elaborate and what the rationale for making the distinction below would be?
We were debating if we should note those tx are with featured apps or not.
On a different note, I noticed that this draft CIP was not added to today's agenda. Do you want to present it today or would you rather go through another round of discussion?
Best regards,
Fernando
2025年5月23日(金) 14:34 Yiannis Varelas via lists.sync.global <y=fivenorth.io@...>:
I echo Kinga’s point. I think that should be unrelated to whether the app/subscription is featured or not. Validators should be free to choose what apps they subscribe to.
Y.
On Fri, May 23, 2025 at 00:34 Chris Matturri <chris@...<mailto:chris@...>> wrote:
Hi Kinga, thanks for taking a read!
That would still fall under this current proposal as we are saying 2 tx/ epoch. The subscription to apps would count as such. We were debating if we should note those tx are with featured apps or not.
On Thu, May 22, 2025 at 5:30 PM Kinga Bosse via lists.sync.global <kinga.bosse=mpch.com@...> wrote:
Hi Chris,
Many thanks. I broadly agree with all of this. However, I would like to point out that participation in the network should also contemplate the active subscription to apps that are aligned with Canton. I propose we also consider running/ subscribing to apps as participation as it helps adoption.
I would love to hear your thoughts.
Best,
Kinga
<https://urldefense.com/v3/__https://aka.ms/o0ukef__;!!EvhwMw!TyC8VLIy17z4u5qLndvOPAqtv7w6HAzin3hoDkoSqqul8eYEht3_axe032xHlrbm1hmBPtNH86J9ZLbhPIvErBp6nYKwym4Z$>
________________________________
From: cip-discuss@... <cip-discuss@...> on behalf of Chris Zuehlke via lists.sync.global <czuehlke=drwholdings.com@...>
Sent: Thursday, May 22, 2025 5:15:40 PM
To: cip-discuss@... <cip-discuss@...>
Subject: Re: [cip-discuss] Potential CIP - Tx Requirements for Validator Rewards
All - We have been working with Proof Group to formalize the CIP on this topic. We are ready to present it to the group for discussion. Please see the below, we would like to discuss it during tomorrow's tokenomics call. Happy to walk through during the call for anyone that doesn't have time to review it beforehand.
Thanks
Chris
=========
Abstract
Create a new “Active” Validator classification to incentivize Validators participating in on-chain transactions in Canton Mainnet.
Specification
This CIP proposes a mechanism and implementation to establish “Participating” and “Passive” Validators on the Canton Network. This classification will be used to determine a Validator’s cap for Liveness Rewards such that Participating Validators will have a higher cap than Passive Validators.
This CIP also proposes a governance process by which the “Participating” and “Passive” designation will be made for a Validator on the Canton Network.
In the remainder of this specification we will provide the details necessary to understand the proposed implementation.
Participating and Passive Validator Definition and Details
* A “Participating” Validator is a Validator on the Canton Network that demonstrates significant participation in the ecosystem by engaging in at least X transactions on average on on-chain per epoch. Initially, X should be equal to 2. Going forward, the value of X shall be determined by standard governance procedures.
* A “Passive” Validator will be defined as a Validator on the Canton Network that does not demonstrate significant participation in the ecosystem via engaging in on-chain transactions. Any Validator that engages in less than X transactions on-chain on average per epoch will be deemed to be a Passive Validator.
* For the avoidance of doubt, Validators can not be both a Participating and Passive validator at the same time, but it is possible for a single Validator to switch back and forth between Participating and Passive.
* Participating and Passive Validators build on the framework for Validators earning liveness rewards, which was laid out in CIP-0003<https://urldefense.com/v3/__https://github.com/global-synchronizer-foundation/cips/blob/87d443909f55fe16a0f2bb7fd2c0219b9905f2cf/cip-0003/CIP-0001-0002-0003.pdf__;!!EvhwMw!TyC8VLIy17z4u5qLndvOPAqtv7w6HAzin3hoDkoSqqul8eYEht3_axe032xHlrbm1hmBPtNH86J9ZLbhPIvErBp6naMMP_6I$>.
* The concept of a Participating Validator follows the precedent laid out for Featured Applications created in CIP-0047
<https://urldefense.com/v3/__https://github.com/global-synchronizer-foundation/cips/blob/87d443909f55fe16a0f2bb7fd2c0219b9905f2cf/cip-0047/cip-0047.md__;!!EvhwMw!TyC8VLIy17z4u5qLndvOPAqtv7w6HAzin3hoDkoSqqul8eYEht3_axe032xHlrbm1hmBPtNH86J9ZLbhPIvErBp6nTOzfJ1E$>
Participating and Passive Validator Liveness Rewards Caps
* We propose Participating Validator’s Liveness Reward minting rights cap remain unchanged from $570 as established in CIP-0048<https://urldefense.com/v3/__https://github.com/global-synchronizer-foundation/cips/blob/87d443909f55fe16a0f2bb7fd2c0219b9905f2cf/cip-0048/cip-0048.md__;!!EvhwMw!TyC8VLIy17z4u5qLndvOPAqtv7w6HAzin3hoDkoSqqul8eYEht3_axe032xHlrbm1hmBPtNH86J9ZLbhPIvErBp6nbxUy17n$>. For use later, we call this variable Y.
* We propose decreasing the cap on Passive Validators minting rights associated with Liveness Rewards. The reduction will be defined as:
* Passive Validator Liveness Rewards Cap = Y/Z.
* We propose Z should initially equal 10. Going forward, the value of Z shall be determined by standard governance procedures.
Implementation
* Follow the logic of CIP-0048 <https://urldefense.com/v3/__https://github.com/global-synchronizer-foundation/cips/blob/87d443909f55fe16a0f2bb7fd2c0219b9905f2cf/cip-0048/cip-0048.md__;!!EvhwMw!TyC8VLIy17z4u5qLndvOPAqtv7w6HAzin3hoDkoSqqul8eYEht3_axe032xHlrbm1hmBPtNH86J9ZLbhPIvErBp6nbxUy17n$> to define the Participating & Passive Validators Liveness rewards cap such that:
* Participating Validators will maintain their existing Liveness Rewards cap of $570.
* Introduce a variable to define the divisor used to determine Passive Validator Liveness Rewards cap as a function of the Participating Validator Liveness Rewards cap as defined above.
* Set this variable to equal 10.
* Establish a Liveness Rewards computation process as follow:
* As already exists, first allocate Validator Activity mint rewards.
* For any remaining Validator reward mints, earmark them for Liveness Rewards.
* Compute each Validator’s potential Liveness minting rewards earned, up to their cap.
* Add up all potential Liveness minting rewards earned for all Validators:
* If the total potential minting rewards is less than or equal to the rewards remaining to be allocated for Liveness, distribute them to the relevant Validators.
* If the total potential minting rewards is greater than the remaining rewards to be allocated for Liveness:
* Determine each Validator’s pro-rata share of the remaining rewards.
* Distribute rewards based on this pro-rata allocation.
Approval Process
* Grant the authority to determine if a Validator is a Participating or a Passive Validators to the Tokenomics Committee similar to what is outlined in CIP-0021<https://urldefense.com/v3/__https://github.com/global-synchronizer-foundation/cips/blob/87d443909f55fe16a0f2bb7fd2c0219b9905f2cf/cip-0021/cip-0021.pdf__;!!EvhwMw!TyC8VLIy17z4u5qLndvOPAqtv7w6HAzin3hoDkoSqqul8eYEht3_axe032xHlrbm1hmBPtNH86J9ZLbhPIvErBp6nWwZXbBQ$>
* Given the vast quantity of validators, the committee will make determinations for existing validators through a batched process based on the criteria listed below.
* On a go-forward basis, Validators will be established as a Passive Validator at time of deployment. The owners of the Validators may then request a review by the tokenomics committee for a potential Participating classification.
Approval Criteria
* Approval for Participating Validators should be measured objectively. To be granted Participating status, a Validator must demonstrate they:
* Conduct at least 2 transactions with Featured Applications per epoch on average during the evaluation window.
* Establish an evaluation period to be from 17 days prior to the evaluation day until 3 days prior to the evaluation day, where a day is defined by midnight eastern time to 11:59:59 PM eastern time the same day. The three day buffered between evaluation period and evaluation day is to give the GSF and Validator time to prepare the necessary data for evaluation.
* A new framework for approving Featured Validators may be adopted by the Super Validators or Tokenomics Committee at a later date after initial deployment of this functionality and the subsequent batch reviews of existing Validators is complete.
Motivation
Early in the network’s existence CIP-0003 was raised as a way to incentivize potential network participants to operate a Validator as additional use cases went live. Since then, there has been and continues to be a material growth in applications and use cases available on the network, as a result we believe the incentives should shift towards Application/Use Case participation and away from Validatory Liveness in order to avoid free-rider problems.
While there are already mechanisms in place to do this already (e.g. Activity Rewards slowly reducing the Liveness Rewards pool) the belief is that mechanism is likely slower than the current state of the network merits.
Rationale
When researching potential implementations options two approaches were considered. The first is outlined in this CIP. The second contemplated splitting Liveness Rewards into two buckets–one that tied rewards to transaction activity and one that tied rewards to validator liveness, over time the % of Liveness Rewards allocated to the first bucket would go up and rewards allocated to the second bucket would go down such that the total % across the two always equaled 100.
The decision was made to take the approach outlined in the CIP as it was possible to reuse the Featured Application logic that already exists in the network allowing for a more efficient implementation of the CIP. It also has the benefit of reusing a concept that already exists within the network rather than introducing something entirely new.
Backwards Compatibility
Potential backwards compatibility issues will continue to be monitored throughout the CIP review and implementation process. Any discovered will be raised to the group for review and to agree on any subsequent changes or actions.
Reference Implementation
To be added once there is agreement to proceed with the CIP.
Copyright
CC0-1.0: Creative Commons CC0 1.0 Universal<https://urldefense.com/v3/__https://creativecommons.org/publicdomain/zero/1.0/__;!!EvhwMw!TyC8VLIy17z4u5qLndvOPAqtv7w6HAzin3hoDkoSqqul8eYEht3_axe032xHlrbm1hmBPtNH86J9ZLbhPIvErBp6nfHb3tWK$>
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.
- All -As a follow up to the conversation last week. I wanted to share a few notes/next steps:
- The group generally agreed that over time the network should incentivize participation in transactions rather than passive validator operation. The timing of this and the mechanism for doing so continues to be discussed.
- The group generally agreed that any change here, if deemed necessary, should be signaled to network participants. Previously we've responded to that feedback with an implementation that would require non de minimis development work but the structure it would introduce should make it clear that this transition was taking place. During the call, the group thought that signaling could happen via commentary rather than a new technical mechanism thus potentially opening up alternative, lower development effort, approaches including leveraging the existing activity reward/liveness reward construct. I'm all for the more efficient approach if we believe a different type of communication for the change will be effective.
- There seemed to be more debate on this call compared to previous about the merits of increasing activity incentives while reducing liveness incentives at this point in time. Some had the opinion that now is the time to start shifting incentives, others believed there was merit in maintaining material liveness rewards now. My read on the conversation is this is more about the right pace to make these changes rather than if a change makes sense in general.
- DA agreed to propose an alternative approach to be considered. They will share their thoughts soon.
Please let me know if I missed anything.ThanksChris - toggle quoted message Show quoted texthi everyone - please see an alternative approach proposal attachedEricOn Tue, May 27, 2025 at 1:41 PM Chris Zuehlke via lists.sync.global <czuehlke=drwholdings.com@...> wrote:All -As a follow up to the conversation last week. I wanted to share a few notes/next steps:
- The group generally agreed that over time the network should incentivize participation in transactions rather than passive validator operation. The timing of this and the mechanism for doing so continues to be discussed.
- The group generally agreed that any change here, if deemed necessary, should be signaled to network participants. Previously we've responded to that feedback with an implementation that would require non de minimis development work but the structure it would introduce should make it clear that this transition was taking place. During the call, the group thought that signaling could happen via commentary rather than a new technical mechanism thus potentially opening up alternative, lower development effort, approaches including leveraging the existing activity reward/liveness reward construct. I'm all for the more efficient approach if we believe a different type of communication for the change will be effective.
- There seemed to be more debate on this call compared to previous about the merits of increasing activity incentives while reducing liveness incentives at this point in time. Some had the opinion that now is the time to start shifting incentives, others believed there was merit in maintaining material liveness rewards now. My read on the conversation is this is more about the right pace to make these changes rather than if a change makes sense in general.
- DA agreed to propose an alternative approach to be considered. They will share their thoughts soon.
Please let me know if I missed anything.ThanksChris--
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. - Noves has launched a new public Canton data studio:
ccdata.noves.fi
This was built to give Canton operators a more in-depth view of the network, parties, and asset flows.
Standout features:
- Featured app economics: rewards, earnings, traffic costs, compliance
- Compliance dashboard: transparent calculations, including for asset issuers
- Party-level analytics: asset flows, activity, and counterparties
For validators, issuers, infrastructure providers, featured apps, and institutions operating on Canton, it gives a clear view into network activity and operating conditions.
Live now: ccdata.noves.fi - Canton Foundation,
Can a Daml contract support a state flag that is both publicly observable on-chain and exclusively bound to a single counterparty or issuance event meaning that once a token enters that state, the binding is legible to any third party inspecting the contract, and the same token cannot enter the same state a second time without first exiting it through a defined release path?
Does Canton's architecture support atomic state transitions initiated by a cross-chain message from an EVM-side event specifically, where a single transaction simultaneously releases a bound state on a Canton-side contract and unlocks the underlying asset, with the trigger originating externally rather than from a Canton participant? Block Infrastructure is a new participant on the Canton Network, and we are building the compliance infrastructure layer that allows institutional adoption of Canton to scale, without importing the legacy processes and thinking that undermine the technology's core value.
Our proposition is straightforward: embed compliance within the transaction itself, not around it. We call this atomic compliance. Travel Rule obligations, sanctions screening, and compliance outcomes resolved and written to chain within the same atomic transaction that executes settlement. Compliance and finality in a single, coordinated flow. No market exposure. No sequential processing. No compromise on the mechanics that make Canton valuable.
Our infrastructure is built for institutional traffic, giving regulated entities confidence that their FATF, Travel Rule, and global sanctions obligations are met, without slowing down or fragmenting the settlement layer.
Block Infrastructure will shortly be carrying out a live demonstration to regulators and governing bodies. We are opening a limited number of places to Canton Network members to observe atomic compliance in action.
To reserve a place, please respond to this message or email: kurtis@... to confirm your attendance.
Splice release 0.6.6is ready for deployment on DevNet, and is available from the GSF
⅔ of Super Validator nodes have upgraded to this release, including the GSF Super Validator node
SV node status: https://sync.global/sv-network
Release notes: https://docs.dev.sync.global/release_notes.html
-
Splice release
0.6.4is ready for deployment on MainNet, and is available from the GSF
⅔ of Super Validator nodes have upgraded to this release, including the GSF Super Validator node
SV node status: https://sync.global/sv-network
Release notes: https://docs.sync.global/release_notes.html
-
Splice release
0.6.7is ready for deployment on DevNet, and is available from the GSF
⅔ of Super Validator nodes have upgraded to this release, including the GSF Super Validator node
SV node status: https://sync.global/sv-network
Release notes: https://docs.dev.sync.global/release_notes.html
- Daml Models from Splice 0.6.2 take effect on MainNet. Requires Splice 0.6.2 at minimum:
- MainNet: UPGRADE BEFORE 2026-06-09
Phase 3: Upgrade Global Synchronizer networks to Canton Protocol 35- All three Global Synchronizer networks will perform a Logical Synchronizer upgrade to Canton protocol Version 35.
- Minimum Splice Version for for Validators for this Upgrade: Splice 0.6.5
- Dates: (All events at 9 am US Eastern / 1300 UTC)
- LSU from protocol version (PV) 34 to 35 on DevNet:
- Topology Freeze: 2026-06-09
- Upgrade: 2026-06-10
- LSU for PV 34->35 on TestNet:
- Toplogy Freeze: 2026-06-16
- Upgrade: 2026-06-17
- LSU for PV 34->35 on MainNet:
- Toplogy Freeze: 2026-06-26
- Upgrade: 2026-06-27
App Provider Experience during Logical Synchronizer Upgrades (LSUs):- All party onboarding, package vetting and other topology transactions will pause for 24 hours before the LSU, and will resume immediately after the LSU completes.
- Daml transactions will be delayed for seconds to minutes at the moment of the LSU
- App providers should experience no other impact.
Also Coming in Phase 3:
Traffic-based App Rewards are currently expected to go live on MainNet at the end of July. Based on the current plan, this will require upgrading Validator nodes to Splice 0.6.11.- Important dates for Traffic-based App Rewards
- July 1: Dry Run of Traffic-based app rewards goes live on MainNet.
- TBD July: MainNet switches to traffic-based app rewards (final date will depend on schedules for various production trading dry runs taking place during July).
- Daml Models from Splice 0.6.2 take effect on MainNet. Requires Splice 0.6.2 at minimum:
