TokenProof — on-ledger compliance enforcement primitive for CIP-0056 token workflows (working PoC)
Hi all,
I’m sharing TokenProof, an open-source compliance primitive for Canton designed to be reusable across CIP-0056 token implementations and DvP settlement workflows.
This is not a concept — the PoC is implemented and running end-to-end.
What’s live (repo below)
DAML contracts
-
ComplianceProof — on-ledger compliance state (issuer + evaluator co-signatories, optional regulator observer)
-
ComplianceGuard — interface enabling atomic compliance gating inside Transfer
-
EvaluationRequest — async evaluation lifecycle
CIP-0056 reference implementation
- TokenBond example where Transfer takes a ComplianceProof contract reference (ContractId) and asserts decisionStatus == Active within the same Canton transaction
-
submitMustFail confirms transfers block when Revoked/Suspended
Atomic DvP workflow
-
CC payment + compliance check + asset transfer in a single Canton transaction
Backend
-
Deterministic Python/FastAPI classification engine
-
Policy packs: GENIUS_v1, CLARITY_v1, SEC_CLASSIFICATION_v1
-
-
Canton JSON Ledger API adapter (SDK 3.4, no deprecated tooling)
End-to-end flow
-
Evaluate → anchor proof → query → verify → enforce
Why this matters (regulatory driver)
Digital asset regulation is shifting from:
→ “compliance must exist”
to:
→ “compliance must be enforceable at the point of transaction”
→ “compliance decisions must be independently verifiable”
→ “audit trails must be deterministic and reproducible”
This is reflected across:
-
GENIUS Act — stablecoin classification, reserve alignment, issuer obligations
-
CLARITY Act — asset classification boundaries and intermediary responsibilities
-
SEC / CFTC guidance — increasing focus on control enforcement, not just disclosure
The gap in current architectures
Today, most RWA workflows perform compliance checks off-ledger before submitting a transaction.
This introduces:
-
Race conditions between evaluation and settlement
-
No verifiable record of what compliance state was enforced
-
Inability to independently validate decisions
-
Duplicated compliance implementations across participants
This is not just a design limitation — it is a regulatory risk surface.
What TokenProof enables
TokenProof moves compliance into the Canton transaction itself:
-
Atomic enforcement
-
No valid proof → transaction cannot execute
-
-
Deterministic verification
-
Proof hash can be independently recomputed
-
-
On-ledger auditability
-
Compliance state anchored and queryable via ACS
-
-
Privacy-preserving regulator access
-
Party-scoped visibility via Canton contract model
-
-
Reusable primitive
-
Any CIP-0056 token can integrate via ComplianceGuard
-
Why this only works on Canton
This pattern relies on:
-
Atomic multi-party transactions
-
Fine-grained, party-scoped privacy
-
Deterministic finality
Without all three, compliance cannot be both:
→ enforceable
→ and private
This is why compliance gating is typically off-chain in other ecosystems — Canton is uniquely capable of supporting it natively.
Immediate use cases (Day 1)
-
CIP-0056 token issuers adding compliance gating directly to Transfer
-
DvP settlement workflows requiring enforceable compliance state
-
Stablecoin / RWA issuance aligned to GENIUS / CLARITY classification
This pattern was previously validated in a settlement context via SettlementGuard (FINOS / DTCC hackathon): https://github.com/finos-labs/dtcch-2026-compliledger
Repo + docs
-
Repo (Apache 2.0): https://github.com/Compliledger/canton_tokenproof
-
Architecture: https://github.com/Compliledger/canton_tokenproof/blob/main/docs/architecture.md
- Dev Fund PR: https://github.com/canton-foundation/canton-dev-fund/pull/231
-
Full proposal: https://github.com/Mharris40/canton-dev-fund/blob/main/proposals/tokenproof.md
Looking for early feedback on
-
ComplianceGuard interface design (abstraction boundary)
-
CIP-0056 integration pattern (Transfer precondition)
-
Regulator observer model (privacy vs access tradeoffs)
-
DvP composition (edge cases / adversarial scenarios)
Direction
The goal is to formalize this as a shared ecosystem primitive, not a vendor-specific product:
-
Production hardening
-
SDK + developer tooling
-
DevNet/TestNet deployment
-
Standardization for reuse across Canton participants
Appreciate any feedback from folks building on Canton — especially around DAML patterns, token standards, and regulated workflows.
Thanks,
Maranda
-
- I'm interested in learning more, and will discuss internally at DA to see how we think this might fit with known needs. .
- Thanks Wayne - appreciate you taking a look
Happy to provide anything useful for the internal discussion.Also, glad to jump on a call if helpful.Thanks,
Maranda - Hi all,I'm Utku from the Jubilee team. We've just submitted a Draft proposal to the Canton Development Fund: an NFT-focused CIP-0056 reference implementation paired with a privacy-native marketplace, fully validated on Canton testnet and prepared for MainNet deployment.
What we're proposing:- - An open-source NFT-focused CIP-0056 DAML reference library (Apache 2.0)
- - An atomic payment distribution pattern — platform fee + creator royalty + seller settlement in a single atomic operation
- - An on-ledger offer escrow primitive that eliminates unbacked-offer spam common in EVM marketplaces
- - A browser-encrypted self-custody wallet reference implementation
- - 4 milestones over ~13 weeks, with two independent security audits before live economic activity
Per CIP-0100, we're seeking a Tech & Ops Committee champion as external contributors. From the SIG directory, we see strong fit with the Token Standards / Asset Standards, dApp Integration, Wallet Apps, and Financial Workflows & Composability SIGs. Happy to share the proposal draft and walk through the testnet build with anyone interested.Best,
Utku
