CIP-0127 (draft) | Cantonscan

Andrew Bryan

Oct 8, 2026

Thank you for posting the updated CIP draft. We have a couple smaller comments:

I think it's potentially operationally dangerous to have on-chain locking go live substantially before substitution and transfers as it could prevent lockers from appropriately managing changes to their technical infrastructure.
I think the statement in the rationale section indicating that a motivating factor is to "Maximize the total value locked on-chain." is incorrect given my reading of the rest of the document and the desire to implement CIPs 0105 and 0116. I think a more accurate rationale statement is "Maximize economic alignment between actors as described in CIP-0105 and CIP-0116, while minimizing operational frictions of the locks"

Separately from the above, i think CIP-0105 lacked clarity on a couple items and should be further specified as part of the automation implementation:

Unlocking at the expiration of the locking requirement. CIP-0105 indicates that the locking requirement will "automatically terminate 30 days after the date of next step down in rewards/halving" but doesn't specify how this should happen. Instead of immediately releasing all CC as specified in this draft, I'd recommend transitioning all locked CC into the unlock vesting state to allow for a more orderly network transition.
Timing for Under-locking Penalties. After becoming under-locked for a tier, CIP-0105 indicates that "The under-locked portion of its SV Weight is removed from the active SV pool within 7 days" while it also indicates that after automated locking "SV Weight updates continuously". I'd recommend the network adds specificity to this given automation enables deterministic timelines and much faster enforcement of under-locking penalties:
- If a SV becomes under-locked, it's SV weight is immediately (i.e., in the next round) adjusted to the appropriate lower tier (i.e., updates happen both continuously and within the required 7 days)
- A SV would still have the 30 day grace period to lock and restore it's previous locking tier. Upon re-gaining the next threshold, the SV would immediately (i.e., in the next round) receive their additional weight for that tier

Simon Meier

Oct 9, 2026

These are great comments. See my answers inline below.

Show quoted message

On Thu, Oct 8, 2026 at 8:48 PM Andrew Bryan via lists.sync.global <abryan=cumberland.io@...> wrote:

Thank you for posting the updated CIP draft. We have a couple smaller comments:

I think it's potentially operationally dangerous to have on-chain locking go live substantially before substitution and transfers as it could prevent lockers from appropriately managing changes to their technical infrastructure.

Yes, I agree. I'll incorporate that into the draft for the revised compatibility mode that I'm working on.

I think the statement in the rationale section indicating that a motivating factor is to "Maximize the total value locked on-chain." is incorrect given my reading of the rest of the document and the desire to implement CIPs 0105 and 0116. I think a more accurate rationale statement is "Maximize economic alignment between actors as described in CIP-0105 and CIP-0116, while minimizing operational frictions of the locks"

Agreed. It also seems to me that this rationale is already covered by the two business level CIPs. I thus opted to remove that list item.

Separately from the above, i think CIP-0105 lacked clarity on a couple items and should be further specified as part of the automation implementation:

Unlocking at the expiration of the locking requirement. CIP-0105 indicates that the locking requirement will "automatically terminate 30 days after the date of next step down in rewards/halving" but doesn't specify how this should happen. Instead of immediately releasing all CC as specified in this draft, I'd recommend transitioning all locked CC into the unlock vesting state to allow for a more orderly network transition.

Indeed. I have adjusted the CIP proposal to only terminate the enforcement of underlocking 30 days after the next halving. I expect the lock owners to go through the normal unlocking workflows thereafter given that their SV locks are no longer required. This way no special automation needs to be built and all SV locks always go through vesting.

I packaged this change into its own commit, making it easy to back out if it proves controversial: https://github.com/canton-foundation/cips/pull/250/changes/609f24adbfca0ea57a1b94561cf2587fa41f8c51

Timing for Under-locking Penalties. After becoming under-locked for a tier, CIP-0105 indicates that "The under-locked portion of its SV Weight is removed from the active SV pool within 7 days" while it also indicates that after automated locking "SV Weight updates continuously". I'd recommend the network adds specificity to this given automation enables deterministic timelines and much faster enforcement of under-locking penalties:

If a SV becomes under-locked, it's SV weight is immediately (i.e., in the next round) adjusted to the appropriate lower tier (i.e., updates happen both continuously and within the required 7 days)

A SV would still have the 30 day grace period to lock and restore it's previous locking tier. Upon re-gaining the next threshold, the SV would immediately (i.e., in the next round) receive their additional weight for that tier

That's a good point. I adjusted the CIP text and its examples to immediately enforce temporary underlocks.

I also packaged this change into its own commit, making it easy to back out if it proves controversial: https://github.com/canton-foundation/cips/pull/250/changes/0ade343b21040bb88e11e03e325beed07cbe9856

The revised draft is available at the same preview address: https://github.com/meiersi-da/cips/blob/meiersi/sv-and-fa-locking-implementation/cip-sv-and-fa-locking-implementation/cip-sv-and-fa-locking-implementation.md

It also contains a changelog at the bottom: https://github.com/meiersi-da/cips/blob/meiersi/sv-and-fa-locking-implementation/cip-sv-and-fa-locking-implementation/cip-sv-and-fa-locking-implementation.md#changelog

Many thanks for the helpful input,

Simon

	Dr. Simon Meier
	Principal Architect			simon@...
				Creators of Canton

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

""""

FA and SV locking implementation

Discussion