Hi everyone! Charles Dusek here, Founder of Merged.One. We’ve submitted a Development Fund proposal for the Canton Collateral Control Plane and wanted to share what we’re building, why we think it matters, and how it connects to work already happening in this community.
What it is
The Canton Collateral Control Plane is an open-source reference control layer for collateral eligibility, haircuting, concentration limits, encumbrance state, substitution, optimization, and atomic collateral mobility on Canton.
It’s a shared rulebook and control utility that sits between Canton apps. It doesn’t own assets, run a venue, or compete with any member business. It answers the question every financial workflow eventually needs answered: Given this obligation, which assets can I use, how much are they worth after haircuts, and how do I move them safely?
Importantly, the Control Plane doesn’t impose a single set of collateral rules on the ecosystem. Each app, counterparty, or institution defines its own policy with its own eligible assets, haircuts, concentration limits, and substitution rights. The Control Plane provides the shared language for expressing those rules and the shared engine for evaluating them, so that collateral decisions are machine-readable, deterministic, and verifiable across apps without requiring everyone to agree on the same parameters.
Why now
Canton is already a collateral network in practice. The Global Collateral Network working group has demonstrated on-chain UST financing against USDC, real-time collateral reuse across counterparties, and cross-border multi-currency intraday repos with tokenized Gilts and LSEG DiSH deposits. Broadridge DLR processes $8T+/month in repo. DTCC is bringing tokenized DTC-custodied Treasuries to Canton this year. Euroclear is integrating collateral mobility. USDCx, USYC, USDM1, and CBTC are live.
But those efforts are expressed through specific apps, pilots, and member-specific implementations. What’s missing publicly is the neutral policy layer that standardizes how a collateral obligation is evaluated and fulfilled across different apps and asset types. Without it, every app reinvents eligibility rules, haircuting logic, substitution workflows, and encumbrance tracking essentially recreating the collateral silos that traditional finance has spent decades trying to solve.
How it connects to existing Daml Finance work
If you’ve worked with Daml Finance, you’ve encountered the building blocks the Control Plane sits on top of:
-
Holding Factories create and archive holdings. Some of you have discussed real pain points here — the factory disclosure problem during settlement where the HoldingFactory isn’t disclosed to settlers, and the tight coupling between Accounts and HoldingFactory CIDs that forces account recreation on upgrades. A collateral control plane that operates at the policy layer above holdings can work with these constraints rather than requiring changes to them.
-
Locking via `Base.Acquire` / `LockType.Semaphore` is the Daml Finance mechanism for what the collateral world calls “encumbrance.” The Control Plane extends this into a full encumbrance-state model with release control, substitution rights, and secured-party authorization.
-
Settlement and DvP — The existing `Batch` / `SettlementInstruction` system with `CreditReceiver` / `DebitSender` allocation handles atomic multi-leg execution. The Control Plane uses this settlement layer for collateral movements and adds the policy and optimization logic that decides what gets moved and why.
-
CIP-56 standardizes tokens. The Control Plane standardizes what makes a token acceptable as collateral, defining which policy governs eligibility, at what haircut, within what concentration limit, and subject to what control conditions.
There was also an earlier CDM-based CSA implementation that tackled haircut tables and eligibility against legal agreements. That work demonstrated the need. The Control Plane takes the same concepts and delivers them as open-source ecosystem infrastructure rather than a product-level implementation.
Five layers
| Layer | What it does | Real-world analogue |
|---|---|---|
| Collateral Policy Language (CPL) | Machine-readable eligibility, haircuts, concentration limits, substitution rights | A central bank’s published collateral schedule |
| Policy Engine | Evaluates assets against a policy, returns pass/fail with reasons | A tri-party agent checking your collateral |
| Optimization Engine | Picks the cheapest/best combination to satisfy an obligation | A custodian bank’s collateral optimizer |
| Workflow Library | Daml contracts for margin calls, substitution, returns, close-out | The operational flows that move collateral |
| Conformance Suite | Proves correctness — no double-pledging, deterministic results, atomic moves | An auditor verifying the plumbing |
Design basis
This isn’t modeled on DeFi convention. It’s modeled on how high-value collateral actually works in central banks, tri-party agents, and CCPs:
- Fedwire model — settlement plumbing separate from collateral policy
- Tri-party pattern — eligibility, valuation, substitution, and optimization as a neutral utility
- CCP/FMI pattern — published haircut schedules, concentration limits, deterministic settlement, auditable exception handling
Canton is uniquely suited for this because it combines programmable privacy, party-specific views, contract-level authorization, and atomic cross-application execution — exactly what collateral workflows require.
What’s working
A public prototype is live: merged-one/canton-collateral-control-plane
It demonstrates DAR deployment into a pinned Quickstart runtime, a reference token-adapter path, and Quickstart-backed confidential margin-call, substitution, and return flows with machine-readable conformance artifacts — including 9+ negative-path scenarios and 118 generated report files.
Looking for feedback
I’d especially welcome input from this community on:
- Which collateral workflow families to prioritize first (margin, repo, securities lending, treasury?)
- Preferred reference environments and asset adapter targets
- How the policy model should interact with the Holding Factory and CIP-56 adapter boundaries
- Expectations around policy profile coverage (bilateral CSA, tri-party, CCP, central-bank)
- Desired format for conformance and qualification outputs
For anyone building in adjacent areas like repo starter kits, tokenized treasury collateralization, or open-source tokenization tooling the Control Plane is designed as infrastructure you can build on, not compete with.
The full proposal: PR #149 on canton-dev-fund
We’re also building the Canton Upgrade & Conformance Kit — a Scala-native qualification and conformance toolchain for Canton deployments. Both projects are designed as shared public-good infrastructure.
Happy to discuss any of this. Thanks for reading.
— Charles