The Erigon execution client team has joined the Encrypt the Mempool coalition, a new initiative focused on bringing transaction encryption to Ethereum’s public mempool. Shutter Network named Erigon as a launch member in a blog announcement describing the coalition’s push to draft and promote an Ethereum Improvement Proposal for encrypted transaction propagation.
Erigon later confirmed its participation through its verified X account, saying it is working with other infrastructure teams on a mempool-encryption standard for a future Ethereum upgrade. The goal is to reduce the visibility of pending transactions before they reach block builders and validators, a long-running concern in debates over maximal extractable value and transaction censorship.
We're proud to be joining the new Encrypt the Mempool Coalition!
Together with industry leaders, we are pushing to integrate an EIP to encrypt the Ethereum mempool in the I* hard fork, in order to stop toxic MEV and real-time censorship in a decentralised and credibly neutral… pic.twitter.com/2XQy9eOBX0
— erigon.eth (@ErigonEth) June 12, 2026
Coalition Targets MEV and Pending-Transaction Exposure
Ethereum’s current mempool works as a transparent queue for pending transactions. Before transactions are included in a block, their gas parameters and intended state changes can be read by validators, builders and searchers monitoring public order flow.
That visibility creates opportunities for front-running, reordering and selective exclusion, especially when automated systems identify profitable transaction sequences before block inclusion. The Encrypt the Mempool coalition is positioning encryption as a way to limit that informational advantage at the infrastructure level.
Erigon’s involvement gives the effort added weight because execution clients are central to Ethereum’s block-processing stack. Any protocol-level mempool change would require client-team alignment, implementation testing and core developer consensus before it could move from research into production.
The coalition has not yet published a specific EIP number, formal technical specification or confirmed activation timeline. The work remains in an early coordination phase, with future progress likely to depend on draft publication, Ethereum Magicians discussion and All Core Devs review.
Encryption Would Shift Information Control Before Block Inclusion
Structurally, encrypted mempools would change where transaction information becomes visible inside Ethereum’s block-building pipeline. If transaction payloads are hidden until commitment or inclusion, searchers and builders would have less ability to extract value from public pending-order data.
The same mechanism could also make some forms of automated censorship harder to execute. Validators cannot easily filter or exclude transactions based on contents they cannot yet decode, though the exact censorship-resistance benefits would depend on the final design.
The tradeoff is complexity. Mempool encryption proposals generally raise questions around coordination overhead, block simulation, latency and how encrypted data is decrypted safely at the right stage of block production. Precise performance costs will only become clear once a technical specification is formalized.
The effort also sits alongside other Ethereum privacy discussions, including EIP-8182, which has been pitched for the Hegotá process as a native private-transfer proposal. While EIP-8182 focuses on state-level privacy for ETH and ERC-20 transfers, mempool encryption targets pre-consensus order-flow protection.
Together, the initiatives point to a broader shift in Ethereum infrastructure thinking. Privacy is no longer being discussed only as an application-layer feature, but increasingly as a base-layer design question tied to user protection, market fairness and censorship resistance.
For now, Erigon’s entry into Encrypt the Mempool marks an important endorsement for a still-developing proposal. The next milestones will be a formal EIP draft, clearer technical requirements and evidence of broader client support before any fork integration can be considered.