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

Outreach
, ,
1

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.

We’re sharing the drafts here to 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

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: 120,000$, 6 months, 2 milestones.

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

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 proven in production on Compound: the Configurator pattern (on-chain parameter governance, Compound Labs’ design, which we operate across the markets we deploy), CAPO (Correlated-Assets Price Oracle, price-induced risk handling, which we implemented for Compound), and the Reserve Growth tracking model (operational risk visibility, our own work).

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.

Provenance. The reserve-growth stack is our own work end to end, public in the woof-software repos. CAPO came out of the Aave ecosystem, where BGD Labs first shipped it, and we brought it to Compound and wrote that implementation (github woof-software/compound-capo). The Configurator is Compound Labs’ design, and we work with it as operators, deploying and running Compound markets. All of it is open source, so generalizing the patterns as Canton public goods is ours to do.

Ask: 150,000$, 6 months, 3 milestones.

Total package

# Proposal Budget Months Milestones
1 Compliance Middleware SDK $120,000 6 2
2 Canton Risk Engine $150,000 6 3
Total $270,000 staged 5

Both budgets are stated in USD and denominated in Canton Coin at the prevailing USD/CC rate on the date each milestone is accepted - the same basis used elsewhere in the queue. That is also how each proposal satisfies CIP-0100’s requirement to state a volatility mechanism for milestones at the six-month mark: the cost of the work is a USD cost, so no CC quantity is fixed at submission, and neither side is exposed to where the rate happens to sit on an arbitrary date.

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 generalizes risk-management patterns proven on Compound (Configurator + CAPO + Reserve Growth, see Provenance) 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.

Both proposals are now open as draft PRs: Compliance Middleware SDK is #621, Canton Risk Engine is #665. See the latest comment in this thread for what changed since this post.

Thanks for reading.

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

2

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)

3

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.

4

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.

5

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.

6

We’re building Canton Event Stream (Dev Fund #300) — an open-source edge tier that classifies raw ledger events into a stable application vocabulary and fans them out over WebSocket/SSE with Canton’s per-party visibility re-enforced at the edge. Both proposals here sit directly downstream of it, so to be specific about which piece touches which:

  • Compliance Middleware SDK → our classified-event API. Compliance monitoring is one of the named consumer classes the classified-event vocabulary is being designed for. A compliance middleware layer is exactly that consumer — it would subscribe to our classified events via the published AsyncAPI spec rather than re-implement classification against raw ledger events. We’d align the vocabulary with the SDK’s needs so it serves this use case directly.
  • Public risk dashboard → our streams. A real-time risk dashboard is a natural client of the WebSocket/SSE classified streams — pre-classified, per-party-authorized feeds are exactly what it needs and would otherwise have to rebuild.

Happy to align interfaces as both move forward. Concrete compliance and risk consumers are genuinely useful for shaping the event vocabulary, so this is a two-way benefit.

7

Thanks Anand! Сonfirming the integration points from our side. The Compliance Middleware SDK’s event layer is built to consume classified, party-scoped events rather than raw ledger updates, so a stream with a stable compliance-event vocabulary is precisely the input we’d want - and the risk dashboard’s state rebuild is an even more direct consumer of the WS/SSE streams. Once our PR is up, we’ll share the SDK’s concrete consumption cases (status transitions, resume/dedup semantics) to help pressure-test the taxonomy. A good example of two proposals composing rather than overlapping.

8

Both proposals are now open as draft PRs:

  • Compliance Middleware SDK: #621
  • Canton Risk Engine: #665

What changed since the first post, and why.

The Risk Engine was reframed after Ian’s comment above. It is a set of open primitives and reference implementations, not a product: the registry plus the Solidity and DAML examples are the core. The simulator and dashboard are optional tooling, and they come last.

Both proposals now have adoption gates. For the SDK, the second milestone requires two external teams to integrate it in a test environment and write up what the integration was actually like. For the Risk Engine, the optional tooling milestone requires at least one external Canton DeFi team to have deployed the registry first. We should not be paying for tooling on top of primitives nobody uses.

Champion is still open on both.

The one thing that would help most: if you are on one of the lending or vault teams named above, spend twenty minutes with the registry design in the Risk Engine’s Specification section and note anything you need that is missing. Feedback that shapes the interface before it is built is worth more than agreement afterwards.