[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>

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

isegall-da · 2026-05-27T01:08:37Z

Thanks @jose-velasco-ieu great work!
I haven't reviewed for corner cases etc., but as a general setup I think this works well now as a PoC, and does exactly what we need.
@moritzkiefer-da can I ask for a review from you as well please?

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

moritzkiefer-da · 2026-05-27T08:25:33Z

+        -- ^ The full beneficiary distribution to set. The total beneficiary
+        -- weight must be less than or equal to the SV weight in 'DsoRules'.
+        -- Any unassigned SV weight is created for the SV itself.
+  | ClearBeneficiaries with


what's the difference between this and just setting SetBeneficiaries (Some cid) []?

None, but ClearBeneficiaries is probably more semantic

I think I'd lean towards having one less choice to maintain and test instead

somewhat related to my discussion below on whether we should ensure this always exists though so let's maybe resolve that first

moritzkiefer-da · 2026-05-27T08:52:43Z

+        let isSvOperator = flip Map.member svs
+        require "svOperator is an SV operator" $ isSvOperator svOperator
+
+        unless (hostedSvHasBeenOnboardedBefore newSvName this) $


do I read it correctly that this is intended for the migration path so you call it for all existing SVs? if so probably worth documenting this here

Not really. This relates to the case where a hosted SV has been offboarded and then onboarded again.

As I mention above, I mirrored the current SV onboard/offboard flow. In that flow, when an SV (SV operator) is offboarded, the corresponding SvRewardState is not archived. So if we onboard it back, we need reuse the old SvRewardState contract.

In the proposed migration path, I archive the SvRewardState contract of the SV operator. Then, here, I create SvRewardState contracts for the hosted SVs.

I think this is solved, right @moritzkiefer-da ?

moritzkiefer-da · 2026-05-27T09:45:48Z

+data SvMigrationData = SvMigrationData with
+    svParty : Party -- ^ The SV party.
+    svName : Text -- ^ Human-readable name; must be unique.
+    svParticipantId : Text -- ^ Participant ID of the SV.


I don't understand why you need participant ids for random non-node operator svs.

I can remove it (again, I mirrored the SV node flows).
@isegall-da

I’ll proceed with removing svParticipantId unless there are objections.

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

…vRewardBeneficiaries with empty beneficiaries to the onboard flow of a hosted SV Signed-off-by: Jose Velasco <jose.velasco@intellecteu.com>

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

draft initial commit (no daml tests)

3b91899

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