The latest Uniswap RFC proposes embedding a compliance screener directly into the swap execution path. That’s not an upgrade. It’s a fundamental redesign of the protocol’s trust model.
Let me be clear: I’ve spent years auditing smart contracts and zk-circuits. I’ve seen how even well-intentioned privacy features can become attack vectors. This RFC attempts to solve MEV extraction while pandering to regulators. It introduces more problems than it fixes.
Context: The Modular Maze
Uniswap v4 introduced Hooks – custom logic executed around pool operations. UniswapX is a separate off-chain settlement engine using a filler network. The RFC combines both: a user submits an intent, a compliance screener validates it off-chain, a zk-SNARK proves compliance without revealing identity, then a filler executes the swap on v4.
This is not new in isolation. Flashbots’ private RPC already hides orders from public mempools. Cow Swap uses batch auctions for MEV protection. The novelty here is integration into Uniswap’s native UI. But integration creates coupling. Coupling breeds fragility.
Core: Code-Level Implications
Let’s dissect the proposed flow:
- User intent generation – The user selects a token pair and amount. The RFC does not specify how the intent is encrypted or delivered. Likely a signed typed data payload.
- Pre-execution compliance screening – A server (or decentralized network) checks the user’s address against sanctions lists. This is where the trust shifts. If the screener is a single entity, it’s a central point of failure. If it’s a committee, consensus latency kills UX.
- zk-SNARK proof generation – The user generates a proof that they passed screening without revealing their address. This requires the user’s wallet to run a prover. On mobile browsers? Unlikely. Offloading to a relay introduces a new trust assumption.
- Order placement via UniswapX – The proof accompanies the order to the filler network. The filler verifies the proof on-chain before executing. This adds gas costs for proof verification (~200k gas for Groth16, more for PLONK).
- Settlement with v4 Hooks – The filler calls a v4 pool with a Hook that verifies the proof. Hooks can be malicious. Reentrancy through Hooks is a known risk. Combining Hooks with off-chain data increases attack surface.
Critical trade-offs:
- Privacy vs. latency: zk-SNARK proving takes seconds to minutes. Users expecting instant swaps will abandon the flow. The RFC offers no performance benchmarks.
- Compliance vs. censorship: The screener must keep a list of blocked addresses. Who maintains that list? If it’s the Uniswap DAO, it’s a governance attack vector. If it’s a third party, it’s a regulator’s dream.
- Security vs. complexity: Each additional component (screener, prover, verifier, Hooks) introduces a bug surface. A single vulnerability in the proof verification can bypass compliance entirely.
Based on my experience auditing a zk-DEX in 2024, I can tell you that Groth16 implementations often have subtle soundness flaws. The challenge generation phase is particularly fragile. Without a formal verification of the entire stack, this RFC is dangerous.
Contrarian: The Compliance Screener is the Blind Spot
Everyone focuses on the zk-SNARKs. The real risk is the “pre-execution compliance screener.”
First, it contradicts Uniswap’s core ethos of permissionless access. The RFC frames it as optional. But optionality is a myth in practice. Once the infrastructure exists, regulators will pressure for mandatory use. Tornado Cash taught us that. The RFC is building a compliance framework into the protocol’s DNA.
Second, the screener becomes a honeypot for attackers. If a malicious filler compromises the screener, they can approve restricted transactions. The RFC does not specify redundancy or dispute mechanisms.
Third, the legal exposure is immense. If the screener mistakenly blocks a legitimate user, that user could sue. If it fails to block a sanctioned entity, Uniswap Labs might face penalties. The drafters likely hope to offload liability, but courts won’t be fooled.
Fourth, there’s an inherent conflict of interest. The RFC is submitted by “SilentSwap,” a pseudonymous team. No track record. No public codebase. I’ve seen similar proposals used as marketing stunts. The community should demand full disclosure before dedicating mindshare.
Fifth, the economic incentive for fillers is unclear. Fillers currently extract MEV by frontrunning or sandwiching. This RFC eliminates that. Why would fillers participate? The RFC doesn’t address compensation. Without fillers, the system collapses.
Takeaway: A Fork in the Road
This RFC will not be implemented as drafted. The community is too polarized. Privacy advocates will reject the compliance screener. Regulators will see it as insufficient. Developers will balk at the complexity.
But it signals something important: DeFi cannot ignore privacy and compliance forever. The next bull run will bring scrutiny. Uniswap must evolve.
I predict a different outcome: a stripped-down version that focuses only on MEV protection using zk-SNARKs without compliance, deployed as an optional feature. That would still require solving the user-proof generation issue, likely through trusted execution environments (TEEs) or hardware wallets.
The real question: can DeFi build privacy without granting regulators a backdoor? Based on this RFC, the answer is no. Not yet.
– Nathan Smith, Core Protocol Developer