Uniswap governance is discussing an RFC submitted by SilentSwap that would add an optional private execution path to the Uniswap interface, using Uniswap v4 hooks and UniswapX to reduce transaction information exposure before swap execution. The proposal frames the feature as a 'Swap Privately' option that would leave standard swaps untouched and pool fees unaffected, using zk-SNARKs and pre-execution compliance screening to process trades more privately. The RFC addresses a persistent DeFi problem: on-chain swap transparency allows transaction intent to leak before execution, giving bots and sophisticated traders opportunities to front-run, sandwich, or otherwise exploit users.
SilentSwap Proposal Targets MEV And Front-Running Exposure
The RFC identifies execution visibility as a core problem in DeFi trading. When users submit transactions, their intentions can become visible before the transaction is finalized, allowing bots to monitor pending transactions, estimate likely price impact, and insert their own trades around the user. The proposal describes MEV, sandwich attacks, and execution leakage as established issues in DeFi. Some users have learned to protect themselves with private RPCs, aggregators, slippage controls, or more advanced routing tools, but the RFC notes that many users have not adopted these protections. The suggested architecture would make protection easier from the interface level, as most users interact with DeFi through frontends rather than directly through contracts.
Uniswap v4 Hooks Enable Custom Execution Logic
The RFC leverages Uniswap v4 hooks as a core component of the proposed architecture. Hooks allow developers to customize pool behavior and execution logic around swaps, supporting new kinds of routing, fees, order handling, and privacy-related features. In this proposal, v4 hooks are part of the suggested architecture for private execution. The RFC also incorporates UniswapX, which already handles more flexible swap execution and external fillers. The combination would give users a route where their transaction details are less exposed before execution, while still using Uniswap's liquidity and interface.
RFC Combines Privacy Architecture With Compliance Screening
The proposal pairs privacy with pre-execution compliance screening. The RFC describes this pairing as reflecting current DeFi privacy development, where users want protection from front-running and data leakage while regulators and protocols want to avoid creating tools that enable sanctioned activity or abuse. The proposal uses zk-SNARKs and compliance screening to process trades. The RFC states that this approach attempts to protect legitimate users while still allowing some form of compliance control.
Proposal Remains In Discussion Stage Without Approval
The RFC is a discussion proposal, not a live or approved product. Uniswap governance still needs to debate whether the design makes sense, whether the technical implementation is safe, whether compliance assumptions are acceptable, whether the UX is clear, and whether the feature creates any new risks for the protocol or interface. The RFC acknowledges that there may be concerns around complexity, trust assumptions, screening providers, legal exposure, cost, and whether users understand what 'private' actually means. The proposal is based on the Uniswap governance RFC on native execution privacy through v4 hooks and UniswapX.
FAQ
What does the Uniswap RFC propose?
The RFC submitted by SilentSwap proposes adding an optional private execution path to the Uniswap interface using Uniswap v4 hooks and UniswapX. The feature would be presented as a 'Swap Privately' option, leaving standard swaps and pool fees unchanged while using zk-SNARKs and pre-execution compliance screening.
Why does the RFC address swap privacy?
The RFC identifies that on-chain swap transparency allows transaction intent to leak before execution, giving bots and sophisticated traders opportunities to front-run, sandwich, or otherwise exploit users through MEV and execution leakage.
What is the current status of the proposal?
The proposal is an RFC in the discussion stage. It is not a live feature or approved governance change, and Uniswap governance still needs to evaluate the design, technical implementation, compliance assumptions, and potential risks.
