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 Kiefer

Architect - Canton Network

Digital Asset, creators of Daml

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

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 45.

 

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.

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 

1. Tech & Ops Committee Review 

1. Formal review of the technical design and reward allocation mechanism (either at the infrastructure operator level or network level). 

2. Clarify responsibility for developing and maintaining the solution. 

2. Governance Definitions — “Liveness” 

1. Define liveness requirements for virtual validator licenses (not infra operator) and incorporate them into license terms. 

3. Reward Allocation Mechanics — Delegated Minting 

1. Assess whether rewards delegated to a single operator can be technically separated. 

2. Confirm whether detailed allocation data will be available or if operators must divide aggregate rewards manually. 

4. Operator Compensation 

1. 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. 

 

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. 

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