CCPEDIAby Unity Nodes
Proposals/canton-foundation/canton-dev-fund/#621GitHub ↗
#621Declined Pull Request

Proposal: Compliance Middleware SDK for EVM Developers on Zenith

Noosphere-31406-08-2026Last activity 1mo ago
needs-champion
References:CIP-0056CIP-0100

Development Fund Proposal Submission

Proposal file: rfps/financial-markets-standards-verification/2026-08-Woof-compliance-middleware-sdk.md

Applicant

Organization: Woof

Author / Primary Contact: Mykola Ilchuk, Woof (@Noosphere-314)

Champion: Needs Champion

Proposal Classification

Proposal Type:

  • RFP-aligned proposal
  • Individual initiative

RFP / Roadmap Area: RFP 12 (RWA Standards), item 12.1: Identity, Credentials and KYC Standards for RWA Workflows, 2026-2028 Strategic Roadmap

Label: regulatory-compliance

Funding & Timeline

Total Funding Request: $120,000 USD, paid in Canton Coin at each milestone's acceptance rate

Project Duration: 6 months

Maximum Amount: N/A

Maximum Duration: N/A

Summary

Canton's compliance primitives are not callable from Solidity on Zenith today. This SDK ships base contracts that accept Canton-authorized actions, the Canton-side templates that produce those authorizations, party-to-address helpers over existing registration flows, a TypeScript middleware layer, and reference dApps that compose with Zenith's Gateway settlement path where it is available. It gates at the application layer (positions, LP shares, pool access), above the instrument-level controls a registry enforces, and consumes credential and party-metadata standards as they land.

Submission Checklist

  • Full proposal file is included in this PR
  • Organization and primary contact identified
  • Champion identified or Needs Champion selected
  • RFP / roadmap alignment identified, if applicable
  • Total funding request provided
  • Project duration provided
  • Proposal is within any RFP maximum amount
  • Proposal is within any RFP maximum duration
  • Milestones and milestone funding are defined in the proposal
  • Acceptance criteria are based on ecosystem value
  • Architectural alignment is addressed

Notes for Reviewers

SIGs: Regulatory Compliance as primary, Token & Asset Standards as secondary, since the SDK is the EVM-side consumption surface for CIP-56. @monsieurleberre and @shaul-da, we'd value your review.

@monsieurleberre reviewed an earlier draft and raised the key boundary question. The Registry App's native blocklist and credential-based allowlist are asset-model controls, set by the issuer over their own instrument. This SDK covers a dApp's own per-action permissions, including objects that are not registry instruments at all, such as positions and LP shares. Motivation now sets that boundary out explicitly. The two layers compose, and the SDK reimplements neither.

The proposal also states its main platform dependency openly and corrects an earlier error: external_call() is invoked from Daml workflows, not from EVM contracts, so the compliance decision comes from Canton and reaches the EVM contract as a bound authorization. Milestone 1 uses an operator-signed permit path that can be built today; the Gateway-coordinated path is designed as an adapter, added as Zenith opens it to third-party workflows.

The credentials standard. We asked the author of the draft Canton Network Credentials Standard whether the revocation signal a consumer should rely on is defined by each registry or is in scope for the standard. The author replied: "I would not expect the registry to define the interpretation, but the apps consuming the credentials and the apps producing the credentials." The reply added that an issuer for whom the DSO Credential Registry's authorization model is not suitable could run its own registry (cips#204). The SDK's authorizing service is one such consuming app.

Already on record. Qasara (#300) named this class of SDK as a target consumer of their classified-event vocabulary (forum post, PR reply).

TokenProof. ComplianceGuard stays published under Apache-2.0 after CompliLedger withdrew #231 on 8 September. Where an issuer uses TokenProof, the SDK reads its ComplianceProof for asset-level facts. Holder-level facts do not need TokenProof: they come from the operator's own compliance-status template or the Registry App allowlist.

Champion: a Tech & Ops Committee member, per CIP-0100; SIG members willing to review are equally welcome; outreach in progress. Happy to walk anyone through the draft.

← Back to Proposals