One leading proposal is EIP-8184, known as LUCID. The draft would require block builders to commit to sealed transactions containing a chargeable ticket and encrypted payload without knowing what the transaction does. Only after the commitment is made would the sender, or an off-protocol key publisher, release the information needed to decrypt it.
While that design closes one avenue for exploitation, it also creates another problem Ethereum developers have yet to solve.
The decryption dilemma
A fully enshrined encryption scheme would need to satisfy a difficult set of constraints at Ethereum's scale.
EIP-8184's authors list small public keys, non-interactive decryption, no trusted setup, practical ciphertext sizes, strong chosen-ciphertext security and a credible route to quantum safety among the requirements.
They say no known cryptographic construction currently satisfies the entire set at Ethereum's scale.
LUCID therefore leaves the decryption construction outside the core protocol, allowing senders to manage their own key release or follow instructions from a key publisher. That preserves flexibility for stronger cryptography later, but EIP-8184's security considerations explicitly make publisher selection part of the user's security model.
The design also creates financial liabilities.
If a key is withheld or fails to arrive on schedule, LUCID's initial draft leaves the protocol-level penalty for a failed multi-key reveal with the transaction sender rather than automatically transferring it to the third-party key provider.
To put an economic cost on failed reveals, LUCID caps its encrypted top-of-block segment at one-eighth of the block gas limit and uses a reservation fee. Most of that amount can be returned after successful decryption, while the full reservation can be lost when the reveal fails.
That makes failed or selective releases expensive, but it cannot establish why a key failed to arrive or determine whether a publisher deliberately leaked it early.
The authors have described an off-protocol sponsorship arrangement where a publisher funds a transaction inside the bundle and absorbs the loss if it remains sealed. Ethereum itself would not enforce that pledge.
Trading intermediaries and network scaling
Wednesday's agenda will ask developers whether a temporary, non-post-quantum cryptographic solution is acceptable.
It also targets the deeper enforcement problem: how withholding or early key selling by members of a validator whitelist could be proved and whether those proofs could be automated.
A whitelist can establish who is authorized to publish keys. It cannot by itself distinguish deliberate misconduct from software failure, network latency, or a missed deadline.
An alternative proposal, EIP-8105, uses a directed trust graph where registered providers identify other providers they trust. Providers can establish their own withholding conditions, leaving incentives, reliability systems, and potential punishment mechanisms outside Ethereum's consensus rules.
Other approaches introduce their own costs. Threshold decryption distributes control among multiple participants but adds timing pressure. Trusted hardware can shorten the path to a key while introducing new hardware and operator dependencies.
Any production deployment would also need to coordinate with Ethereum's broader roadmap. LUCID is designed to extend the inclusion-list pipeline associated with FOCIL, or EIP-7805, which gives multiple validators a role in identifying transactions a builder must include.
Ethereum's security roadmap currently targets FOCIL as a consensus-layer priority for the Hegotá upgrade in 2027, while broader post-quantum infrastructure milestones sit further out.
