Draft CIP-XXX: CC Locking Module - Phase 2 Primitive#2
Conversation
Initial Standards Track draft of the on-chain CC locking primitive required to satisfy Phase 2 enforcement of CIP-0105 and CIP-0116, and the Lock Substitution provision of the SV Locking Operational Guidelines. Specifies the network primitive's compute / enforce / expose requirements: two-state token model, ActiveLockContext / VestingLockContext lifecycle, beneficiary attribution and aggregation, alternative authorization sets for unlock / withdraw / substitution, atomic Lock Substitution (replacing the Phase 1 24-hour add-then-swap window), and the event surface for indexers, dashboards, and underlock / restoration enforcement. Summarizes Path A (Amulet root state) and Path D (sibling template) from the working-group requirements document as illustrative implementation paths; final path selection is deferred to Splice contributor engineers and remains open to further engineering input. Authors: Luke Farrell (Cashen), Ian Hensel (Avro) w/ Community Working Group.
|
I did a review of Test plan bullet 1. |
| - **Lock creation is unilateral (§4.4.5).** A holder can create an `ActiveLockContext` against any beneficiary they choose, contributing to that beneficiary's aggregate. Beneficiaries that do not wish to receive locks from arbitrary holders should consider this when defining substitution and withdraw authorization arrangements with counterparties (the operational, not protocol, layer). | ||
| - **Underlock event timing (§4.5.3).** The event fires at the round in which the threshold is crossed. Foundation tooling that triggers penalties at the round level needs to accept this cadence; tooling that batches events on a slower cadence may delay enforcement actions defined in CIP-0105 §6. | ||
|
|
||
| ## 10. Open discussion points |
There was a problem hiding this comment.
1 - implementation specific
2 - Leave to tech choice, implementation question
3 - can strike
4 - leave too tech choice
5 - state, assert that rewards can be emitted in locked state.
6 - leave too tech choice
|
|
||
| The shape of the token-layer state is the point of divergence between the candidate paths (see §6). | ||
|
|
||
| ### 4.8 Reward attribution (work in progress) |
There was a problem hiding this comment.
per Wayne
Include ability to allocate earned coupons to multiple beneficiaries and also to allocate minting actions into locked and liquid states
I need to verify the language here, remove the WIP status
- Move Source documents out of section 3 (already covered by section 11 References); add a one-line pointer instead. - Rework section 4.3.2 to state that beneficiary-type storage is left to the implementation, rather than flagging it as an open working-group question with a section 10 cross-reference. - Update section 6.5 cross-reference to the requirements doc from section 3 to section 11.
Now that section 4.3.2 frames beneficiary-type storage as implementation discretion, the matching entry in section 10 (open discussion points) is redundant. Remove it and renumber the remaining items.
The underlying reward-allocation logic already exists in Canton Coin's
minting and distribution machinery. Section 4.8 now states what the
primitive supports rather than flagging open questions:
- Allocation across multiple beneficiaries (split policy at the
application layer; primitive surfaces attribution data).
- Allocation of minting actions into Locked and Liquid states in
configured proportions.
|
Thanks @Ian-avro, @waynecollier-da, @ericmann, @ali-abrar, @cardenaso11, @cashenLuke and everyone who pushed this forward. Helix supports the direction of the draft and the post-call updates to Section 4.8. Two points I would like to make explicit before this moves from draft PR to CIP Discuss / formal CIP PR:
Acceptance criterion: given the same lock contexts, reward/coupon stream, and round cutoff, independent dashboards should compute the same beneficiary attribution, locked/liquid split, lifetime-rewards denominator, and tier inputs without private spreadsheets or Foundation-only joins. This keeps application/commercial deal logic above the primitive while making the network facts testable from public state. |
|
@vaziliaz seems your message here and my post to cip-discuss crossed paths - CIP-TBD has been posted and is live on forum.
Thank you everyone for your input to get a very strong collaborative document that should shorten the timeline to get |
3 participants
Summary
Initial Standards Track draft of the on-chain CC locking primitive required to satisfy Phase 2 enforcement of CIP-0105 (SV Locking) and CIP-0116 (Featured App Locking), plus the atomic form of the Lock Substitution provision from the SV Locking Operational Guidelines.
ActiveLockContext/VestingLockContextlifecycle, beneficiary attribution, alternative authorization sets for unlock / withdraw / substitution, atomic Lock Substitution (replacing the Phase 1 24-hour add-then-swap window), and the event surface needed for indexers, dashboards, and underlock / restoration enforcement.Authors: Luke Farrell (Cashen), Ian Hensel (Avro) w/ Community Working Group. CIP number is a placeholder; CIP editors assign the real number at acceptance.
Test plan