CIP-0127: FA and SV locking implementation
- Hi all,We are happy to share a proposal for how to implement on-chain SV and FA locks and their enforcement. You can find the full proposal in this PR: https://github.com/canton-foundation/cips/pull/250Here is the abstract explaining its content and motivation:-----
This CIP serves to align the stakeholders of CIP-0105 (SV Locking) and CIP-0116 (FA Locking) on the implementation of on-chain enforcement of SV and FA locking. It is motivated by the fact that the concrete mechanisms chosen to implement locking have a material impact on the operability of SVs, FAs, and staking apps.
The proposed implementation closely follows the high-level guidance laid out by these two CIPs except for the following three minor changes:
Add a grace period for underlocked FA rights during which they are only temporarily suspended. The grace period defaults to seven days and can be changed by SV voting. It serves to reduce the trust that FA operators need to have in their lock owners; and thus increases the expected total amount locked by FA locks.
Require locks to lock a minimum amount to avoid “dust” locks whose management overhead surpasses their value. The minimum lock amount defaults to 10k CC and can be changed by SV voting.
Support configurable controllers for unlocking, substitution and withdrawing vested funds to simplify building staking apps.
The CIP further clarifies the technical integration between wallets and locks; and it proposes incremental delivery and migration paths. Thereby creating clarity for the work required from the stakeholders to land on-chain enforcement of SV and FA locks on MainNet.
-----You can find a preview of the full-text here.Obsidian and DA created this implementation proposal as part of DevFund grant "2026-04-Obsidian-CIP-0105". We have already received positive reviews from multiple stakeholders. We are sharing this CIP here for the community to learn about it and provide additional feedback. Timely feedback is appreciated, as we would like to start implementing this in the coming months.Thank you for your input.Kind regards,Simon--Dr. Simon Meier
Principal Architect
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. - Hi all,the design including the full Daml implementation of the CIP proposal from this discussion thread is progressing well. You can see the progress on this preview PR: https://github.com/canton-network/splice/pull/7415/changesSo far we've received positive feedback on the CIP itself (and some questions that we answered) out-of-band. We'd also be happy to hop on a call to answer questions you might have. To organize that call, we'd appreciate if interested parties could reply to this email, so we can find a common time. Alternatively you are most welcome to comment directly on the PR proposing the implementation of SV and FA locking: https://github.com/canton-foundation/cips/pull/250/changesKind regards,Simon Meier
- Hi All,Cumberland would like to propose an adjustment to the current proposal to enable transfer of locks between wallets and similar use cases where existing locks are used instead of pre-funding. To do this, a substitution should be able to "transfer" locked CC from an existing lock to the newly created lock in lieu of prefunding with additional locked CC. This would require the approval of the initial lock owner.We think this can be modeled via an additional parameter on substitutions, "transferAmount", which represents the amount of CC lock to be transferred from the existing lock to the newly created lock UTXO. Some details:
- The transferAmount should be deducted from the existing lock and added to the new one
- The ending lock must have the same benefiting SV or FA as the initial lock from which the transferAmount was sourced. The transferAmount cannot be used to "transfer" lock from one SV or FA to another
- The transferAmount should be optional (i.e., it can be 0) within a substitution
- Any transferAmount must be used in the newly created lock UTXO and cannot be entirely unlocked
- Any vesting or other unlocking parameters on the locked cc used in transferAmount must be unchanged in the newly created lock
An example below:In a substitution proposal with:- new lock party_id owner = B
- fundingAmount (the prefunded amount) = 0.0
- transferAmount (the non-prefunded amount taken from the lock) = 5M CC
To substitute from a lock of:- existing lock party_id owner = A
- amount = 5M CC
Would result the following changes to locks:- A new lock with:
- party_id owner B
- amount = 5M CC
- No remaining lock for party_id owner A
- No funds returned to party_id A
Please let us know any feedback, and happy to discuss furtherThanks,Andrew - Hi Andrew
This is essentially liquid staking from my initial read?
One thing to consider is the case where an FA has borrowed CC from a locked party on direct commercials. So if the lock is an FA support collateral the FA should be a party on the transfer.
Daryn.
- this look more likely to be used when an existing locked wallet owner wants to migrate to a new partyID they also control without needing double the capital
for example, migrating from one host (custodian, wallet, or validator) to another that is controlled by the same owner.the pre-funded substitution (already scoped) is used when the owner of the existing lock and the new lock are different - Yes that makes sense. Given there is inherent protection to the FA or SV - the beneficiary of the lock stays same - a natural extension of that is the beneficiary is a party. Similar to assignment of debt.
- I've found it helpful to think of two use cases for substitution:
1. Locked funds are controlled by the same entity, but they want to change the wallet where the locked funds are recorded. In this case funds transfer from one wallet to another, no new funds are locked, and nothing gets unlocked.
2. Locked funds are no longer provided by one entity, and are instead being provided by a different entity. In this case new funds are locked, and existing funds are unlocked.I think it's feasible to support both cases, though I'll let Simon Meier (the CIP author) confirm. - I agree with Wayne on the differences in use cases in scope. Our goal with the proposed addition is to allow a SV or FA to transfer between their own wallets when needed for operational purposes such as transitioning between custody providers.
- I believe this is a much-needed addition that will help our work at the SVAC.
Currently we are looking at SVs that move locked CC from one wallet to another
and the frequent response we get is "internal operations".
This will provide clarity and more operational freedom to SV operators.
Y.
On Mon, Oct 5, 2026 at 11:14 PM Andrew Bryan via lists.sync.global
<abryan=cumberland.io@...> wrote:
I agree with Wayne on the differences in use cases in scope. Our goal with the proposed addition is to allow a SV or FA to transfer between their own wallets when needed for operational purposes such as transitioning between custody providers. Hi all,
Thanks to Simon and Jonathan for the detailed work. I have one suggestion on the provisional FA lock flow, since this CIP is where the automation promised in CIP-0116 §2.2 lands. It follows the same logic as the transfer discussion above: locking should not tie up more capital than the network's security actually needs.
Today the review queue is ordered by when assets were pre-positioned, and the provisional lock makes that pre-positioning the entry ticket to review. For independent builders and small teams this means 5M CC sitting idle for the full length of an open-ended review, or borrowing it from a staking app and paying for it with no certainty of approval. In practice many of them give up before applying, and the network loses exactly the long tail of apps it wants.
Proposal: require the full FA lock after the review is complete, not before it.
- Review queue ordered by application time, not by pre-positioning time.
- To keep out spam applications, a provisional lock at the minimum lock amount (10k CC by default) is enough as a refundable entry deposit.
- Once the app is approved, the provider gets a fixed window (for example 30 days, matching the transition window for existing FAs) to create the full lock.
- The on-chain featuring vote stays gated on the full lock, exactly as CIP-0116 already requires, so the network's security guarantee is unchanged.
This keeps "skin in the game" where it matters, at the moment of featuring, while removing a capital barrier that only exists during review.
I raised this point earlier with the Foundation and wanted to bring it to the wider group here. Happy to join the call to discuss.
Best,
Abdulkadir Canpolat, The Hub- Hi Abdulkadir,I can't speak to whether the SV rights owners are willing to lower the requirements for getting a featured app right.I'm wondering whether there's an option to modify your proposal, so that it doesn't need extra on-chain state. If you set the time-window for providing the full amount of funds to equal the FA underlock grace period, the only change needed is the foundation's requirement for an FA right review. Once the FA right is granted, the FA right owner has the grace period to lock the remaining required funds.The CIP currently proposes a grace period of 7 days before the underlock of a FA right is made permanent by archiving the right. However, I wouldn't be surprised if there were willingness to increase it, as the underlock state immediately suspends the ability to get app rewards. In particular, as the SV rights grace period is set to 30 days.Questions:
- Abdulkadir: What's the minimum grace period you believe would work for delivering the required FA locks?
- SV rights owners: What's the maximum grace period that you would accept? Would it be OK to align the FA underlock grace period to 30 days?
Kind regards,Simon - Fair points Simon.Regardless of any change to rules, I agree with aligning to one variable of underlock grace period.In our view, 7 days should be more than sufficient given the availability of capital via multiple locked CC marketplaces. For example, Cashen deals have been fully sourced and closed in the same day.A 30 day window for FAs seems too long, creates a long lag between approval and vote, and could be ripe for abuse to underlock when rewards conditions are less economic, then re-lock 3-4 weeks later without impacting status.The 30day transition window referenced in #3 was only a one time event in June between initial CIP passage to implementation.-Luke
- Thanks Andrew for discovering this missing workflow step.I have updated the CIP proposal with a separate section specifying the ability to transfer locks:
- you can read the new section here: 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#transfers
- I propose to not "Make transfers a special case of substitutions" as for the reason explained in the rationale section here: 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#alternatives-considered
- the exact diff adding the new section and wiring it into the existing text is here: https://github.com/canton-foundation/cips/pull/250/changes/ef996a422c7ec0913211e1bc616345d2f4bc02f0
Andrew, Yannis and other stakeholders would you mind reviewing the new text and check whether that matches your expectations? PR comments and responses on this email are most welcome.In the meantime, I've also learned that compatibility mode should support both partial substitutions and partial transfers of owner-controlled locks. It should also support partial unlocks without requiring extra metadata. This ensures that SV rights owners have the right tools to manage their on-chain locks using their existing wallets. I'm working on a proposal for an updated compatibility mode addressing these new requirements, and will revert to this list once I have a concrete proposal.Kind regards,Simon - 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
- These are great comments. See my answers inline below.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/0ade343b21040bb88e11e03e325beed07cbe9856The 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.mdIt 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#changelogMany thanks for the helpful input,Simon--Dr. Simon Meier
Principal Architect
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. - I completed revising the delivery plan and the compatibility mode specification, which resulted in the following changes:
- Adjust the delivery plan to deliver transfers and substitutions as part of Increment 1
- Refactor the compatibility mode to support transfers and substitutions of owner-controlled locks; and align all other operations with their request-to-lock-manager style.
- Remove explicit top-up operations in favor for the simpler and more general automatic lock merging
You can see the diff for these changes in the following commit: https://github.com/canton-foundation/cips/pull/250/changes/5c5ef2980e23ff5ed94567c90c61b54b75284c13The preview of the full proposal includes these changes and is still available at: 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.mdI do not plan to make any further changes (unless the design team discovers inconsistencies during validation) nor am I aware of any unaddressed change requests.Timely feedback is appreciated, so we can finalize this proposal soon.Kind regards,Simon - Thanks everyone for the feedback and improving this proposalDA is ready to sponsor this
- Cumberland is happy to endorse this CIP.ThanksChris
- Note that the CIP has just been merged in "Proposed" state. It's rendered view is now available from: https://github.com/canton-foundation/cips/blob/main/cip-0127/cip-0127.md