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

moritzkiefer-da · 2026-07-15T12:42:46Z

+          let GovernanceLockedControllers{..} = governanceLockedControllersFromMeta locked.meta ownerParty
+          require "Unlock controller must be one of the options" $ any (\conj -> all (`elem` authorizers) conj) unlockControllerSets
+          require "Not allowed to unlock to a different party than locked the funds" $ locked.allocation.authorizer == withdrawTo.allocation.authorizer
+          if not allowImmediateUnlock then require "Unlock without vesting is only allowed when specifically enabled" False else pure ()


I don't understand what this field is for. When do you want unlock without vesting?

In (https://docs.google.com/document/d/1VGtgNSNHrHnSLggqxlvhCTFrMPgaeCs2OLEJ8Fq9Ar4/edit?tab=t.0) under the Aggregated Locking Requirements, FR-25 says "It must be possible to require that locked coins only be unlocked through the vesting process." which is phrased in such a way as to suggest that this requirement is an optional possibility.

FR-26 says "It must be possible to permit immediate unlocks of all coins locked to an Aggregate Lock, to support Featured App non-approval; when in this state the vesting process is not required."

I might be misinterpreting how an implementation of that would look (just getting spun up on the details of this project still), but this might be related.

When you've tried to set up a Featured App, locked the required amulet to satisfy the threshold requirement, and then failed to actually become a Featured App at this time. CIP-0116 says that "if an application is not approved, CC may be moved immediately", and I am defaulting to "implement things in the CIP on-chain if reasoable". No objection to specifying a different process for handling that scenario.

ok that makes sense to handle. But your implementation only seems to handle the case where allowImmediateUnlock = True and otherwise just fail in the require instead of doing vesting?

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

+      where
+        controller authorizers
+        do
+          locked <- view <$> fetch lockedCid


use the various checked fetch variants, CI is also gonna fail on this

moritzkiefer-da · 2026-07-15T13:28:56Z

+                      instrumentId
+                      meta = emptyMetadata
+                    ]
+                  nextIterationFunding = Some $ TM.singleton instrumentId newLockedAmount


The math doesn't add up for me. locked locks up currentLockedAmount. You are now trying to unlock amount. So newLockedAmount is currentLockedAmount - amount. But then you are trying to create two allocations with nextIterationFunding for that amount?

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.

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.

moritzkiefer-da · 2026-07-20T12:56:56Z

+        controller authorizers
+        do
+          -- remainingLocked stays in nextIterationFunding
+          vestingLock <- view <$> fetch vestingLockCid


no naked fetches

moritzkiefer-da · 2026-07-20T12:57:34Z

+
+          -- TODO: Probably add valid unlockController set check?
+          -- TODO: Potentially do case statement with nextIterationFunding optionals
+          require "There are no remaining funds to withdraw"


assertion text is the wrong way around, you should state the property that should hold. so "there are remaining funds to withdraw"

moritzkiefer-da · 2026-07-20T12:59:42Z

+        authorizers : [Party]
+        vestingLockCid : ContractId Allocation
+      where
+        controller authorizers


there are zero checks on authorizers

moritzkiefer-da · 2026-07-20T13:10:21Z

+          let GovernanceLockedControllers{..} = governanceLockedControllersFromMeta locked.meta ownerParty
+          require "Unlock controller must be one of the options" $ any (\conj -> all (`elem` authorizers) conj) unlockControllerSets
+          require "Not allowed to unlock to a different party than locked the funds" $ locked.allocation.authorizer == withdrawTo.allocation.authorizer
+          if not allowImmediateUnlock then require "Unlock without vesting is only allowed when specifically enabled" False else pure ()


Suggested change

if not allowImmediateUnlock then require "Unlock without vesting is only allowed when specifically enabled" False else pure ()

require "Unlock without vesting is only allowed when specifically enabled" allowImmediateUnlock

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

moritzkiefer-da · 2026-07-20T14:41:25Z

+
+  AmuletRegistryV2.tapFaucet registriesEnv.amuletV2 bob 1800.0
+
+  aggLock <- submit (actAs [alice, dso]) $ createCmd AggregateLock with


you can't assume that you can submit with both alice and dso as actAs. Getting authorization right is a crucial part in Daml models so let's please not "cheat" here

in this case I also don't understand why you even need actAs alice, the only signatory seems to be DSO.

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

fix tests

29e569e

jonored requested a deployment to ci-forks July 20, 2026 17:53 — with GitHub Actions Waiting

		lockedCid : ContractId Allocation
		withdrawToCid : ContractId Allocation


		type ControllerSets = [[Party]]

		partiesFromText : Text -> Optional [Party]

	if not allowImmediateUnlock then require "Unlock without vesting is only allowed when specifically enabled" False else pure ()
	require "Unlock without vesting is only allowed when specifically enabled" allowImmediateUnlock


		AmuletRegistryV2.tapFaucet registriesEnv.amuletV2 bob 1800.0

		aggLock <- submit (actAs [alice, dso]) $ createCmd AggregateLock with

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!

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!

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!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants