Summary

Encrypted mempools hide transaction content from block builders and validators until after ordering is committed, eliminating MEV from order-dependent attacks (sandwiching, frontrunning). Three distinct approaches are in active development for Ethereum: LUCID (proposed for Hegotá, H2 2026), GhostPool (ZK-based), and encrypted frame transactions (order-execute separation). Each makes different tradeoffs on latency, implementation complexity, and the exact MEV it prevents.

Why Ethereum Needs This

From Julian Ma’s analysis (Mar 2026):

  1. Sandwiching attacks harm retail users and are near-impossible to detect until after execution.
  2. Institutional demand: financial institutions require pre-execution privacy as a precondition for on-chain participation. Unlike retail users, institutions have legal and fiduciary requirements around information asymmetry.
  3. Builder competition: private orderflow to select builders concentrates market power. An encrypted public mempool levels the playing field — builders compete on execution quality, not information access.
  4. Censorship resistance: a public encrypted mempool is harder to censor than private OFA channels.

LUCID (Proposed for Hegotá)

LUCID (Leveraging Uniform Confidential Inclusion for Decentralization) is the planned encrypted mempool for the Hegotá hard fork (H2 2026).

Core Design

  • Users encrypt their transactions with a threshold decryption key held by a committee.
  • Encrypted transactions are submitted to the public mempool and picked up by FOCIL inclusion lists — censorship resistance is inherited.
  • Transactions are decrypted in slot N+1: after block N is committed, the decryption keys for slot N’s transactions are released.
  • Builders in slot N see only ciphertexts; they cannot frontrun or sandwich.

Key Components

  • ABBs (Attestation-Based Blobs): encrypted transaction payloads distributed via blob sidecar mechanism.
  • Distributed payload propagation: payload is split and propagated through the validator committee, not through a central party.
  • Decryption trigger: slot N finalization (or partial finality) triggers key release for slot N transactions.

Same-Slot Decryption Extension (Apr 2026)

A later proposal extends LUCID to achieve decryption within the same slot rather than N+1:

  • Users make pre-ABB economic commitments — they stake collateral before transaction submission.
  • Decryption happens after ~3 seconds (the time for economic commitment to be accepted), allowing execution in the same slot.
  • Slashable collateral replaces the wait-for-N+1 guarantee: if a user submits inconsistent encrypted data, they are slashed.
  • Latency: ~3 seconds from submission to decryption.

FOCIL Integration

LUCID and FOCIL are designed to work together: encrypted transactions can appear on inclusion lists (builders see them but can’t read them), and FOCIL enforcement ensures they can’t be censored. The FOCIL + native AA proposal (Thomas Thiery, 2026-03-16) extends this to frame transactions.

GhostPool (ZK-Based Admission)

GhostPool (2026-03-09) solves a specific problem: standard encrypted mempools still leak metadata at admission time. To enter the public mempool, a transaction must reveal its sender (for nonce/balance checks), exposing identity to a watching adversary.

Design

  • Uses ZK proofs instead of plaintext sender/nonce checks at admission.
  • The prover demonstrates “I have a valid nonce and sufficient balance” without revealing which account.
  • A shared nullifier namespace prevents double-spending across encrypted transactions.
  • The sender’s identity is never revealed until decryption.

Limitations

  • Does not hide the existence of a transaction, only the sender.
  • ZK proof generation adds latency and cost.
  • Primarily prevents identity-based targeting; does not prevent statistical timing attacks.

Encrypted Frame Transactions

Encrypted frame transactions (2026-03-18) integrate encryption at the account abstraction layer via EIP-8141 (Frame Transactions):

Architecture

  • KEM-DEM split: Key Encapsulation Mechanism (KEM) wraps a symmetric key; Data Encryption Mechanism (DEM) encrypts the transaction body.
  • Order-execute separation: the encrypted transaction is ordered (assigned a position in the block) before decryption. The block includes a commitment to the ciphertext; actual execution happens after decryption.
  • Same-slot encrypted execution: the key is released within the same slot after block ordering is committed.

exec_params Format

exec_params = {
  encrypted_body: bytes,  // DEM-encrypted frame payload
  kem_ciphertext: bytes,  // Wrapped symmetric key
  decryption_condition: Condition  // When to release key
}

Free-Option Problem

A key challenge: if decryption keys can be withheld by the user, a user could observe the block’s state after ordering and choose not to reveal the key for transactions that would be unprofitable. This creates a free option at the expense of the block’s other users. Solutions: slashing conditions, pre-committed decryption, or time-lock encryption.

Encrypted DA and the MCP/PBS Divide

For Multi-Chain Protocols (MCP) that don’t use PBS, encrypted mempool approaches differ:

  1. Threshold encryption: ≥t committee members must cooperate to decrypt (most robust; slow).
  2. VE-PDA (Verifiable Encryption with Probabilistic Decryption Assignment): probabilistic assignments reduce coordination overhead.
  3. TEE-based decryption: single TEE holds decryption key; faster but requires hardware trust.
  4. Commit-reveal: user commits to transaction hash, then reveals; vulnerable to last-reveal attacks.
  5. Time-lock encryption: no trusted party; decryption requires computational work after a time period.

The analysis argues that in a world where sequencers (not PBS builders) control ordering, the threat model changes: encrypted mempools become strictly more important, but PBS (with its relay layer) becomes unnecessary.

Comparison

ApproachMEV preventedLatencyTrust assumption
LUCID (N+1)All pre-execution MEV+1 slotThreshold committee
LUCID (same-slot)All pre-execution MEV~3sEconomic commitment + slash
GhostPoolIdentity-based targetingZK proof timeNone (ZK)
Encrypted Frame TxsOrder-dependent MEVSame slotDecryption condition
Time-lockAll pre-execution MEVComputation timeNone

Open Questions

  • How does LUCID interact with ePBS? ePBS removes relays but the decryption timing relative to payload commitment needs specification.
  • Can the same-slot extension’s collateral mechanism prevent all free-option attacks?
  • How do encrypted mempools interact with FOCIL enforcement? (The FOCIL + native AA proposal addresses the FrameTx case but not arbitrary encrypted transactions.)
  • Does same-slot decryption give builders enough time to include profitable MEV after decryption, or does it mostly prevent front-running while allowing backruns?

Key Sources

  • Hegotá Headliner: LUCID (2026) — LUCID design and Hegotá inclusion
  • Why Ethereum Needs an Encrypted Mempool (Julian Ma, Mar 2026) — demand case
  • GhostPool (Mar 2026) — ZK-based identity hiding
  • Encrypted Frame Transactions (Mar 2026) — KEM-DEM split; free-option problem
  • We Need Encrypted DA (+ Mempools) (2026) — MCP context; 5 approaches taxonomy