CIP-0073: Weighted Validator Liveness Rewards for SV-Chosen Parties
CIP-0073
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.
This CIP also enables external parties to sign a contract authorizing any party to automatically submit a minting transaction on behalf of the external party.
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.
The full functionality of external parties is supported including
multi-hosting, refer to the
documentation
for details. Note that for rewards to be minted for those parties, it
is still required to submit transactions to create and mint activity
records just like it is currently for the existing validator licenses.
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:
- An SV can grant a validator license to a user-specified party id.
- SVs can vote on weight changes for an existing validator license.
- 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
MintingDelegationcontract 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 thatMintingDelegationis 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 for parties relying on external signing. Thedelegateis the provider on the transfer used for minting and therefore receives the app activity markers generated by this transfer. - To support weighting of liveness rewards, the
ValidatorLicenseandValidatorLivenessActivityRecordare extended with an optional weight field. If not set, as is the case for all existing licenses, it defaults to weight 1. - The
ValidatorLicensecontract will be extended with a flag to indicate whether the license is for a validator operator party (which applies to all existing licenses) or a non-operator party.
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.
Copyright
This CIP is licensed under CC0-1.0: Creative Commons CC0 1.0 Universal
Note: other licenses are avilable see recommendations in [CIP-0000](../../cips/CIP-0000/CIP-0000.md)
Changelog
- 2025-08-19: Initial draft of the proposal sent to cip-discuss
- 2025-08-27: Approved CIP.
- 2026-01-05: Add post history and mark this CIP is superseded by CIP-0096.
The reference implementation of the Daml changes is available in two draft PRs.
