diff --git a/proposals/CIP-0105.md b/proposals/CIP-0105.md
new file mode 100644
index 00000000..1d67c990
--- /dev/null
+++ b/proposals/CIP-0105.md
@@ -0,0 +1,290 @@
+# CIP-0105 Implementation: On-Chain Enforcement of Super Validator Locking and Long-Term Commitment
+
+**Author:** Obsidian Systems LLC  
+**Status:** Final \- submitted for Committee review  
+**Created:** 2026-04-20  
+**Updated:** 2026-04-29  
+**Implements:** CIP-0105 (Phase 2 — On-Chain Enforcement)
+
+---
+
+## Abstract
+
+CIP-0105 (Super Validator Locking & Long-Term Commitment Framework) was approved by the Canton Foundation on March 2, 2026\. Phase 1 (off-chain transitional enforcement) is active today and depends on manual disclosure and off-chain verification by Digital Asset. Phase 2, the on-chain enforcement layer that delivers the framework's core value, remains unimplemented.
+
+This proposal funds Obsidian Systems to design, build, deploy, and maintain Phase 2 as a Splice application. Scope covers the full locking lifecycle: lock creation, tier configuration, vesting, multi-custody aggregation, continuous weight calculation, under-lock penalty enforcement, SV-app governance automations, compliance visibility for Super Validators, Mainnet deployment gated on SV governance vote, and six months of post-Mainnet ownership. Delegated locking is excluded. Helix Labs is pursuing it separately at hyperledger-labs/splice\#4842.
+
+## Motivation
+
+CIP-0105 establishes the framework by which Super Validators cryptographically commit to Canton through locked capital. Without on-chain enforcement, four problems persist:
+
+**Replace reputation-based trust with cryptographic proof.** Phase 1 tracks SV lock status via spreadsheets and off-chain disclosures. Standing is asserted rather than proven. The CIP's core thesis of publicly observable, cryptographically enforced validator commitment cannot be satisfied without on-chain contracts.
+
+**Eliminate manual disclosure and off-chain verification.** SVs self-report locked positions across self-custody wallets, custodians, and third-party providers and DA manually reconciles. The arrangement is operationally brittle, does not scale, and creates credibility risk when institutions evaluate Canton as production infrastructure.
+
+**Make validator commitment publicly observable and enforceable.** SV weight in governance and traffic rewards does not automatically reflect lock status. A validator below tier threshold continues to receive full weight until DA intervenes manually. Phase 2 closes this gap with automatic weight adjustment, a defined cure period, and permanent removal of excess weight on cure expiry.
+
+**Reduce centralized governance overhead.** Phase 1 enforcement does not scale as the SV set grows. Phase 2 moves enforcement to the protocol layer, decentralizing operational governance load consistent with Canton Foundation direction for Splice.
+
+## Specification
+
+### Objective
+
+Deliver the on-chain enforcement layer for CIP-0105 as a Splice application covering:
+
+- Locking contracts and tier configuration  
+- Vesting (progressive unlock at 1/365.25 daily rate upon unlock initiation)  
+- Continuous weight calculation against tier thresholds with time-based adjustments per spec (Tier 1: 70% start, stepping to 55% by year 3; Tier 2: 45% start, stepping to 50% at year 1; Tier 3: 35% flat)  
+- Multi-custody aggregation across multiple wallets, custodians, and third-party providers  
+- Under-lock penalty enforcement: automatic weight removal within seven days of breach, thirty day cure period, permanent loss after cure expiry  
+- SV-app governance automations: continuous weight evaluation, threshold monitoring, cure-period countdown, penalty execution  
+- Compliance visibility: per-SV lock status, tier standing, weight impact, vesting schedule  
+- Mainnet deployment gated on governance vote  
+- Wallet-app lock/unlock integration  
+- Post-Mainnet ownership and refinement
+
+### Implementation Mechanics
+
+Three components with approximate effort allocation. Component names are illustrative. The final component surface is defined in the M1 design doc.
+
+**Component 1 — Daml Contracts (\~40%).** Primary templates: `LockingContract` (the core SV-party locking primitive keyed by `(svParty, asset, custodian)`), `VestingSchedule` (unlock-in-progress positions with progressive vesting), `TierConfiguration` (SV-app-governed thresholds and penalty parameters). Multi-custody aggregation is computed from these primitives. Under-lock penalty enforcement is a Daml-level choice on SV governance records, with cure-period state and permanent-penalty outcomes modeled in the contract state machine.
+
+**Component 2 — SV-App Governance & Automations (\~50%).** Triggers: `UnderLockPenaltyTrigger` (executes the penalty workflow on tier-threshold breach), `CureCountdownAutomation` (manages the thirty-day cure state and terminal weight adjustment), `TierThresholdMonitor` (alerting and approach-warnings), `ContinuousWeightEvaluationTrigger` (replaces the Phase 1 weekly off-chain process with on-chain evaluation). Services: `MultiCustodyAggregator`, `LockWeightCalculator`. Scan APIs: `LockStatusAPI` (per-SV lock state) and `ComplianceDashboardAPI` (aggregate view for Super Validator representatives and governance observers).
+
+**Component 3 — Documentation, Utilities & Integrations (\~10%).** Operator documentation, a `WalletLockOperations` extension to the Canton wallet app for SV lock/unlock flows, utility surfaces for SV reporting and compliance verification, and iterative refinements based on SV feedback during rollout.
+
+### Coordination with PR \#223 (SV Governance dApp)
+
+Avro Digital's PR \#223 proposes a standalone governance dApp separating non-operational voting from node operations. CIP-105 and PR \#223 operate at different layers and are complementary:
+
+- **CIP-105:** on-chain enforcement primitive — Daml contracts, automation triggers, weight-calculation services. Ledger-side substrate.  
+- **PR \#223:** governance dApp — UI/UX for SV voting, proposal lifecycle, external signing. User-facing surface.
+
+Enforcement triggers operate against on-chain governance state regardless of which surface presents it. Specific integration points (e.g., how `ContinuousWeightEvaluationTrigger` outputs surface in the PR \#223 UI, or how cure-period state is exposed to operators) are defined in the M1 design doc. Obsidian commits to coordinate with Avro and Digital Asset on integration design if both proposals proceed.
+
+PR \#184 (Concordia — reusable allocation primitives) is adjacent governance-tooling work; CIP-105's enforcement scope is orthogonal. Coordination, if needed, happens at Splice contributor level.
+
+### Backward Compatibility and SCU Compatibility
+
+CIP-105 introduces new Daml contracts (`LockingContract`, `VestingSchedule`, `TierConfiguration`) and new SV-app-side automation. No Canton protocol changes are required.
+
+The new Daml contracts are subject to Smart Contract Upgrade (SCU) compatibility as the Daml schema evolves. Obsidian's commitments:
+
+- All CIP-105 contracts conform to SCU at Mainnet deployment.  
+- Future Daml schema upgrades affecting CIP-105 contract templates are accompanied by upgrade definitions and migration paths consistent with SCU patterns established by CIP-0104 and the Splice contributor framework.  
+- Upgrades affecting the locking lifecycle or weight calculations require SV governance vote; minor schema upgrades that do not affect operational semantics follow standard Splice contributor practice.
+
+### Extensibility and Refresh Path
+
+CIP-105 is intended to evolve with Canton protocol maturity. Three structural elements support extensibility:
+
+- **Apache 2.0 contributor license** consistent with Splice contribution practice — all deliverables released to the Splice repository with no proprietary claim from Obsidian.  
+- **PR-contribution path** for downstream extensions — any contributor (including future stewards or DA, should DA take co-maintenance responsibility) submits pull requests via the standard Splice contributor flow.  
+- **Protocol-evolution review at the close of M5.** Obsidian delivers a recommended follow-on scope identifying production-observed refinements, candidate enhancements, and any open SCU upgrade paths. The follow-on scope informs whether subsequent maintenance is absorbed within an existing or future Splice maintenance arrangement, bundled with co-maintenance work via a future stewardship CIP, or carried by a separate refresh proposal.
+
+## Milestones and Deliverables
+
+Milestone amounts below reflect Obsidian's recommended sizing.
+
+### M1 — Design Doc \+ SV Alignment Foundation
+
+**Timeline:** Months 1–2  
+**Focus:** Approved design doc as gate to build; preliminary SV alignment; draft Daml contracts validating core locking/vesting logic.
+
+**Deliverables:**
+
+- Design doc approved by DA Splice team and Wayne Collier — contract surface, trigger topology, SV-app integration points, multi-custody aggregation approach, devnet/Mainnet testing strategy, and PR \#223 integration considerations  
+- Preliminary SV alignment workshop with a representative cross-section of the SV set (institutional custodians, self-custody operators, third-party providers)  
+- Draft Daml PR in the Splice repository with core `LockingContract`, `VestingSchedule`, `TierConfiguration` templates and a passing unit-test suite  
+- Governance vote scope defined for M4 Mainnet deployment
+
+**Acceptance criteria:**
+
+- Written sign-off from DA Splice team and Wayne on the design doc  
+- Unit tests passing in CI for the M1 Daml PR  
+- Written confirmation from a representative cross-section of Super Validators (across custody profiles) that the design approach is compatible with their operational constraints
+
+**Estimated amount:** 1,200,000 CC
+
+### M2 — Daml Contract Suite Complete \+ Component 2 Foundations \+ SV Signoff
+
+**Timeline:** Month 3  
+**Focus:** Full Component 1 contract suite implemented; Component 2 scan API stubs and trigger contract surfaces in place to enable M3 execution in one month; SV-signed-off.
+
+**Deliverables:**
+
+- All Daml templates, services, and choices in Component 1 implemented with unit and integration test coverage  
+- Multi-custody aggregation service functional against representative custody profiles  
+- Penalty enforcement state machine (breach → seven day removal → thirty day cure → permanent penalty) with explicit state transitions and test coverage  
+- SCU compatibility verified for the contract suite as deployed  
+- **Component 2 enabling work:** `LockStatusAPI` and `ComplianceDashboardAPI` scan API contracts specified and stubbed; trigger contract surfaces (`UnderLockPenaltyTrigger`, `CureCountdownAutomation`, `TierThresholdMonitor`, `ContinuousWeightEvaluationTrigger`) defined at Daml interface level with stubs ready for M3 implementation  
+- Second SV alignment workshop; SV signoff recorded
+
+**Acceptance criteria:**
+
+- Test coverage meets Splice contribution standards  
+- Component 2 stubs reviewed by DA Splice team — explicit gate for M3 entry  
+- Written SV signoff captured from the M1 cohort (or expanded)
+
+**Estimated amount:** 1,000,000 CC
+
+### M3 — SV-App Governance, Automations, Compliance UI
+
+**Timeline:** Month 4  
+**Focus:** Automation and governance surface that makes the M2 contract suite operationally usable. Built on M2 trigger stubs and scan API contracts (M2 acceptance gates this milestone).
+
+**Deliverables:**
+
+- All Component 2 triggers fully implemented from M2 stubs (`UnderLockPenaltyTrigger`, `CureCountdownAutomation`, `TierThresholdMonitor`, `ContinuousWeightEvaluationTrigger`)  
+- Compliance dashboard UI (per-SV lock status, tier standing, weight impact, vesting schedule, cure-period countdown)  
+- Multi-custody position aggregation UI  
+- On-chain continuous weight evaluation, replacing the Phase 1 weekly off-chain process  
+- SV-app and validator-app integration; PR \#223 integration touchpoints documented if PR \#223 has progressed
+
+**Acceptance criteria:**
+
+- Automations live on devnet with end-to-end test runs covering breach, cure, and permanent-penalty scenarios  
+- Compliance dashboard reviewed by Super Validator representatives and DA governance staff
+
+**Estimated amount:** 1,000,000 CC
+
+### M4 — Mainnet Deployment (Governance-Vote Gated)
+
+**Timeline:** Month 5  
+**Focus:** Production deployment on SV governance vote; wallet and utility surfaces complete.
+
+**Deliverables:**
+
+- Governance vote passed; Mainnet deployment in accordance with the voted scope  
+- `WalletLockOperations` wallet-app extension deployed  
+- Operator documentation published  
+- Utility apps for SV reporting and compliance verification deployed  
+- Production handoff documentation for DA governance and Super Validator representatives
+
+**Acceptance criteria:**
+
+- Successful Mainnet deployment with all Component 1 and 2 functionality live  
+- Governance vote recorded and scope adhered to  
+- DA Splice team and Super Validator representatives formally acknowledge production handoff
+
+**Estimated amount:** 400,000 CC
+
+### M5 — Six-Month Post-Mainnet Ownership
+
+**Timeline:** Months 6–11  
+**Focus:** Bug fixes, SV feedback absorption, iterative refinements, incident response during the initial production period.
+
+**Deliverables:**
+
+- Bug fix releases as needed  
+- Iterative refinements based on SV feedback  
+- Incident response and Mainnet operational support for the contract suite and automations  
+- End-of-period handoff report covering operational experience, open items, and recommended follow-on scope (per Extensibility and Refresh Path)
+
+**Acceptance criteria:**
+
+- Mainnet operation continuous with no unresolved critical bugs from the M4 deployment  
+- SV feedback log maintained and acted upon  
+- End-of-period report delivered to DA and Super Validator representatives
+
+**Estimated amount:** 400,000 CC
+
+### Total
+
+**11 months. 4,000,000 CC base \+ 480,000 CC early completion bonus potential \= 4,480,000 CC total.**
+
+---
+
+## Funding
+
+| Line item | Amount |
+| :---- | :---- |
+| M1 — Design doc \+ SV alignment foundation | 1,200,000 CC |
+| M2 — Daml contract suite \+ Component 2 foundations \+ SV signoff | 1,000,000 CC |
+| M3 — SV-app governance, automations, compliance UI | 1,000,000 CC |
+| M4 — Mainnet deployment (governance-vote gated) | 400,000 CC |
+| M5 — Six-month post-Mainnet ownership | 400,000 CC |
+| **Subtotal** | **4,000,000 CC** |
+| Early completion bonus (15% of M1–M3 if Mainnet within 4 months) | 480,000 CC |
+| **Total with bonus** | **4,480,000 CC** |
+
+**Payment schedule:** Paid on milestone acceptance. M5 invoiced in two tranches (Month 8 and Month 11\) to align with ongoing support delivery.
+
+**Volatility structure:** Fixed Canton Coin denomination throughout. Direct precedent from PR \#107 (Traffic-Based App Rewards), which denominated in fixed CC for a 6-month engagement. CIP-105's build phase (M1–M4) is also 5 months; M5's 6-month ownership tail extends the horizon but at significantly reduced monthly intensity.
+
+**Early completion bonus:** 15% bonus on M1–M3 if delivered to Mainnet within 4 months of grant approval. Mirrors PR \#107's bonus structure exactly. Bonus amount: 480,000 CC.
+
+**Licensing:** All deliverables released under Splice's contribution license (Apache 2.0), consistent with CIP-0104.
+
+**Co-marketing:** Obsidian and the Canton Foundation jointly announce delivery of each milestone through standard Splice contributor channels.
+
+## Maintenance Plan
+
+CIP-105 maintenance falls into three time horizons:
+
+- **In-build (Months 1–5).** Bug fixes and design refinements absorbed within milestone scope. Test coverage and SCU compatibility maintained as build-time obligations.  
+- **Post-Mainnet ownership (Months 6–11, M5).** Obsidian retains direct operational responsibility — bug fixes, SV feedback, incident response — closing with the recommended follow-on scope deliverable.  
+- **Long-run (Month 12 onward).** Three candidate paths, confirmed at the close of M5 based on observed maintenance load and DA / Foundation direction:  
+  - **Maintenance absorbed by an existing or future Splice maintenance arrangement** — if alignment with DA and the Foundation exists at M5 close and maintenance load is modest, no incremental CIP-105 funding may be required.  
+  - **Separate stewardship CIP** — a renewable annual stewardship grant sized to actual observed maintenance load.  
+  - **Refresh proposal** — a one-shot proposal for a specific protocol-evolution refresh, if maintenance is bounded and episodic rather than continuous.
+
+The Month-12 path is recommended in the M5 end-of-period report based on operational data from the first six months of Mainnet.
+
+Long-run scope must also account for framework auto-termination, which the spec mandates 30 days after the late 2029 halving. At termination, the on-chain enforcement contracts wind down. The wind-down deliverable is a candidate for the post-Mainnet refresh proposal path noted above.
+
+## Rationale
+
+**Splice-app scope; no Canton protocol changes.** Phase 2 is entirely a Splice application. Unlike CIP-0104, no protocol changes are required; work can start without a protocol design cycle.
+
+**Design-doc first.** The M1 design doc is the gate. It surfaces complications, particularly multi-custody aggregation and SV alignment, before implementation cost is incurred, and gives the SV cohort an early vehicle to raise objections.
+
+**Super Validator alignment is the critical path.** SVs are competing institutions with differing compliance postures. Some are actively resistant to constraints on discretion. CIP-0105 does not work without an SV governance vote at M4. SV workshops are embedded across M1–M4 rather than treated as a checkbox.
+
+**Six-month post-Mainnet ownership.** Obsidian maintains what it builds. M5 makes this explicit, consistent with DA's direction for Splice (contributors maintain their contributions).
+
+**Delegated locking is a separate proposal.** It is excluded from this proposal’s scope. Helix Labs has an in-progress attempt at hyperledger-labs/splice\#4842.
+
+## Design Alternatives Considered
+
+| Alternative | Rationale for rejection |
+| :---- | :---- |
+| Status quo — extend Phase 1 off-chain enforcement with better tooling | Does not satisfy the CIP's core value of cryptographically enforced validator commitment. Relies on DA manual reconciliation. Does not scale. |
+| Build as a standalone app rather than a Splice app | CIP-0105 is specified to operate within the Splice governance surface. Standalone deployment would re-implement SV app integration and would not satisfy the CIP's stated architecture. |
+| Wait for PR \#223 (Avro) to ship before starting CIP-105 | The two proposals operate at different layers. Sequencing provides no design benefit and delays the cryptographic-enforcement value the CIP specifies. Coordination at integration points is achievable in parallel via the M1 design doc. |
+| Bundle delegated locking into this proposal | Delegated locking is a materially different design problem with an in-progress attempt by Helix Labs. Bundling expands timeline and risk, duplicates work, and blurs accountability. |
+| Single-milestone delivery (4–5 months, one payment) | Misaligned with Canton Foundation milestone-gated funding practice; increases execution risk; provides the SV cohort no intermediate review points. |
+
+## Why Obsidian Systems
+
+- **Active Splice contributor.** Obsidian is delivering CIP-0104 and works actively with DA's Splice engineering team. Obsidian's Divam Narula is co-author on PR \#107 (Traffic-Based App Rewards) alongside Wayne Collier and a member of the Splice core contributors group.  
+    
+- **Canton Foundation governance presence.** Obsidian's co-founder Ryan Trinkle sits on the Canton Foundation board; Obsidian holds active seats on five Canton Network committees.  
+- **Super Validator.** Obsidian operates a Super Validator and is subject to CIP-0105 enforcement — structural alignment between governance accountability and implementation quality.  
+- **Track record on demanding Canton deployments.** Obsidian provides Canton engineering on major institutional network builds. 
+
+## Team
+
+| Phase | Composition |
+| :---- | :---- |
+| M1 (Months 1–2) | 1 Senior Daml Engineer (design doc \+ initial contracts) \+ 1 architect \+ 0.25 PM |
+| M2 (Month 3\) | 1 Senior Daml Engineer \+ 1 Mid-Level Daml Engineer (ramp into Component 1 \+ Component 2 stub work) \+ 1 architect \+ 0.25 PM |
+| M3 (Month 4\) | 1 Senior Daml Engineer \+ 1–2 Mid-Level Daml Engineers (Component 2 implementation) \+ 0.25 PM |
+| M4 (Month 5\) | 1 Senior Daml Engineer \+ 1 Mid-Level Daml Engineer (Mainnet deployment, utility apps, handoff) \+ 0.25 PM |
+| M5 (Months 6–11) | \~0.5 FTE ownership capacity (bug fixes, SV feedback, incident response, refresh recommendation) |
+
+Architectural review provided across M1-M2. Final engineer assignments confirmed prior to grant approval.
+
+## References
+
+- **CIP-0105 specification:** [https://github.com/canton-foundation/cips/blob/main/cip-0105/cip-0105.md](https://github.com/canton-foundation/cips/blob/main/cip-0105/cip-0105.md)  
+- **PR \#107 (format and precedent reference):** canton-foundation/canton-dev-fund — Traffic-Based App Rewards, co-authored by Wayne Collier and Obsidian's Divam Narula  
+- **PR \#223 (Avro — SV Governance dApp):** [https://github.com/canton-foundation/canton-dev-fund/pull/223](https://github.com/canton-foundation/canton-dev-fund/pull/223)  
+- **PR \#184 (Concordia — allocation primitives):** [https://github.com/canton-foundation/canton-dev-fund/pull/184](https://github.com/canton-foundation/canton-dev-fund/pull/184)  
+- **PR \#47 (DA Splice Management Grant):** 1,000,000 CC/month recurring; structural reference for Maintenance Plan candidate paths  
+- **Helix Labs delegated locking attempt (excluded):** [https://github.com/hyperledger-labs/splice/issues/4842](https://github.com/hyperledger-labs/splice/issues/4842)  
+- **CIP-0104 (specification and design depth reference):** protocol changes, implementation funded under PR \#107
+
+---
+
+*Submitted April 29, 2026\. Prepared by Obsidian Systems for Canton Foundation Development Fund Grants Committee review.*