[DRAFT] SV weight management fully on-ledger by jose-velasco-ieu · Pull Request #5567 · canton-network/splice

jose-velasco-ieu · 2026-05-15T15:02:01Z

Summary

This PR adds a Daml draft for the new on-ledger SV weight model. The goal is to represent SV weights fully on-ledger, including SV beneficiary weights.

Main changes:

Adds HostedSvInfo and the hostedSvs / offboardedHostedSvs fields to the DsoRules template to represent SV reward weights separately from legacy SV node/operator state.
Keeps SvInfo for SV node/operator information, but marks joinedAsOfRound and svRewardWeight as deprecated in favor of HostedSvInfo.
Adds governed choices for hosted SV lifecycle management: DsoRules_AddHostedSv to add hosted SVs, DsoRules_UpdateHostedSvRewardWeight to update hosted SV weights, and DsoRules_OffboardHostedSv to offboard hosted SVs.
Adds DsoRules_AddSvNode, which replaces DsoRules_AddSv for adding SV nodes. Unlike DsoRules_AddSv, it does not take newSvRewardWeight or joinedAsOfRound, since SV nodes no longer have reward weight attached in the new model.
Adds the SvRewardBeneficiaries template to optionally configure on-ledger beneficiary splits for an SV’s rewards.
Adds DsoRules_SetSvRewardBeneficiaries to create, update, or clear beneficiary distributions.
Adds a temporary convenience choice, DsoRules_MigrateHostedSvs, to migrate an SV operator’s legacy reward weight into hosted SV entries.
Adds DsoRules_ReceiveSvRewardCoupon_V2, which creates reward coupons for all SVs operated by an SV operator using hosted SV weights and optional beneficiary splits.
Deprecates the legacy SV reward weight flow, including DsoRules_UpdateSvRewardWeight and DsoRules_ReceiveSvRewardCoupon, once all SVs have migrated to hostedSvs.
Marks the existing SV onboarding flow as deprecated, as it still creates legacy SV node entries with reward-weight semantics.
Adds a Daml Script test covering migration, beneficiary setup/update/removal, V2 reward coupon creation, hosted SV migration between operators, and SV node onboarding/offboarding.

Pull Request Checklist

Cluster Testing

If a cluster test is required, comment /cluster_test on this PR to request it, and ping someone with access to the DA-internal system to approve it.
If a hard-migration test is required (from the latest release), comment /hdm_test on this PR to request it, and ping someone with access to the DA-internal system to approve it.
If a logical synchronizer upgrade test is required (from canton-3.5), comment /lsu_test on this PR to request it, and ping someone with access to the DA-internal system to approve it.

PR Guidelines

Include any change that might be observable by our partners or affect their deployment in the release notes.
Specify fixed issues with Fixes #n, and mention issues worked on using #n
Include a screenshot for frontend-related PRs - see README or use your favorite screenshot tool

Merge Guidelines

Make the git commit message look sensible when squash-merging on GitHub (most likely: just copy your PR description).

Signed-off-by: Jose Velasco <jose.velasco@intellecteu.com>

isegall-da · 2026-05-15T15:41:45Z

+    choice DsoRules_AddSvOperator : DsoRules_AddSvOperatorResult
+      with
+        newSvParty : Party
+        -- DRAFT note for the reviewer: In the future, newSvName should not be used, since an SV operator may operate multiple SVs.


I would suggest making this choice
AddSvNode, not AddSvOperator, and if a single operator operates multiple nodes, then it is just listed as the operator on each of them.

ok

On the other hand:

What do you think about my comment on newSvName : Text ?

What about newSvParty : Party ? Actually it is an SV operato even though we insert it in the svs Map,

I think we will still need a name for sv nodes, at least for onboarding, so probably need a newSvNodeName.

we insert it in the svs Map

Yeah, that's an ugliness we'll probably need to carry with us as we cannot rename that map. Ideally, I'd rename it to svNodes, but that's an incompatible daml change.

I would suggest making this choice AddSvNode, not AddSvOperator, and if a single operator operates multiple nodes, then it is just listed as the operator on each of them.

I'm afraid the current model cannot support a single SV operator party operating multiple nodes, because SV operators are used as keys in the map.

svs : Map.Map Party SvInfo

I think that actually makes sense to forbid.
The operator party is an internal party in the node itself, so clearly they should be unique per node.

isegall-da · 2026-05-15T15:42:21Z

+        -- which is not a requirement in the current proposal.
+        newSvName : Text
+        newSvParticipantId : Text
+        joinedAsOfRound : Round


I don't think we need this, this was typically to track rewards. If rewards are no longer associated with the node, we don't need it in the node contract

Currently, joinedAsOfRound is part of SvRewardState, which ensures that SV rewards are created only once per round.

-- check and update state rewardState <- fetchAndArchive (ForSv with dso; svName = info.name) rewardStateCid let state = rewardState.state require ("Round " <> show openRound.round <> " is greater than the last round a reward has been received for " <> show state.lastRoundCollected) (state.lastRoundCollected < openRound.round)

Right, but this is for adding a node, so no weights associated with it.
Or do we need it initially during the migration period?

I'm not referring to the migration period.

My point is that the SV operator exercising the new DsoRules_ReceiveSvRewardCoupon_V2 still needs to provide its SvRewardState contract, which contains lastRoundCollected, as we do today, to ensure that SV rewards are created only once per round.

Therefore, I think we still need joinedAsOfRound to create the initial RewardState for the SV operator. Maybe I’m missing something.

But won't you have different joinedAsOfRound for every (weighted) SV?
I think this should be part of sv onboarding, not part of the node onboarding.

Either way, next step should be some daml tests. These usually flesh out the details of the different usage scenarios, and help envision much better what the end result would look like. We should have our answers on this once we see those.

Ok, I wasn't aware that we needed a new onboarding flow for adding new SVs. I thought SV onboarding would only require creating the corresponding on-ledger weight.

How should that flow work?

Yeah, sorry, that's what I meant by onboarding. Either way, when the SV got added in, that's the minimum round for when they should get rewards. Not when the node was onboarded.

ok, I will work on that.

isegall-da · 2026-05-15T15:46:27Z

            newDsoRules <- create this with svs = newSvs
            return DsoRules_UpdateSvRewardWeightResult with ..

+    choice DsoRules_UpdateSvRewardWeight_V2 : DsoRules_UpdateSvRewardWeight_V2Result


I think you meant for this to be nonconsuming
(but see my comment below)

isegall-da · 2026-05-15T15:47:39Z

+          weight = newRewardWeight
+        pure DsoRules_UpdateSvRewardWeight_V2Result with svWeightCid
+
+    nonconsuming choice DsoRules_AddSvRewardWeight : DsoRules_AddSvRewardWeightResult


Given that the long term direction is for votes to be associated with weights, I think the weights should be part of dsoRules, similarly to how nodes are (or how SVs are today) rather than just standalone contracts between operator&sv.

But I must admit that I'm not 100% clear on the tradeoffs around this design choice. What's the downside of doing what I proposed? More churn on dsoRules? (which I think is fine, as weights won't change very often)

It sounds good. I wouldn't expect many weights changes.
In that case, I should get rid of the template SvWeight, right?

Yes, if we manage it on dsoRules then I don't think we need SvWeight at all.

ok, I will refactor this model accordingly

Co-authored-by: Itai Segall <itai.segall@digitalasset.com> Signed-off-by: Jose Velasco <jose.velasco@intellecteu.com>

Signed-off-by: Jose Velasco <jose.velasco@intellecteu.com>

jose-velasco-ieu · 2026-05-22T15:43:06Z

@isegall-da
I've added a Daml test covering the happy path scenario

draft initial commit (no daml tests)

3b91899

Signed-off-by: Jose Velasco <jose.velasco@intellecteu.com>

isegall-da reviewed May 15, 2026

View reviewed changes

Comment thread daml/splice-dso-governance/daml/Splice/DsoRules.daml Outdated

isegall-da reviewed May 15, 2026

View reviewed changes

jose-velasco-ieu and others added 6 commits May 15, 2026 17:02

Update daml/splice-dso-governance/daml/Splice/DsoRules.daml

49d2893

Co-authored-by: Itai Segall <itai.segall@digitalasset.com> Signed-off-by: Jose Velasco <jose.velasco@intellecteu.com>

replace SvWeight contracts with hostedSvs Map in DsoRules

fed0180

Signed-off-by: Jose Velasco <jose.velasco@intellecteu.com>

leftovers

1c41f98

Signed-off-by: Jose Velasco <jose.velasco@intellecteu.com>

move extra beneficiaries on-ledger

3bea7dc

Signed-off-by: Jose Velasco <jose.velasco@intellecteu.com>

leftover

72797c3

Signed-off-by: Jose Velasco <jose.velasco@intellecteu.com>

add daml test with happy path scenarios

1fe975b

Signed-off-by: Jose Velasco <jose.velasco@intellecteu.com>

jose-velasco-ieu requested a review from isegall-da May 22, 2026 15:43

Conversation

jose-velasco-ieu commented May 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Pull Request Checklist

Cluster Testing

PR Guidelines

Merge Guidelines

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

isegall-da May 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jose-velasco-ieu commented May 22, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

jose-velasco-ieu commented May 15, 2026 •

edited

Loading

isegall-da May 15, 2026 •

edited

Loading