Woof - two Dev Fund proposals: EVM-side compliance & risk infrastructure for Canton (seeking feedback + Champion)

Two open Dev Fund proposals from Woof - EVM-side compliance and risk infrastructure for Canton

Hi all - woof.software is preparing two submissions to the Canton Protocol Development Fund. The pack is intentionally narrow and verifiable: we’re senior EVM engineers (active Compound DAO contractor team), and our proposals occupy two infrastructure layers that the EVM side of Canton needs before mainnet DeFi can scale safely.

Before opening PRs against `canton-foundation/canton-dev-fund`, we want to share the drafts here, calibrate scope, and surface any concerns we may have missed.

About Woof

Senior EVM engineers for DeFi, and an active Compound DAO contractor team across multiple funded cycles.

Selected delivered work for Compound (verifiable via on-chain governance and the partnership reports): new-chain deployments (Optimism, Mantle) as part of Compound’s Growth Program, 60+ asset listings across 12 markets, a from-scratch protocol front-end, AAVE v3 → Compound migration logic, Chainlink SVR integration, the CAPO price oracle, and the reserve-growth tracking stack.

Open-source artifacts (all public under github.com/woof-software)

Other production deliveries include the Silo and Benqi cross-protocol migrators and the Avalanche Urbanspace app (native USDC payments) - and others (Kava Hard Swap, King Protocol, Mezzanine, Mana)).

We do not present ourselves as DAML protocol experts. Both proposals are scoped accordingly - the EVM / Solidity side specifically, with explicit complementarity to DAML-side counterparts.

We’ve validated the core pattern end-to-end in two public PoCs - EVM-side `onlyKYC` gating (canton-compliance-poc, green CI) and a DAML counterpart executed on a live Canton ledger (canton-localnet-poc, logs + DAR committed). Details in the repos.

Proposal 1 - Compliance Middleware SDK for EVM Developers on Zenith

Submission target: first in sequence. Coordinated with Compliledger (TokenProof team) before submission.

CompliLedger - Proof Infrastructure for Canton (TokenProof Proposal PR #231) provides the planned on-ledger ComplianceGuard primitive on the DAML side with a working PoC. Their proposal explicitly does not address the Solidity surface. We propose the EVM-side complement - Solidity contracts deployable on Zenith that consume ComplianceGuard via external_call(), plus three reference DeFi dApps (Compound-shaped permissioned lending, ERC-4626 compliant vault, KYC-gated AMM).

Coordinated with TokenProof. We raised the boundary with the Compliledger team (@Mharris40) on PR #231, and they confirmed the two efforts are complementary, not overlapping and are open to coordinating on ComplianceGuard interface stability as both progress. We’ll keep our Solidity wrappers adaptable to their interface; if their design later covers the Solidity side directly, we’ll revise rather than duplicate.

We’ve reviewed the adjacent EVM↔CIP-56 efforts - #453 (Proposal: CIP-56/ERC-20 Middleware), which focuses on the transport layer, and #190 (Proposal: BlockTravel – Transaction Compliance Framework), which focuses on off-ledger decisioning. Both complement our proposal rather than overlap with it, and we’re happy to coordinate. Details are included in the proposal.

Ask: ~800,000 CC, 6 months, 2 milestones.

Proposal 2 - Canton Risk Engine (open-source risk-parameter primitives + reference implementations)

Submission target: second in sequence, after community feedback on Proposal 1 lands. Independent positioning - no required counterparty coordination.

It’s a set of MIT-licensed building blocks: an on-chain risk-parameter registry (Solidity) plus open reference implementations - Solidity examples that consume the registry, and a DAML example showing the same propose → timelock → execute parameter-governance pattern Canton-native, so firms whose contracts need these params can leverage it directly. Not a product or a hosted service. On top, an optional open-source simulator and a self-hostable dashboard as tooling - nothing operated by Woof as a paid service. The primitives generalize three risk-management patterns developed during Woof’s contribution to Compound’s risk infrastructure: the Configurator pattern (on-chain parameter governance), CAPO (Correlated-Assets Price Oracle, price-induced risk handling), and the Reserve Growth tracking model (operational risk visibility).

Why this is needed now. At least 6 lending / vault proposals in the open queue require risk parameter management before mainnet: Mystic (#99), Cantopy (#235), D2 Finance (#144), Margarita CC20 (#186), Meria (#65), Institutional Yield Segmentation (#44). None of them propose to solve risk parameter management themselves - these primitives are the shared dependency they build on, not a competing product.

The primitives sit in a distinct layer from adjacent risk work (SafeVault, Risk Ratings, Collateral Control Plane, Hacken) - on-chain parameter management specifically; details in the proposal.

Unique provenance. CAPO + Configurator + Reserve Growth is Woof-specific code and operational experience contributed to Compound. These are open-source patterns (Compound’s stack is open-source), so we have full rights to generalize them as Canton public goods - and we are uniquely positioned to do so because we built them.

Ask: ~1,000,000 CC, 6 months, 3 milestones.

Total package

# Proposal CC USD (@ 0.15) Months
1 Compliance Middleware SDK 800,000 $120,000 6
2 Canton Risk Engine 1,000,000 $150,000 6
Total 1,800,000 $270,000 staged

Submissions will be staggered ~4–6 weeks apart, not bombed at once. The committee can evaluate each in context, and we can incorporate feedback between submissions.

Strategic positioning

Woof brings EVM-side compliance and risk infrastructure to Canton’s Zenith layer. Compliance Middleware makes CIP-56 compliance natively callable from Solidity dApps on Zenith, complementing TokenProof’s planned on-ledger primitive. Canton Risk Engine extracts risk-management patterns developed during Woof’s Compound work (Configurator + CAPO + Reserve Growth) as Canton public goods. Together they provide the institutional-grade safety layer for EVM-side Canton DeFi.

What we are asking from the community

  1. SIG Champion volunteers (our main ask - external proposals need a Champion):
    • Token Standards / Regulatory Compliance SIG - for Compliance Middleware SDK.
    • DeFi Protocols & Liquidity SIG - for Canton Risk Engine.
  2. Potential first integrators for Canton Risk Engine - Mystic, Cantopy, D2 Finance, Margarita, Meria - a public signal that you’d evaluate integration would strengthen Proposal 2.
  3. Any feedback welcome - TokenProof has already confirmed our SDK is complementary; we’d value boundary checks from other adjacent teams (SafeVault, Risk Ratings, Collateral Control Plane, Hacken), and a heads-up from anyone with in-flight work we may have missed.

Future pipeline (not in this package)

  • Compound v3 Reference Deployment on Zenith - requires Compound DAO governance coordination. Q3–Q4 2026 candidate, contingent on a successful first pack landing and Compound community alignment.

We aim to open the first GitHub PR (Compliance Middleware SDK) within 3-4 weeks of this post, contingent on coordination outcomes and community feedback. The Risk Engine draft will follow once community feedback on the first proposal has been incorporated.

Thanks for reading.

Best regards,
Mykola Ilchuk
Head of R&D, Woof

Tokenisys

We would be interested in integrating products on this type of infrastructure. Two obvious products come to mind. (1) our token model risk rating that runs off chain in Fortran ( https://terminal.tokenisys.com ) and the probability distribution we use to price options and VAR/CVAR in DAML (https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6512078)

Hi Mykola

Generally, I think this would help to improve risk management across the canton ecosystem.
However, I think the ComplianceGuard daml-native primitive has more impact/utility.

From my perspective, a “risk engine” is a product… perhaps implementation examples in daml that are OSS would be another way to frame this? Then, firms implementing contracts that require params like this could leverage it.

Thanks Ian - really helpful, and I think you’re right on the framing.

Agreed the compliance primitive is higher-leverage - that’s why Compliance Middleware is our first submission and this the second.

And “engine” does read like a product, which isn’t the intent. It’s meant as public-good OSS: MIT on-chain parameter primitives plus open reference implementations (Solidity + DAML) that any firm can leverage when their contracts need these params - with the simulator/dashboard as optional open tooling, nothing hosted or proprietary. We’ll reframe it exactly that way (“open-source risk-parameter primitives + reference implementations”) so it reads as infra teams build on, not a product.

If that framing works for you, would you be open to championing it for the DeFi SIG? Either way, the input genuinely makes the proposal better - thank you.

Hi Ian. Your perspective helped us sharpen how we present this part of the proposal, and the write-up now reflects that more clearly: “open-source risk-parameter primitives + reference implementations.”

Concretely, the deliverables are an MIT-licensed on-chain registry plus open-source reference implementations, including a DAML example of the propose → timelock → execute parameter-governance pattern that runs on a local Canton ledger. That way, Canton-native teams can adopt the approach without touching the EVM side. The simulator/dashboard is now explicitly optional tooling and scheduled as the final deliverable - nothing hosted or proprietary.

With that addressed, would you be open to championing the proposal for the DeFi Protocols & Liquidity SIG? (And if championing isn’t the right fit, a pointer to the right person in the SIG would be just as helpful). Your feedback helped shape the proposal in a meaningful way, and I think it aligns well with the direction you suggested.