[Discussion] Privacy-Preserving MiCA Compliance — How Is Uniswap Handling EU Users?

Requests for Comment
1

MiCA is fully enforced. Uniswap serves EU users across multiple deployments. I haven’t seen governance discussion on how compliance will work without geo-blocking or fragmenting liquidity.

I’ve built an open-source ZK compliance layer (Piyora) — users do KYC once with any provider, then generate a zero-knowledge proof in-browser (3-5 seconds) that says “I’m compliant” without revealing identity. Verified on-chain.

Practically:

  • Single Solidity modifier to integrate. No separate pools or permissioned deployments.
  • 25K gas overhead per tx on L2 (~$0.002 on Base). One-time attestation: 280K gas (~$0.02).
  • Uniswap never touches PII. No KYC data custody, no liability.
  • Users re-prove every 7-30 days (auto-checks latest sanctions list).
  • Built in Noir (~30K constraints, UltraPlonk). Open source. Working prototype.

Not proposing a vote — genuinely checking:

  1. Is EU regulatory compliance being discussed anywhere I’m missing?
  2. Would governance consider a ZK-based approach vs traditional KYC gating?
  3. What compliance checks would be needed? (KYC level, jurisdiction, sanctions, accredited investor?)

Demo + code: piyora.org

Appreciate any input.

4

To make this concrete — here’s the scenario I think governance should be discussing:

Article 68 of MiCA requires CASPs to apply the Travel Rule to all crypto transfers. The European Banking Authority’s implementing technical standards went live June 2025. National regulators are now enforcing.

Uniswap Labs already geo-blocks certain tokens for sanctioned countries. But MiCA goes further — it requires user identification for transactions, not just token restrictions.

The options as I see them:

  1. Geo-block the EU entirely. Lose 450M+ potential users. Competitors (who comply) take the volume.
  2. Full KYC on the frontend. Kills pseudonymity. Creates massive PII liability. Fragments liquidity into “clean” and “unclean” pools.
  3. ZK compliance layer. User proves compliance in-browser, proof verified on-chain. No PII touches the protocol. Single liquidity pool. ~$0.002 per tx on L2.

I’m not pushing option 3 because I built it. I’m asking: is anyone working on option 1 or 2? Because if the answer is “we’ll deal with it when we get a letter from a regulator,” that’s a strategy — just a risky one.

Has Uniswap Foundation or any delegate spoken to EU legal counsel about the protocol’s exposure here? Genuine question — happy to be pointed to existing discussions.

5

I assume this was assessed by Uniswap Labs with EU legal counsels.

But just a quick note from my side on this topic: The essential question in my opinion (to be answered before crafting KYC mechanisms) is whether operating a monetized front-end for EU users makes Uniswap Labs an intermediary providing a crypto-asset service — in which case MiCA’s CASP regime applies and Recital 22’s “fully decentralised, without any intermediary” carve-out is unavailable – or whether the front-end is merely a non-custodial interface to autonomous smart contracts, leaving the regulated activity (if any) with the users and the exemption intact for Uniswap Labs.

It is worth checking the EU Commission’s consultation document published in May 2026.

Looking at the DeFI protocol itself, the EU Commission seems to explore indirect steering mechanisms: CASPs could be required to conduct due diligence before connecting users to DeFi protocols; access could be limited to certified DeFi applications (see questions 63 et seq). So certification schemes for smart contracts and DeFi protocols could become a route to regulatory comfort.

This may also push the regulatory analysis towards a more differentiated view of the DeFi technology stack: distinguishing between the protocol layer, smart contracts, governance mechanisms, liquidity pools, front-ends, and regulated access providers. For DAOs and protocol teams, the key question may therefore (if adapted) no longer be simply whether something is “decentralised”, but which part of the stack is controlled by whom, who monetizes access, and where users actually interact with the system.

6

@ed2i2000 — this is exactly the analysis I’ve been looking for. Thank you.

You’re right that the threshold question matters: does the monetized frontend make Labs a CASP? But I’d argue the practical outcome is the same regardless of how that’s answered. If Labs is a CASP, they need compliance tooling. If Labs isn’t, but CASPs are required to “conduct due diligence before connecting users to DeFi protocols” (your point on questions 63+), then the access providers need compliance tooling. Either way, something needs to sit between the user and the protocol that says “this person is cleared.”

The EU Commission consultation on “certified DeFi applications” is particularly interesting. A ZK compliance layer could serve as exactly that certification mechanism — the protocol itself doesn’t change, but there’s a verifiable on-chain attestation that the user accessing it has passed compliance checks. No PII on-chain, no custodial KYC, just a cryptographic proof.

Do you have a link to the May 2026 consultation document? I’d like to review questions 63+ in detail. If the Commission is actively scoping certification frameworks, that’s the window to propose ZK-based approaches before they default to traditional identity verification.

7

A few nuances from my side:

First, small correction to my earlier wording: as far as I understand, Uniswap Labs no longer charges an interface fee. So the “monetized frontend” point may be less strong today than it was when interface fees were still charged. The broader point remains, though: the frontend is a controllable layer and therefore analytically different from the autonomous protocol layer.

Second, I would be careful not to read the Commission’s “certified DeFi applications” language as meaning user-level KYC. My reading is that this is more naturally about protocol/smart-contract/ operational-risk certification (“verifying that it robustly mitigates against smart contract vulnerabilities, operational risk in general and functions in accordance with its publicised performance.”). Note that the document is still only a consultation paper, not a settled Commission position. The relevant document to search for is the European Commission / DG FISMA “Targeted consultation on the review of the Markets in Crypto-Assets Regulation (MiCA)”, published in May 2026. The relevant DeFi section is around questions 62–65. I cannot post links in the forum.

Thirdly, I do not see where CASPs (such as CEXs like Kraken) necessarily need information from DeFi protocols to comply with their current Travel Rule obligations. Their KYC duties are primarily customer-facing: identify their own customer, assess risk, collect/retain required transfer information, and monitor transfers to/from self-hosted wallets.

8

These are important corrections — thank you.

On the certification point: I take your point that “certified DeFi applications” likely refers to smart contract/operational risk auditing rather than user-level compliance. That’s a different layer entirely from what I’ve built.

On the CASP angle: you’re right that Travel Rule obligations are customer-facing today. CASPs identify their own users. But the open question is what happens at the boundary, when a CASP user withdraws to a DeFi protocol, the CASP’s obligation is to assess risk of that transfer. If a user could present a ZK proof that they’ve passed compliance checks before interacting with DeFi, that reduces the CASP’s risk assessment burden on outbound transfers to self-hosted wallets and DeFi interactions. The value might sit there rather than at the protocol frontend.

I’ll look up the DG FISMA targeted consultation. Appreciate the pointer to questions 62-65 specifically.

One follow up question: in your reading, do you see any scenario where DeFi frontends face direct compliance obligations in the next 2-3 years? Or is your view that regulation will continue to flow through CASPs as the controlled access points?

9

To be clear, to my understanding, DeFi front-ends operated by an intermediary can already fall within MiCAR today without any legislative changes. I am not promoting the application of traditional financial regulation to DeFi frontends; quite the opposite – a algorithm-based self-regulation of the DeFi space with minimal-invasive regulatory input.

But if you roll out an interpretation of the existing CASP rules in MICA, the analysis is not nearly as straightforward as is sometimes suggested. The provision I find most relevant is the definition of “reception and transmission of orders for crypto-assets on behalf of clients” in Article 3(1)(23) MiCAR:

“…the reception of an order from a person to buy or to sell one or more crypto-assets or to subscribe for one or more crypto-assets and the transmission of that order to a third party for execution.”

I don’t want to discuss every single element in detail here. To me, the analysis largely comes down to the question: Is Labs as the frontend operator actually transmitting an order for end users? And a strong counterclaim is: “We do not execute anything. The user signs and submits the transaction through their own wallet.”

Whether these arguments succeed depends, in my view, on the underlying technical architecture.

For a classic swap, the frontend receives the user’s trading parameters, receives a quote, determines a routing path across one or more liquidity pools, prepares the target contract and transaction call data, and presents the resulting transaction to the user’s wallet. The user then manually reviews and signs that transaction, which is broadcast to the blockchain by the wallet. The swap is executed directly against the liquidity pools.

Accordingly, you could state: Labs merely prepares a transaction which the user independently signs and submits. On that view, Labs does not itself transmit an order to a third party for execution.

Uniswap X is technically different. Here, the user signs an off-chain order rather than a blockchain transaction. That signed order is submitted through the Labs infrastructure, distributed to competing third-party fillers, and ultimately executed by one of those fillers through the Uniswap X settlement contracts.

While I understand that this architecture improves execution quality and reduces MEV risks, it comes with a regulatory implication: It looks considerably closer to what Article 3(1)(23) MiCAR describes: a signed order is received, transmitted through the operator’s infrastructure, and made available to third parties for execution.

10

This is the most interesting point in the thread so far.

The architectural distinction between classic swaps and Uniswap X is exactly the kind of analysis I was hoping someone would bring up. The user-signs-and-submits defense works for the classic flow, but once you have signed orders passing through operator infrastructure to third-party fillers, the Article 3(1)(23) argument gets much harder to dismiss.

So let me push this one step further: if a frontend operating Uniswap X-style architecture does trigger CASP classification — and with it, user identification obligations — what does proportionate compliance actually look like?

Full KYC at the frontend kills the product. Geo-blocking the EU is the path of least resistance but leaves money on the table. The third option is something like a ZK compliance layer: user proves they meet the requirements (jurisdiction, age, not sanctioned) without the frontend operator ever seeing their identity documents. The frontend gets a cryptographic yes/no, which satisfies the regulatory obligation without turning into a data controller.

Is that a realistic middle ground in your reading? Or do you think regulators would insist on the frontend operator having direct access to identifying information, even where the underlying obligation is just “know that your user is eligible”?

Also curious whether you see 1inch Fusion and CoW Protocol’s solver architecture falling into the same bucket as Uniswap X here. Similar pattern — off-chain signed intent, routed through operator infra to third-party execution.

11

This is easily one of the most critical discussions on the forum right now. The distinction @ed2i2000 makes between classic swaps (where the user signs and broadcasts locally) and off-chain order routing/intents (like Uniswap X, CoW, or 1inch Fusion) is spot on. The moment signed orders pass through operator infrastructure, the regulatory classification under MiCA Article 3(1)(23) becomes a major hurdle.

As builders at SilentSwap (a compliance-first, non-custodial privacy aggregator), we’ve spent a lot of time on this exact architectural boundary. We lean heavily on the philosophy that privacy and compliance are not mutually exclusive.

Here is how we practically address these architectural challenges:

  1. Decoupling Compliance from Frontend Gating: Traditional KYC gating ruins pseudonymous DeFi. A cryptographically verifiable, privacy-preserving compliance check (via secure enclave/TEE-based execution) allows a user to prove eligibility (e.g., non-sanctioned, correct jurisdiction) to the router without exposing PII to the protocol.
  2. Compliant Privacy by Design: The goal should be to keep frontend operators from becoming ‘data controllers.’ By leveraging selective disclosure mechanisms, protocols can remain compliant with global frameworks (AML/OFAC/MiCA) while keeping user liquidity completely private on-chain.
  3. Solving the Latency & Friction Trade off: Generating ZK-proofs in-browser introduces heavy UX friction (3-5 seconds of latency). Our approach utilizes a hybrid architecture where the heavy lifting, specifically real-time, compliant KYT and AML/OFAC blacklist screening, is handled seamlessly on the backend and decentralized contract layer. This ensures compliance without adding a time or latency burden to the end-user.

For teams looking at how to actually implement this at the interface or routing level, we’ve designed our architecture to integrate modularly. If anyone in the Uniswap governance or dev community is mapping out compliant routing implementations for the frontend, we’d love to share how our SDK handles these compliance rails seamlessly.

12

Good to see someone else working on this exact problem. One question on your architecture though, you mention backend KYT/AML screening handled by a “decentralized contract layer.” Is the user’s wallet address exposed to that layer during screening? Because that’s where privacy claims tend to fall apart.

We went with pure ZK (Noir circuits, on-chain verifier) specifically to avoid trust assumptions around enclaves. If a TEE is compromised, user data is gone. With ZK the user never reveals anything to anyone , the proof is the only thing that touches infra. The 3-5s proving time is a real downside, but it’s shrinking fast.

Would be curious to compare notes on what you’re hearing from protocol teams on the demand side.

1 Like
13

That is a completely fair challenge, and you are hitting on the exact architectural friction point where most privacy designs struggle.

To answer your question directly: No, the users persistent wallet address is not exposed to an open public layer during execution, and there is no traceable connection between wallets. Our hybrid architecture decouples the entry deposit from the final exit recipient through a decentralized contract layer and a proprietary backend that handles live, compliant KYT and AML/OFAC blacklists.

Regarding the cryptographic stack, we do not treat this as a TEE versus ZK compromise. SilentSwap utilizes a modular combination of ZKPs, TEEs, FHE, and MPC to optimize performance and quality. Specifically, ZK is used directly at the settlement level. Our architecture features a dedicated SilentSwap Prover that generates a ZK proof of order fulfillment to claim original deposits at the gateway contract layer.

From an infrastructure perspective, this framework addresses the exact user experience hurdles that frontends face. While generating a zero-knowledge compliance proof completely in browser values zero trust purity, it introduces heavy 3 to 5 second UX latencies directly on the user interface. High volume retail interfaces, DeFi frontends, and mobile wallets are incredibly sensitive to user drop-off caused by that kind of processing friction.

We solve this using what we call Pre-Charged Anonymity. Behind the scenes, SilentSwap continuously cycles liquidity through multiple stacked privacy layers and non-custodial sleeper accounts. This removes the time burden entirely from the users side, paying those time costs before a deposit is even initiated. The result is a secure, compliant swap that completes natively without offloading execution lag to the users browser.

Addressing the regulatory elephant in the room regarding MiCA, the framework is architecturally designed to address these upcoming European front-end liabilities. Because our architecture is fundamentally non-custodial, independently verified by Halborn in our V2 Backend Security Assessment, it interfaces perfectly with the European Banking Authority’s parameters. Under MiCA, non-custodial routing infrastructure that does not take possession or custody of user assets explicitly falls outside the scope of licensing and geographic monitoring obligations.

Furthermore, unlike historical mixer models like Tornado Cash that pooled user funds without controls, SilentSwap is a non-custodial router. We do not pool funds, and we maintain automated screening at our backend layer to cross check transactions against OFAC’s Specially Designated Nationals list before any order is routed. This non-custodial structure is backed by independent legal opinions from Montague Law.

This infrastructure model has been heavily validated at scale. Since December 2025, our protocol has processed over $3 Billion in cumulative privacy transactions. We are fully AML/OFAC compliant, thoroughly audited by CertiK, Hacken and Halborn, and recently ranked as high as #2 globally on DefiLlama for 30-day bridge aggregator volume, peaking at $452M (30 day). We have deployed this framework within the BNB Chain ecosystem and as graduates of the YZI Labs Residency Program Season 3.

The consensus from major protocol teams is clear: they want compliant architecture to insulate frontends from regulatory exposure under frameworks like MiCA, but they cannot sacrifice transaction execution or conversion rates to achieve it. A modular, non-custodial hybrid stack that implements ZK validation alongside optimized backend routing is proving to be the only viable path forward for ecosystem wide adoption.