[POC] 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 hosted SV weight model. The goal is to represent SV reward weights fully on-ledger, including SV beneficiary distributions. Additionally, a new SV node onboarding flow is implemented.

The actual implementation will consist of two phases:

Phase 1: SV weights fully on-ledger, including hosted SV lifecycle management, beneficiary distributions, migration, and V2 reward coupon creation.
Phase 2: New SV node onboarding + deprecation of unneeded legacy choices.

Phase 1

TODO

Phase 2

TODO

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>

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>

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

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

isegall-da · 2026-06-10T21:48:10Z

      with
-        newHostedSvParty : Party
-        newHostedSvName : Text
+        newHostedSv : Party


hmm, why did you remove the name? I believe we do want also a human-readable name in addition to the party.

ok, I will add it

isegall-da · 2026-06-10T21:51:52Z

-            pure DsoRules_UpdateHostedSvWeightResult with newDsoRules
+        hostedSv <- fetchAndArchive (ForDso with dso) hostedSvCid
+        newHostedSvCid <- create hostedSv with rewardWeight = newRewardWeight
+        pure DsoRules_UpdateHostedSvWeightResult with newHostedSvCid


Shouldn't we just have a consuming choice in HostedSv controlled by the dso, and call it from here?

ok, I will add it

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

moritzkiefer-da

Thanks, this looks directionally correct. But I think the vetting assumptions are not gonna work out.

We should aim to keep the property that non-SV node operators do not need to vet dso-governance and instead only need to vet amulet. Right now the way you have set observers this will not work in practice.

I'm also a bit unclear on the trust assumptions. It seems like we may be giving the SV operators a bit too much power here.

moritzkiefer-da · 2026-06-11T10:17:11Z

+    -- ^ Voted action to instruct the update of the SV operator for a hosted SV.
+  | SRARC_AddSvNode DsoRules_AddSvNode
+    -- ^ Voted action to directly add an SV node.
+  | SRARC_OffboardSvNode DsoRules_OffboardSvNode


you added 3 new variants here but did not deprecate SRARC_AddSv, SRARC_offboard_SV and SRARC_ConfirmSvOnboarding. When will we use which of them?

I've added some notes like this one:

-- Note: Deprecate in phase 2 choice DsoRules_AddSv : DsoRules_AddSvResult

Note that this is just a POC, not a final Daml PR

Note that this is just a POC, not a final Daml PR

That's fine. What I would suggest is to add clear TODOs/FIXME comments for everything you're skipping over at this point.

moritzkiefer-da · 2026-06-11T10:22:29Z

  deriving (Eq, Show)

+
+-- Note: Implement in phase 1


Maybe add a TODO or FIXME here. I don't mind these phase comments for this PR but they should be gone in the final implementation.

moritzkiefer-da · 2026-06-11T10:39:08Z

+      -- reward weight percentages. Each beneficiary party must be unique.
+  where
+    ensure
+      unique (map fst beneficiaries)


any reason not to make this a Map so you don't need the unique assertion?

Asked differently: Is the order significant?

It makes sense

moritzkiefer-da · 2026-06-11T10:42:21Z

+        && notElem hostedSv (map fst beneficiaries)
+
+    signatory dso
+    observer hostedSv


Let's please add comments in all the places where we add extra observers on why we need them. Generally we should aim to limit them as much as possible to avoid potential vetting issues.

Given your comment

We should aim to keep the property that non-SV node operators do not need to vet dso-governance and instead only need to vet amulet. Right now the way you have set observers this will not work in practice.

I can remove hostedSv as an observer, since it is not necessary: the DSO controls all the flows.

We need to keep it as the hostedSv needs to exercise HostedSv_UpdateBeneficiaries

moritzkiefer-da · 2026-06-11T10:43:33Z

+    ensure rewardWeight > 0
+
+    signatory dso
+    observer hostedSv


If you make the hostedSv an observer on this, each hostedSv needs to now have vetted the dso packages. Is that a valid assumption? It is definitely not given for how hosted SVs are used through beneficiaries today.

I agree, I will remove it.

We need to keep it as the hostedSv needs to exercise HostedSv_UpdateBeneficiaries

choice HostedSv_UpdateBeneficiaries : HostedSv_UpdateBeneficiariesResult with newBeneficiaries : Map Party Decimal controller hostedSv

Do you think we still need a comment about why we need hostedSv to be an observer?

moritzkiefer-da · 2026-06-11T10:44:37Z


            return DsoRules_OffboardSvResult with ..

+    -- Note: Implement in phase 2


don't really understand the comment if you're already implementing it.

Ok, I will remove all the comments regarding phases.

moritzkiefer-da · 2026-06-11T10:45:43Z

+        svOperator : Party
+      controller dso
+      do
+        require "There is more than one sv node" (Map.size svs > 1)


related to my comment above on deprecating the other choices, it's not obvious to me how this is different from the other offboard choice

It is just about naming.
@isegall-da requested this

A whole new choice just for changing the name? @isegall-da that seems pretty questionable to me.

Ha? I don't think I requested this.
I only requested that in new choices we are explicit and consistent in naming, and said "unfortunately we cannot fix this in existing choices". Did not mean to suggest that we should reimplement the existing ones for this.

My bad, I misunderstood your suggestion.

moritzkiefer-da · 2026-06-11T11:06:43Z

+          -- ^ The full beneficiary distribution to set.
+        svOperator : Party
+          -- ^ The SV node operator hosting the hosted SV whose beneficiary distribution is being managed.
+      controller svOperator


so a hosted SV gets unilateral control over the beneficiaries? So if I'm hosting 10 SVs I can just change all their beneficiaries to myself and get their rewards until someone notices? That seems kinda bad. You do have to trust an SV operator for availability so if it's down (malciously or not) you don't mint but giving them the power to just mint everything to themselves seems much worse.

The SV node operator has control over their hosted SV beneficiaries. This was a requirement and trust assumption raised by @isegall-da and @waynecollier-da.

@isegall-da @waynecollier-da can you expand why we want this? It makes sense that each hosted SV can configure their beneficiaries. But the fact that an SV operator can configure the beneficiaries of all SV hosted on them seems super dodgy. The whole point of the on-ledger weights is to have this properly governed and not just fully under the control of the operator. This essentially fully undoes that and the SV operator can again freely chose how it splits the minted rewards for SVs hosted on its node.

AFAICT the requirement was that the hosted SV (not the operator) can change beneficiaries without a vote.
We accepted the trust assumption that "the hosted SV fully trusts the operator anyway, so might as well trust them to set the beneficiaries for them", but I wouldn't call that a requirement.

The problem is that currently we don't plan to have a UI for hosted SVs which is why I thought "just send an email to your operator to do it for you" is acceptable for now.

More than happy for better ideas how not to require this strong of a trust.

Can you please confirm this?

HostedSv template will live in splice-amulet, HostedSv_UpdateBeneficiaries is controlled by hostedSv, and HostedSv_UpdateBeneficiaries is exercised directly via the contract.
The rest will be managed via DsoRules.

template HostedSv with dso : Party -- ^ The DSO party. hostedSv : Party -- ^ The hosted SV party whose reward coupons are created by the SV operator. svOperator : Party -- ^ The SV node operator party responsible for creating reward coupons for -- 'hostedSv'. rewardWeight : Int -- ^ The hosted SV reward weight. Must be strictly greater than 0. hostedSvName : Text -- ^ Human-readable name of the hosted SV. beneficiaries : [(Party, Decimal)] -- ^ Beneficiary parties, excluding 'hostedSv', and their corresponding positive -- reward weight percentages. Each beneficiary party must be unique. where ensure rewardWeight > 0 && unique (map fst beneficiaries) && all (> 0.0) (map snd beneficiaries) && sum (map snd beneficiaries) <= 1.0 && notElem hostedSv (map fst beneficiaries) signatory dso observer hostedSv choice HostedSv_UpdateRewardWeight : HostedSv_UpdateRewardWeightResult with newRewardWeight : Int controller dso do hostedSvCid <- create this with rewardWeight = newRewardWeight pure HostedSv_UpdateRewardWeightResult with hostedSvCid choice HostedSv_UpdateBeneficiaries : HostedSv_UpdateBeneficiariesResult with newBeneficiaries : [(Party, Decimal)] controller hostedSv do hostedSvCid <- create this with beneficiaries = newBeneficiaries pure HostedSv_UpdateBeneficiariesResult with hostedSvCid

Ah I missed the fact that we now also merged the templates. In that case, maybe let's actually keep it in dso-governance. Moving everything seems like a bit of a mess. Let's be clear in the design doc though that this will require changes to the validator app to support configuring it such that it vets dso governance packages.

we now also merged the templates

Sorry, I suggested that yesterday, missed these potential implications.

changes to the validator app to support configuring it

Maybe add a button/checkbox in the same new wallet UI tab that we discussed above that triggers that vetting, something like "enable hosted SV functionality" or some better wording ?

Maybe add a button/checkbox in the same new wallet UI tab that we discussed above that triggers that vetting, something like "enable hosted SV functionality" or some better wording ?

I would just make it a validator config setting. I don't think you want an end user to allow controlling this.

done
I will add a note about that in the design doc.

moritzkiefer-da · 2026-06-11T11:07:22Z

+    -- Note: Implement in phase 1
+    -- Note: Deprecate in phase 2.
+    --
+    -- Trust assumption:


why would we trust the SV operator to do that and not make it a vote?

Yeah, we might have a temporary vote for the migration.
Please let me know if I should implement that.
cc: @isegall-da

I honestly don't see a big problem trusting the operators to trigger this once, we can manage this through sv-ops procedures and make it mandatory to comply, this doesn't need to be simultaneous for everyone. But also wouldn't object to a vote if you want to go through the trouble of implementing one.

Please let me know how you'd like me to proceed.
@isegall-da @moritzkiefer-da

The part I somewhat dislike is that we're introducing governed on-ledger state but then the introduction of that state is not done through governance but unilaterally. That just feels a bit fishy to me compared to an explicit step where you vote on it. And given that it's a one-time action the overhead in terms of votes seems irrelevant and maybe even desired as everyone needs to review the state the SV set unilaterally anyway.

So I'd still lean towards the vote. @isegall-da what exactly do you mean by "the trouble of implementing one"? From a Daml perspective this adds very little extra. I guess the UI work does have a bit of overhead?

Or maybe we should modify the existing DsoRules_MigrateHostedSvs choice so that it migrates all hosted SVs.

It would be a one-time action for each SV node operator.

sure but that's 13. Not that crazy of a number.

I'd still lean towards a vote but happy to be overruled here.

We'll need to support this vote type everywhere, external explorers will need to parse it, etc.

I also don't feel super strongly against. @jose-velasco-ieu want to be the tie breaker? ;)

In my opinion, as I mentioned in the “trust assumption” section, this just extends the hosted SVs’ trust slightly.
Notice that DsoRules_MigrateHostedSvs checks that the overall weight is not modified.

-- This is consistent with the current model, where the SV operator already configures -- the reward weights and beneficiary distribution in its SV app. Therefore, the SVs -- operated by this SV operator already rely on it to use the correct reward -- distribution.

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

…es HostedSv_UpdateBeneficiaries directly) Signed-off-by: Jose Velasco <jose.velasco@intellecteu.com>

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

…(the contract may change when the vote is effective) Signed-off-by: Jose Velasco <jose.velasco@intellecteu.com>

waynecollier-da · 2026-06-13T13:22:36Z

Let's review and discuss in the Monday governance call. @isegall-da can you put this on the agenda?

isegall-da · 2026-06-13T13:31:46Z

Let's review and discuss in the Monday governance call. @isegall-da can you put this on the agenda?

@waynecollier-da Sorry, are you referring to something specific here, or are you proposing a walkthrough of the entire current state?

waynecollier-da · 2026-06-13T13:39:39Z

The question of whether to require all hosted SVs to vet governance changes. My preference would be to avoid doing that, but I don't understand all the tradeoffs just by reading the discussion above.

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

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

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

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

isegall-da reviewed May 15, 2026

View reviewed changes

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

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

isegall-da reviewed May 27, 2026

View reviewed changes

Comment thread daml/splice-dso-governance-test/daml/Splice/Scripts/TestSvWeights.daml Outdated

isegall-da reviewed May 27, 2026

View reviewed changes

Comment thread daml/splice-dso-governance-test/daml/Splice/Scripts/TestSvWeights.daml Outdated

isegall-da reviewed May 27, 2026

View reviewed changes

Comment thread daml/splice-dso-governance-test/daml/Splice/Scripts/TestSvWeights.daml

Update daml/splice-dso-governance-test/daml/Splice/Scripts/TestSvWeig…

2fcf87c

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

moritzkiefer-da reviewed May 27, 2026

View reviewed changes

jose-velasco-ieu added 10 commits May 27, 2026 12:17

split test (target flow + migration)

d4fba7e

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

document SvMigrationData

9552ebc

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

adjust signatories and observers in SvRewardBeneficiaries template

d09430c

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

cleanup

2c6571c

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

add a note about the three kind of parties in DsoRules

5013aef

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

remove unneeded svParticipantId for hosted svs

927d514

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

make SvRewardBeneficiaries contract mandatory + add the creation of S…

15df700

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

add doc

b448dff

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

enhance DsoRules_AddHostedSvResult

755a5bb

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

set beneficaries in the migration choice

68685bd

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

jose-velasco-ieu added 7 commits June 4, 2026 23:09

naming + leftover

ddb0493

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

daml documentation

dc845a1

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

Add a new flow for onboarding an SV node

9d2344e

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

naming

7a9dcac

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

naming

f60d88b

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

naming

4260d90

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

make sv node operator the controller for managing hosted SV beneficia…

7bf2013

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

isegall-da reviewed Jun 9, 2026

View reviewed changes

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

jose-velasco-ieu added 3 commits June 9, 2026 16:49

naming

6087d72

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

testing - factor out creation of SV coupons V2

9222d3f

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

refactor - one contract per hosted SV approach

83258a3

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

jose-velasco-ieu requested a review from isegall-da June 10, 2026 15:49

isegall-da reviewed Jun 10, 2026

View reviewed changes

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

jose-velasco-ieu added 3 commits June 11, 2026 09:05

add hostedSvName

f6c8d8f

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

add HostedSv_UpdateRewardWeight choice to HostedSv

d99714d

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

remove beneficiaries contract + add beneficiares to HostedSv contract

41377c2

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

moritzkiefer-da reviewed Jun 11, 2026

View reviewed changes

jose-velasco-ieu added 5 commits June 11, 2026 15:22

add FIXMEs

e788d74

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

sv node onboarding - reuse part of the existing flow

7f18474

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

make beneficiaries a map

9bf07b7

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

remove DsoRules_SetHostedSvRewardBeneficiaries (the hosted SV leverag…

794e00e

…es HostedSv_UpdateBeneficiaries directly) Signed-off-by: Jose Velasco <jose.velasco@intellecteu.com>

add HostedSv_UpdateSvOperator

a1dafff

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

jose-velasco-ieu requested review from isegall-da and moritzkiefer-da June 11, 2026 20:00

implement instruction pattern for updating the weight of a hosted SV …

dd1a08b

…(the contract may change when the vote is effective) Signed-off-by: Jose Velasco <jose.velasco@intellecteu.com>


		return DsoRules_OffboardSvResult with ..

		-- Note: Implement in phase 2

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

Phase 1

Phase 2

Pull Request Checklist

Cluster Testing

PR Guidelines

Merge Guidelines

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jose-velasco-ieu commented May 22, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

isegall-da commented May 27, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

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!

Uh oh!

moritzkiefer-da left a comment

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!

jose-velasco-ieu commented May 15, 2026 •

edited

Loading