Code executes exactly as written, not as intended. The Ethereum community's latest push to encrypt the mempool is a case study in that axiom. EIP-8184, LUCID, EIP-8105, FOCIL—these are not solutions. They are cryptographic blueprints for a problem that has no known cryptographic primitive. The hype is building. The reality is a research paper with missing proofs.
I have spent the last decade dissecting protocol failures. From the 0x liquidity depth inflation in 2017 to the Terra Luna algorithmic collapse, I have learned one thing: when a proposal promises to eliminate a systemic risk without introducing a new trust anchor, the math usually fails. The encrypted mempool discussion is no exception.
Context: The MEV Arms Race and the Public Mempool
Maximal extractable value (MEV) is not a bug. It is a feature of the public mempool—the open broadcast of pending transactions. Every DeFi trader knows the pain: a frontrun bot snipes your limit order, a sandwich attack erodes your swap. The current fix is private relays—trusted intermediaries that pass transactions directly to block builders. But that is a bandage, not a cure. It centralizes the ordering pipeline and introduces a new class of gatekeepers.
Ethereum's core developers have been debating a protocol-level solution for years. The August 19 "Encrypt the Mempool" call brought together researchers from the Ethereum Foundation, client teams, and external cryptographers. The agenda: evaluate proposals for hiding transaction content until inclusion is guaranteed. The result: a set of draft EIPs that are still in the research phase. No testnet deployment. No formal verification. No independent cryptography review.
Three proposals dominate the conversation:
- LUCID (EIP-8184): A commit-reveal scheme where the block builder seals transactions without knowing their content. The decryption key is held by the sender or a third-party key publisher. The builder only learns the contents after the block is sealed.
- EIP-8105: A directed trust graph. Registered providers can identify other providers they trust. Trust, incentives, and penalties are left entirely off-chain. The protocol only enforces the graph structure.
- FOCIL (EIP-7805): A inclusion list pipeline where multiple validators signal which transactions a block builder must include. This is not an encryption scheme but a mechanism to constrain builder power. It is slated for the Hegotá upgrade (2027) as a consensus layer priority.
On paper, the combination seems elegant. In practice, the assumptions are brittle.
Core: Systematic Teardown of the Cryptographic Gaps
LUCID's Trust Paradox
LUCID is the most ambitious proposal. It attempts to hide transaction content from the builder until the block is sealed. The builder submits a sealed commitment—a cryptographic hash or encrypted blob—without knowing the underlying data. After the block is proposed, the sender reveals the decryption key, and the builder can execute the transactions.
But here is the catch: the decryption key is not managed by the protocol. It is held by the sender or a designated key publisher. If the sender goes offline, the key is lost. If the publisher is malicious, they can collude with the builder to reveal the key early. The proposal acknowledges this: "The LUCID design relies on the sender or key publisher to be honest during the reveal phase."
Utility is the vacuum where hype goes to die. LUCID moves the trust from the builder to the key publisher. That is not a reduction in trust. It is a relocation of trust. The protocol does not enforce key disclosure. It cannot punish a failed reveal because it cannot distinguish between malicious withholding and network failure. The result is a system that works only if all participants behave altruistically.
In my 2017 audit of 0x's liquidity depth, I found a similar pattern: the team claimed to solve a problem with a cryptographic trick, but the trick required a centralized oracle to correct the data. The trick worked only when the oracle was honest. LUCID works only when the key publisher is honest. That is not a solution. It is a redefinition of the attack surface.
The Cryptographic Wishlist
The EIP-8184 authors are transparent about the limitations. They state explicitly: "No known cryptographic construction exists that satisfies all requirements at Ethereum scale." The requirements are:
- Small public keys (efficient on-chain verification)
- Non-interactive decryption (no back-and-forth between sender and builder)
- No trusted setup (permissionless participation)
- Practical ciphertext size (within gas limits)
- Strong chosen-ciphertext security (resilience against adaptive adversaries)
- A credible path to quantum security (post-quantum safe)
The list reads like a cryptographic wishlist from a 2015 academic paper. The field of threshold encryption and identity-based encryption has made progress, but no single scheme meets all these constraints. The closest candidates—like lattice-based encryption—have large keys and high computational overhead. The EIP-8184 authors admit that the current draft is a "strawman" and that the actual construction may require relaxing some requirements.
Chaos reveals itself only when the noise stops. The noise here is the excitement around the vision. The silence is the absence of a working implementation. As of October 2026, there is no code. There is no testnet. There is no formal specification that has been peer-reviewed by independent cryptographers.
EIP-8105: Off-Chain Trust, On-Chain Irrelevance
EIP-8105 proposes a directed trust graph. Each provider registers a list of other providers they trust. The protocol then uses this graph to determine which providers can see transaction content. The idea is to reduce the centralization of private relays by allowing multiple trust paths.
But the proposal punts on the hard problems. Punishment for misbehavior is left off-chain. Reliability is left off-chain. The on-chain component is just a list of addresses. If a provider trusts a malicious actor, there is no mechanism to revoke that trust except through an off-chain social process. The protocol cannot prove that a provider misbehaved. It can only record that a transaction was front-run—but that could be due to a leak anywhere in the trust graph.
History repeats, but the code changes the syntax. The same pattern appeared in the 2020 Compound liquidity crisis I analyzed. The protocol assumed that liquidators would behave rationally under extreme volatility. They did not. The edge case I identified in the interest rate model—a cascading collapse triggered by a 15% drop—required a trusted third party to intervene. The protocol's design assumed away the failure mode. EIP-8105 assumes away the misbehavior of trusted providers.
FOCIL: The Missing Consensus Layer
FOCIL is the most concrete of the three proposals. It is already on the roadmap for the Hegotá upgrade in 2027. The idea is simple: a set of validators, chosen randomly, signal a list of transactions that the block builder must include. This prevents the builder from excluding certain transactions (censorship) or reordering them maliciously.
But FOCIL does not hide transaction content. It only ensures that transactions are included. The builder still sees the contents before the block is built. So FOCIL alone does not solve the frontrunning problem. It must be combined with an encryption scheme like LUCID. The timeline: FOCIL in 2027, LUCID later. The integration is not yet designed.
In my 2021 analysis of Bored Ape Yacht Club's royalty enforcement, I reverse-engineered the smart contract and found that the royalty standard was bypassable via a simple transaction wrapping. The project claimed to protect artists, but the code had no enforcement mechanism. The same is true here: FOCIL claims to prevent censorship, but without encryption, the builder can still frontrun the transactions it is forced to include. The combination is necessary, but the combination is not yet defined.
The 1/8 Gas Limit Trap
LUCID includes a specific performance constraint: the encrypted portion of the block is limited to one-eighth of the block gas limit. This is a deliberate design choice to keep the computational overhead manageable. But it also means that only a fraction of the block's transactions can be encrypted. The rest—the other seven-eighths—remain public.
What types of transactions will be encrypted? The proposal suggests high-value transfers and DeFi swaps. But the selection is left to the user. If only high-value transactions are encrypted, the bots will target the public ones. The MEV problem is not solved; it is shifted to the smaller transactions. The low-value users—the ones who cannot afford the gas for encrypted submission—will still be vulnerable.
Additionally, the 1/8 gas limit creates a capacity constraint. If the demand for encrypted transactions exceeds the supply, the market will price it out. Only the highest bidders will get encryption. The rest will be exposed. This is not a level playing field. It is a VIP lane for those who can pay.
The Quantum Cloud on the Horizon
The EIP-8184 authors explicitly require a credible path to quantum security. They note that Q-Day—the day when a quantum computer can break elliptic curve cryptography—might arrive as early as 2029. That is three years from now. The cryptographic primitives that LUCID might use (e.g., pairing-based encryption) are vulnerable to quantum attacks. The proposal suggests using lattice-based cryptography, but as mentioned, the key sizes are large and the computational overhead is high.
The quantum threat is not a distant future problem. It is a design constraint that must be addressed now. Any encryption scheme deployed today must be upgradeable to post-quantum security. LUCID's authors acknowledge this, but they have not provided a concrete upgrade path. The draft says "a credible path to quantum security" but does not specify what that path is.
Contrarian: What the Bulls Got Right
I have been critical. But the proposals are not without merit. The bulls are correct on three points.
First, the direction is correct. The current private relay system is a fragile trust model. A protocol-level encryption mechanism, even if imperfect, is a step toward reducing the power of a few intermediaries. The Ethereum community is right to explore this path.
Second, the cost of attack will increase. LUCID's reserve fee mechanism—where the sender posts a deposit that is returned only if the decryption is successful—creates an economic disincentive for failed reveals. A bot that attempts to frontrun an encrypted transaction must either crack the encryption (hard) or wait for the reveal and then try to build a competing block (expensive). The reserve fee raises the bar for profitable attacks. This is not a solution, but it is a deterrent.
Third, the inclusion of FOCIL in the Hegotá upgrade signals that the Ethereum core developers are serious about tackling MEV at the protocol level. The roadmap is long, but it is real. The funding and developer attention are there. This is not a vaporware project. It is a research initiative with institutional support.
However, the bulls are wrong to equate intention with readiness. The proposals are draft EIPs, not production code. The cryptographic gaps are not minor. The trust assumptions are not eliminated. The timeline is measured in years, not months.
Takeaway: The Accountability Call
The encrypted mempool is a necessary evolution for Ethereum. But it is not imminent. The current proposals—LUCID, EIP-8105, FOCIL—are research artifacts. They represent a direction, not a destination. The community must be honest about the gaps: no known cryptographic primitive meets all requirements, the trust model is simply relocated, and the quantum threat looms.
I will watch the next "Encrypt the Mempool" call. I will read the next revision of EIP-8184. But I will not adjust my due diligence checklist based on these proposals. The code does not exist yet. The assumptions are not validated. The only certain thing is the hype.
Code executes exactly as written, not as intended. The encrypted mempool, as currently written, intends to eliminate trust. But it executes as a relocation of trust. The question is not whether Ethereum will encrypt the mempool. The question is whether the community will accept the trade-offs before the cryptography is ready.
Based on my audit experience, I expect the answer to be no. Not because the idea is bad, but because the math is not there yet. And math does not care about timelines.