Proposal: TokenProof — reusable on-ledger compliance primitive for CIP-0056 tokens (working PoC, CI green)

[Mharris40]

Development Fund Proposal Submission

Proposal file:
Find the Proposal at https://github.com/Mharris40/canton-dev-fund/blob/proposal-tokenproof/proposals/tokenproof.md

Summary

TokenProof is a shared, open-source compliance primitive for the Canton Network — designed to be reusable across CIP-0056 token implementations and DvP settlement workflows.

The PoC is already running on Canton local ledger. This is a production hardening proposal, not a greenfield request.

• Repo (Apache 2.0): https://github.com/Compliledger/canton_tokenproof
• Architecture: https://github.com/Compliledger/canton_tokenproof/blob/main/docs/architecture.md
• CI: https://github.com/Compliledger/canton_tokenproof/actions

---

CI evidence — all 3 DAML packages green

dpm build --all + dpm test passing on every push to main.

Package	dpm build	dpm test
daml/ — ComplianceProof, ComplianceGuard, EvaluationRequest	✓ pass	✓ pass
examples/cip0056-gated-transfer/ — TokenBond atomic DvP	✓ pass	✓ pass
examples/stablecoin-genius-act/ — GENIUS Act stablecoin	✓ pass	✓ pass

dpm test output (all 5 tests passing):

✔ complianceProofLifecycleTest   (6 transactions)
✔ transferGateTest               (5 transactions)
✔ atomicDvPDemo                  (5 transactions)
✔ dvpWorkflowDemo                (4 transactions)
✔ geniusActMintingDemo           (5 transactions)

Key behaviours verified:

• Active → Suspended → Revoked lifecycle enforced
• Transfer succeeds when decisionStatus == Active
• Transfer fails (submitMustFail) when Revoked or Suspended — atomic compliance gate confirmed
• Payment + compliance check + asset transfer in one Canton transaction (DvP)
• Proof hash anchored and retrieved via ACS query

---

Problem this solves

Digital asset regulation is shifting from disclosure-based to enforcement-based compliance. GENIUS Act, CLARITY Act, and SEC/CFTC guidance all share a common requirement:

Compliance must be enforceable at the point of transaction, verifiable after execution, and auditable with a deterministic record.

Today, RWA workflows perform compliance checks off-ledger before submitting a transaction. This creates:

• Race conditions between evaluation and settlement
• No verifiable record of what compliance state was enforced
• Inability for regulators to independently verify decisions
• Duplicated compliance infrastructure across participants

This is not just an architectural limitation — it is a regulatory exposure.

---

What TokenProof enables

• Atomic enforcement — no valid proof = transaction cannot execute (enforced inside Transfer)
• Deterministic verification — proof hash independently recomputable by any party
• 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 integrates via ComplianceGuard interface

---

Why Canton — architectural requirement

This pattern depends on three properties unavailable on public chains:

• Atomic multi-party transactions
• Privacy-preserving contract visibility (sub-transaction privacy)
• Deterministic finality with DAML authorization model

Without all three, compliance cannot be both enforceable and private. This is why compliance gating today is implemented off-chain in other ecosystems — introducing the gaps described above. Canton is the only environment where this enforcement model can be implemented natively.

---

Alignment with approved Dev Fund investments

Approved PR	TokenProof relationship
Token Standard V2 (#97)	ComplianceGuard is additive — zero modification to CIP-0056 primitives
Logical Synchronizer Upgrades (#76)	ComplianceProof contracts are sync-domain-native
ISS-Based BFT (#53)	Stronger finality = more robust compliance proof enforcement
Daml Package Analyzer (#130)	TokenProof is an ideal first real-world validation candidate

---

Day 1 use cases

• 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

The atomic compliance gating pattern was previously validated via SettlementGuard (FINOS / DTCC hackathon). TokenProof generalises that pattern into a reusable ecosystem primitive.

---

No overlap statement

This proposal does not overlap with any existing PR in the canton-dev-fund queue.

It is not a dev tooling proposal, not a token standard change, and not a synchronizer/infrastructure proposal. It is a new application-layer primitive: reusable on-ledger compliance enforcement for Canton.

PRs reviewed: #3, #4, #5, #6, #7, #8, #9, #97, #130 — no overlap.

---

Checklist

• Proposal file added under /proposals/
• Milestones defined (5 milestones, $80,000 USD total)
• Acceptance criteria defined per milestone with gate metrics
• Alignment with Canton priorities (CIP-0056, CIP-0103, CIP-0076, Token Standard V2 #97 Proposal: Logical Synchronizer Upgrades #76 Development Fund Proposal: ISS-Based BFT #53 Proposing Daml Package Analyzer #130)
• Working PoC — CI-verified dpm build --all + dpm test on 3 packages
• Apache 2.0 open-source license
• CONTRIBUTING.md, SECURITY.md, CHANGELOG.md present in repo

---

Appreciate technical review on: ComplianceGuard interface design, CIP-0056 Transfer precondition pattern, regulator observer model, and DvP composition edge cases.

[waynecollier-da]

@Mharris40
I'd like to advise that based on feedback I've received so far, it's likely that the grant proposal voting group will approve this proposal if you can show the following evidence:

1. A major web3 token issuer confirms that this will help them achieve and maintain compliance, with some explanation of how this will work for them; and
2. A major regulated financial institution confirm the same.

[Mharris40]

@waynecollier-da

Thanks Wayne.

Quick update on both fronts:

1. Web3 issuer signal

We’re in active discussions with Hedera around piloting TokenProof for stablecoin / token issuance workflows. As of right now we are gaining a better understanding of how the integration will work with TokenProof and HTS.

Their primary requirement is enforceable, on-ledger compliance — particularly around classification and issuance constraints.TokenProof addresses this by moving compliance into the transaction layer, preventing non-compliant minting or transfers from executing.

We’re working to formalize a short written statement from their team.

2. Regulated financial institution signal

The compliance gating pattern behind TokenProof was previously implemented in a settlement context through SettlementGuard (developed during a FINOS / DTCC hackathon).

That work highlighted the need for deterministic, in-transaction compliance enforcement within institutional DvP workflows — specifically to eliminate race conditions between compliance evaluation and settlement execution and to improve auditability.

I’m currently following up with FINOS / capital markets participants to provide a concise statement aligned to this pattern in real-world workflows.

I’ll follow up shortly with:
• a formal issuer statement (Web3 side, Hedera), and
• a corresponding institutional validation statement (FINOS)

so the committee has clear evidence on both dimensions.

Appreciate the guidance here

Best,
Maranda

[waynecollier-da]

You'll need to find a token issuer on Canton, I think. The criteria will be somewhat different in a privacy-first chain.

[Mharris40]

Thanks Wayne — that’s a helpful clarification and makes sense given the privacy-first model on Canton.

I’m now focusing specifically on validation from a Canton-native issuer.

I’m already in discussions with Brale around potential integration, which aligns closely with TokenProof’s use case (stablecoin issuance and compliance-gated transfers on Canton). I’m working to formalize a short statement from their team on how this would apply to their workflows.

I’ll follow up shortly with that, along with the institutional validation I’m lining up in parallel.

Appreciate the guidance

[Mharris40]

I’ve also posted a follow-up in grants-discuss specifically asking for input from Canton-native token issuers (CIP-0056 / stablecoin / DvP workflows) to gather that validation.

I’ll share updates here as soon as I have a concrete signal.

[Mharris40]

@waynecollier-da
following up with a concrete signal from a Canton-native issuer.

We’ve received validation from LongView Compute LLC (LongView Crew — multi-tenant NFT issuer platform on Canton) confirming the value of this approach:

“On-ledger enforcement at the controller level would close the ‘compromised issuer credentials’ gap cleanly.”

“Having compliance state stamped into the transaction makes the audit inherent to the ledger — no separate system to reconcile.”

They also noted that while race conditions are less acute for single-mint NFTs, eliminating off-ledger consistency issues is architecturally cleaner—particularly for higher-frequency issuance and DvP-style flows.

I’m continuing to follow up with additional Canton issuers (including Brale) and will share further signals as they come in, but wanted to provide this concrete validation in the meantime.

[Mharris40]

@waynecollier-da

Im continuing conversations with LongView Compute LLC (multi-tenant issuer platform), and we’ve been working through how this maps directly into their minting and issuer lifecycle workflows.

Based on that exchange, we’re now setting up next steps to walk through their architecture in more detail and map enforcement into their transaction flow (issuer good-standing checks, quota constraints, and policy versioning at execution).

Will keep you posted as this progresses and as we formalize validation.