Mailing Lists/Potential CIP - Tx Requirements for Validator RewardsSource on lists.sync.global ↗

Potential CIP - Tx Requirements for Validator Rewards

cip-discuss16 messagesstarted 18-04-2025

Also mentions:CIP-0003 CIP-0021 CIP-0047 CIP-0048

#1Chris Zuehlke18-04-2025source ↗
All –

As the network continues to grow there is an increasing potential for the free rider problem to emerge with Validators and liveness rewards—essentially Validators collecting liveness rewards but not otherwise participating in the network. I suggest the network is upgraded to address this by shifting its focus for validator rewards from liveness to actively participating in transactions.

I’d like other’s input not only on the idea but the mechanism as well.

My current idea is to keep it relatively simple and do the following:
1. Take the current total potential per-round liveness awards for Validators and split it into two buckets.
2. Bucket 1 – Liveness Awards: Criteria to capture this award is the same as the current liveness awards.
3. Bucket 2 – Activity Awards: Criteria to capture this award is for the Validator to participate in at least X transactions per round. My suggested starting point is X = 1.
4. Per round – Bucket 1 (Liveness) represents Y% of the total potential award. My suggested starting point is Y = 5.
  
  This is awarded per round if the Validator meets the current liveness criteria.
5. Per round – Bucket 2 (Activity) represents Z% of the total potential award. My suggested starting point is Z = 95.
  
  This is awarded per round if the Validator participated in at least X transactions in that round.
6. Y + Z must always equal 100.
I haven’t reviewed the necessary code changes for this yet so it may be complex, but hopefully by working mostly within current constructs this is a rather simple change . Ideally, we could engage with one of the maintainers of the open source repositories to make the change with some guidance from others.

Please let me know your thoughts. I will write the CIP with these concepts in mind but happy to modify the details based on input.

Chris
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.
#2Jan Hoenisch21-04-2025source ↗
Hi Chris,

I agree we should tackle this problem, doesn’t seem fair for people to create a bunch of dummy apps or validators to get liveness rewards.

I am probably proposing something dumb but will try it anyways. These liveness rewards seem like an incentive to get the ecosystem kickstarted, and should reward the early on adopters.

So my thinking is, why not stop the liveness rewards all together after some date when the ecosystem should be growing organically due to the merits of the transactions and features of the network? WE can always delay the date via a vote by the GSF.

Thoughts?

Cheers,

Jan
From: cip-discuss@... <cip-discuss@...> on behalf of Chris Zuehlke via lists.sync.global <czuehlke=drwholdings.com@...>
Date: Friday, April 18, 2025 at 14:39
To: cip-discuss@... <cip-discuss@...>
Subject: [cip-discuss] Potential CIP - Tx Requirements for Validator Rewards

All –

As the network continues to grow there is an increasing potential for the free rider problem to emerge with Validators and liveness rewards—essentially Validators collecting liveness rewards but not otherwise participating in the network. I suggest the network is upgraded to address this by shifting its focus for validator rewards from liveness to actively participating in transactions.

I’d like other’s input not only on the idea but the mechanism as well.

My current idea is to keep it relatively simple and do the following:

Take the current total potential per-round liveness awards for Validators and split it into two buckets.
Bucket 1 – Liveness Awards: Criteria to capture this award is the same as the current liveness awards.
Bucket 2 – Activity Awards: Criteria to capture this award is for the Validator to participate in at least X transactions per round. My suggested starting point is X = 1.
Per round – Bucket 1 (Liveness) represents Y% of the total potential award. My suggested starting point is Y = 5.

This is awarded per round if the Validator meets the current liveness criteria.

Per round – Bucket 2 (Activity) represents Z% of the total potential award. My suggested starting point is Z = 95.

This is awarded per round if the Validator participated in at least X transactions in that round.

Y + Z must always equal 100.

I haven’t reviewed the necessary code changes for this yet so it may be complex, but hopefully by working mostly within current constructs this is a rather simple change . Ideally, we could engage with one of the maintainers of the open source repositories to make the change with some guidance from others.

Please let me know your thoughts. I will write the CIP with these concepts in mind but happy to modify the details based on input.

Chris

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.
#3Moritz Kiefer22-04-2025source ↗

Hi,

Validator liveness rewards are only issued for the remainder of the validator reward tranche per round. So as the number of validator rewards from CC transfers goes up, validator liveness rewards gradually go down which seems to solve the problem of people running validators just for the sake of getting liveness rewards.

Given that, I'm not sure we need to do anything about validator liveness rewards. We could reduce the cap if needed but I'd rather just wait until we have enough activity that this problem solves itself.

I think there is still an interesting problem that we could consider addressing: Validator rewards are only issued to the validator hosting a sender of a CC transfer. So for nodes that participate in apps that do not move CC, they do not gain validator rewards. There have been considerations to change this to issue validator rewards for all transactions proportional to the traffic costs of the transaction but it's a fairly involved change technically.

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.
#4Chris Zuehlke23-04-2025source ↗
Hey All –

Thanks for the engagement on this topic, its great to see folks getting involved! In addition to the posts here, I’ve discussed offline with others as well. I’ll do my best to categorize/summarize where there was push back on the idea then provide additional comments. If I over simplify anyone’s comments I apologize, just trying to be succinct.
1. Validator liveness incentives are an important feature to increase early adoption, reducing them could negatively impact that early adoption.
  
  I agree with the principal of this, but don’t believe this should be a reason to avoid making a change. As it stands I believe the network could benefit from two things (1) a disincentive for launching a validator and then going dormant (2) an improved incentive for active participation in transactions. For the former, I think most of us would agree there should be a mechanism to disincentivize that behavior (more on that below). For the later, this is a natural progression for network growth—I agree that validators joining the network is the first important step but an arguably more important step is for those validators to become active participants in transactions. So, for me partitioning the validator awards as I’ve proposed is a natural evolution and elegant solution to this.
2. Validator liveness rewards go down over time via few different mechanisms, so perhaps a change isn’t necessary.
  
  Yes, it is true that these will be reduced overtime, but I don’t think it will do so at a rate that disincentivizes free-riders nor will these mechanisms incentivize participation in transactions in the near term. Given there are several available apps and more being deployed soon, now seems like a great time to consider a change.
3. Continuing to increase decentralization and diversity of infrastructure operators and network participants is priority one, and validators with strong incentives help with this.
  
  Agreed, but again not a reason to avoid a change. Rather, perhaps it’s a debate about the rate at which the incentive distribution across liveness vs. txs changes. I also think there are fairly light lift ways to participate in a tx per round a this point so this isn’t a large concern in practice.
4. Is stopping the liveness awards at a specific date in the future a better approach?
  
  Perhaps, but if we are going to go that route, why not take the opportunity to build an incentive mechanism for the next phase of participation by validators (txs) at the same time while gaining a significant amount of flexibility for incentives? If we go with the two bucket approach then the network could slowly transition the distribution over time via governance in ways which may be more optimal.
Interestingly, I’ve also received feedback highlighting that some current builders are finding it difficult to transact in Canton coin. Perhaps the build is difficult, perhaps their customers don’t want to us CC yet, etc. I think aligning incentives for validators to txs over time could go a long way to addressing this concern.

Bottom line, for me the underlying question isn’t if, it is when and how should the incentive evolve. What I proposed, I believe, can address all of these comments simultaneously. First, adopt the principal that incentives tied to joining the network as Validator are distributed in two buckets (1) operating the validator and (2) using your validator to participate in transactions.

From there its a debate on the variables. Perhaps tomorrow its 100% in (1) and 0% in (2) and wait a bit before voting to change that distribution in recognition of your comments. Or, maybe on go-live its 90% in (1) and 10% in (2) to indicate the direction of this change but do so slowly. Or the change can be more substantial on go-live. Either way, the underlying principal is established and the dynamic mechanism is now available for future votes. I think a larger change day one is the correct approach, but open to debate.

Similarly, there is a variable on number of transactions. We could start with the smallest lift possible—one CC-included tx per round to qualify. There are multiple applications live (or soon to be live) in the network to transact with so meeting this requirement should be relatively easy for anyone that has a non-zero level of engagement.

I welcome any additional thoughts. My biggest take away for drafting the CIP thus far is that perhaps two CIPs are merited—one to introduce the principal/mechanism and one to set the award allocation % per bucket.

Thanks!

Chris
toggle quoted message Show quoted text

From: cip-discuss@... <cip-discuss@...> On Behalf Of Moritz Kiefer via lists.sync.global
Sent: Tuesday, April 22, 2025 2:58 AM
To: cip-discuss@...
Subject: [ext] Re: [cip-discuss] Potential CIP - Tx Requirements for Validator Rewards

Hi, Validator liveness rewards are only issued for the remainder of the validator reward tranche per round. So as the number of validator rewards from CC transfers goes up, validator liveness rewards gradually go down which seems to solve the

Hi,

Validator liveness rewards are only issued for the remainder of the validator reward tranche per round. So as the number of validator rewards from CC transfers goes up, validator liveness rewards gradually go down which seems to solve the problem of people running validators just for the sake of getting liveness rewards.

Given that, I'm not sure we need to do anything about validator liveness rewards. We could reduce the cap if needed but I'd rather just wait until we have enough activity that this problem solves itself.

I think there is still an interesting problem that we could consider addressing: Validator rewards are only issued to the validator hosting a sender of a CC transfer. So for nodes that participate in apps that do not move CC, they do not gain validator rewards. There have been considerations to change this to issue validator rewards for all transactions proportional to the traffic costs of the transaction but it's a fairly involved change technically.

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.

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.
#5Jan Hoenisch24-04-2025source ↗
Hi Chris,

An interesting corollary model is the tape revenue share from equity exchanges. So any exchange participant that executes on the exchange and it creates a print on the consolidated tape, gets a revenue share from that exchange when the exchange sells that data.

Best,

Jan
From: cip-discuss@... <cip-discuss@...> on behalf of Chris Zuehlke via lists.sync.global <czuehlke=drwholdings.com@...>
Date: Wednesday, April 23, 2025 at 18:24
To: cip-discuss@... <cip-discuss@...>
Subject: Re: [cip-discuss] Potential CIP - Tx Requirements for Validator Rewards

Hey All –

Thanks for the engagement on this topic, its great to see folks getting involved! In addition to the posts here, I’ve discussed offline with others as well. I’ll do my best to categorize/summarize where there was push back on the idea then provide additional comments. If I over simplify anyone’s comments I apologize, just trying to be succinct.

Validator liveness incentives are an important feature to increase early adoption, reducing them could negatively impact that early adoption.

I agree with the principal of this, but don’t believe this should be a reason to avoid making a change. As it stands I believe the network could benefit from two things (1) a disincentive for launching a validator and then going dormant (2) an improved incentive for active participation in transactions. For the former, I think most of us would agree there should be a mechanism to disincentivize that behavior (more on that below). For the later, this is a natural progression for network growth—I agree that validators joining the network is the first important step but an arguably more important step is for those validators to become active participants in transactions. So, for me partitioning the validator awards as I’ve proposed is a natural evolution and elegant solution to this.

Validator liveness rewards go down over time via few different mechanisms, so perhaps a change isn’t necessary.

Yes, it is true that these will be reduced overtime, but I don’t think it will do so at a rate that disincentivizes free-riders nor will these mechanisms incentivize participation in transactions in the near term. Given there are several available apps and more being deployed soon, now seems like a great time to consider a change.

Continuing to increase decentralization and diversity of infrastructure operators and network participants is priority one, and validators with strong incentives help with this.

Agreed, but again not a reason to avoid a change. Rather, perhaps it’s a debate about the rate at which the incentive distribution across liveness vs. txs changes. I also think there are fairly light lift ways to participate in a tx per round a this point so this isn’t a large concern in practice.

Is stopping the liveness awards at a specific date in the future a better approach?

Perhaps, but if we are going to go that route, why not take the opportunity to build an incentive mechanism for the next phase of participation by validators (txs) at the same time while gaining a significant amount of flexibility for incentives? If we go with the two bucket approach then the network could slowly transition the distribution over time via governance in ways which may be more optimal.

Interestingly, I’ve also received feedback highlighting that some current builders are finding it difficult to transact in Canton coin. Perhaps the build is difficult, perhaps their customers don’t want to us CC yet, etc. I think aligning incentives for validators to txs over time could go a long way to addressing this concern.

Bottom line, for me the underlying question isn’t if, it is when and how should the incentive evolve. What I proposed, I believe, can address all of these comments simultaneously. First, adopt the principal that incentives tied to joining the network as Validator are distributed in two buckets (1) operating the validator and (2) using your validator to participate in transactions.

From there its a debate on the variables. Perhaps tomorrow its 100% in (1) and 0% in (2) and wait a bit before voting to change that distribution in recognition of your comments. Or, maybe on go-live its 90% in (1) and 10% in (2) to indicate the direction of this change but do so slowly. Or the change can be more substantial on go-live. Either way, the underlying principal is established and the dynamic mechanism is now available for future votes. I think a larger change day one is the correct approach, but open to debate.

Similarly, there is a variable on number of transactions. We could start with the smallest lift possible—one CC-included tx per round to qualify. There are multiple applications live (or soon to be live) in the network to transact with so meeting this requirement should be relatively easy for anyone that has a non-zero level of engagement.

I welcome any additional thoughts. My biggest take away for drafting the CIP thus far is that perhaps two CIPs are merited—one to introduce the principal/mechanism and one to set the award allocation % per bucket.

Thanks!

Chris
toggle quoted message Show quoted text

From: cip-discuss@... <cip-discuss@...> On Behalf Of Moritz Kiefer via lists.sync.global
Sent: Tuesday, April 22, 2025 2:58 AM
To: cip-discuss@...
Subject: [ext] Re: [cip-discuss] Potential CIP - Tx Requirements for Validator Rewards

Hi, Validator liveness rewards are only issued for the remainder of the validator reward tranche per round. So as the number of validator rewards from CC transfers goes up, validator liveness rewards gradually go down which seems to solve the

Hi,

Validator liveness rewards are only issued for the remainder of the validator reward tranche per round. So as the number of validator rewards from CC transfers goes up, validator liveness rewards gradually go down which seems to solve the problem of people running validators just for the sake of getting liveness rewards.

Given that, I'm not sure we need to do anything about validator liveness rewards. We could reduce the cap if needed but I'd rather just wait until we have enough activity that this problem solves itself.

I think there is still an interesting problem that we could consider addressing: Validator rewards are only issued to the validator hosting a sender of a CC transfer. So for nodes that participate in apps that do not move CC, they do not gain validator rewards. There have been considerations to change this to issue validator rewards for all transactions proportional to the traffic costs of the transaction but it's a fairly involved change technically.

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.

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.
#6Chris Zuehlke29-04-2025source ↗
Jan - I agree, a similar idea of aligning incentives on participation. Thanks for sharing!

All - We've continued to consider/discuss this CIP. Base on those discussions, it seems the focus is on two things:
1. The pace at which the incentive alignment changes for Validators. I see that as a variable to the underlying mechanism change and suggest we focus on the mechanism for now. When the time comes for the CIP we will propose a first step to take.
2. The mechanism that should be introduced to address the incentive structure change.
During my conversations for (2), an alternative approach was suggested: Rather than use what I originally proposed (a % split between liveness and per-round tx participation), the idea of a "Feature" validator was floated. Similar to featured applications, this would establish a base line incentive structure for validators and then a "featured" incentive structure for those validators that are particularly active on the network. A CIP could introduce what the featured multiplier would be.

Part of the rationale behind this was that it may be easier to implement since it may be able to use existing code from Featured Apps to expedite the implementation. We won't know for sure until a technical feasibility analysis is done.

As a next step, we'd like to work with a group of engineers to do this analysis and, based on the findings, initiate a formal CIP. We will begin this work, likely coordinating with a code repo maintainer (will let them comment) and report back prior to initiating the CIP.

In the meantime, if you have any thoughts about the "featured" validator approach vs. the % split approach please let us know.

Thanks

Chris
#7Chris Matturri30-04-2025source ↗
Chris- thank you for sharing!

Proof Group is one of the repo maintainers and happy to volunteer to help out to figure out the best path forward on a 'featured validator' vs % split approach.

At a high level we agree that as the ecosystem continues to mature we should try to incentive validators to participate in more onchain transactions as opposed to just earning the base liveness rewards.

Look forward to digging in more here as well and sharing our findings with the other SVs.

toggle quoted message Show quoted text
On Tue, Apr 29, 2025 at 4:47 PM Chris Zuehlke via lists.sync.global <czuehlke=drwholdings.com@...> wrote:
Jan - I agree, a similar idea of aligning incentives on participation. Thanks for sharing!

All - We've continued to consider/discuss this CIP. Base on those discussions, it seems the focus is on two things:

The pace at which the incentive alignment changes for Validators. I see that as a variable to the underlying mechanism change and suggest we focus on the mechanism for now. When the time comes for the CIP we will propose a first step to take.

The mechanism that should be introduced to address the incentive structure change.

During my conversations for (2), an alternative approach was suggested: Rather than use what I originally proposed (a % split between liveness and per-round tx participation), the idea of a "Feature" validator was floated. Similar to featured applications, this would establish a base line incentive structure for validators and then a "featured" incentive structure for those validators that are particularly active on the network. A CIP could introduce what the featured multiplier would be.

Part of the rationale behind this was that it may be easier to implement since it may be able to use existing code from Featured Apps to expedite the implementation. We won't know for sure until a technical feasibility analysis is done.

As a next step, we'd like to work with a group of engineers to do this analysis and, based on the findings, initiate a formal CIP. We will begin this work, likely coordinating with a code repo maintainer (will let them comment) and report back prior to initiating the CIP.

In the meantime, if you have any thoughts about the "featured" validator approach vs. the % split approach please let us know.

Thanks

Chris
#8Chris Zuehlke22-05-2025source ↗
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 3.
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:
- 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:
- Establish a Liveness Rewards computation process as follow:
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:
- 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
#9Kinga Bosse22-05-2025source ↗
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
toggle quoted message Show quoted text
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 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
#10Chris Matturri22-05-2025source ↗
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.

toggle quoted message Show quoted text
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 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 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
#11Yiannis Varelas23-05-2025source ↗
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.

toggle quoted message Show quoted text
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 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 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
#12Fernando Vazquez23-05-2025source ↗
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@...> 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 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 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
#13Chris Zuehlke23-05-2025source ↗

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
toggle quoted message Show quoted text

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

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.
#14Fernando Vazquez23-05-2025source ↗

Done. I just added it.

2025年5月23日(金) 21:25 Chris Zuehlke via lists.sync.global <czuehlke=drwholdings.com@...>:
toggle quoted message Show quoted text

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.
#15Chris Zuehlke27-05-2025source ↗
All -

As a follow up to the conversation last week. I wanted to share a few notes/next steps:
1. 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.
2. 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.
3. 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.
4. DA agreed to propose an alternative approach to be considered. They will share their thoughts soon.
Please let me know if I missed anything.

Thanks

Chris
#16Eric Saraniecki31-05-2025source ↗
hi everyone - please see an alternative approach proposal attached

Eric

toggle quoted message Show quoted text
On 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.

Thanks

Chris
--
W. Eric Saraniecki
Co-founder / +1 773 719 1983
Digital Asset, creators of Daml

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.

Potential CIP - Tx Requirements for Validator Rewards

Abstract

Specification

Abstract

Specification

Abstract

Specification

Abstract

Specification

Abstract

Specification