[RFC] Native Execution Privacy in the Uniswap Interface via v4 Hooks and UniswapX

Requests for Comment
1

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

4 Likes
2

Providing an optional privacy-preserving execution path while keeping Uniswap as the execution venue could improve the user experience for those who value transaction privacy, especially if it can be achieved without modifying the core protocol.

One area I’d like to understand better is how governance would evaluate the long-term sustainability of the AML/OFAC screening model. Since compliance requirements can evolve, who is responsible for maintaining the screening infrastructure, and how transparent will updates to those policies and providers be?

From a technical perspective, I’m also interested in how the additional privacy-routing step affects execution reliability and user expectations. If settlement typically completes within 1–3 minutes, are there safeguards or fallback mechanisms if the process is delayed or interrupted?

Overall, I think an opt-in approach is a sensible starting point, but clear operational, legal, and performance expectations will be important before considering broader adoption.

3

On the screening model: compliance is maintained at the protocol level and is entirely our responsibility, with none of the cost or burden falling on the DAO, Uniswap Labs, or LPs. Screening data comes from an established third-party compliance provider, the same category of vendor exchanges rely on, which is a deliberate choice for exactly the reason you raise: keeping sanctions and AML data current is their core business. SilentSwap enforces the results, so a failed screen blocks the transaction from proceeding. And because screening runs upstream of execution, compliance can evolve without ever touching Uniswap contracts, the Hook, or the interface. On transparency around policy and provider updates, that’s a fair ask, and we think the right place to define it is the technical review and documentation phases with community input.

On reliability and fallbacks: the key safeguard is structural. SilentSwap never takes custody of user funds. When a user initiates a private swap, funds go into an escrow smart contract, not to SilentSwap. It’s a time-locked, order-based escrow: the deposit is locked against a specific order with an expiration, and funds can only leave that contract in one of two ways. Either we present a valid cryptographic attestation that the swap was delivered to its destination in a timely manner, or the order expires and the user withdraws their funds themselves, directly from the contract, with no support ticket and no permission from us needed. The contract enforces the guarantee rather than relying on trust in us.

Beyond that, the process is self-healing: if a transaction hits a problem mid-route it’s automatically reattempted, which is why stalls rarely surface to users at all. Typical settlement is 1 to 3 minutes, and in the rare case an order genuinely can’t complete, the expiry withdrawal path is the backstop.

For the Uniswap integration specifically, deterministic refund behavior is listed in the RFC as a primary Hook design constraint, and the full failure analysis will be specified in Phase 3 documentation and independently reviewed before any deployment. If there are specific failure scenarios you’d want addressed there, we’d welcome them.

1 Like
4

A good follow-up is to acknowledge their detailed response and push the discussion toward transparency and governance without repeating points they’ve already answered.

Thanks for the detailed explanation. The escrow-based design and deterministic refund path address one of my biggest concerns around custody and failed execution, and it’s helpful to see that compliance updates can happen independently of the Uniswap integration.

One area I think will be particularly important during the later phases is observability. If this becomes an opt-in feature on a major interface, having transparent metrics—such as successful settlements, expiry refunds, average settlement time, and screening rejection rates (where appropriate and privacy-preserving)—could help both users and the community evaluate how the system performs in practice.

I’ll be interested to see how those operational metrics and the technical review evolve as the proposal progresses. I think that level of transparency would go a long way toward building confidence in the integration.

5

Thanks @Toza really appreciate the thoughtful engagement and validation on the escrow and compliance design :handshake:

1 Like
6

The pleasure is mine. :innocent:

1 Like
7

This is the future of swaps. I would use Uniswap more with this integration.

1 Like
8

Update: Concluding Phase 1 (RFC) & Next Steps

Thank you to the Uniswap community for taking the time to review our RFC over the past week and for engaging with the core concepts around non-custodial execution, compliance models, and system safety.

Key Takeaways & Architectural Clarifications

Based on the feedback gathered during Phase 1, we want to reiterate a few core design principles that guide our integration framework:

  1. Non-Custodial Safety & Fallback Mechanics:
    User safety remains our highest priority. As detailed in our RFC, SilentSwap operates on a non-custodial framework. In the rare event an execution path encounters a delay, funds remain secured within order-based escrow logic with deterministic timeout protections, allowing users to safely recover funds without relying on central intervention.

  2. Upstream Compliance:
    Sanctions and AML screening occur upstream at the protocol level prior to execution, maintaining zero cost or regulatory burden on the DAO, Uniswap Labs, or Liquidity Providers.

  3. Observability & Execution Privacy:
    We appreciate the discussion around system observability. On-chain execution state changes naturally remain verifiable via standard contract events. However, to strictly maintain user execution privacy and prevent data leakage, internal routing mechanisms and screening telemetry remain non-public by design.

Moving into Phase 2 & 3

Per our proposed roadmap, we are officially concluding the initial RFC discussion phase. We are now moving into Phase 2 (Technical Review) to engage with protocol contributors and engineers on evaluating high-level v4 Hook vs. UniswapX integration pathways.

Following these initial technical reviews, our team will share a Phase 3 Integration & User Flow Summary directly to this thread, focusing on:

  • High-level user execution flows (referencing our public Technical Overview)
  • Standard front-end integration parameters for Uniswap v4 / UniswapX
  • General gas efficiency benchmarks
  • High-level safety considerations ahead of formal evaluation

Thank you again to the Uniswap community for the review. We look forward to sharing our integration updates here as Phase 2 progresses!

— The SilentSwap Team

2 Likes
9

Thanks for the detailed write-up and for clarifying how the compliance path is structured – especially this part:

“On the screening model: compliance is maintained at the protocol level and is entirely our responsibility, with none of the cost or burden falling on the DAO, Uniswap Labs, or LPs.”

That separation of responsibilities between SilentSwap and Uniswap makes a lot of sense for an opt-in privacy feature exposed in the main Uniswap and UniswapX interfaces.

We are building Newton Protocol (newton.xyz) — a privacy-preserving compliance and attestation layer aimed at making KYC/AML policy checks cryptographically verifiable onchain without leaking underlying user data. In the context of this RFC, I think there’s a natural complement between SilentSwap’s role as the central gatekeeper for screening and an onchain attestation layer that lets Uniswap governance and integrators verify that screening happened as specified.

Right now, the model is:

Screening and risk analysis run upstream at the SilentSwap protocol level, using an exchange-grade third‑party compliance vendor.

SilentSwap enforces results; failed screens are blocked, and updates to policies/providers never touch Uniswap contracts, hooks, or the interface.

That’s good from an operational perspective, but for delegates and institutional users it’s still largely a “trust the black box” story. There’s no easy way to prove onchain that a given private swap satisfied the relevant AML/OFAC policy, or to expose aggregate metrics in a privacy-preserving way.

What Newton is working on (and would be excited to collaborate on here) is a design where:

The compliance vendor + SilentSwap produce privacy-preserving attestations (e.g., ZK proofs or similar) that “this wallet / this order passed policy X under provider Y,” without revealing PII or underlying screening data.

Those attestations are verifiable onchain by the escrow/settlement contracts and, in aggregate, by Uniswap governance – so delegates see cryptographic evidence that the opt‑in privacy path is enforcing the promised policies, not just operational assurances.

SilentSwap keeps full responsibility for running the screening engine and evolving policies, but the outputs become auditable artifacts rather than opaque results.

Concretely, that could help with:

Strengthening the RFC’s pitch to Uniswap delegates: “our AML/OFAC model is not only robust and upstream, it’s also onchain-verifiable in a privacy-preserving way.”

Giving Uniswap a clearer line of sight on long‑term sustainability and transparency for the screening model.

Opening the door to reusing the same verifiable‑compliance primitives in other Uniswap products, like the Permissioned Pools, where regulated participants need strong guarantees about both privacy and policy enforcement.

If/when this moves into the “technical review” and “detailed documentation” phases, I’d be happy to share more concrete ideas (circuit design options, attestation formats, and integration surfaces around the escrow contracts and hooks) and see whether a Newton‑style layer could slot cleanly into your existing architecture without disrupting the responsibilities you’ve laid out here.

1 Like
10

It’s great to see the discussion progress into the technical review phase. I also appreciate the team’s willingness to address questions around compliance responsibility and the non-custodial escrow model in detail.

I understand why routing and screening telemetry need to remain private, but I think there’s still room for transparency through aggregated, privacy-preserving metrics. For example, publishing statistics such as average settlement times, successful settlement rates, expired orders, and system availability could help the community evaluate the reliability of the integration without exposing sensitive operational details or user information.

Looking forward to seeing how the engineering review addresses these operational considerations alongside the hook architecture and security model.

11

One reframe on the black box point.

Enforcement here isn’t operational assurance alone. The screening gate is structural, since a failed screen means the transaction cannot proceed, and the settlement guarantees are contract enforced rather than trust based.

Screening is maintained at the protocol level as our responsibility, powered by an established third party compliance provider, and that model is how we keep sanctions and AML enforcement current without any burden touching Uniswap contracts, the Hook, or the interface.

What delegates can rely on is the outcome the design guarantees. A failed screen cannot execute, and no user ever has to trust us to get their funds back. The screening stack itself is the provider’s, and its internals aren’t ours to publish.

Interesting to see teams working on this problem space. Appreciate you laying it out.

12

One angle missing from this discussion: SilentSwap is proposing to be both the infrastructure operator and the sole privacy provider embedded natively in the interface. Before any PoC, it would help to see (1) a clear conflict-of-interest disclosure given SilentSwap’s commercial incentive to be the default/only ‘Swap Privately’ backend, (2) whether the integration is provider-agnostic or could later support alternative privacy infra without another full governance cycle, and (3) concrete, measurable success KPIs for the pilot (adoption %, latency, failure rate, screening false-positive rate) with a defined sunset/rollback clause if those thresholds aren’t met within a set timeframe. Native UI placement gives SilentSwap significant distribution advantage over competitors - governance should weigh that as carefully as the technical and compliance risks already raised.

@SilentSwap_BD

13

These are fair points and the conflict of interest one deserves a direct answer.

Yes, SilentSwap has a commercial interest in this integration. We proposed it, we build privacy infrastructure, and native placement would benefit us. We don’t think that should be obscured, and you’re right that governance should weigh it alongside the technical and compliance questions. What we’d point to is how the RFC is structured around that reality. We’re asking for a community signal, not a mandate. Interface decisions rest with Uniswap Labs, which means we cannot vote, lobby, or fund our way into the interface. Labs decides on the merits, and this thread is part of the record they’d weigh.

On exclusivity, we’re not asking for it and the RFC doesn’t create it. Nothing in this proposal would prevent governance from signaling for, or Labs from integrating, other privacy providers alongside or instead of us, and no part of our design locks Uniswap into our infrastructure. Part IV states there’s no lock in, and we’d have no standing to object to a competing proposal going through this same process. If our integration only survives by being the only option, it doesn’t deserve the placement.

On KPIs and a sunset clause, it’s worth naming where those mechanisms come from. They’re standard where a proposal draws treasury funds or delegated authority, because the clause makes the spending or the mandate stop by default. This proposal contains neither. There’s no treasury ask, no delegated power, and the feature is opt in at the interface layer, which means there’s nothing here that flows by default and needs a clause to stop it. The rollback mechanism is stronger than a sunset date. Interface decisions rest with Labs, so the feature can be removed at any time without a governance cycle, and the roadmap is phased so nothing advances without community support at each stage. The community’s ability to stop this exists continuously, not at a single checkpoint. We’ve deliberately not invented numeric thresholds before anything exists, because pre PoC numbers tend to be theater rather than accountability. Whether and how a pilot gets measured belongs to the phase where a pilot actually exists, and the community will be in that conversation by construction.

The distribution advantage point is real and we won’t pretend otherwise. Our position is that the answer to it is the process this thread is part of, an open one any competitor can also use.