[Discussion] ZK compliance layer for EU users — alternative to permissioned pools

Governance General
1

MiCA is enforced. Aave needs a compliance path for EU users that doesn’t fragment liquidity into separate permissioned pools like Arc did.

I’ve built a working ZK compliance attestation protocol (Piyora). Users do KYC once with any provider, then generate a zero-knowledge proof in-browser (3-5s) that says “I’m compliant” — valid KYC, allowed jurisdiction, not sanctioned, not expired — without revealing identity. Verified on-chain, 25K gas per tx on L2.

What this means practically for Aave:

  • No separate pool needed. Compliance check sits as a modifier on EU-facing functions in the main pool.
  • No KYC data custody. Aave never touches PII. Liability stays with the KYC provider.
  • 25K gas overhead per tx ($0.002 on Base). One-time attestation submission: 280K gas ($0.02).
  • Users re-prove every 7-30 days (checks latest sanctions list automatically).

The circuit is built in Noir (~30K constraints, UltraPlonk, no trusted setup). Solidity verifier auto-generated. I have a working prototype — contracts tested (13 passing), proof generates and verifies locally.

I’m not proposing a governance vote here — just checking:

  1. Is EU compliance being actively discussed? I see nothing in recent proposals.
  2. Would a ZK approach be considered, or is the preference for traditional KYC gating?
  3. What specific checks would governance want? (KYC level, jurisdiction whitelist, sanctions, accredited investor status?)

Happy to share a demo or technical details if there’s interest.

2 Likes
2

Thanks for kicking this off MiCA alignment for EU users is a gap in the current roadmap and deserves explicit governance discussion, not just implementation‑layer experimentation.

From a governance and risk perspective, a few concerns stand out:

  1. Regulatory interpretation risk: You frame Piyora as a “compliance path”, but there is no reference to legal opinions, interaction with EU supervisors, or how this setup would be treated under MiCA for a CASP operating systemically at Aave’s scale. Without this, the protocol is effectively taking an unpriced bet that ZK‑mediated attestations will be viewed as equivalent to more traditional KYC/whitelisting structures.

  2. KYC provider governance: The security and compliance guarantees here are entirely downstream of the KYC providers’ practices, jurisdiction and supervision. Who decides which providers are acceptable for Aave, on what criteria, and how often they are reviewed or rotated? Without a clearly defined “Aave‑level” standard for providers, this can devolve into compliance‑washing: on‑chain boolean = true, but off‑chain controls weak or fragmented.

  3. Enforcement and revocation mechanics: You mention re‑proving every 7–30 days and automatic sanctions checks, but it is unclear how revocation, false positives, or changes in user status propagate into the Aave system in a way that satisfies regulators’ expectations around auditability and ex‑post investigations. For example, can Aave (or its risk / legal representatives) reconstruct who accessed what, when required by law, without turning this into a de facto identity honeypot?

  4. Future‑proofing vs. lock‑in: MiCA‑related RTS and guidance are still evolving. If future rules explicitly favour segregated / permissioned environments for EU users or stricter CASP obligations around direct customer records, how easily can this ZK layer be adapted or unwound without fragmenting liquidity or creating breaking changes for existing users? Right now this feels more like an elegant technical solution than a fully costed regulatory strategy.

I’d be very interested to see:

  • Any written legal / regulatory analysis that maps the Piyora model to specific MiCA articles / obligations.

  • A proposed governance framework for (a) recognising / de‑recognising KYC providers, and (b) handling incidents where attestations are shown to be faulty or abused.

  • A comparison between this approach and a more conservative “EU‑specific instance / whitelabel” path in terms of legal risk, operational overhead, and liquidity fragmentation, so delegates can reason about trade‑offs explicitly rather than only from an engineering perspective.

Without this evidence layer, I’d be hesitant to treat ZK attestations as the EU compliance answer for Aave, even though it’s clearly a promising building block.

3

These are the right questions and I want to be upfront about what I have solid answers for and where the gaps still are.

Regulatory mapping

The legal hook I’m building on isn’t speculative, it’s Article 3(1)(23) MiCAR, which defines CASP activity as “reception and transmission of orders for crypto-assets on behalf of clients.” There’s been a detailed discussion on the Uniswap governance forum with regulatory researchers about how this applies to frontends with off-chain order routing (Uniswap X, 1inch Fusion, CoW). The short version: when a user signs an off-chain
order that gets routed through operator infrastructure to third party fillers, that looks onsiderably closer to what Article 3(1)(23) describes than a classic direct swap.

For Aave, the relevant pressure comes from Articles 67-68 (Transfer of Funds Regulation) and the broader CASP obligations around user identification. The question isn’t whether regulation arrives, it’s which compliance architecture preserves unified liquidity when it does.

How the ZK model maps: the user’s identity IS verified (by a supervised KYC provider), the verification IS auditable (credential issuance is logged), but the protocol never becomes a data controller. The on-chain proof confirms compliance status without storing PII. That’s also a GDPR advantage, alternatives that require the protocol to hold user data make Aave a data controller, with everything that implies.

Honest gap: I don’t have a formal legal opinion from a law firm yet. That costs €15-30K and is in the grant pipeline (EF application pending since June 24). What I do have is the regulatory analysis from the Uniswap governance thread and the DG FISMA targeted consultation from May 2026 (questions 62-65), which explicitly asks about “certified DeFi applications.” Not the same as a legal opinion, but it’s not nothing.

KYC provider governance

Here’s what I think a workable framework looks like, open to pushback:

An on-chain Credential Issuer Registry, governed by Aave governance. Providers get added via proposal + vote, with minimum criteria: supervised by an EU NCA or equivalent, supports programmatic verification, meets a data protection baseline (ISO 27001 or similar), and agrees to a revocation API with defined SLAs.

Removal works on an expedited path (shorter voting period), triggered by regulatory action against the provider, unacceptable false-positive/negative rates, or failure to respond to revocation requests. Every 6 months, each provider’s status gets re-confirmed.

For incidents: if an attestation is shown to be faulty, the provider’s credential gets frozen pending investigation. Affected on-chain attestations get flagged as “disputed” rather than auto-revoked, due process matters, and mass auto-revocation creates its own risks.

On the auditability question, can Aave reconstruct who accessed what under legal compulsion? Yes, but not directly. The ZK proof doesn’t reveal identity, but the credential issuer retains the KYC record. Under a court order or regulatory demand, the issuer (not the protocol) produces the identity. Aave never holds the data, can’t leak it, but the legal trail exists. Architecturally this is similar to how SWIFT works: the bank holds customer data, not the network.

ZK attestations vs. EU-specific permissioned pool

ZK attestation layer EU permissioned pool
Liquidity Unified, all users same pool Fragmented, EU users separated
Data liability Protocol holds zero PII Protocol/operator holds PII (GDPR controller)
Adaptability Update credential requirements off-chain; contracts unchanged Rebuild pool architecture if rules change
If we’re wrong Attestations expire naturally in 7-30 days, module unwound cleanly Liquidity migration required
User experience Prove once, use across any protocol with same standard Whitelist per-protocol, re-apply everywhere

The permissioned pool path creates two-tier DeFi and makes Aave a data controller. If future RTS does end up favouring segregated environments, the ZK layer can still gate access to a specific pool, same contract interface, just add a pool-level policy check. It’s strictly more flexible.

What I’m not saying: that this is production-ready for Aave today. The circuits and contracts work (full E2E verified, 13 Solidity tests passing, public repo), but deploying at Aave’s scale needs a formal legal opinion, a security audit, and a governance-approved provider list. None of that exists yet.

What I am saying: starting this discussion now, before enforcement forces a rushed decision, is cheaper than starting it later. And the architecture is right even if the timeline isn’t omorrow.

1 Like
4

Appreciate the detailed breakdown, this is exactly the kind of evidence-based response governance discussions need.

That said, I’d flag that the three biggest asks from my original comment are still open:

  1. Formal legal opinion — the Article 3(1)(23)/67-68 mapping is a reasonable hypothesis, but it’s still your interpretation, not independent legal counsel. Given the EF grant is only “pending,” this could take a while to materialize.

  2. Security audit — 13 passing tests is a good start but isn’t a substitute for a third-party audit, especially for something touching compliance/identity at Aave’s scale.

  3. Governance-approved provider list — the Credential Issuer Registry framework is well thought out, but until actual providers go through a vote, this remains theoretical.

Given these gaps, I’d suggest this stays firmly in “watch and prepare” territory rather than something delegates should act on. Happy to revisit once the legal opinion and audit are in hand, until then, this reads more like a strong RFC than a governance-ready proposal.

1 Like
5

The regulatory risk point is legit. But I think the liability framing might be the trickier part — saying it “stays with the KYC provider” assumes MiCA lets Aave sidestep responsibility for EU transactions just because the proof is valid. If regulators decide Aave’s still the CASP on the hook, then the ZK part solves the UX problem, not the legal one. Has anyone checked whether that actually flies with an actual regulator, or is that still the open question?