WIP: cip 0105 externally implemented governance locks by jonored · Pull Request #6427 · canton-network/splice

jonored · 2026-07-15T11:52:11Z

WIP code for possible direction for CIP-0105 locking implementation using the existing AmuletAllocationV2 unmodified, for reference only. Do not merge.

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 an upgrade test is required, comment /upgrade_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).

…ations.

moritzkiefer-da · 2026-07-15T12:38:43Z

+-- vesting to be in a separate dar from amulet only needed for SVs and
+-- interested observers.
+
+template AggregateLock


unclear to me why this is a separate template, ideally this would be done through the withdraw choice. If that is not an option, it seems like this could just be a choice on ExternalPartyAmuletRules

comment still applies

Current in-progress plan is to remove at least the choices (moving to allocation withdraw), and probably the whole template. The remaining pieces that need to land somewhere else are early unlock support (which may be it's own tiny "allow early unlock" template provided as context to withdraw) and producing an appropriate key to group lock allocations with.

moritzkiefer-da · 2026-07-15T13:29:47Z

+        lockedCid : ContractId Allocation
+        withdrawToCid : ContractId Allocation


Can you add some comments on how you expect the two allocations to be used? it's not clear to me. Or even better add the test script.

comment still applies, add some comments on what the allocations are supposed to represent

lockedCid was the active lock and withdrawTo was a fresh allocation to hold the withdrawn-to-vesting funds. Removed with the move to integrate into allocation withdraw, where the contract operates explicitly with the holder's authority as well as whatever is in the flexible controller lists.

moritzkiefer-da · 2026-07-15T13:31:10Z

+
+type ControllerSets = [[Party]]
+
+partiesFromText : Text -> Optional [Party]


there are a bunch of utilities already e.g. parseCommaSeparated, let's reuse those instead of reimplementing half of them.

comment still applies

Should be fixed below. Do we want to do the same with controllerSetFromMeta and make a helper utility function for semi-colons?

…ed-governance-locks' into jg/cip-0105-externally-implemented-governance-locks

Dpak/cip 105 v2 vesting

…evelopment cycles by allowing the LSP to work cross-package when working on code.

Fix some issues related to PR comments for VestingLock

moritzkiefer-da · 2026-07-24T11:29:41Z

  partiesToMeta,
  dropMeta,
  validateNoMeta,
+  -- TODO: Is exporting the below cool?


yes that's ok

moritzkiefer-da · 2026-07-24T11:30:25Z

+  -- Lock some funds for the aggregate
+  AllocationInstructionResult { output = AllocationInstructionResult_Completed locked } <- lockForAggregate env 1000.0 bob aggLock
+
+  -- Check total for the aggregate; needs to be implemented.


let's actually add that

Total check in the test is on the way.

moritzkiefer-da · 2026-07-24T11:32:10Z

+
+type ControllerSets = [[Party]]
+
+partiesFromText : Text -> Optional [Party]


comment still applies

moritzkiefer-da · 2026-07-24T11:32:18Z

+-- vesting to be in a separate dar from amulet only needed for SVs and
+-- interested observers.
+
+template AggregateLock


comment still applies

moritzkiefer-da · 2026-07-24T11:32:32Z

+-- "the settlement" for the allocations locked to it, and use iterated
+-- settlement to execute updates on the committed allocations as needed.
+-- This approach would permit most of the specific governance locking and
+-- vesting to be in a separate dar from amulet only needed for SVs and


separate dar comment doesn't make much sense imho

Discussed and agreed given the additional context, removal of most or all is in progress.

moritzkiefer-da · 2026-07-24T12:52:09Z

+
+          -- We should have one result from settleBatch
+          require "VestingUnlock_Withdraw should result in one allocation result. " $
+            L.length batchResults.allocationSettleResults == 1


similar as above with the isNone + fromSome, don't first do an assertion and then a partial match but instead just pattern match directly

Should be much cleaner: https://github.com/canton-network/splice/pull/6427/changes#diff-42bf48da99a7b4ebce12dcb026f648b6e7214a957e5380695103d9c2a839015cR264

moritzkiefer-da · 2026-07-24T12:52:39Z

+
+  assert $ length allocations == 2
+
+  -- Need to check other than via inspection that the two allocations actually exist with correct values.


let's add it

moritzkiefer-da · 2026-07-24T12:52:59Z

+
+  now <- getTime
+  let initialAmountToUnlock = 365.25
+  AllocationInstructionResult { output = AllocationInstructionResult_Completed vestingInput } <- lockForVesting initialAmountToUnlock (addRelTime now $ minutes 5) env bob aggLock


why + 5 min

There was a condition in validateVestingSchedule which said now < start which would not be satisfied unless there was a strict time difference there. Unless there's a good reason, that maybe ought to be now <= start, and I don't see any reason in our design doc, but perhaps @jonored knows better?

<= seems fine

5 mins is removed, and we now check <=: https://github.com/canton-network/splice/pull/6427/changes#diff-42bf48da99a7b4ebce12dcb026f648b6e7214a957e5380695103d9c2a839015cR69

moritzkiefer-da · 2026-07-24T12:53:14Z

+    authorizers = [ bob ]
+    vestingLockCid = toInterfaceContractId vestingLockAllocationCid
+    extraArgs = enriched.arg.extraArgs
+  debug vestingAllocResult


let's remove all these random debugs

moritzkiefer-da · 2026-07-24T12:53:31Z

+  let [(_, (Some unlockedHolding))] = filter (\(hcid, (Some h)) -> isNone h.lock && hcid `elem` holdingCids) holdings
+  debug unlockedHolding
+
+  let tolerance = 0.01


what's the tolerance for? I don't see why you can't do an exact computation in your test

This tolerance is because the actual number is extremely close to, but not exactly 10. However, it might be best just to copy the computed number into the test, given that Decimal is fixed point, an exact equality comparison is not as bad as it might otherwise be for floating point. To get a nice round number of tokens here, we'd need to very precisely compute the time interval we waited for (there is presumably some number of microseconds at which the value is exactly 10).

Tolerance has been removed and we now have an exact Decimal instead: https://github.com/canton-network/splice/pull/6427/changes#diff-c33c401bd06c2f019c9f1901af1c6d7225d6f1a3193e4b7d6d06da3262069646R141

moritzkiefer-da · 2026-07-27T10:49:10Z

@@ -0,0 +1,29 @@
+#!/usr/bin/env bash


change is merged, please rebase and remove from this pr

Yeah, that was an accident because I'd previously cherry-picked it onto the branch. Sorry!

Address some CIP-0105 PR comments

…ing up development cycles by allowing the LSP to work cross-package when working on code." This reverts commit 15dfa70.

…y-implemented-governance-locks

jonored and others added 5 commits July 14, 2026 11:15

WIP of user-of-allocations code

6c8b68a

WIP: Potentially fix some errors/imports

63a9f45

WIP correct some more fields and functions

082ca6f

WIP fixing type errors in AggregageLock.daml

dcd3af3

WIP: externally-defined governance lock implementation using V2 alloc…

5b42656

…ations.

jonored had a problem deploying to ci-forks July 15, 2026 11:52 — with GitHub Actions Error

canton-network-da assigned isegall-da, martinflorian-da, rautenrieth-da and ray-roestenburg-da Jul 15, 2026

jonored marked this pull request as draft July 15, 2026 11:52

moritzkiefer-da reviewed Jul 15, 2026

View reviewed changes

moritzkiefer-da unassigned rautenrieth-da, ray-roestenburg-da, isegall-da and martinflorian-da Jul 15, 2026

WIP: Converting Vesting state to use the V2 Allocations

101c58b

dbzguy56 had a problem deploying to ci-forks July 15, 2026 21:53 — with GitHub Actions Error

WIP Fixing withdrawing from VestingLock choice

cbf22de

dbzguy56 had a problem deploying to ci-forks July 16, 2026 20:06 — with GitHub Actions Error

moritzkiefer-da reviewed Jul 20, 2026

View reviewed changes

jonored added 2 commits July 20, 2026 14:34

WIP: Test for lock-to-aggregate and unlock, and bug fixes.

fd4c8a7

Merge remote-tracking branch 'public/jg/cip-0105-externally-implement…

9de20ca

…ed-governance-locks' into jg/cip-0105-externally-implemented-governance-locks

jonored had a problem deploying to ci-forks July 20, 2026 14:39 — with GitHub Actions Error

moritzkiefer-da reviewed Jul 20, 2026

View reviewed changes

Comment thread daml/splice-amulet-test/daml/Splice/Scripts/TestAggregateLocks.daml Outdated

Comment thread daml/splice-amulet-test/daml/Splice/Scripts/TestAggregateLocks.daml Outdated

fix tests

29e569e

jonored had a problem deploying to ci-forks July 20, 2026 17:53 — with GitHub Actions Error

dbzguy56 added 3 commits July 20, 2026 21:21

WIP Start adding VestingLock Testing

7e1be84

WIP Flush out vestingUnlock tests more

661fbe5

Finish basic happy test for vestingUnlock

f722c80

dbzguy56 added 2 commits July 21, 2026 22:01

Move passTime within vesting happy path test

457febe

Merge pull request #3 from obsidiansystems/dpak/cip-105-v2-vesting

973c20c

Dpak/cip 105 v2 vesting

dbzguy56 had a problem deploying to ci-forks July 21, 2026 22:03 — with GitHub Actions Error

Add a script which constructs a fake single package for speeding up d…

15dfa70

…evelopment cycles by allowing the LSP to work cross-package when working on code.

cgibbard had a problem deploying to ci-forks July 22, 2026 20:44 — with GitHub Actions Error

dbzguy56 added 2 commits July 22, 2026 20:47

Fix some issues related to PR comments for VestingLock

e4e35f7

Merge pull request #4 from obsidiansystems/dpak/cip-105-v2-vesting

2bd6b3d

Fix some issues related to PR comments for VestingLock

dbzguy56 had a problem deploying to ci-forks July 23, 2026 16:34 — with GitHub Actions Error

moritzkiefer-da reviewed Jul 24, 2026

View reviewed changes

Address some CIP-0105 PR comments

4b29e95

moritzkiefer-da reviewed Jul 27, 2026

View reviewed changes

Merge pull request #5 from obsidiansystems/dpak/cip-105-v2-vesting

76bf6d1

Address some CIP-0105 PR comments

cgibbard had a problem deploying to ci-forks July 27, 2026 17:04 — with GitHub Actions Error

Revert "Add a script which constructs a fake single package for speed…

c0da78d

…ing up development cycles by allowing the LSP to work cross-package when working on code." This reverts commit 15dfa70.

cgibbard had a problem deploying to ci-forks July 27, 2026 17:14 — with GitHub Actions Error

Merge remote-tracking branch 'origin/main' into jg/cip-0105-externall…

b49c176

…y-implemented-governance-locks

cgibbard had a problem deploying to ci-forks July 27, 2026 17:17 — with GitHub Actions Error

jonored and others added 4 commits July 28, 2026 14:54

WIP: hook the withdraw-like operations to withdraw.

bde618e

Fixes to rebase and update tests

0f752f1

Fix tests and a couple bugs in vesting withdraw.

f312c8a

Fixes and test updates.

d601e0e

jonored requested a deployment to ci-forks July 28, 2026 23:39 — with GitHub Actions Waiting

		lockedCid : ContractId Allocation
		withdrawToCid : ContractId Allocation


		type ControllerSets = [[Party]]

		partiesFromText : Text -> Optional [Party]


		assert $ length allocations == 2

		-- Need to check other than via inspection that the two allocations actually exist with correct values.

Uh oh!

Conversation

jonored commented Jul 15, 2026

Pull Request Checklist

Cluster Testing

PR Guidelines

Merge Guidelines

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!

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!

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!

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!

Reviewers