**Authors:** SilentSwap Core Development Team
**Category:** Protocol Integration / Privacy Infrastructure
**Status:** Request for Comment - Phase 1 of the Uniswap governance process
-–
## TL;DR
We propose integrating an optional **“Swap Privately”** execution path directly into the **Uniswap interface** - the official web app and wallet - powered by SilentSwap’s non-custodial privacy infrastructure and implemented through **Uniswap v4 Hooks** and/or **UniswapX**.
The goal is native UX integration: privacy-enhanced execution presented as a first-class option alongside the standard swap, not an external tool users have to find and trust separately. The integration can be fully white-labeled, so the experience remains entirely Uniswap’s.
**What this RFC asks for:** Community and delegate feedback on (1) whether native execution privacy belongs in the Uniswap interface as an opt-in “Swap Privately” option, and (2) which integration architecture - v4 Hooks or UniswapX - should anchor a proof of concept. We recognize interface decisions ultimately rest with Uniswap Labs; a strong community signal here is the foundation for that conversation.
**What this RFC does not ask for:** Treasury funding, changes to Uniswap’s core contracts or fee structure, or any modification to how existing swaps work. Privacy is strictly opt-in, and every privacy-enhanced trade still executes against Uniswap liquidity.
**Why it matters for Uniswap:** Privacy-seeking volume currently leaves the ecosystem for external tools. Putting “Swap Privately” one tap away in the interface keeps that flow on Uniswap - the swap happens here; the privacy layer wraps around it.
**On the obvious concerns:** We know “privacy” in DeFi triggers immediate questions about mixers, sanctions, and security. Short answers up front, full detail below:
- **Not a mixer.** SilentSwap never pools deposits, never takes custody, never touches user keys.
- **Screening before execution.** Real-time AML and OFAC sanctions screening runs *before* any transaction is authorized - transactions that fail screening cannot proceed.
- **Audited.** SilentSwap’s infrastructure has undergone independent security review by Halborn, Hacken, and CertiK.
- **Legal opinion in hand.** Independent review by Montague Law concluded the non-custodial architecture does not constitute an exchange, broker-dealer, or clearing agency under the Exchange Act, with analysis of FinCEN guidance. Documentation available to delegates on request.
The rest of this post covers the business case, the compliance and legal posture in detail, and the proposed technical design at the level of Hooks, Flash Accounting, BalanceDelta, and UniswapX reactors.
-–
# Part I - The Case for Execution Privacy on Uniswap
## The problem
Every on-chain swap permanently publishes information most market participants would never voluntarily disclose in traditional finance: full wallet balances, position sizes, trading strategies, treasury movements, counterparty relationships, and complete historical activity. This data is continuously harvested by analytics platforms, MEV searchers, and competing trading systems.
For a growing class of serious users - professional traders whose strategies are alpha, DAOs whose treasury moves get front-run, businesses whose payment flows reveal supplier relationships, institutions with confidentiality obligations - total transparency is not a feature. It is the reason a meaningful share of their volume never touches a public DEX, or touches it only through cumbersome workarounds involving fresh wallets, bridges, and external privacy tools.
Based on SilentSwap’s internal market analysis, privacy-enhanced transaction activity represents roughly **12% of crypto transaction volume - over $250B annually**. We present this as our own estimate of the opportunity’s scale, not an industry-standard figure, and we’re happy to discuss methodology in the comments.
## Why Uniswap should care
Today, a user who wants both Uniswap liquidity and transaction privacy has to leave the ecosystem: swap here, then bridge or route through third-party tools elsewhere. Uniswap captures the swap but loses the relationship, the UX, and often the return flow.
This proposal inverts that. **Every privacy-enhanced transaction begins as a Uniswap swap, initiated from the Uniswap interface itself.** The trade executes against Uniswap liquidity exactly as it does today; SilentSwap operates as an optional settlement layer after execution. Concretely, this gives Uniswap:
**Retained and recaptured volume.** Privacy-seeking flow that currently exits to external tools - or avoids public DEXs entirely - stays on (or returns to) Uniswap, because the venue and the privacy layer are finally in one place: the interface users already trust.
**Differentiation no major DEX offers.** Native, compliant, opt-in execution privacy in the front-facing UX would be a genuinely new capability among top-tier DEXs, consistent with Uniswap’s pattern of shipping the category-defining feature first (AMMs, concentrated liquidity, intents, hooks).
**A door to institutional segments.** Treasury managers, funds, and on-chain businesses consistently cite transaction surveillance as a barrier to using public DEXs at size. An opt-in privacy path with screening and audits built in - accessible from the official interface rather than a third-party tool - is the version of this feature institutions can actually adopt.
**Zero disruption to the existing protocol.** No changes to core contracts, pools, fees, or the default swap experience. Users who never touch “Swap Privately” see nothing different. LPs see the same flow - privacy-routed trades still cross Uniswap pools.
**A familiar UX.** The interface change is one option in the existing swap flow: **Swap** or **Swap Privately**. Settlement completes in roughly **1–3 minutes** — no waiting periods, no anonymity-set queues, no multi-step manual workflows. Critically, this lives inside the Uniswap interface itself - one toggle in the flow users already know, not a separate site, extension, or workflow.
## Who is proposing this
SilentSwap is a non-custodial privacy infrastructure provider, live in production since **2024**, supporting Ethereum, Solana, Bitcoin, BNB Chain, Tron, Avalanche, Base, Robinhood Chain, and additional EVM networks. The protocol combines zk-SNARKs, proprietary privacy routing, and cross-chain execution to reduce on-chain linkage between wallet activity - while users retain control of their assets at every step.
Since launch, SilentSwap has processed more than **$3 billion in cumulative transaction volume**, with over **$400 million in rolling 30-day execution volume**, and has ranked among the leading Bridge Aggregators on DefiLlama.
SilentSwap ships an integration SDK and supports fully white-labeled deployments. In practice, that means “Swap Privately” can appear in the Uniswap interface as a native Uniswap capability - SilentSwap branding is not required anywhere in the user experience, and Uniswap retains complete ownership of the front end.
-–
# Part II — Compliance, Security, and Legal Posture
We are putting this section ahead of the technical design deliberately. A privacy option in Uniswap’s front-facing interface carries a higher bar than a back-end integration - and delegates are right to ask hard questions before engaging with architecture. Here is where SilentSwap stands.
## This is not a mixer
The comparison every privacy protocol gets is Tornado-style pooled mixing. The architectures are not alike - here is the point by point contrast:
**Custody of user funds.** Pooled mixers take custody - user deposits sit in a shared pool controlled by the mixer’s contracts. SilentSwap never takes custody of user funds at any point in the transaction.
**Control of user private keys.** SilentSwap never holds, sees, or controls a user’s private keys; users retain full control of their wallets throughout.
**How anonymity is achieved.** Pooled mixers create anonymity by commingling many users’ funds in one pool. SilentSwap uses non-custodial privacy routing instead - there are no commingled pools anywhere in SilentSwap’s architecture.
**Sanctions and AML screening.** Pooled mixers perform no screening of any kind. SilentSwap runs real-time AML and OFAC sanctions screening on every transaction, **before** it is authorized.
**Ability to block a transaction.** A pooled mixer cannot stop an illicit transaction - anyone can deposit. SilentSwap enforces a hard gate: any transaction that fails AML, OFAC, or wallet screening is simply not authorized and cannot proceed on the platform. There is no override and no exception path.
SilentSwap’s design goal is privacy from public surveillance and front-running - not evasion of sanctions or law enforcement. Screening is a precondition of execution, not an afterthought.
## Compliance controls
- Real-time AML screening on every transaction
- Real-time OFAC sanctions screening on every transaction
- Wallet screening and transaction risk analysis
- Automated enforcement: transactions that fail screening cannot proceed - screening is a hard precondition, not a flag for later review
- Limited operational record retention for support and compliance purposes
This framework was designed to meet the operational safeguards ecosystem partners and institutional participants expect - which is precisely what makes it suitable for surfacing in Uniswap’s own interface, where a screening-free design would be a non-starter.
## Independent security audits
SilentSwap’s infrastructure and overall security architecture have undergone independent review by leading blockchain security firms:
- **Halborn**
- **Hacken**
- **CertiK**
Audit documentation is available on request, and we would expect any integration-specific code (the Hook, settlement logic) to undergo fresh independent review before deployment - that’s a required phase of the roadmap below, not optional.
## Independent legal review
**Montague Law** conducted an independent review of SilentSwap’s non-custodial operating model. The opinion concluded that the software-based, non-custodial architecture does not constitute an exchange, broker-dealer, or clearing agency under the Securities Exchange Act of 1934 and does not operate as a traditional financial intermediary. The analysis also addressed FinCEN guidance and the broader regulatory landscape for non-custodial software.
Full documentation is available to governance delegates, protocol contributors, and engineering teams on request. We recognize a legal opinion is an input to the community’s judgment, not a substitute for it, and we welcome delegates’ counsel reviewing it.
-–
# Part III - Proposed Technical Design
Two complementary integration paths, evaluable independently or together. Neither modifies Uniswap’s settlement architecture; both keep Uniswap as the execution venue, initiated from the Uniswap interface.
## End-to-end execution flow
1. User selects **Swap Privately** in the Uniswap interface.
2. SilentSwap receives the execution request.
3. Pre-authorization screening runs: wallet screening, AML, OFAC sanctions, transaction risk analysis. Transactions that fail screening are not authorized and cannot proceed.
4. SilentSwap validates the privacy execution request and the required zero-knowledge execution data.
5. The asset conversion executes **against Uniswap liquidity**.
6. Output assets enter SilentSwap’s privacy-routing infrastructure.
7. Zero-knowledge verification and privacy routing complete.
8. Assets settle to the user’s designated destination wallet.
Typical end-to-end settlement: **1–3 minutes**.
## Path A: Uniswap v4 Hook
v4 Hooks allow execution logic to extend pool functionality without touching core contracts - which is exactly the shape of this integration.
A SilentSwap Hook would handle:
- Validation of privacy-enhanced execution requests and parameters
- Coordination of the initial Uniswap swap
- Privacy-routing authorization
- Settlement confirmation, failure handling, and refund coordination
- Applicable fee accounting
Design considerations we expect to work through with Uniswap engineers:
- **PoolManager interactions and hook permissions** - which callbacks (`beforeSwap`/`afterSwap`) are required, and minimizing the permission surface
- **Flash Accounting and BalanceDelta** - the Hook must settle deltas correctly within v4’s internal accounting; compatibility with PoolManager’s accounting model is a primary design constraint, and we do not propose any alternative settlement path
- **Gas efficiency** - keeping the privacy path’s overhead acceptable relative to a standard swap
- **Failure recovery and upgrade safety** - deterministic refund behavior if privacy routing fails post-swap
A production Hook would go through full engineering review, independent audit, and public testnet exposure before any deployment.
## Path B: UniswapX
UniswapX’s intent-based architecture offers a second, potentially complementary route: users could opt into a private execution route while continuing to use UniswapX infrastructure, rather than exposing intent through fully public pathways.
SilentSwap’s role in a UniswapX flow would include receiving eligible private execution requests, pre-authorization screening, coordination with existing liquidity pathways, privacy routing after execution, and final settlement to the destination wallet.
Open engineering questions we’d want delegate and contributor input on:
- Reactor compatibility and Permit2 handling
- Interaction with exclusive fillers and Dutch auction execution
- Quote generation for privacy-routed orders
- Settlement guarantees and failure recovery
- Fee accounting
We are intentionally presenting both paths at architectural level rather than prescribing an implementation - sequencing (e.g., proving out one path before the other) is one of the questions for the community below.
## How the privacy layer works
**Zero-knowledge execution.** SilentSwap uses zk-SNARKs to validate aspects of transaction execution without publicly exposing the full relationship between participants. ZK proofs are one component of the pipeline - they do not replace Uniswap’s settlement process or the underlying chain’s security guarantees.
**Privacy routing.** After the Uniswap swap, assets enter routing infrastructure designed to reduce direct on-chain linkage between inputs and outputs. The architecture combines ZK proofs, non-custodial execution, transaction decomposition and reconstruction, and cross-chain settlement support.
**Pre-funded execution accounts.** SilentSwap maintains pre-funded execution accounts so settlement doesn’t wait on sequential routing cycles - this is what enables 1-3 minute settlement without the long delays or anonymity-set waiting periods of traditional privacy systems, while reducing observable relationships between transaction participants. A complete technical specification covering account lifecycle, authorization, liquidity management, reconciliation, and security assumptions will be provided during engineering review.
## What further documentation we’ll provide
If the community wants to go deeper, we will publish engineering documentation covering: Hook implementation, smart contract architecture, gas analysis, security assumptions, settlement logic, zk-SNARK implementation, cross-chain routing, failure recovery, testing methodology, and reference implementations. This RFC deliberately stays at architecture level to focus the first round of discussion.
-–
# Part IV - Cost & Commitments
To be clear about scope: this RFC seeks discussion and a community signal, not approval of a commercial agreement. Commercial specifics - including the fee for the opt-in privacy path - would be defined in later phases, shaped by feedback gathered here. What we can state plainly now:
- **Cost to Uniswap: zero.** SilentSwap funds all integration engineering - Hook development, SDK adaptation, documentation, testnet deployment, and the independent security review of integration-specific code. No treasury funding is requested at any phase, including future phases.
- **Standard swaps are completely untouched.** Users who select **Swap** pay exactly what they pay today. Uniswap pool fees and LP economics are unaffected - privacy-routed trades pay pool fees like any other swap. Any privacy-routing fee applies only to users who opt into **Swap Privately** and would be disclosed in the interface before confirmation.
- **Ongoing operation at no cost to the DAO.** SilentSwap operates, monitors, and maintains the privacy-routing infrastructure.
- **No lock-in or exclusivity.** Because SilentSwap is an optional execution layer with no core-contract changes, deprecating the integration is a front-end and Hook-deprecation decision with zero impact on standard swaps.
-–
# Part V - Questions for Delegates and the Community
We’d particularly value input on:
1. Should optional execution privacy be integrated natively into the Uniswap interface as a “Swap Privately” option - and which user segments matter most?
2. v4 Hooks or UniswapX as the initial integration path - or should a proof of concept target one before the other?
3. What security assumptions deserve the hardest scrutiny before implementation?
4. Are there compliance considerations beyond the framework described above that the community wants addressed?
5. What engineering challenges (gas overhead, failure recovery, filler interactions) should receive priority attention?
6. Are there alternative architectures we should evaluate?
All feedback will be incorporated into revisions before any Temperature Check.
-–
# Proposed Roadmap
1. **Community discussion** via this RFC *(now - minimum 7 days)*
2. **Technical review** with Uniswap contributors and protocol engineers
3. **Detailed engineering documentation** published
4. **Proof-of-concept implementation** (funded by SilentSwap)
5. **Independent security review** of integration code (funded by SilentSwap)
6. **Public testnet deployment**
7. **Temperature Check**, if community-supported
8. **Formal governance proposal**, if appropriate
Nothing advances past Phase 1 without community support at each gate. Interface integration itself would proceed in coordination with Uniswap Labs, informed by the community signal this process produces.
-–
# Closing
Uniswap has repeatedly shipped the innovation that defined the next era of decentralized trading. Execution privacy - done non-custodially, with screening before authorization and independent security review behind it, surfaced natively in the interface users already trust - is a capability users are already seeking elsewhere, with worse UX and without Uniswap capturing any of the flow.
This RFC asks a narrow question: does “Swap Privately” belong in the Uniswap interface? We’re here for the discussion - technical objections, compliance concerns, and architectural alternatives all welcome.
— The SilentSwap Team
-–
## Appendix A: Why integrate rather than build natively?
Execution-layer privacy requires far more than smart contracts: production routing infrastructure, ZK proof systems, compliance tooling, security reviews, legal analysis, monitoring, and continuous maintenance. SilentSwap provides all of this today, in production. Integration lets the Uniswap ecosystem evaluate execution privacy without first funding and building a comparable privacy network from scratch - and without taking on its ongoing operational burden.
## Appendix B: SilentSwap capabilities summary
Privacy-enhanced swaps and transfers · cross-chain execution and multi-chain routing · non-custodial infrastructure · zero-knowledge execution · AML/OFAC and wallet screening · enterprise SDK · white-label integrations.
Supported networks: Ethereum, Bitcoin, Solana, BNB Chain, Tron, Avalanche, Base, Robinhood Chain, and additional EVM-compatible networks.
## Appendix C: Public resources
- Website: https://silentswap.com
- Dune Analytics: https://dune.com/silentswap/silentswap-on-chain-analytics
- DefiLlama: https://defillama.com/protocol/silentswap