[Amendment] SV Weights on Ledger #777: absolute milestone dates

Development Fund Proposal

Organization: IntellectEU
Author / Primary Contact: Arkadiusz Konior, Przemysław Pawelec, Jonathan Mayeur (IntellectEU)
Status: Approved
Created: 2026-06-23
Updated: 2026-10-27
Approved: 2026-10-21
Proposal Type: RFP-aligned
RFP / Roadmap Area: Governance, Identity & Network Coordination - RFP 9 Governance automation (also relevant to RFP 8 Canton Coin Tokenomics)
Champion: Itai Segall (Digital Asset)
Total Funding Request: 4,000,000 CC
Project Duration: ~8 months (33 weeks from approval)
Label: onchain-governance

---

Abstract

Multiple Super Validator Right Owners can host their weights on a single Super Validator Node. The weights of these SV Right Owners are combined and represented on-ledger under the name of the SV Node Operator.

The management of SV Right Owners, along with their weights and beneficiaries happens entirely off-ledger. Not only does this not take advantage of the transparency and trust provided by the ledger but the process of applying changes is slow, cumbersome and must happen serially.

This proposal moves management of SV Right Owners, their weights and beneficiaries onto the ledger.

Digital Asset will partner on this proposal to help with design and ensure delivery.

---

RFP Alignment and Ecosystem Need

RFP. This responds to RFP 9, Governance automation: it turns a repeatable governance workflow (adding, removing and re-weighting SV Right Owners) from a vote plus a manual off-ledger config change into a single on-ledger vote, and it supports moving a rights owner between different SV nodes. It also serves RFP 8's goal of limiting off-chain governance decisions.

Who needs it and why.

• SV node operators stop maintaining right owners and beneficiaries in node config.
• SV Right Owners hosted on another operator's node can see their weight on-ledger and manage their own beneficiaries without asking the operator.
• Super Validators and the Foundation can audit every right owner's weight and beneficiaries in Scan, and change them with a normal vote.

Adoption. It ships in a standard Splice release, so every SV node gets it. The switch to the new model is one SV vote, and existing beneficiaries' minting flow does not change.

---

Specification

1. Objective

Align the Daml ledger model with current practices when it comes to the management of SV Right Owners and their beneficiaries.

At the moment things work as follows:

• SV Nodes are represented on ledger with a weight assigned to them
• Each SV Node keeps a configuration (off-ledger) of their SV Right Owners and their beneficiaries (including the weights)
• For coupon creation, each SV Node uses the beneficiaries mechanism present in the Daml model to create coupons for their SV Right Owners and their beneficiaries with weights derived from their off-ledger configuration
• Adding or removing a new SV Right Owner involves the SV Node requesting a vote on changing its own reward weight, and then the node operator updating the off-ledger configuration of beneficiaries of the node.
• All other SVs need to configure their off-ledger configuration of the total weight of the node, which is used for re-onboarding in case offboarding is required for any reason.

Crucially, SV Right Owners and beneficiaries are not represented on ledger.

Goals include:

• Represent every SV Right Owner, their weight and beneficiaries in the Daml ledger model
• Eliminate the off-ledger weight configuration
• SV Right Owner onboarding, offboarding and weight update requires approval from the SV Nodes
• The weights of any SV Right Owners can be updated independently and in parallel
• An SV Right Owner must only be able to mint rewards if its SV Node and beneficiaries participate in the minting workflow for that round
• SV Right Owners should be able to manage their own beneficiaries without requiring approval or voting of other SVs.
• Migration from the legacy to the new model should invalidate the legacy SV coupon creation flow
• Migration should not result in any loss or duplication of rewards

2. Implementation Mechanics

Introduction

We will represent each SV Right Owner on the ledger along with its reward weight and beneficiaries (along with the proportion of rewards each beneficiary should receive). To change the reward weight of an SV Right Owner, an SV vote is required.

This will completely replace the extraBeneficiaries off-ledger configuration.

If a node operator is an SV Right Owner itself, it will also be represented as an SV Right Owner on its own node, with its weight managed in the exact same way as all other SV Right Owners.

After the migration to the new model, SV Nodes will no longer have any weight associated to them directly.

SV Right Owner Management

A UI will be provided such that an SV Right Owner admin user is able to:

• View information about its SV Right Owner status
• Manage its beneficiaries

This will be supported by choices in the Daml model.

Both the SV UI and Scan UI will be extended to include information about SV Right Owners, supported by an endpoint to be added to the Scan API.

A few voted actions will be added to the Daml model and the SV UI to allow managing SV Right Owners in at least the following ways:

• Onboard a new SV Right Owner
• Update SV Right Owner reward weight
• Offboard an SV Right Owner
• Migrate an SV Right Owner to a different SV Node

Coupon Creation

SV Reward Coupons will continue to be created by each SV Node on behalf of SV right owners hosted on that node for reward minting. One SVRewardCoupon per round will be created for each beneficiary of each SV Right Owner (plus one for the SV Right Owner itself if there is leftover weight).

DsoRules will be extended with a choice to do this. There will be contracts tracking the reward collection state for the SV Right Owners to ensure no double dipping happens.

Within an SV Right Owner, it will be guaranteed by the Daml model that each beneficiary gets at most one SVRewardCoupon per round and with the correct weight. Making sure that each such coupon actually gets created will not be enforced by the Daml model (it is possible for a malicious SV Node or in the case of an SV outage that no coupons are created).

No UI changes are expected regarding coupon creation.

Migration

There will be a choice provided in DsoRules with a corresponding vote to allow migration from the old model to the new. The migration does not require any action on the side of existing beneficiaries. The reward minting flow on their side is unchanged.

This migration voted action will be made available in the voting UI.

Changes to SV Node Onboarding Flow

Since SV Nodes will no longer have any weight associated with them, it is proper that the onboarding flow changes to reflect this. We expect only minor changes to the codebase to reflect the fact that we no longer have reward weight associated with SV Nodes.

In the typical case of a new SV Node with some associated reward weight, the onboarding will be done in two steps:

1. The SV Node is onboarded (with no weight attached to them)
2. We onboard them as an SV Right Owner

The offboarding process will be similar to the onboarding flow. We will reuse as much as possible and decouple SV Node / SV Right Owner offboarding.

Note

Many or most of these flows require additional changes to the various backend services, mainly triggers to further the new flows along.

3. Architectural Alignment

Our proposal:

• Enhances transparency and verifiability on ledger, reducing trust requirements
• Preserves and reuses as much as possible the existing flows
• Is fully backward compatible
• Has an easy migration path
• Makes it much easier to perform governance operations related to SV Right Owners
• Is more decentralized as the SV Right Owners can now control their own beneficiaries
• Enables further developments such as weight-based voting or automated flows to scale down SV Right Owner weights (for example in the context of CIP 105)

4. Backward Compatibility

All of the changes should be backward compatible. The system can continue operating at all points in time.

---

Milestones and Deliverables

Milestone 1: CIP and Daml Draft

• Estimated Delivery: 2026-12-16 (+8 weeks from DFP approval on 2026-10-21)
• Committed Delivery: 2026-12-30 (+10 weeks from DFP approval on 2026-10-21)
• Focus: Implement the Daml Draft and the CIP
• Deliverables / Value Metrics:
  • Daml PR with a draft implementation approved by Splice core maintainers.
  • CIP submitted
  • CIP approved

Milestone 2: Implementation

• Estimated Delivery: 2027-02-24 (+18 weeks from DFP approval on 2026-10-21)
• Committed Delivery: 2027-03-31 (+23 weeks from DFP approval on 2026-10-21)
• Focus: Full functionality implemented and ready for release
• Deliverables / Value Metrics:
  • Merge a series of PRs with the functionality
  • The feature is prod-ready, and ready to be released in the coming minor Splice release

Milestone 3: Roll-out

• Estimated Delivery: 2027-06-09 (+33 weeks from DFP approval on 2026-10-21)
• Payment: due after enabling on MainNet and acceptance, not at a specific date, or forfeited if the acceptance criteria are not met within 12 months of DFP approval (by 2027-10-21).
• Focus: Roll-out of the new model on all networks
• Deliverables / Value Metrics:
  • Deployment to DevNet
  • Migration to the new model on DevNet
  • Manual testing in DevNet
  • Deployment to TestNet
  • Migration to the new model on TestNet
  • Deployment to MainNet
  • Migration to the new model on MainNet
  • Retire defunct code once all SVs completed the migration across all networks

Note: implementation is kept separate from roll-out so that the implementation work can be accepted once it is merged and accepted by the Splice core maintainers, while the roll-out, whose timing depends on network upgrade windows outside of our control, is tracked and accepted as its own milestone.

---

Acceptance Criteria

The Tech & Ops Committee will evaluate completion based on:

• Deliverables completed as specified for each milestone
• Demonstrated functionality or operational readiness
• Documentation and knowledge transfer provided
• Alignment with stated value metrics

---

Funding

Total Funding Request: 4,000,000 CC

IntellectEU and Digital Asset deliver this work jointly. The funding is split 60% to IntellectEU and 40% to Digital Asset, applied to each milestone.

Payment Breakdown by Milestone

• Milestone 1 CIP and Daml Draft: 1,000,000 CC upon committee acceptance (IntellectEU 600,000 CC, Digital Asset 400,000 CC)
• Milestone 2 Implementation: 2,000,000 CC upon committee acceptance (IntellectEU 1,200,000 CC, Digital Asset 800,000 CC)
• Milestone 3 Roll-out to TestNet and MainNet: 1,000,000 CC upon final release and acceptance (IntellectEU 600,000 CC, Digital Asset 400,000 CC)

Total per party: IntellectEU 2,400,000 CC, Digital Asset 1,600,000 CC.

Volatility Stipulation

If the project duration is greater than 9 months: The grant is denominated in fixed Canton Coin and will require a re-evaluation at the 9-month mark.

If the project duration is under 9 months: Should the project timeline extend beyond 9 months due to Committee-requested scope changes, any remaining milestones must be renegotiated to account for significant USD/CC price volatility.

---

Co-Marketing

Upon release, IntellectEU will collaborate with the Foundation on:

• Announcement coordination
• Case study or technical blog
• Developer or ecosystem promotion

---

Motivation

SV Right Owner weight being completely off-ledger has at least a few problems:

• Onboarding, offboarding or changing weight for SV Right Owners is a laborious process. It requires voting to change the SV Node's weight and then an off-ledger configuration change on that SV Node.
• Onboarding, offboarding or changing weight for SV Right Owners can only happen sequentially for each SV Node. We have to wait for the voting to be complete before requesting another SV Node weight change.
• Full trust of SV Nodes is required when it comes to managing their SV Right Owners. Each SV Node can arbitrarily change their reward allocation every round.
• SV Right Owners have to bother their SV Node to have them change their off-ledger configuration when managing their beneficiaries.
• Further developments that rely on SV Right Owner weight are currently hard to implement (e.g. weighed voting or automatic weight updates)
• SV Right Owners and their weights are not visible publicly in block explorers and in Scan APIs.

This proposal solves all of these issues and provides a strong base for further developments involving SV weight and rewards.

---

Rationale

This approach is broadly in line with existing conventions, reuses what exists as much as possible and is fully backward compatible with an easy migration path.

The possibility of storing the SV Right Owner info in DsoRules itself rather than having separate contracts was considered. This has the disadvantage of increasing contention for DsoRules, which might become significant if, for example, further developments around automated weight updates become a reality.

Having a bulk choice/vote to add/remove/update was also considered but decided against because it makes votes harder to reason about and is less aligned with the existing conventions in splice.