PledgeGuard

Private collateral registry · Canton Network

One collateral.
One live claim.

PledgeGuard prevents the same collateral from being pledged to two lenders, without exposing either lender's book. The check runs inside the settlement: a colliding draw simply does not fund.

Explore the mechanism See it on the ledger
Privacy preserving Atomic No single operator
COLLATERAL 7f8c…a92d REGISTRY sees the hash only LENDER A claim live · funded book private LENDER B blocked · 0 transferred book private
Daml templates6 Scenario transactions24 Privacy assertionsall passing Registry threshold2 of 3 Settled on DevNetCanton Coin, cBTC Funds moved on a collision0

01 · The problem

The collateral can be private.
The collision cannot be.

A borrower pledges the same receivables pool to two lenders. Each lender's diligence is correct on its own book and blind to the other's. Tricolor cost JPMorgan a $170M charge-off. First Brands double-financed receivables into a bankruptcy of roughly $10B.

Todayundetectable
Borrower pledges poolLender A300
Same pool, same monthLender B300

Two facilities. One collateral. No shared visibility, and no neutral place to ask the question without handing over the book.

With PledgeGuardcaught before funding
Lender A sees
its own facility
Lender B sees
its own facility
Registry sees
7f8c…a92d
Nobody sees
the other side's terms

Canton's own CIP #245 names this gap and asks who may hold the role that detects it. It proposes no code. This is the answer.

02 · Why this needs Canton

Detection and confidentiality,
in the same transaction.

ArchitectureDetects the collisionKeeps each book privateCheck is atomic with funding
Public ledgeryesnoyes
Central registry operatoryesonly from other lendersno
Cantonyesyesyes

A central registry can hide lenders from each other but never from itself, and its answer arrives beside the payment rather than inside it, so it can be raced. On Canton the sub-transaction projection gives each lender its own view, a neutral party can sign the check without being a stakeholder of any facility, and the check and the token-standard transfer are one atomic transaction.

03 · The mechanism

One pledge. One atomic decision.

04 · Privacy model

Same truth. Four views.

These are not filtered screens. Each panel is what that party's own participant returns from /v2/state/active-contracts. A party that is not a stakeholder never receives the contract at all.

Borrower
collateral
7f8c…a92d
facilities
2
collisions
not visible
Lender Afunded
collateral
7f8c…a92d
amount
300
claim
live
lender B
does not exist here
Lender Bcollision
collateral
7f8c…a92d
amount
180
transferred
0
lender A
does not exist here
Auditor
collisions
2 notices
facilities
none
amounts
none
claims
none
What the registry itself can seestated plainly

The registry holds fingerprints, a per-hash index, claims without terms, and collision notices. It also sees the amount of the leg it executes, because it is the token-standard executor and a party that sees an action sees its consequences. It never holds a facility: no commitment, no rate, no maturity. We say this before a reviewer finds it.

05 · Governance

The registry belongs to no one.

A market utility that lenders must trust cannot be one company's database. The registry's identity is a Canton Decentralized Party: hosted by three participants, two of three owner keys required for anything sensitive.

Automation handles the ordinarydelegated once, by vote
Open the index for a new fingerprintautomatic
Check and settle a drawautomatic

Every Daml check still applies. The automation can never settle without the live delegation, and that is asserted in the test suite.

Governance controls the exceptional2 of 3
Grant the delegationvote
Revoke the automationvote
Force-release a disputed fingerprintvote

Below the threshold the ledger itself refuses: "Enough confirmations to execute action" was not met. The threshold lives in the Daml contract, not in a backend.

06 · Proof

Proven on the ledger,
not in a diagram.

0
Transactions in the scenario
0
Daml templates
2 / 3
Registry governance
0
Colliding draws funded
DevNet run, 25 September 2026 · node hackcanton-devnet-3 · real Canton Coin live network
OffsetUpdate idEvent
116875212204252f8d1d8db…a6458a4fingerprint registered, index opened
116879412203923cfd38d57…2cfae06lender A allocates 120 CC, executor is the registry
116881012205c5d51c77d89…3ae1b44edraw A settles: index occupied, claim created, transfer executed, one transaction
116883612200a26ada73333…c184a914draw B on the same fingerprint: no transfer, one notice per lender
1168842122060d4fac2b510…148a29bdlender A repays, fingerprint released
11688721220e5d5d49735d1…752d6374lender B retries and settles

Reproduce locally

./daml/build.sh
./scripts/localnet.sh scenario

Three Canton participants, the registry as a decentralized party, the governance vote and the below-threshold refusal.

Reproduce on DevNet

AMULET=1 ./scripts/devnet.sh scenario
CBTC=1 ./scripts/devnet.sh scenario

The same flow against the shared HackCanton node, settling real Canton Coin or real cBTC.

Honest limits

A matching fingerprint proves the same pack was presented twice, not that a freshly fabricated pack describes the same assets. Index admission is delegated in v1. On the shared DevNet node all parties sit on one participant, so operator independence is shown on LocalNet, not claimed here.

Built for the desks moving collateral on-chain this quarter.

Receivables and warehouse lenders, private credit, and the collateral venues arriving with tokenised settlement.

Open the live party views Read CIP #245