CIP-0096: Remove Liveness Rewards from Validator Rewards Pool | CIP Discussion

Andrew BryanOriginal post

Dec 12, 2025

Hi All,

Per discussion in last week’s Foundation Tokenomics Committee working group, please see below a draft CIP from Cumberland to remove liveness rewards from the validator rewards pool (also attached as a Word document). We welcome any feedback.

Canton Improvement Proposal: Removing Liveness Rewards from Validator Rewards Pool

Abstract

As the network continues to grow, there is an increasing potential for the free rider problem to emerge with Validators and liveness rewards; Validators can collect liveness rewards as incentives from the network without otherwise participating in the network and adding utility.

To mitigate this and encourage participation among validators operating on the network, we suggest adjusting the Validator liveness rewards cap and burning unminted Validator rewards while leaving other aspects of Validator rewards unchanged.

The reduction in liveness rewards would happen over a 30 day period following CIP approval, following the below schedule:

On CIP Approval: Liveness rewards set to 50% of current levels
+15 Days from CIP Approval: Liveness rewards set to 25% of current levels
+30 Days from CIP Approval: Liveness rewards set to 0

New values in the Canton Coin DSO configuration would be set as follows for each stage:

On CIP Approval: Validator Liveness Reward Cap = $2.5
+15 Days from CIP Approval: Validator Liveness Reward Cap = $1.25
+30 Days from CIP Approval: Validator Liveness Reward Cap = $0

Specification

Updating Liveness Reward Caps

Super Validator node operators will perform 3 on-chain votes to make the following changes.

Vote 1 - Effective Immediately:

Change
issuanceCurve.futureValues.0._2.optValidatorFaucetCap,
issuanceCurve.futureValues.1._2.optValidatorFaucetCap,
issuanceCurve.futureValues.2._2.optValidatorFaucetCap,
issuanceCurve.futureValues.3._2.optValidatorFaucetCap

From 570

To 2.5

On DevNet, followed by TestNet and then MainNet.

Vote 2 - Effective 15 days after CIP approval:

Change
issuanceCurve.futureValues.0._2.optValidatorFaucetCap,
issuanceCurve.futureValues.1._2.optValidatorFaucetCap,
issuanceCurve.futureValues.2._2.optValidatorFaucetCap,
issuanceCurve.futureValues.3._2.optValidatorFaucetCap

From 2.5

To 1.25

On DevNet, followed by TestNet and then MainNet.

Vote 3 - Effective 30 days after CIP approval:

Change
issuanceCurve.futureValues.0._2.optValidatorFaucetCap,
issuanceCurve.futureValues.1._2.optValidatorFaucetCap,
issuanceCurve.futureValues.2._2.optValidatorFaucetCap,
issuanceCurve.futureValues.3._2.optValidatorFaucetCap

From 1.25

To 0

On DevNet, followed by TestNet and then MainNet.

Burning Unminted CC

Unminted CC from the Validator rewards pool will be burned by Super Validators every 30 days.

Other Impacts

This CIP will also supersede work to be done as part of CIP-0073 to allow allocating liveness rewards to non-operating parties. As a result, no additional changes will be made to allow granting of a ValidatorLicense with a default weight to an arbitrary party. For the avoidance of doubt, functionality described in CIP-0073 regarding allowing a party to create a MintingDelegation contract will not be impacted by this CIP.

Motivation

CIP 0003 was initially raised to provide incentives to operate necessary infrastructure to interact with the network and offset the initial friction associated with engaging in activity on the network. As an initial set of users has onboarded and a number of use cases have gone live, the network should shift its incentive structure toward active participation.

Adjusting the Liveness cap and burning of unminted Validator rewards allows the Super Validators to signal a change in these incentives while removing the incentive to run infrastructure without active participation.

Rationale

Over the period 11/8-12/7, roughly 70% of validator rewards minted from the validator minting pool are associated with liveness rewards. The network has provided infrastructure operators with 132M CC of liveness incentives during this time. Given the growth of on-chain use cases and on-chain activity, combined with a substantial queue of new validators onboarding to the network, these incentives are likely to be no longer needed to bootstrap initial operators on the network.

As the ecosystem evolves and as more avenues emerge for acquiring Canton Coin to use to purchase traffic, Validator doing work on the network and acquiring Canton Coin via liveness rewards also provide less utility to the network as a means of facilitating participation.

Backwards Compatibility

This CIP requires no new Daml models and no other breaking changes, so it will be fully backwards compatible.

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.

CIP 00XX - Removing Liveness Rewards.docx

Sam Hassan

Dec 15, 2025

What will be the remaining incentives for validators to run the infra and maintain it if the liveness rewards go to zero? I'm concerned removing this completely gives no incentive for passive validators (which are a part of every network)

Luka

Dec 15, 2025

Hello!

This proposal does not seem well thought to me. First of all, Canton is (supposedly) built upon network participation - that includes validators as well. Running a validator does require infra and devops as well. The rationale is wrong if you think validators will onboard and run infra for free or at a loss (unless they are selective on which app they onboard as many have expensive subscriptions now compared to rewards shared). SVs dont do it right? They even get paid nicely for milestones on top.

Theres basically three types of validators we see on Canton:

- pure infra centric validators
- validators that support existing, onboard new apps
- validators that are actually developers building an app

You are now taking away 100% of liveness rewards for all 3 types, even though that seems undeserving. Even pure passive validators provide support and decentralization to Canton, so I would assume it would have been better to just lower them a bit instead. Validators that do support these apps are also paying large subscription costs to do so, some that might not even break even anymore, so completely removing liveness rewards makes even less sense.

What could have been done instead, in my opinion, is the following:

- better screening of all the operators that request extra slots (there are many that just request them for liveness rewards, even amongst SVs)
- better screening of apps (there are plenty that in my opinion have no place being a featured app, there are HUGE differences between the quality of these apps)
- some apps are not even apps but instead just some info portals so i am not sure why they deserve to be a featured app with liveness rewards?

I dont think some of the ones mentioned above are deserving of liveness rewards/featured app status. If you want to control emissions, be at least thorough. I thought the point of onboarding many validators is to enhance network security and decentralization, not for a few entities to grab a lot of validator slots just because there was no thorough review why. Now all validators will be punished for that it seems.

If you want to overhaul that, you should probably start with all these large entities running multiple validators. While you are at it, maybe also SV rewards should be lowered then?

I will not claim I know every single aspect as to why this proposal was put up, but what i do know is that it seems poorly thought out and very narrow way of trying to patch up past mistakes. I would think having an even larger decentralized set of validators, with most of them supporting ecosystem apps, would be far more valuable than a few entities running something like half the active validators. If anything is misaligned here, i would say its that. The free rider problem you mention in the OP is majorly impacted by all those entities that grabbed a ton of validator slots just because they could. I am 100% sure none of the entities needed as many as they requested and received, to support Canton and its ecosystem apps. Maybe that is where you should start instead and think of a better way to stabilize inflation.

Lowering would be fine, making it dependant on if validators support apps also fine. Completely cutting just seems like an easy way out of mistakes that were made with granting too many slots to free riders that also sit as SVs. Also ps: the queue is long because most of the slots were taken by node operator providers.

I wanted to say something about this process earlier but i didnt, because i kind of hoped that there was sufficient screening done before allowing multiple slots to some, but it seems that was not the case as is now evident with this CIP. Overall, SUPER disappointed at the CIP along with how the slots were handled before.

For full disclosure, we run 1 mainnet validator node and support many apps through it and we are looking to support more and do not need extra slots for that. If we ever will, it will be because of legitimate reasons and clients that we will be able to prove.

Eric Saraniecki

Dec 15, 2025

Thank you Sam and Luka for submitting comments on this proposal.

A few added bits of context for those looking at the proposal.

Canton Validators do not provide validation for the network _generically_. Validators provide validation for smart contract updates where a user they host is a party to the smart contract update.

Imagine the following example:

Asset Issuer (AI) mints TOKEN on the network and centrally validates transfers
Investor (INV) receives TOKEN from Asset Issuer as part of some primary distribution of the asset

The only two Validators, in the world, that validate that transfer of TOKEN from AI to INV are the Validators hosting AI and INV. This is how privacy is achieved in the Canton Network.

Now, there are plenty of examples where AI is actually a decentralized party. But, even then, those parties are specifically chosen and are always part of validation of the smart contract updates on that asset.

To put a finer point on this, yes, there are passive Validators in every network but in Canton passive Validators add limited network value unless they end up assisting in processing transactions on behalf of parties or apps they host. They serve as a potential host for parties on the network but if there are no users willing to host their party with that operator and if those hosted parties are not acting on the network then that Validator is not doing any work.

Validators were always designed to earn their rewards from Activity Rewards.

Liveness was added in CIP-0003 as a solution to a bootstrapping problem. In order to have enough CC to transact in the Network and earn Activity Rewards, CC needed to be distributed to those required to burn it.

As early as April 2025, there were serious discussions around removing Liveness, amplifying Validator Activity Rewards, qualifying Validators for Liveness via various mechanisms, etc. At that time, CC was still too hard to acquire on the market for common users and those proposals were tabled at that time.

Today, CC is easily acquired - onchain, embedded in wallets, in CEXs, broadly OTC, and more. Returning to the original, activity-based distribution mechanism for Validators is a logical thing to consider given the reason Liveness was introduced is no longer true.

Fair launching a network and token presents a number of cold start problems that most networks are not accustomed to dealing with and this was one mechanism born from those frictions.

WRT comments about Featured Apps, there has been a lot of action taken there recently and more to come in improving those processes and designations. That is being considered independently of the Liveness discussion.

WRT SV rewards - they are being ‘double halved’ in a few short weeks through the normal issuance schedule. Rewards have gone through quite an evolution there over the past 6 months - now SV rewards are entirely gated on material outcomes for the network. Failing to meet the milestones means that SV will walk away without those earnings.

If this CIP passes, the full Validator Reward pool can still be minted; it just has to be issued on the back of Activity.

As with any endeavor, processes can and must improve. Feedback is always welcome and taken seriously.

Show quoted message

On Mon, Dec 15, 2025 at 1:01 PM luka via lists.sync.global <luka=pops.one@...> wrote:

Hello!

This proposal does not seem well thought to me. First of all, Canton is (supposedly) built upon network participation - that includes validators as well. Running a validator does require infra and devops as well. The rationale is wrong if you think validators will onboard and run infra for free or at a loss (unless they are selective on which app they onboard as many have expensive subscriptions now compared to rewards shared). SVs dont do it right? They even get paid nicely for milestones on top.

Theres basically three types of validators we see on Canton:

- pure infra centric validators
- validators that support existing, onboard new apps
- validators that are actually developers building an app

You are now taking away 100% of liveness rewards for all 3 types, even though that seems undeserving. Even pure passive validators provide support and decentralization to Canton, so I would assume it would have been better to just lower them a bit instead. Validators that do support these apps are also paying large subscription costs to do so, some that might not even break even anymore, so completely removing liveness rewards makes even less sense.

What could have been done instead, in my opinion, is the following:

- better screening of all the operators that request extra slots (there are many that just request them for liveness rewards, even amongst SVs)
- better screening of apps (there are plenty that in my opinion have no place being a featured app, there are HUGE differences between the quality of these apps)
- some apps are not even apps but instead just some info portals so i am not sure why they deserve to be a featured app with liveness rewards?

I dont think some of the ones mentioned above are deserving of liveness rewards/featured app status. If you want to control emissions, be at least thorough. I thought the point of onboarding many validators is to enhance network security and decentralization, not for a few entities to grab a lot of validator slots just because there was no thorough review why. Now all validators will be punished for that it seems.

If you want to overhaul that, you should probably start with all these large entities running multiple validators. While you are at it, maybe also SV rewards should be lowered then?

I will not claim I know every single aspect as to why this proposal was put up, but what i do know is that it seems poorly thought out and very narrow way of trying to patch up past mistakes. I would think having an even larger decentralized set of validators, with most of them supporting ecosystem apps, would be far more valuable than a few entities running something like half the active validators. If anything is misaligned here, i would say its that. The free rider problem you mention in the OP is majorly impacted by all those entities that grabbed a ton of validator slots just because they could. I am 100% sure none of the entities needed as many as they requested and received, to support Canton and its ecosystem apps. Maybe that is where you should start instead and think of a better way to stabilize inflation.

Lowering would be fine, making it dependant on if validators support apps also fine. Completely cutting just seems like an easy way out of mistakes that were made with granting too many slots to free riders that also sit as SVs. Also ps: the queue is long because most of the slots were taken by node operator providers.

I wanted to say something about this process earlier but i didnt, because i kind of hoped that there was sufficient screening done before allowing multiple slots to some, but it seems that was not the case as is now evident with this CIP. Overall, SUPER disappointed at the CIP along with how the slots were handled before.

For full disclosure, we run 1 mainnet validator node and support many apps through it and we are looking to support more and do not need extra slots for that. If we ever will, it will be because of legitimate reasons and clients that we will be able to prove.

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.

Luka

Dec 15, 2025

Hi Eric,

thanks for the answers! I am (mostly) aware of everything, but maybe im misunderstanding what you are trying to do here. You wrote

"If this CIP passes, the full Validator Reward pool can still be minted; it just has to be issued on the back of Activity." - does this mean the whole liveness rewards just translate to activity rewards, if validators are hosting apps etc? If so, that is indeed much better.

I would still comment two things though, assuming my understanding of your above sentence is correct:

- there should (imo) still be some smaller liveness rewards as its actually quite expensive to subscribe to apps and host them (we would not be able to host as many as we do without the liveness rewards since its simply too expensive to subscribe to them)
- i would seriously go through all node operators that got granted multiple validator licenses, as mentioned in the OP, you will find a lot of free riders right there, unfortunately; this also leads to my second part of this point - you didnt really onboard that many different validators, just a bunch of same entities who were spinning up nodes taking advantage of liveness rewards

I think the first point warrants a consideration, but the second one should be a must do, asap, as the process was flawed and resulted with a lot less unique validators onboarded than we would all like to see. The sad thing is just that some of these are also SVs so they likely already extracted millions, some for some half decent work/apps.

Eric Saraniecki

Dec 15, 2025

The algorithm for Validator Rewards is (roughly) as follows:

1. Calculate all Activity Rewards first

2. If there is any remainder, split pro-rata across the Validators online as Liveness

This proposal recommends removing #2. #2 is naturally crowded out over time and this CIP says 'not necessary anymore, no need to wait for the natural outcome'

I would welcome a conversation offline about the expenses you are carrying to host apps to understand that point better

Show quoted message

On Mon, Dec 15, 2025 at 5:07 PM luka via lists.sync.global <luka=pops.one@...> wrote:

Hi Eric,

thanks for the answers! I am (mostly) aware of everything, but maybe im misunderstanding what you are trying to do here. You wrote
"If this CIP passes, the full Validator Reward pool can still be minted; it just has to be issued on the back of Activity." - does this mean the whole liveness rewards just translate to activity rewards, if validators are hosting apps etc? If so, that is indeed much better.

I would still comment two things though, assuming my understanding of your above sentence is correct:

- there should (imo) still be some smaller liveness rewards as its actually quite expensive to subscribe to apps and host them (we would not be able to host as many as we do without the liveness rewards since its simply too expensive to subscribe to them)
- i would seriously go through all node operators that got granted multiple validator licenses, as mentioned in the OP, you will find a lot of free riders right there, unfortunately; this also leads to my second part of this point - you didnt really onboard that many different validators, just a bunch of same entities who were spinning up nodes taking advantage of liveness rewards

I think the first point warrants a consideration, but the second one should be a must do, asap, as the process was flawed and resulted with a lot less unique validators onboarded than we would all like to see. The sad thing is just that some of these are also SVs so they likely already extracted millions, some for some half decent work/apps.

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.

Andrew Bryan

Dec 21, 2025

Hi All,

Thank you for all the feedback on this CIP. Cumberland has made several edits based on feedback we’ve received and would like to share an updated draft. A summary of the changes:

Extending the wind-down of liveness rewards to allow more time for adjustment to new tokenomics. After the initial 30 day timeline, we have added a 60-day period where liveness rewards will be reduced to a maximum of $0.60 per round for each validator.
We have removed the burning of un-minted CC from the validator rewards pool

Canton Improvement Proposal: Removing Liveness Rewards from Validator Rewards Pool

Abstract

As the network continues to grow, there is an increasing potential for the free rider problem to emerge with Validators and liveness rewards; Validators can collect liveness rewards as incentives from the network without otherwise participating in the network and adding utility.

To mitigate this and encourage participation among validators operating on the network, we suggest adjusting the Validator liveness rewards cap while leaving other aspects of Validator rewards unchanged.

The reduction in liveness rewards would happen over a 30 day period following CIP approval, following the below schedule:

On CIP Approval: Liveness rewards set to 50% of current levels
+15 Days from CIP Approval: Liveness rewards set to 25% of current levels
+30 Days from CIP Approval: Liveness rewards set to $0.60
+90 Days from CIP Approval: Liveness rewards set to 0

New values in the Canton Coin DSO configuration would be set as follows for each stage:

On CIP Approval: Validator Liveness Reward Cap = $2.5
+15 Days from CIP Approval: Validator Liveness Reward Cap = $1.25
+30 Days from CIP Approval: Validator Liveness Reward Cap = $0.60
+90 Days from CIP Approval: Validator Liveness Reward Cap = $0

Specification

Updating Liveness Reward Caps

Super Validator node operators will perform 3 on-chain votes to make the following changes.

Vote 1 - Effective Immediately:

Change
issuanceCurve.futureValues.0._2.optValidatorFaucetCap,
issuanceCurve.futureValues.1._2.optValidatorFaucetCap,
issuanceCurve.futureValues.2._2.optValidatorFaucetCap,
issuanceCurve.futureValues.3._2.optValidatorFaucetCap

From 570

To 2.5

On DevNet, followed by TestNet and then MainNet.

Vote 2 - Effective 15 days after CIP approval:

Change
issuanceCurve.futureValues.0._2.optValidatorFaucetCap,
issuanceCurve.futureValues.1._2.optValidatorFaucetCap,
issuanceCurve.futureValues.2._2.optValidatorFaucetCap,
issuanceCurve.futureValues.3._2.optValidatorFaucetCap

From 2.5

To 1.25

On DevNet, followed by TestNet and then MainNet.

Vote 3 - Effective 30 days after CIP approval:

Change
issuanceCurve.futureValues.0._2.optValidatorFaucetCap,
issuanceCurve.futureValues.1._2.optValidatorFaucetCap,
issuanceCurve.futureValues.2._2.optValidatorFaucetCap,
issuanceCurve.futureValues.3._2.optValidatorFaucetCap

From 1.25

To 0.60

On DevNet, followed by TestNet and then MainNet.

Vote 4 - Effective 90 days after CIP approval:

Change
issuanceCurve.futureValues.0._2.optValidatorFaucetCap,
issuanceCurve.futureValues.1._2.optValidatorFaucetCap,
issuanceCurve.futureValues.2._2.optValidatorFaucetCap,
issuanceCurve.futureValues.3._2.optValidatorFaucetCap

From 0.60

To 0

On DevNet, followed by TestNet and then MainNet.

Other Impacts

This CIP will also supersede work to be done as part of CIP-0073 to allow allocating liveness rewards to non-operating parties. As a result, no additional changes will be made to allow granting of a ValidatorLicense with a default weight to an arbitrary party. For the avoidance of doubt, functionality described in CIP-0073 regarding allowing a party to create a MintingDelegation contract will not be impacted by this CIP.

Motivation

CIP-0003 was initially raised to provide incentives to operate necessary infrastructure to interact with the network and offset the initial friction associated with engaging in activity on the network. As an initial set of users has onboarded and a number of use cases have gone live, the network should shift its incentive structure toward active participation.

Adjusting the Liveness cap allows the Super Validators to signal a change in these incentives while removing the incentive to run infrastructure without active participation.

Rationale

Over the period 11/8-12/7, roughly 70% of validator rewards minted from the validator minting pool are associated with liveness rewards. The network has provided infrastructure operators with 132M CC of liveness incentives during this time. Given the growth of on-chain use cases and on-chain activity, combined with a substantial queue of new validators onboarding to the network, these incentives are likely to be no longer needed to bootstrap initial operators on the network.

As the ecosystem evolves and as more avenues emerge for acquiring Canton Coin to use to purchase traffic, Validator doing work on the network and acquiring Canton Coin via liveness rewards also provide less utility to the network as a means of facilitating participation.

Backwards Compatibility

This CIP requires no new Daml models and no other breaking changes, so it will be fully backwards compatible.

toggle quoted message Show quoted text

From: cip-discuss@... <cip-discuss@...> On Behalf Of Eric Saraniecki via lists.sync.global
Sent: Monday, December 15, 2025 4:34 PM
To: cip-discuss@...
Subject: [ext] Re: [cip-discuss] CIP-00XX: Remove Liveness Rewards from Validator Rewards Pool

The algorithm for Validator Rewards is (roughly) as follows: 1. Calculate all Activity Rewards first 2. If there is any remainder, split pro-rata across the Validators online as Liveness This proposal recommends removing #2. #2 is naturally

The algorithm for Validator Rewards is (roughly) as follows:

1. Calculate all Activity Rewards first

2. If there is any remainder, split pro-rata across the Validators online as Liveness

This proposal recommends removing #2. #2 is naturally crowded out over time and this CIP says 'not necessary anymore, no need to wait for the natural outcome'

I would welcome a conversation offline about the expenses you are carrying to host apps to understand that point better

On Mon, Dec 15, 2025 at 5:07 PM luka via lists.sync.global <luka=pops.one@...> wrote:

Hi Eric,

thanks for the answers! I am (mostly) aware of everything, but maybe im misunderstanding what you are trying to do here. You wrote

"If this CIP passes, the full Validator Reward pool can still be minted; it just has to be issued on the back of Activity." - does this mean the whole liveness rewards just translate to activity rewards, if validators are hosting apps etc? If so, that is indeed much better.

I would still comment two things though, assuming my understanding of your above sentence is correct:

- there should (imo) still be some smaller liveness rewards as its actually quite expensive to subscribe to apps and host them (we would not be able to host as many as we do without the liveness rewards since its simply too expensive to subscribe to them)
- i would seriously go through all node operators that got granted multiple validator licenses, as mentioned in the OP, you will find a lot of free riders right there, unfortunately; this also leads to my second part of this point - you didnt really onboard that many different validators, just a bunch of same entities who were spinning up nodes taking advantage of liveness rewards

I think the first point warrants a consideration, but the second one should be a must do, asap, as the process was flawed and resulted with a lot less unique validators onboarded than we would all like to see. The sad thing is just that some of these are also SVs so they likely already extracted millions, some for some half decent work/apps.

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.

Demo

Dec 23, 2025

I would like to propose an alternative to the Liveness Rewards

Liveness Rewards Proposal:
I’ve been thinking more about the Liveness Rewards discussion and wanted to share a refined proposal for the committee to consider.As we discussed, validator infrastructure providers will need sufficient time to educate both internal teams and customers.This adjustment period would allow us to engage with existing clients and prospects on how best to contribute to Canton network activity as they build and deploy applications.Proposed Step-Down Plan (90–120 Days):
Provide a structured runway through end of Q1 or April, with gradual reductions to Liveness Rewards as participants ramp up their activity:

Jan 26: Reduce by 25%
Feb 26: Reduce by another 25%
Mar 26: Reduce by another 25%
Apr 26: Final 25% reduction

Alternative:
Use Jan 26 as a grace period (100% rewards maintained), and start reductions on Feb 1, ending in May instead of April.This structure ensures predictability while giving validators and customers time to align their application activity and contribution to network liveness.Appreciate your thoughts on this approach, and happy to walk through the rationale when we speak.Best,Demo

Chris Matturri

Dec 23, 2025

Thank you for sharing the comments Demo and the updated proposal Andrew & Cumberland team. I believe the recommended 90 day timeline does a nice job of reflecting the feedback we heard last week on extending the grace period for tapering down the validator liveness rewards.

This is also in line with the original proposal we worked on earlier this year so we are supportive.

For the record I think it’s also really important to note this does not mean validator earnings go away, but rather are now solely based off of activity which will directly benefit the burn/ overall network.

Proof Group is happy to endorse this to an official vote.

Chris Matturri

chris@...

ProofGroup.xyz

toggle quoted message Show quoted text

Show quoted message

On Tue, Dec 23, 2025 at 11:29 AM demo via lists.sync.global <demo=blockdaemon.com@...> wrote:

I would like to propose an alternative to the Liveness Rewards

Liveness Rewards Proposal:
I’ve been thinking more about the Liveness Rewards discussion and wanted to share a refined proposal for the committee to consider.As we discussed, validator infrastructure providers will need sufficient time to educate both internal teams and customers.This adjustment period would allow us to engage with existing clients and prospects on how best to contribute to Canton network activity as they build and deploy applications.Proposed Step-Down Plan (90–120 Days):
Provide a structured runway through end of Q1 or April, with gradual reductions to Liveness Rewards as participants ramp up their activity:

Jan 26: Reduce by 25%

Feb 26: Reduce by another 25%

Mar 26: Reduce by another 25%

Apr 26: Final 25% reduction

Alternative:
Use Jan 26 as a grace period (100% rewards maintained), and start reductions on Feb 1, ending in May instead of April.This structure ensures predictability while giving validators and customers time to align their application activity and contribution to network liveness.Appreciate your thoughts on this approach, and happy to walk through the rationale when we speak.Best,Demo

Luke Streckenbach

Dec 23, 2025

I agree with Demo and think his proposed more gradual step-down is a better solution here.

To preface, I’ll reiterate that we’re not opposed to a wind-down of liveness rewards, but believe that doing so too abruptly will lead to the loss of potentially valuable network participants.

As Eric has mentioned, liveness rewards were intended to help bootstrap an initial participant set on the network. From my perspective, they’ve been remarkably effective in this regard - today we operate validators on Canton for many large institutions, and as everyone is doubtlessly aware, the attractive economics of joining have been a significant driver of interest across the board. Naturally, we've made it clear to everyone we've onboarded that liveness rewards will not last forever and that eventually activity will be what drives the rewards earned. They're aware of this, but many haven't made their participation strategy a priority yet.

The core issue I see with this updated proposal is that it still effectively forces any NaaS operators charging fees as a percentage of rewards to start charging fiat within a month - if rewards drop to 12% of where they would otherwise have been within 30 days, this functionally breaks the economics for any competitive percent-of-rewards based validator pricing. This will happen at the same time as many currently-inactive customers stop earning rewards. As a result, the economics for many customers will be abruptly inverted and they'll have a very small window to prioritize and evaluate participating before they're losing money to be on Canton.

I understand that this is intentional and aimed to solve the free-rider problem, but would argue that not all "free-riders" today are the same - we've always been very selective in onboarding participants we think can be net beneficial to the ecosystem, and I'm confident that we and other operators will be better able to convert any "free-riders" to active participants if the network can provide a more gradual ramp into an activity-only rewards model.

If we think of historical liveness rewards as participant acquisition costs paid by the network, the incremental cost to provide a slightly more gradual step down (as Demo has proposed) is trivial by comparison. That relatively small cost buys a materially extended timeline during which participants can evaluate how they want to participate without their Canton presence abruptly turning into a net cost.

If you share the view that even a few valuable users that otherwise would have left will instead stay and build due to a more gradual ramp, it seems to me that the cost-benefit tradeoff for the network and CC holders is overwhelmingly in favor of that approach.

Andrew Bryan

Dec 26, 2025

Thank you Luke and Demo for your feedback on the impact of the Liveness winddown timeline. We’d like to propose a new schedule based on your feedback:

No more than 5 days business from CIP Approval: Liveness rewards set to 67% of current levels
+30 Days from (1): Liveness rewards set to 50% of current levels
+60 Days from (1): Liveness rewards set to $0.60
On April 30: Liveness rewards set to 0

This schedule would prevent potential slippage in the liveness end-date by using a strict date for setting Liveness to 0 while also extending the winddown period to end 125 days from today. Ideally this gives you and similar market participants enough time to evaluate impact and adjust your own processes/obligations as needed.

I’ve included the full updated text below and in the attached Word doc. If no more feedback, Cumberland would be ready to sponsor this CIP to move to vote.

Canton Improvement Proposal: Removing Liveness Rewards from Validator Rewards Pool

Abstract

As the network continues to grow, there is an increasing potential for the free rider problem to emerge with Validators and liveness rewards; Validators can collect liveness rewards as incentives from the network without otherwise participating in the network and adding utility.

To mitigate this and encourage participation among validators operating on the network, we suggest adjusting the Validator liveness rewards cap while leaving other aspects of Validator rewards unchanged.

The reduction in liveness rewards would begin no more than 5 business days following CIP approval, along the below schedule:

No more than 5 days business from CIP Approval: Liveness rewards set to 67% of current levels
+30 Days from (1): Liveness rewards set to 50% of current levels
+60 Days from (1): Liveness rewards set to $0.60
On April 30: Liveness rewards set to 0

New values in the Canton Coin DSO configuration would be set as follows for each stage:

No more than 5 business days from CIP Approval: Validator Liveness Reward Cap = $3.33
+30 Days from (1): Validator Liveness Reward Cap = $2.50
+60 Days from (1): Validator Liveness Reward Cap = $0.60
On April 30: Validator Liveness Reward Cap = $0

Specification

Updating Liveness Reward Caps

Super Validator node operators will perform 4 on-chain votes to make the following changes.

Vote 1 - Effective at Threshold:

Change
issuanceCurve.futureValues.0._2.optValidatorFaucetCap,
issuanceCurve.futureValues.1._2.optValidatorFaucetCap,
issuanceCurve.futureValues.2._2.optValidatorFaucetCap,
issuanceCurve.futureValues.3._2.optValidatorFaucetCap

From 570

To 3.33

On DevNet, followed by TestNet and then MainNet.

Vote 2 - Effective 30 days after Vote 1:

Change
issuanceCurve.futureValues.0._2.optValidatorFaucetCap,
issuanceCurve.futureValues.1._2.optValidatorFaucetCap,
issuanceCurve.futureValues.2._2.optValidatorFaucetCap,
issuanceCurve.futureValues.3._2.optValidatorFaucetCap

From 3.33

To 2.5

On DevNet, followed by TestNet and then MainNet.

Vote 3 - Effective 60 days after Vote 1:

Change
issuanceCurve.futureValues.0._2.optValidatorFaucetCap,
issuanceCurve.futureValues.1._2.optValidatorFaucetCap,
issuanceCurve.futureValues.2._2.optValidatorFaucetCap,
issuanceCurve.futureValues.3._2.optValidatorFaucetCap

From 2.5

To 0.60

On DevNet, followed by TestNet and then MainNet.

Vote 4 - Effective on April 30:

Change
issuanceCurve.futureValues.0._2.optValidatorFaucetCap,
issuanceCurve.futureValues.1._2.optValidatorFaucetCap,
issuanceCurve.futureValues.2._2.optValidatorFaucetCap,
issuanceCurve.futureValues.3._2.optValidatorFaucetCap

From 0.60

To 0

On DevNet, followed by TestNet and then MainNet.

Other Impacts

This CIP will also supersede work to be done as part of CIP-0073 to allow allocating liveness rewards to non-operating parties. As a result, no additional changes will be made to allow granting of a ValidatorLicense with a default weight to an arbitrary party. For the avoidance of doubt, functionality described in CIP-0073 regarding allowing a party to create a MintingDelegation contract will not be impacted by this CIP.

Motivation

CIP-0003 was initially raised to provide incentives to operate necessary infrastructure to interact with the network and offset the initial friction associated with engaging in activity on the network. As an initial set of users has onboarded and a number of use cases have gone live, the network should shift its incentive structure toward active participation.

Adjusting the Liveness cap allows the Super Validators to signal a change in these incentives while removing the incentive to run infrastructure without active participation.

Rationale

Over the period 11/8-12/7, roughly 70% of validator rewards minted from the validator minting pool are associated with liveness rewards. The network has provided infrastructure operators with 132M CC of liveness incentives during this time. Given the growth of on-chain use cases and on-chain activity, combined with a substantial queue of new validators onboarding to the network, these incentives are likely to be no longer needed to bootstrap initial operators on the network.

As the ecosystem evolves and as more avenues emerge for acquiring Canton Coin to use to purchase traffic, Validator doing work on the network and acquiring Canton Coin via liveness rewards also provide less utility to the network as a means of facilitating participation.

Backwards Compatibility

This CIP requires no new Daml models and no other breaking changes, so it will be fully backwards compatible.

toggle quoted message Show quoted text

From: cip-discuss@... <cip-discuss@...> On Behalf Of Luke Streckenbach via lists.sync.global
Sent: Tuesday, December 23, 2025 3:32 PM
To: cip-discuss@...
Subject: [ext] Re: [cip-discuss] CIP-00XX: Remove Liveness Rewards from Validator Rewards Pool

I agree with Demo and think his proposed more gradual step-down is a better solution here. To preface, I’ll reiterate that we’re not opposed to a wind-down of liveness rewards, but believe that doing so too abruptly will lead to

I agree with Demo and think his proposed more gradual step-down is a better solution here.

To preface, I’ll reiterate that we’re not opposed to a wind-down of liveness rewards, but believe that doing so too abruptly will lead to the loss of potentially valuable network participants.

As Eric has mentioned, liveness rewards were intended to help bootstrap an initial participant set on the network. From my perspective, they’ve been remarkably effective in this regard - today we operate validators on Canton for many large institutions, and as everyone is doubtlessly aware, the attractive economics of joining have been a significant driver of interest across the board. Naturally, we've made it clear to everyone we've onboarded that liveness rewards will not last forever and that eventually activity will be what drives the rewards earned. They're aware of this, but many haven't made their participation strategy a priority yet.

The core issue I see with this updated proposal is that it still effectively forces any NaaS operators charging fees as a percentage of rewards to start charging fiat within a month - if rewards drop to 12% of where they would otherwise have been within 30 days, this functionally breaks the economics for any competitive percent-of-rewards based validator pricing. This will happen at the same time as many currently-inactive customers stop earning rewards. As a result, the economics for many customers will be abruptly inverted and they'll have a very small window to prioritize and evaluate participating before they're losing money to be on Canton.

I understand that this is intentional and aimed to solve the free-rider problem, but would argue that not all "free-riders" today are the same - we've always been very selective in onboarding participants we think can be net beneficial to the ecosystem, and I'm confident that we and other operators will be better able to convert any "free-riders" to active participants if the network can provide a more gradual ramp into an activity-only rewards model.

If we think of historical liveness rewards as participant acquisition costs paid by the network, the incremental cost to provide a slightly more gradual step down (as Demo has proposed) is trivial by comparison. That relatively small cost buys a materially extended timeline during which participants can evaluate how they want to participate without their Canton presence abruptly turning into a net cost.

If you share the view that even a few valuable users that otherwise would have left will instead stay and build due to a more gradual ramp, it seems to me that the cost-benefit tradeoff for the network and CC holders is overwhelmingly in favor of that approach.

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.

Chris Matturri

Dec 26, 2025

Thank you for the work on this Andrew.

Proof Group would like to formally endorse this for a vote.

Chris Matturri

chris@...

ProofGroup.xyz

toggle quoted message Show quoted text

Show quoted message

On Fri, Dec 26, 2025 at 2:07 PM Andrew Bryan via lists.sync.global <abryan=cumberland.io@...> wrote:

Thank you Luke and Demo for your feedback on the impact of the Liveness winddown timeline. We’d like to propose a new schedule based on your feedback:

No more than 5 days business from CIP Approval: Liveness rewards set to 67% of current levels
+30 Days from (1): Liveness rewards set to 50% of current levels
+60 Days from (1): Liveness rewards set to $0.60
On April 30: Liveness rewards set to 0

This schedule would prevent potential slippage in the liveness end-date by using a strict date for setting Liveness to 0 while also extending the winddown period to end 125 days from today. Ideally this gives you and similar market participants enough time to evaluate impact and adjust your own processes/obligations as needed.

I’ve included the full updated text below and in the attached Word doc. If no more feedback, Cumberland would be ready to sponsor this CIP to move to vote.

Canton Improvement Proposal: Removing Liveness Rewards from Validator Rewards Pool

Abstract

As the network continues to grow, there is an increasing potential for the free rider problem to emerge with Validators and liveness rewards; Validators can collect liveness rewards as incentives from the network without otherwise participating in the network and adding utility.

To mitigate this and encourage participation among validators operating on the network, we suggest adjusting the Validator liveness rewards cap while leaving other aspects of Validator rewards unchanged.

The reduction in liveness rewards would begin no more than 5 business days following CIP approval, along the below schedule:

No more than 5 days business from CIP Approval: Liveness rewards set to 67% of current levels
+30 Days from (1): Liveness rewards set to 50% of current levels
+60 Days from (1): Liveness rewards set to $0.60
On April 30: Liveness rewards set to 0

New values in the Canton Coin DSO configuration would be set as follows for each stage:

No more than 5 business days from CIP Approval: Validator Liveness Reward Cap = $3.33
+30 Days from (1): Validator Liveness Reward Cap = $2.50
+60 Days from (1): Validator Liveness Reward Cap = $0.60
On April 30: Validator Liveness Reward Cap = $0

Specification

Updating Liveness Reward Caps

Super Validator node operators will perform 4 on-chain votes to make the following changes.

Vote 1 - Effective at Threshold:

Change
issuanceCurve.futureValues.0._2.optValidatorFaucetCap,
issuanceCurve.futureValues.1._2.optValidatorFaucetCap,
issuanceCurve.futureValues.2._2.optValidatorFaucetCap,
issuanceCurve.futureValues.3._2.optValidatorFaucetCap

From 570

To 3.33

On DevNet, followed by TestNet and then MainNet.

Vote 2 - Effective 30 days after Vote 1:

Change
issuanceCurve.futureValues.0._2.optValidatorFaucetCap,
issuanceCurve.futureValues.1._2.optValidatorFaucetCap,
issuanceCurve.futureValues.2._2.optValidatorFaucetCap,
issuanceCurve.futureValues.3._2.optValidatorFaucetCap

From 3.33

To 2.5

On DevNet, followed by TestNet and then MainNet.

Vote 3 - Effective 60 days after Vote 1:

Change
issuanceCurve.futureValues.0._2.optValidatorFaucetCap,
issuanceCurve.futureValues.1._2.optValidatorFaucetCap,
issuanceCurve.futureValues.2._2.optValidatorFaucetCap,
issuanceCurve.futureValues.3._2.optValidatorFaucetCap

From 2.5

To 0.60

On DevNet, followed by TestNet and then MainNet.

Vote 4 - Effective on April 30:

Change
issuanceCurve.futureValues.0._2.optValidatorFaucetCap,
issuanceCurve.futureValues.1._2.optValidatorFaucetCap,
issuanceCurve.futureValues.2._2.optValidatorFaucetCap,
issuanceCurve.futureValues.3._2.optValidatorFaucetCap

From 0.60

To 0

On DevNet, followed by TestNet and then MainNet.

Other Impacts

This CIP will also supersede work to be done as part of CIP-0073 to allow allocating liveness rewards to non-operating parties. As a result, no additional changes will be made to allow granting of a ValidatorLicense with a default weight to an arbitrary party. For the avoidance of doubt, functionality described in CIP-0073 regarding allowing a party to create a MintingDelegation contract will not be impacted by this CIP.

Motivation

CIP-0003 was initially raised to provide incentives to operate necessary infrastructure to interact with the network and offset the initial friction associated with engaging in activity on the network. As an initial set of users has onboarded and a number of use cases have gone live, the network should shift its incentive structure toward active participation.

Adjusting the Liveness cap allows the Super Validators to signal a change in these incentives while removing the incentive to run infrastructure without active participation.

Rationale

Over the period 11/8-12/7, roughly 70% of validator rewards minted from the validator minting pool are associated with liveness rewards. The network has provided infrastructure operators with 132M CC of liveness incentives during this time. Given the growth of on-chain use cases and on-chain activity, combined with a substantial queue of new validators onboarding to the network, these incentives are likely to be no longer needed to bootstrap initial operators on the network.

As the ecosystem evolves and as more avenues emerge for acquiring Canton Coin to use to purchase traffic, Validator doing work on the network and acquiring Canton Coin via liveness rewards also provide less utility to the network as a means of facilitating participation.

Backwards Compatibility

This CIP requires no new Daml models and no other breaking changes, so it will be fully backwards compatible.

From: cip-discuss@... <cip-discuss@...> On Behalf Of Luke Streckenbach via lists.sync.global
Sent: Tuesday, December 23, 2025 3:32 PM
To: cip-discuss@...
Subject: [ext] Re: [cip-discuss] CIP-00XX: Remove Liveness Rewards from Validator Rewards Pool

I agree with Demo and think his proposed more gradual step-down is a better solution here. To preface, I’ll reiterate that we’re not opposed to a wind-down of liveness rewards, but believe that doing so too abruptly will lead to

I agree with Demo and think his proposed more gradual step-down is a better solution here.

To preface, I’ll reiterate that we’re not opposed to a wind-down of liveness rewards, but believe that doing so too abruptly will lead to the loss of potentially valuable network participants.

As Eric has mentioned, liveness rewards were intended to help bootstrap an initial participant set on the network. From my perspective, they’ve been remarkably effective in this regard - today we operate validators on Canton for many large institutions, and as everyone is doubtlessly aware, the attractive economics of joining have been a significant driver of interest across the board. Naturally, we've made it clear to everyone we've onboarded that liveness rewards will not last forever and that eventually activity will be what drives the rewards earned. They're aware of this, but many haven't made their participation strategy a priority yet.

The core issue I see with this updated proposal is that it still effectively forces any NaaS operators charging fees as a percentage of rewards to start charging fiat within a month - if rewards drop to 12% of where they would otherwise have been within 30 days, this functionally breaks the economics for any competitive percent-of-rewards based validator pricing. This will happen at the same time as many currently-inactive customers stop earning rewards. As a result, the economics for many customers will be abruptly inverted and they'll have a very small window to prioritize and evaluate participating before they're losing money to be on Canton.

I understand that this is intentional and aimed to solve the free-rider problem, but would argue that not all "free-riders" today are the same - we've always been very selective in onboarding participants we think can be net beneficial to the ecosystem, and I'm confident that we and other operators will be better able to convert any "free-riders" to active participants if the network can provide a more gradual ramp into an activity-only rewards model.

If we think of historical liveness rewards as participant acquisition costs paid by the network, the incremental cost to provide a slightly more gradual step down (as Demo has proposed) is trivial by comparison. That relatively small cost buys a materially extended timeline during which participants can evaluate how they want to participate without their Canton presence abruptly turning into a net cost.

If you share the view that even a few valuable users that otherwise would have left will instead stay and build due to a more gradual ramp, it seems to me that the cost-benefit tradeoff for the network and CC holders is overwhelmingly in favor of that approach.

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.

Leave a reply