People often ask how to propose an encrypted mempool for their ecosystem. There is no universal playbook. Technical architectures range from monolithic Layer 1s to modular rollups, and governance spans foundations, tokenholder delegates, working groups, and commercial partnerships. A proposal that works on one chain may fall flat on another, even if the technology is identical.
This article shares what we've learned from implementing and proposing encrypted mempools across different environments. It provides a practical approach to proposing an encrypted mempool integration that you can adapt to your specific context.
Our aim is not to promise a path for guaranteed integration, but to provide a clear, defensible framework for advocating and deploying credible, measurable improvements against harmful Maximal Extractable Value (MEV) and real-time censorship.
If you want to propose an encrypted mempool for your chain or community, please contact us, and we'll be glad to collaborate with you on it.
What an Encrypted Mempool Means in Practice
Shutter uses a threshold encrypted mempool system. In this setup, a user's transaction is encrypted before it enters the mempool. A decentralized set of Keypers is responsible for managing the decryption process. The key principle of this system is "commit-then-decrypt": first, a validator or sequencer commits to the order and inclusion of the transaction; only then do the Keypers release their decryption shares to allow the transaction to be executed. Until this commitment is made, the contents of the transaction remain opaque to observers in the mempool.
When proposing integration, distinguish between two separate and perpendicular axes:
Where Encryption Happens
- Wallet (native): best UX, direct control over what's encrypted.
- dApp (SDK/library): lets apps protect specific flows quickly.
- RPC proxy: fastest adoption path; encrypt before forwarding to existing clients.
How Deeply the Chain Integrates the Encrypted Flow
- Out-of-protocol: opt-in encrypted submissions coexisting with plaintext.
- PBS-aligned commitments: proposer commitments and builder constraints enforce commit-then-decrypt in the block-building pipeline.
- In-protocol: encrypted payloads become first-class (a later step, after evidence and consensus).
Your path depends on governance appetite and client complexity, not on where encryption is performed.
Why a Threshold-Encrypted Mempool Is Worth Proposing
An encrypted mempool is not about secrecy for its own sake; instead, it aims to eliminate the real-time information leakage that enables malicious pre-trade MEV and censorship. By keeping transaction details hidden until the order is finalized, adversaries cannot position themselves between a user and their desired outcome. This process is mechanical and does not depend on the goodwill of the validator or sequencer.
Core Benefits at a Glance
- Mitigates harmful MEV: Reduces front running/sandwiching, copy-trading, and sniping in mints and gaming.
- Front-running-resistant scheduling: Time/block-scheduled transactions can remain hidden until the agreed commitment window (useful for launches and auctions).
- Credible neutrality for validators/sequencers: If contents aren't visible at the decision point, they can't be exploited; aligns naturally with Ethereum's PBS and rollups' centralized sequencers.
- Regulatory/compliance relevance: Incorporating privacy by design can help mitigate risks related to real-time exploitation and market manipulation. It fosters a narrative of fairness and market integrity, which is beneficial for governance and regulators.
Who Benefits
- Users & apps: More predictable execution; less predatory manipulation.
- DEXs, aggregators & wallets: Cleaner price formation and lower support burden.
- Validators/sequencers: A tool for neutrality that focuses on specific behaviors like real-time censorship.
- Researchers & risk teams: Measurable pre-trade privacy with clear failure modes and telemetry.
Compatibility and Trade-Offs
Encrypted mempools do not aim to eliminate all kinds of MEV. Competitive back-running, such as arbitrage and liquidations, can still occur after decryption. The processes of encryption and key release introduce a limited amount of latency. Deployments are designed with conservative time windows, fallback options for non-sensitive transactions, and mechanisms for retries and inclusion services.
Encrypted mempools are built to utilize distributed Keyper sets, open-source implementations, and public monitoring, all guided by a documented operational playbook. The economic model is straightforward: users pay for encryption services and the usual resources on the blockchain. Communities can assess outcomes through telemetry and staged rollouts.
Lessons From Our Integrations and Proposals
Gnosis Chain — Client-First, Then RPC for Adoption
In July 2024, we launched an encrypted mempool on Gnosis Chain. Our early work added encrypted transaction handling inside the Nethermind client, so validators were able to process these transactions. For broader adoption, we introduced an encrypting RPC as an easy on-ramp, then progressed from testnet to a controlled mainnet launch.
Documentation and an explorer were shipped alongside the software, allowing validators, wallets, and users to monitor system health without compromising privacy. This slow, observable progression surfaced UX edge cases, such as behavior under load and retry semantics, before they became full-blown incidents.
Op Stack — Governance-First With a Small Demo
In March 2024, we launched the Shutterized OP Stack testnet on Sepholia, aiming to prevent front-running and provide a censorship-resistant trading environment.
To reach that milestone, we had shaped our proposals around the OP Stack community itself, aligning with its governance style, decision-making processes, and cultural expectations.
In a culture that prizes public goods and working groups, we framed requirements in local terminology, produced a focused demo, and documented costs/benefits so delegates could reason about trade-offs.
Centralized sequencers change incentives, so we paired encryption with explicit commitments to fair ordering. Grants were effective for research and prototyping; sustained engineering requires a continuation plan.
BNB Chain — Formal BEP Process
On BNB Chain, we developed our proposal through a formal improvement proposal process, known as a BEP. Engaging through a BEP broadened technical review across clients and validators and simplified coordination with wallets and RPCs. High throughput expectations made benchmarking and gated rollout criteria essential.
Ethereum L1 — a Measured Roadmap Through PBS
In February 2025, Shutter with a cohort of partners released the white paper The Road to a Distributed Encrypted Mempool on Ethereum, outlining a proposed roadmap for integrating an encrypted mempool on Ethereum.
The roadmap proposed was deliberately made incremental and measurable to adapt to the evolving infrastructure of Ethereum.
It starts with eth_sendEncryptedTransaction co-existing with standard submission (no hard fork required), then introduces commit-then-decrypt in the PBS pipeline via proposer commitments and builder constraints (e.g., mechanisms explored by Primev). If data supports it and the community agrees, in-protocol support can make encrypted payloads first-class. Engagement spans client teams, relays/builders, validators, and researchers, with telemetry and fallbacks as table stakes.
Non-EVM Grant — Scope and Fit
A declined research grant provided valuable lessons: align proposals with the local threat model, enlist local champions within client and validator communities, and appropriately adjust project scope. A small local demo can outperform a comprehensive written request.
A Practical Path to Proposing an Encrypted Mempool
1. Map decision-making and artifacts
Who makes decisions (foundation, token governance, working group, partnership)? What kind of artifact is expected (EIP-like specification, RFC, grant, partnership brief)?
2. Define the local threat model and success criteria
Focus on addressing harms and establishing measurable targets (e.g., reduction in sandwiching, inclusion latency limits, adoption rates among target apps).
3. Recruit champions
Technical aspects include client teams, validators/sequencers, and RPCs; product components encompass DEXs, wallets, bridges, and games; governance involves delegates, stewards, and researchers.
4. Choose your path on two axes
- Where to encrypt: wallet, dApp, or RPC proxy—pick the fastest route to credible testing in your ecosystem.
- How deep to integrate: start out-of-protocol; add PBS-aligned proposer commitments and builder constraints as needed; consider in-protocol only after evidence and buy-in.
5. Ship a minimal, testable reference
One wallet and one app flow, a faucet, and an explorer page. Publish dashboards for Keyper health, inclusion latency, and failure rates.
6. Pick a funding track
Grants and RFPs for research and early engineering; commercial partnerships for routing flow; operator alignment if validators or sequencers run additional infrastructure.
7. Submit, measure, and iterate
Anticipate several rounds of review. Consider the first deployment as a controlled experiment with clear checkpoints and a rollback plan.
Reach Out to Us Early
Proposing an encrypted mempool is not something to tackle alone. Reach out to the Shutter team early. Each ecosystem has its own governance, decision-making processes, and technical realities. We’ve seen this firsthand across Gnosis Chain, the OP Stack, BNB Chain, and Ethereum L1.
That experience, both when proposals succeeded and when they stalled, shows that the most reliable strategies are careful planning, early conversations, and phased rollouts that are transparent to stakeholders.
In practice, this usually looks like starting with a scoping conversation, co-authoring requirements and architecture, setting up a small demo, and then preparing a production rollout with monitoring and accountability.
So, reach out. And let’s encrypt the mempool.
FAQ (At a Glance)
Does an encrypted mempool kill benign MEV?
No, it focuses on preventing pre-trade exploitation. However, competitive back-running, including arbitrage and liquidations, can still occur after decryption.
What latency should we expect?
Encryption and key release introduce limited latency. Deployments establish conservative windows and offer alternatives for non-sensitive transactions, along with retry and inclusion services.
Who are the Keypers?
A decentralized Keyper set manages keys, with transparent composition and rotation. Selected by a Shutter DAO.
Does this centralize power?
Designs favor distribution and verifiability: multiple Keypers, open implementations, and public metrics reduce trust assumptions and make accountability visible.
What happens if decryption fails or is late?
Systems are designed to fail safely. Transactions can proceed via standard paths or be retried; rollout criteria include clear incident playbooks.
What will it cost?
Users pay for encryption services and standard chain resources; operators allocate budgets for Keyper and monitoring infrastructure. Communities assess value through measured outcomes.
