CIP-0073: Weighted Validator Liveness Rewards for SV-Determined Parties
- Hi,We'd like to submit the following CIP for discussion. Looking forward to any feedback!## Weighted Validator Liveness Rewards for SV-Determined Parties
<pre>
CIP: ?
* Layer: Daml
Title: Weighted Validator Liveness Rewards for SV-Chosen Parties
Author: Moritz Kiefer
* Discussions-To: cip-discuss@...
* Comments-Summary: N/A
* Comments-URI: N/A
Status: Draft
Type: Tokenomics
Created: 2025-07-23
License: CC0-1.0
* Post-History: N/A
</pre>
## Abstract
This CIP proposes extending the concept of validator liveness rewards
to arbitrary parties--not just validator operators--as well as
supporting weights defined through governance.
This allows hosting multiple parties on a single validator while still providing the same
rewards to the parties on the same node as if they were running their
own node. It also allows weighting certain some parties higher, e.g.,
because they have been shown to contribute significantly to the
success of the network, or have committed to do so.
## Copyright
This CIP is licensed under CC0-1.0: [Creative Commons CC0 1.0 Universal](https://creativecommons.org/publicdomain/zero/1.0/)
Note: other licenses are avilable see recommendations in [CIP-0000](../../cips/CIP-0000/CIP-0000.md)
## Specification
The existing functionality where each SV can grant a
`ValidatorLicense` to any validator operator by providing a validator
onboarding secret, is extended such that each SV can
grant a `ValidatorLicense` with the default weight to arbitrary
parties (including parties relying on external signing) through the SV
UI.
In addition to that, SVs get the ability to change the weight of a
validator license to a non-negative decimal. The liveness rewards
minted by a license with weight N are equivalent to the liveness
rewards minted by N licenses.
### SV UI
The SV UI is extended with three different functionalities:
1. An SV can grant a validator license to a user-specified party id.
2. SVs can vote on weight changes for an existing validator license.
3. SVs can vote on withdrawing a validator license.
### Daml
- At the Daml level there is no distinction between validator operator
parties and any other parties. So the existing choices that allow an
SV to grant a validator license to validator operator parties can
already be used to grant licenses to arbitrary parties.
- To support automatic reward minting for parties relying on external
signing, a new `MintingDelegation` contract is added which allows
signing an transaction once which delegates the right to create and
mint liveness activity records to a validator operator party. This
then allows the automation in the validator app to submit the
required transactions each round on behalf of the external
party. Note that `MintingDelegation` is limited to creating and
minting activity records, it does not grant the delegate rights to
do anything else on behalf of the party. Minting delegations can be
created and accepted through the splice wallet UI for local parties
or through the ledger API endpoints for [external transaction
signing](https://docs.digitalasset.com/build/3.3/tutorials/app-dev/external_signing_submission.html)
for parties relying on external signing.
- To support weighting of liveness rewards, the `ValidatorLicense` and
`ValidatorLivenessActivityRecord` are extended with an optional
weight field. If not set, as is the case for all existing licenses,
it defaults to weight 1.
## Motivation
MainNet is close to the maximum number of validators that can be
supported. This is driven to a significant degree due to spinning up a
separate validator being the only option to get more liveness rewards.
By supporting liveness rewards for non-validator operator parties,
this pressure is reduced without impacting the rewards that users can
receive.
Weighting allows balancing the benefit to the network coming from
users that do nothing other than accumulating validator rewards with the benefits provided by parties
that significantly contribute to the success of the network.
## Rationale
Manual weighting through votes provides a simple mechanism to balance
the contributions of different parties to the network. While more
complex automatic mechanisms based on staking, measuring activity in
apps or similar could be built, those all have vastly more
implementation complexity and could be added on top of this CIP by
automating votes on weight changes.
Allowing SVs to unilaterally grant a license after approval from the
tokenomics committee with default weight to any party is already
supported by the current Daml code and consistent with being able to
unilaterally grant it to validator operators. If this gets abused,
other SV operators can withdraw validator licenses or set their weight
to 0.
Weight changes on the other hand require more care and so those require a vote.
## Backwards compatibility
The changes are all backwards compatible. However, like any Daml change
it introduces a soft fork where all nodes on the network must upgrade
to the version that introduced this change before it becomes effective.
## Reference implementation
The reference implementation of the Daml changes is available in two draft PRs.
1. [weighting of validator licenses](https://github.com/hyperledger-labs/splice/pull/1634)
2. [delegated reward minting](https://github.com/hyperledger-labs/splice/pull/1627)
--Moritz KieferArchitect - Canton NetworkDigital 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. - toggle quoted message Show quoted textThe CIP is available on github here https://github.com/global-synchronizer-foundation/cips/pull/84On Mon, Jul 28, 2025 at 1:25 PM Moritz Kiefer via lists.sync.global <moritz.kiefer=digitalasset.com@...> wrote:Hi,We'd like to submit the following CIP for discussion. Looking forward to any feedback!## Weighted Validator Liveness Rewards for SV-Determined Parties
<pre>
CIP: ?
* Layer: Daml
Title: Weighted Validator Liveness Rewards for SV-Chosen Parties
Author: Moritz Kiefer
* Discussions-To: cip-discuss@...
* Comments-Summary: N/A
* Comments-URI: N/A
Status: Draft
Type: Tokenomics
Created: 2025-07-23
License: CC0-1.0
* Post-History: N/A
</pre>
## Abstract
This CIP proposes extending the concept of validator liveness rewards
to arbitrary parties--not just validator operators--as well as
supporting weights defined through governance.
This allows hosting multiple parties on a single validator while still providing the same
rewards to the parties on the same node as if they were running their
own node. It also allows weighting certain some parties higher, e.g.,
because they have been shown to contribute significantly to the
success of the network, or have committed to do so.
## Copyright
This CIP is licensed under CC0-1.0: [Creative Commons CC0 1.0 Universal](https://creativecommons.org/publicdomain/zero/1.0/)
Note: other licenses are avilable see recommendations in [CIP-0000](../../cips/CIP-0000/CIP-0000.md)
## Specification
The existing functionality where each SV can grant a
`ValidatorLicense` to any validator operator by providing a validator
onboarding secret, is extended such that each SV can
grant a `ValidatorLicense` with the default weight to arbitrary
parties (including parties relying on external signing) through the SV
UI.
In addition to that, SVs get the ability to change the weight of a
validator license to a non-negative decimal. The liveness rewards
minted by a license with weight N are equivalent to the liveness
rewards minted by N licenses.
### SV UI
The SV UI is extended with three different functionalities:
1. An SV can grant a validator license to a user-specified party id.
2. SVs can vote on weight changes for an existing validator license.
3. SVs can vote on withdrawing a validator license.
### Daml
- At the Daml level there is no distinction between validator operator
parties and any other parties. So the existing choices that allow an
SV to grant a validator license to validator operator parties can
already be used to grant licenses to arbitrary parties.
- To support automatic reward minting for parties relying on external
signing, a new `MintingDelegation` contract is added which allows
signing an transaction once which delegates the right to create and
mint liveness activity records to a validator operator party. This
then allows the automation in the validator app to submit the
required transactions each round on behalf of the external
party. Note that `MintingDelegation` is limited to creating and
minting activity records, it does not grant the delegate rights to
do anything else on behalf of the party. Minting delegations can be
created and accepted through the splice wallet UI for local parties
or through the ledger API endpoints for [external transaction
signing](https://docs.digitalasset.com/build/3.3/tutorials/app-dev/external_signing_submission.html)
for parties relying on external signing.
- To support weighting of liveness rewards, the `ValidatorLicense` and
`ValidatorLivenessActivityRecord` are extended with an optional
weight field. If not set, as is the case for all existing licenses,
it defaults to weight 1.
## Motivation
MainNet is close to the maximum number of validators that can be
supported. This is driven to a significant degree due to spinning up a
separate validator being the only option to get more liveness rewards.
By supporting liveness rewards for non-validator operator parties,
this pressure is reduced without impacting the rewards that users can
receive.
Weighting allows balancing the benefit to the network coming from
users that do nothing other than accumulating validator rewards with the benefits provided by parties
that significantly contribute to the success of the network.
## Rationale
Manual weighting through votes provides a simple mechanism to balance
the contributions of different parties to the network. While more
complex automatic mechanisms based on staking, measuring activity in
apps or similar could be built, those all have vastly more
implementation complexity and could be added on top of this CIP by
automating votes on weight changes.
Allowing SVs to unilaterally grant a license after approval from the
tokenomics committee with default weight to any party is already
supported by the current Daml code and consistent with being able to
unilaterally grant it to validator operators. If this gets abused,
other SV operators can withdraw validator licenses or set their weight
to 0.
Weight changes on the other hand require more care and so those require a vote.
## Backwards compatibility
The changes are all backwards compatible. However, like any Daml change
it introduces a soft fork where all nodes on the network must upgrade
to the version that introduced this change before it becomes effective.
## Reference implementation
The reference implementation of the Daml changes is available in two draft PRs.
1. [weighting of validator licenses](https://github.com/hyperledger-labs/splice/pull/1634)
2. [delegated reward minting](https://github.com/hyperledger-labs/splice/pull/1627)
--Moritz KieferArchitect - Canton NetworkDigital 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.--Moritz KieferArchitect - Canton NetworkDigital 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. - Thanks for putting this together, Moritz.Breaking this down, there are two primary components to the CIP.
1) Extending functionality such that each SV can grant a ValidatorLicense with the default weight to arbitrary parties.We are supportive of this. It seems like a necessary capability to efficiently manage multi-tenant validators.2) SV's get the ability to change the liveness reward weight of a ValidatorLicense to an arbitrary non-negative number.We don't believe this is a good change, but maybe we're missing something. Part of the motivation for this change seems to be awarding good actors with a higher liveness reward weight. I believe that is the wrong way to think about liveness.First, via validator activity rewards, very active validators should see an outsized reward (that scales dynamically with activity) vs. liveness reward free-riders. Also, activity rewards being calculated at the top of the waterfall has the effect of liveness rewards being allocated to activity rewards when there is enough activity to merit it.Second, I think liveness rewards should be just that. Liveness rewards. Enabling this change will create a mechanism to attribute liveness rewards to something else which can become confusing.I suppose you could argue that having the ability to configure it to 0 would be beneficial to address bad actors, but SVs will have the ability to revoke the ValidatorLicense which seems like a cleaner approach to that.
Open to discuss this further, perhaps we're missing something. One thought I had--does this move bring us closer to the concept of configurable awards in general. I'm a proponent of increased flexibility for the network so changes can be made more easily when merited, but I don't think this is the right use case.ThanksChris - Thank you for the proposal.
- I think the possibility to delegate minting power to a configurable party or external party is a good feature. It allows flexibility and the possibility to secure on external party.
- Governance on liveness rewards per party through weight can be useful (bad actors case).
- `MintingDelegation` Is it just delegation 1 to 1 or there could more than 1 licence per validator ?
- In this new design, will it be possible for a party the obtain a licence, weight, and liveness rewards voted by SVs without relying on a Validator Operator Party ?
-
By supporting liveness rewards for non-validator operator parties
Today, when a node is down, no liveness rewards are minted for Validator Operator Party.How liveness rewards will be trigger or not for those "non-validator operator parties".It depends on the real validator operator party where they are hosted ? - Can we add also the possibility to the 'validator operator party' to orchestrate a weighted re-distribution on parties, if operator wants to. Like the existing option extraBeneficiaries for SV ?
- I remember asking this questions a few month ago :
"If there is no activity, the liveness pool is bigger?"answered by"Yes, for the given number of active validators".I suppose the reverse is true too: "If there is activities, the liveness pool is smaller".So, is there a correlation between the liveness pool and activities pool each round?Let's promote, provide details about, and educate users and operators on these activities rewards.Are activities rewards linked to licence too ?Are activities rewards different from app rewards, featured app rewards ? Weekend thoughts on this topic:
Motivation of the CIP:
I understand that the motivation for extending minting licenses beyond validator operators is to promote network growth and allow more actors to participate. The current technical limitations on the number of validators (around 300?) restrict growth, and this change would enable more contributors to receive rewards.
Virtual vs Operator Licence concept.
Adding license capability to any party seems to be a quick and feasible solution as presented in this CIP introduction, utilizing existing liveness rewards. However, as also mentioned in this comment, I think it is important to differentiate between Validator Operator Licenses and these Virtual Validator Licenses that receive rewards but do not operate infrastructure.
If this CIP passes, it would be beneficial for SVs to clearly define the duties and contributions expected from Virtual Validator License holders when granting these licenses. This would enable proper governance of their contributions. Additionally, it should be specified whether Virtual Validator Licenses receive liveness rewards based on the actual liveness of Validator Operator License servers (if this connection is confirmed as mentioned in my previous message).
Liveness rewards for Validator Operator License are more clear for me: maintaining 24/7 service, performing weekly software upgrades, major upgrade, ensuring data availability and backups for hosted parties, providing open and secure validator APIs, integrating OIDC providers, integrating with canton external parties wallets providers, deploying DARs and their associated application UIs, upgrading these DAR applications and their potential UIs, and implementing supervision, monitoring, and alerting systems etc …
What exactly constitutes "liveness" for Virtual Validator Licenses? This needs to be clearly defined in the license terms.
(This concept of "Operator" and "Virtual Operator" exists in Telecom industry also with MVNO for instance)
Multi-tenant SV experience.
I do not know if a licence model is define also for SV level. It would be helpful to distinguish between SVs with voting and onboarding power versus those with only SV weight reward coupons. More on this distinction here.
The responsibilities and expectations will differ between "Operator SV License" and "Virtual SV License" holders.
We see that in this previous CIP 45 adding multi-tenant at SV level and rewards weight can potentially create this:
“The GSF multitenant is creating a bit of a free rider problem and it would be beneficial to set some rules around its utilization.”
The previous implementation was at the SV level for adding extra Beneficiary rewards. This CIP would extend this capability to the Validator multi-tenant level with newly granted parties receiving liveness rewards.
Rules must be clearly defined since we need to recognize that this new possibility could create a new pathway for free-riders like said in the previous CIP-0045.
Network mesh structure
Finally, will the network mesh structure will look like this?:
- "Virtual SV Licenses" provided by "Operator SV License" holders, approved through SV governance, with extraBeneficiary configuration.
- "Virtual Validator Licenses" provided by "Operator Validator License" holders, approved through SV governance, with new configuration parameters to be defined in this CIP.
I look forward to seeing how governance will evolve on this topic and remain available for dialectical conversation regarding this matter.
- toggle quoted message Show quoted textHey Francois, thanks for the good questions and comments! Answers inline:> `MintingDelegation` Is it just delegation 1 to 1 or there could more than 1 licence per validator ?You can delegate the automation from multiple parties to the same party. Essentially this is what happens for parties not using external signing already: They implicitly delegate all their minting delegation to the validator operator party. What this adds is the option to do the same for external parties.> In this new design, will it be possible for a party the obtain a licence, weight, and liveness rewards voted by SVs without relying on a Validator Operator Party ?> Today, when a node is down, no liveness rewards are minted for Validator Operator Party.Minting fundamentally relies on performing an action in both the open round and the issuing phase. For that to work at least one of the nodes your party is hosted on must be functional and someone must submit one transaction in each of the two phases. So you could in theory get a bit more redundancy by hosting your party on multiple nodes but in the common case of only being hosted on one node, you still rely on that node to be up and unless you write your own minting automation you rely on the minting delegation being used to submit the two transactions by the validator operator party.> Can we add also the possibility to the 'validator operator party' to orchestrate a weighted re-distribution on parties, if operator wants to. Like the existing option extraBeneficiaries for SV ?We could, it's orthogonal to the CIP in its current form though which is why we left it for a separate CIP to be tackled. Note that the parties you distribute to would still need to setup a MintingDelegation so the transactions are submitted on there behalf.> So, is there a correlation between the liveness pool and activities pool each round?The validator reward pool has a fixed size per round. It is first distributed towards activity generated from burns for traffic credits and burns for CC transfers. Only the remainder goes to liveness rewards. This CIP just changes how you can get liveness rewards, it does not change that it only uses the remainder for liveness. ValidatorLicense contracts only affect liveness rewards, they have no impact on app rewards, sv rewards or validator usage rewards for traffic and cc burns.> What exactly constitutes "liveness" for Virtual Validator Licenses? This needs to be clearly defined in the license terms.It's a good question, I would expect the tokenomics commitee to come up with a policy here. For the CIP, we wanted to keep it CIP focused on the technical aspects that enable issuance of those licenses and leave the aspect of governance of how licenses and weights are issued up to the tokenomics committee here.> Multi-tenant SV experience.The only thing tracked on-ledger through governance is the weight of SV node which I suppose is similar to a license. The beneficiaries feature then just allows to redistribute the reward that you get from that weight between different parties.This CIP does not change anything wrt to SVs and imho we should keep such changes to a separate CIP.On Sun, Aug 10, 2025 at 7:45 PM Francois Branciard via lists.sync.global <francois.branciard=kiln.fi@...> wrote:
Weekend thoughts on this topic:
Motivation of the CIP:
I understand that the motivation for extending minting licenses beyond validator operators is to promote network growth and allow more actors to participate. The current technical limitations on the number of validators (around 300?) restrict growth, and this change would enable more contributors to receive rewards.
Virtual vs Operator Licence concept.
Adding license capability to any party seems to be a quick and feasible solution as presented in this CIP introduction, utilizing existing liveness rewards. However, as also mentioned in this comment, I think it is important to differentiate between Validator Operator Licenses and these Virtual Validator Licenses that receive rewards but do not operate infrastructure.
If this CIP passes, it would be beneficial for SVs to clearly define the duties and contributions expected from Virtual Validator License holders when granting these licenses. This would enable proper governance of their contributions. Additionally, it should be specified whether Virtual Validator Licenses receive liveness rewards based on the actual liveness of Validator Operator License servers (if this connection is confirmed as mentioned in my previous message).
Liveness rewards for Validator Operator License are more clear for me: maintaining 24/7 service, performing weekly software upgrades, major upgrade, ensuring data availability and backups for hosted parties, providing open and secure validator APIs, integrating OIDC providers, integrating with canton external parties wallets providers, deploying DARs and their associated application UIs, upgrading these DAR applications and their potential UIs, and implementing supervision, monitoring, and alerting systems etc …
What exactly constitutes "liveness" for Virtual Validator Licenses? This needs to be clearly defined in the license terms.
(This concept of "Operator" and "Virtual Operator" exists in Telecom industry also with MVNO for instance)
Multi-tenant SV experience.
I do not know if a licence model is define also for SV level. It would be helpful to distinguish between SVs with voting and onboarding power versus those with only SV weight reward coupons. More on this distinction here.
The responsibilities and expectations will differ between "Operator SV License" and "Virtual SV License" holders.
We see that in this previous CIP 45 adding multi-tenant at SV level and rewards weight can potentially create this:
“The GSF multitenant is creating a bit of a free rider problem and it would be beneficial to set some rules around its utilization.”
The previous implementation was at the SV level for adding extra Beneficiary rewards. This CIP would extend this capability to the Validator multi-tenant level with newly granted parties receiving liveness rewards.
Rules must be clearly defined since we need to recognize that this new possibility could create a new pathway for free-riders like said in the previous CIP-0045.
Network mesh structure
Finally, will the network mesh structure will look like this?:
- "Virtual SV Licenses" provided by "Operator SV License" holders, approved through SV governance, with extraBeneficiary configuration.
- "Virtual Validator Licenses" provided by "Operator Validator License" holders, approved through SV governance, with new configuration parameters to be defined in this CIP.
I look forward to seeing how governance will evolve on this topic and remain available for dialectical conversation regarding this matter.
--Moritz KieferArchitect - Canton NetworkDigital 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. - > Let's promote, provide details about, and educate users and operators on these activities rewards.> Are activities rewards linked to licence too ?> Are activities rewards different from app rewards, featured app rewards ?Hi, FrancoisRewards for Validator activity other than Liveness come from Canton Coin activity: burning Canton Coin to purchase traffic, and burning Canton Coin fees as part of Canton Coin transfers and other activities. This is detailed in the Canton Coin whitepaper, posted at the bottom of the homepage at
https://sync.global
and also here:
https://www.digitalasset.com/hubfs/Canton%20Network%20Files/Documents%20(whitepapers%2c%20etc...)/Canton%20Coin_%20A%20Canton-Network-native%20payment%20application.pdf Hello Moritz,
To progress the conversation on this CIP we collated the feedback from interested operators who are part of the Multi-tenant Working Group (MTWG) for the benefit of the Tokenomics Committee. See below our collective feedback and recommendations for consideration and discussion.
Summary
The Multi-Tenant Working Group collectively supports the CIP, contingent on the Tech & Ops Committee addressing the outlined technical and governance considerations to ensure effective implementation and risk mitigation.
1) “Extending functionality such that each SV can grant a ValidatorLicense with the default weight to arbitrary parties.”
Comment: The MTWG is supportive of the capability to efficiently manage multi tenant validators who don’t require full operator access other than minting.
2) “In addition to that, SVs get the ability to change the weight of a validator license to a non-negative decimal. The liveness rewards minted by a license with weight N are equivalent to the liveness rewards minted by N licenses.”
Comment: The MTWG would like to propose the discussion around adoption of such terms such as "Operator" and "Virtual Operator" - “Virtual” when no infrastructure operation is done. “Virtual SV” when only SV weights and no voting or onboarding power and “Virtual Validator” when delegation of liveness rewards like presented in the new CIP.
Additionally, we would like request defining the liveness requirements for virtual validator licenses (not infra operator) to prove eligibility to mint.
3) “To support automatic reward minting for parties relying on external signing, a new Minting Delegation` contract is added which allows signing an transaction once which delegates the right to create and mint liveness activity records to a validator operator party.”
Comment: For this aspect of the CIP, the working group would like to give conditional support to the CIP subject to the provision of the following capability: We would like to request a feasibility review by the Tech & Ops committee to better understand what this means for a validator operator. Specifically who performs the allocation of the minted rewards and if it requires involvement from the validator operators either through the mechanical distribution or calculation of rewards. If the latter, the operators would like to discuss a conditional approval of this CIP subject to technology being built that enables the automatic distribution of rewards.
4) “SVs can vote on weight changes for an existing validator license”
Comment: The MTWG would like to propose the ability to allow flex weight assignments initially, but would welcome clarity on triggers for removal (i.e. who has decision authority to approve a weight change).
Requests & Recommendations
-
Tech & Ops Committee Review
-
Formal review of the technical design and reward allocation mechanism (either at the infrastructure operator level or network level).
-
Clarify responsibility for developing and maintaining the solution.
-
Governance Definitions — “Liveness”
-
Define liveness requirements for virtual validator licenses (not infra operator) and incorporate them into license terms.
-
Reward Allocation Mechanics — Delegated Minting
-
Assess whether rewards delegated to a single operator can be technically separated.
-
Confirm whether detailed allocation data will be available or if operators must divide aggregate rewards manually.
-
Operator Compensation
-
Infrastructure operators running validator infrastructure for minting should receive compensation tied to liveness performance.
Further Considerations Beyond this CIP
-
Governance & Oversight
-
Governance should reflect the ethos of a public network: avoid “policing” participants, focusing instead on those who demonstrably contribute value.
-
Be mindful that large-scale non-application participants could create governance gridlock.
-
- toggle quoted message Show quoted textHi Kinka,I've pushed a small amendment based on your input https://github.com/global-synchronizer-foundation/cips/pull/84/commits/539e5f06b37a208660cd2828a67876a205a60d35On Wed, Aug 13, 2025 at 11:35 PM Kinga Bosse via lists.sync.global <kinga.bosse=mpch.com@...> wrote:
Hello Moritz,
To progress the conversation on this CIP we collated the feedback from interested operators who are part of the Multi-tenant Working Group (MTWG) for the benefit of the Tokenomics Committee. See below our collective feedback and recommendations for consideration and discussion.
Summary
The Multi-Tenant Working Group collectively supports the CIP, contingent on the Tech & Ops Committee addressing the outlined technical and governance considerations to ensure effective implementation and risk mitigation.
1) “Extending functionality such that each SV can grant a ValidatorLicense with the default weight to arbitrary parties.”
Comment: The MTWG is supportive of the capability to efficiently manage multi tenant validators who don’t require full operator access other than minting.
2) “In addition to that, SVs get the ability to change the weight of a validator license to a non-negative decimal. The liveness rewards minted by a license with weight N are equivalent to the liveness rewards minted by N licenses.”
Comment: The MTWG would like to propose the discussion around adoption of such terms such as "Operator" and "Virtual Operator" - “Virtual” when no infrastructure operation is done. “Virtual SV” when only SV weights and no voting or onboarding power and “Virtual Validator” when delegation of liveness rewards like presented in the new CIP.
Additionally, we would like request defining the liveness requirements for virtual validator licenses (not infra operator) to prove eligibility to mint.
3) “To support automatic reward minting for parties relying on external signing, a new Minting Delegation` contract is added which allows signing an transaction once which delegates the right to create and mint liveness activity records to a validator operator party.”
Comment: For this aspect of the CIP, the working group would like to give conditional support to the CIP subject to the provision of the following capability: We would like to request a feasibility review by the Tech & Ops committee to better understand what this means for a validator operator. Specifically who performs the allocation of the minted rewards and if it requires involvement from the validator operators either through the mechanical distribution or calculation of rewards. If the latter, the operators would like to discuss a conditional approval of this CIP subject to technology being built that enables the automatic distribution of rewards.
4) “SVs can vote on weight changes for an existing validator license”
Comment: The MTWG would like to propose the ability to allow flex weight assignments initially, but would welcome clarity on triggers for removal (i.e. who has decision authority to approve a weight change).
Requests & Recommendations
-
Tech & Ops Committee Review
-
Formal review of the technical design and reward allocation mechanism (either at the infrastructure operator level or network level).
-
Clarify responsibility for developing and maintaining the solution.
-
Governance Definitions — “Liveness”
-
Define liveness requirements for virtual validator licenses (not infra operator) and incorporate them into license terms.
-
Reward Allocation Mechanics — Delegated Minting
-
Assess whether rewards delegated to a single operator can be technically separated.
-
Confirm whether detailed allocation data will be available or if operators must divide aggregate rewards manually.
-
Operator Compensation
-
Infrastructure operators running validator infrastructure for minting should receive compensation tied to liveness performance.
Further Considerations Beyond this CIP
-
Governance & Oversight
-
Governance should reflect the ethos of a public network: avoid “policing” participants, focusing instead on those who demonstrably contribute value.
-
Be mindful that large-scale non-application participants could create governance gridlock.
--Moritz KieferArchitect - Canton NetworkDigital 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. -
- Thank you - MPCH is ready to sponsor this CIP.
Hi Kinka,I've pushed a small amendment based on your input https://github.com/global-synchronizer-foundation/cips/pull/84/commits/539e5f06b37a208660cd2828a67876a205a60d35On Wed, Aug 13, 2025 at 11:35 PM Kinga Bosse via lists.sync.global <kinga.bosse=mpch.com@...> wrote:Hello Moritz,
To progress the conversation on this CIP we collated the feedback from interested operators who are part of the Multi-tenant Working Group (MTWG) for the benefit of the Tokenomics Committee. See below our collective feedback and recommendations for consideration and discussion.
Summary
The Multi-Tenant Working Group collectively supports the CIP, contingent on the Tech & Ops Committee addressing the outlined technical and governance considerations to ensure effective implementation and risk mitigation.
1) “Extending functionality such that each SV can grant a ValidatorLicense with the default weight to arbitrary parties.”
Comment: The MTWG is supportive of the capability to efficiently manage multi tenant validators who don’t require full operator access other than minting.
2) “In addition to that, SVs get the ability to change the weight of a validator license to a non-negative decimal. The liveness rewards minted by a license with weight N are equivalent to the liveness rewards minted by N licenses.”
Comment: The MTWG would like to propose the discussion around adoption of such terms such as "Operator" and "Virtual Operator" - “Virtual” when no infrastructure operation is done. “Virtual SV” when only SV weights and no voting or onboarding power and “Virtual Validator” when delegation of liveness rewards like presented in the new CIP.
Additionally, we would like request defining the liveness requirements for virtual validator licenses (not infra operator) to prove eligibility to mint.
3) “To support automatic reward minting for parties relying on external signing, a new Minting Delegation` contract is added which allows signing an transaction once which delegates the right to create and mint liveness activity records to a validator operator party.”
Comment: For this aspect of the CIP, the working group would like to give conditional support to the CIP subject to the provision of the following capability: We would like to request a feasibility review by the Tech & Ops committee to better understand what this means for a validator operator. Specifically who performs the allocation of the minted rewards and if it requires involvement from the validator operators either through the mechanical distribution or calculation of rewards. If the latter, the operators would like to discuss a conditional approval of this CIP subject to technology being built that enables the automatic distribution of rewards.
4) “SVs can vote on weight changes for an existing validator license”
Comment: The MTWG would like to propose the ability to allow flex weight assignments initially, but would welcome clarity on triggers for removal (i.e. who has decision authority to approve a weight change).
Requests & Recommendations
-
Tech & Ops Committee Review
-
Formal review of the technical design and reward allocation mechanism (either at the infrastructure operator level or network level).
-
Clarify responsibility for developing and maintaining the solution.
-
Governance Definitions — “Liveness”
-
Define liveness requirements for virtual validator licenses (not infra operator) and incorporate them into license terms.
-
Reward Allocation Mechanics — Delegated Minting
-
Assess whether rewards delegated to a single operator can be technically separated.
-
Confirm whether detailed allocation data will be available or if operators must divide aggregate rewards manually.
-
Operator Compensation
-
Infrastructure operators running validator infrastructure for minting should receive compensation tied to liveness performance.
Further Considerations Beyond this CIP
-
Governance & Oversight
-
Governance should reflect the ethos of a public network: avoid “policing” participants, focusing instead on those who demonstrably contribute value.
-
Be mindful that large-scale non-application participants could create governance gridlock.
Moritz KieferArchitect - Canton Network -
- I think it's important to call out that the node operator will get featured app rewards for submitting the minting transaction on behalf of the external party.This means the validator operator receives application rewards for node operation on behalf of external parties.
- On Mon, Aug 25, 2025 at 5:50 PM Wayne Collier via lists.sync.global <wayne.collier=digitalasset.com@...> wrote:I think it's important to call out that the node operator will get featured app rewards for submitting the minting transaction on behalf of the external party.This means the validator operator receives application rewards for node operation on behalf of external parties.This reads as if they would always get such rewards. That's not the case. A node operator that runs this kind of "reward minting automation app" for another party will get featured app rewards if they are registered as a featured application provider. Whether to feature node operators for running such a "reward minting automation app" is a decision that's left to the tokenomics committee.--
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. - Yep, that's right; I should have just said "will get app rewards".
- Amanda: This CIP should have been moved to a vote, given:
DA: Sponsor
MPCH: EndorserIf I read the responses correctly, Cumberland might vote in favor of some aspects of the CIP, like delegating to a Validator the automation that kicks of off minting operations performed by external parties, but perhaps they'd also support it in its current form. - Hello,As this CIP has been voted and approved, this functionality will be implemented/deployed soon ? After the major upgrade canton-3.4 splice-0.5.0 ?
- There's a team at Obsidian currently working on an implementation of this CIP.
- I'd like to call out an implementation detail that was not made clear in the approved text of this CIP: it's my understanding from talking with various Super Validators, who voted in favor of this CIP, that their intention was that this CIP would make it possible for a validator operator designate to external party that will get credit for liveness rewards earned by the the Validator node controlled by that Validator operator party.To be precise, this will mean that the Validator operator may designate an external party as beneficiary of the liveness rewards. This means that the coupons resulting from that Validator's activity will be assigned to that external party. This also means that if that external party signs a delegated minting contract allowing the validator operator to kick off a minting operation with the external party as both the sender and receiver, that external party can then mint those coupons directly into Canton Coin held by that external party, without the validator operator party ever taking ownership of the coupons, or the Canton Coin.If you were a voting Super Validator on this CIP, and you oppose this understanding of the CIP, please reply here.
- To clarify: Digital Asset supports this interpretation, and it's my understanding that the other Super Validators support this approach as well.
- Hello Wayne - our understanding is that the validator operator will be able to assign a portion (0-100%) of the minted rewards (similarly to SV reward allocations) to an external party as a beneficiary. The resulting allocation to your point would be assigned without taking ownership of the allocated coupons. Let me know if this is not aligned with your understanding below. Thank you, -Kinga
- Thanks for the quick response Kinga.On Thu, Nov 20, 2025 at 6:54 PM Kinga Bosse via lists.sync.global <kinga.bosse=mpch.com@...> wrote:Hello Wayne - our understanding is that the validator operator will be able to assign a portion (0-100%) of the minted rewards (similarly to SV reward allocations) to an external party as a beneficiary. The resulting allocation to your point would be assigned without taking ownership of the allocated coupons. Let me know if this is not aligned with your understanding below. Thank you, -KingaWhat would be the use-case for a partial assignment of the minted rewards?Implementation-wise the following option would be simpler: "Validator node operators can optionally configure a single beneficiary party in their node's validator app. If configured, that beneficiary party will get credit for all validator activity from that node, i.e., the traffic purchases executed by the node and the validator liveness activity proven by that node."
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.
