Proposal: CIP-0105 Phase 2 On-Chain SV Locking Enforcement

[ericmann]

Development Fund Proposal Submission

Proposal file: proposals/cip_0105_implementation.md

---

Summary

This proposal requests funding to design, implement, and devnet-validate CIP-0105 Phase 2 — on-chain Super Validator locking enforcement — as a contribution to the hyperledger-labs/splice repository.

Today, SV reward weight is a governance-set constant with no on-chain relationship to locked tokens. Phase 1 (manual Foundation verification) is active but does not provide continuous, cryptographic enforcement. This project delivers DAML contracts and DSO automation that derive SV weight from verified lock state, enforce CIP-0105's escalating penalty schedule (7-day grace → temporary removal → 30-day permanent weight destruction), and support multi-wallet/multi-organization aggregation — all contributed upstream under Apache 2.0.

The implementation is intentionally narrow: direct CC locking is the first and fully sufficient path for CIP-0105 compliance. If Splice maintainers are comfortable including a thin verification abstraction in v1, the design can accommodate it without changing the core implementation. No product integration, token work, or proprietary tooling is in scope.

Estimated calendar duration: ~3 months across 4 milestones
Funding request: 900,000 CC (~$126k USD at $0.14/CC, conservative as of March 2026)

---

Checklist

• Proposal file added under /proposals/
• Milestones and funding amounts defined
• Acceptance criteria included
• Alignment with Canton priorities described

---

Notes for Reviewers

1. CIP-0105 is approved but unimplemented. No implementation of CIP-0105 Phase 2 exists in the Splice codebase or any known fork. This is entirely greenfield work.

2. This is infrastructure, not product. The grant funds DAML contracts and Splice automation contributed to the public Splice repository. No proprietary token, UI, or product tooling is in scope. Direct CC locking is the intended first implementation path and is sufficient on its own.

3. Design analysis is complete. The proposer has completed internal architectural analysis of the Splice integration surface, reward distribution pipeline, and DSO automation patterns. Key design questions — custody model, identity binding, lifetime rewards tracking, and automation integration — have been resolved. This proposal reflects completed analysis, not a research plan.

4. Tech & Ops Committee champion needed. Per the Dev Fund process, external contributors require a champion from the committee. Outreach is in progress and introductions are welcome.

5. Scope is CIP-0105-first and intentionally narrow. The funded deliverable is direct CC locking for CIP-0105 on-chain enforcement. No speculative Featured App locking scope from the active cip-discuss thread is included in the deliverables or funding.

6. Completion is defined by PR-ready artifacts and devnet validation. Because upstream merge timing is partly controlled by external maintainers, milestone acceptance is based on delivered contracts, passing tests, documentation, and documented review engagement — not merge timing alone.

7. PackageUpgrade governance dependency. A minor additive field on an existing Splice data type requires a package version bump and PackageUpgrade DSO governance action. The upgrade script is included in the deliverables; the governance vote itself is outside the proposer's control but follows a standard, well-precedented process.

[ericmann]

Could someone from the team (@tkatrichenko @hythloda @stas-sbi @waynecollier-da @isegall-da) please add the daml-tooling tag to this PR to help with champion identification?