Ethereum researchers are advancing an encrypted mempool eip proposal that hardens the protocol against MEV-related exploits while keeping block generation efficient and permissionless.
Overview of the proposed encrypted memory pool
The new Ethereum Improvement Proposal (EIP): encrypted memory pool directly at the protocol level. Allow users to send encrypted transactions It will remain hidden until it is included in a block, reducing the problem. front running Perform sandwich attacks while improving censorship resistance. However, this upgrade is not intended for long-term privacy, as all transactions are eventually decrypted and published on-chain.
The design is clearly Encryption method independent. any support decryption key Providers that use threshold encryption, MPC board, TEE, delayed encryption, or FHE-based systems. Additionally, traditional plaintext transactions are still fully supported, ensuring that the chain continues to progress even if a particular key provider fails to supply keys.
This proposal builds on previous efforts, including: beacon chain with shutter An encrypted memory pool is then deployed outside the live protocol. gnosis chain. That said, EIP aims to address long-standing issues with MEV by moving this functionality within the protocol, mitigating harmful side effects such as builder centralization.
Motivation and role in Ethereum’s roadmap
The main purpose is to protect users from malicious transaction permutations such as front-running and sandwiching. The mechanism also aims to make the protocol more real-time, so-called “weak” censorship resistance, by temporarily blinding builders and other market participants. Furthermore, we aim to lower it. regulatory risk Protect block builders by limiting visibility of user intent during block construction.
EIP was not designed as a privacy upgrade in the classic sense. Instead, it works like this: MEV mitigation The fairness layer ensures that user transactions are not abused during the critical pre-inclusion period. A design that blends naturally Separation of proposer and builder (ePBS)this becomes a logical extension of Ethereum’s long-term roadmap.
Key provider registry contract and trust graph
In this proposal, the execution layer Key provider registry agreement. Any account can register as a key provider and receive a unique ID. Registration requires specifying a contract with both a decryption function and a key validation function, each of which accepts a key ID and a key message as a byte string. Additionally, key providers may designate other providers as directly trusted, forming a directed trust graph.
In this model, key provider A is considered to trust provider B only if there is a directed path from A to B in its graph. of beacon chain Reflects the state of the registry using a mechanism similar to how Beacon Chain deposits are currently handled. This ensures a consistent view of registered key providers at both the execution and consensus layers.
Registration is done explicitly technology neutralminimizing barriers to entry and allowing users to choose their preferred scheme. However, many advanced cryptographic systems are inefficient to represent in EVM and require specialized precompilation. Strategies and implementers should note that such precompilation is outside the scope of this EIP.
Trading format and order rules
EIP introduces new functionality. Types of encrypted transactions It consists of two components: an envelope and an encrypted payload. The envelope specifies the envelope nonce, gas amount, gas price parameters, key provider ID, key ID, and envelope signature. The encrypted payload contains its own payload nonce, value, calldata, and payload signature that collectively represent the actual transaction logic.
With valid blocks, the protocol enforces strict ordering rules. A transaction encrypted with a key from provider A can only be preceded by a plaintext transaction, an encrypted transaction with a key from provider A, or an encrypted transaction with a key from a provider trusted by A. This ordering prevents encrypted inclusions from trust graph This reflects your preferences indirectly via your chosen provider.
This structure effectively splits every block into two sections: a plaintext segment followed by an encrypted segment. Builders can fully simulate plaintext sections and apply existing block construction and MEV strategies. Additionally, cryptographic transactions can be added to the end of blocks without significant opportunity cost, thus remaining competitive in PBS auctions.
Envelope execution and decryption workflow
During execution payload processing, the encrypted transaction envelopes are executed in batches once all plaintext transactions have been processed. This updates the envelope signer’s nonce and charges the gas fee from the corresponding account. This fee is designed to cover the block space used by the envelope, decrypted payload, and decryption key, as well as the computations associated with decryption and key validation.
The protocol then attempts to decrypt each payload using the decryption function specified by the associated key provider. A successful decryption executes the resulting payload transaction, limited by both the envelope gas limit and the overall block gas limit. However, if decryption or execution fails, or if the decryption key proves to be missing, the protocol simply skips the transaction without undoing the envelope that has already been executed.
For simplicity, the signature is chosen to be included within the encrypted payload. A less private, but more efficient approach is to treat the envelope signer as the final sender of the payload. That said, the current design prioritizes flexibility and a clean separation between envelope metadata and the underlying transaction logic.
Key exposure processes and the role of PTC
For each slot, when a key provider sees the execution payload exposed by the builder, it collects all key IDs referenced in envelopes addressed to that provider. For each such key ID, the provider must publish one of the corresponding key IDs. decryption key or key hold notification. The decryption key message references the associated beacon block hash, preventing replay in future slots. Providers can publish immediately or delay the release until later in the same slot.
members of Payload Timeliness Committee (PTC) You need to listen for decryption keys for all of them. It then validates each key using a validation function defined in the registry, but with a small hard-coded gas limit for each key. Finally, PTC certifies the presence or absence of a valid decryption key for each encrypted transaction through an extended payload authentication message with a dedicated bitfield.
This mechanism introduces an additional layer of cryptographic responsibility for the key provider. Additionally, it creates in-protocol data that can be consumed by off-chain monitoring and custom slashing schemes, allowing the market to reward trusted providers and penalize poor performance.
User trust assumptions and security implications
Users must trust their chosen key provider not to release decryption keys prematurely. Releasing the decryption key too early can expose you to classic MEV tactics, and releasing it too late can result in transactions failing while still paying envelope fees. Providers can build this trust through cryptographic guarantees such as threshold encryption, hardware-based protection, economic penalties such as slashes, or governance-driven reputation.
To a lesser extent, users must also trust all key providers used for cryptographic transactions that appear before their own transactions in the block. After observing the keys of subsequent transactions, these providers can decide whether to publish or withhold the keys, giving them a small amount of influence over the pre-state of subsequent transactions. A maliciously designed “decryption” scheme could exploit this to manipulate certain parts of the decrypted state to perform more powerful front-running sandwich mitigation bypasses.
Importantly, users do not need to trust the key provider used for encrypted transactions that follow theirs, as later payloads do not affect the previous state of their transactions. Similarly, users sending cleartext transactions continue to rely on the builder’s honest behavior, but are not required to trust the key provider.
Reduce reorganization and decryption key front-running
Because the decryption key is exposed before the underlying encrypted transaction is completed, a chain reorganization can create a situation where a transaction is exposed, even if it ultimately contained no transaction. However, the decryption key message references the beacon block hash, allowing the verifier to invalidate the key if the underlying block is not part of the canonical chain. This prevents payload execution and limits front running opportunities.
Another risk involves an attacker exploiting the shared key identity. Once a user encrypts using a particular key ID, an attacker can observe the transaction in progress and create another encrypted transaction using the same key provider and key ID. If the second transaction were to arrive first, the naive provider could expose the key and inadvertently expose the original transaction. This is one form of Decryption key withholding attack pressure.
Key providers can alleviate such scenarios by “namespaced” key IDs. For example, you can release only the keys whose key IDs begin with the envelope signer’s address and withhold all other keys. Because the attacker typically does not have control over the victim’s signing account, a correctly namespaced key ID cannot be used to generate a valid transaction, preserving the original user’s confidentiality period.
Incentives, collusion risks, and future extensions
Current EIPs intentionally avoid defining rewards or penalties within the protocol for key providers. Instead, there is scope to develop diverse incentive models off-chain. Major providers may charge users a fee for each transaction, have bespoke contracts with builders, or operate as a public good, sometimes with the support of external funding. Additionally, providers can voluntarily adopt drastic rules against unwarranted key withholding to improve reliability.
Potential collusion vectors involve major providers and builders. To construct a new block, the builder must know the complete posterior state of the previous block, including which keys were published or withheld. This information is made public once the PTC certification is broadcast, but a malicious provider could privately notify favorable builders sooner and get a slight head start on building blocks.
The impact of such collusion is likely to be limited. The interval between PTC authentication and slot end is typically long enough for conflict block construction, leaving critical moments even near the end of the slot where the complete transaction set is known. Additionally, delaying a major rollout in favor of one builder risks missing out on PTC certification, negating any benefits. If few cryptographic transactions depend on colluding providers, an optimistic strategy that approximates the state without full decryption may also mitigate the edge.
Execution payload encryption and backward compatibility
The authors outline a possible future evolution in which builders use the same key provider to encrypt the entire execution payload. This allows builders to publish payloads immediately after construction, instead of waiting until around the 50% slot mark. Such changes, especially when combined with zero-knowledge proofs that prove which keys are used within a block, could improve peer-to-peer efficiency and reduce missed slots due to crashes.
In that scenario, attaching a zero-knowledge proof allows the decryption window to start sooner and last longer, giving the key provider more flexibility. However, this functionality will be explicitly left in future EIPs to avoid over-complicating the current design. The current proposal still introduces backward-incompatible changes to both the execution and consensus layers as it changes the rules for transaction types, block structure, and payload timeliness committee certification.
Overall, the crypto mempool eip proposal represents a substantial step towards protocol-level MEV mitigation and aligns closely with Ethereum’s long-term efforts toward robust proposer-builder separation of epbs and fairer transaction ordering.
summary
Encrypted memory pools are intended to incorporate encrypted transaction envelope execution, key provider coordination, and structured decryption into Ethereum’s core protocol. This increases user protection for MEV, increases censorship resistance, and opens the door to future upgrades such as full execution payload encryption, while preserving options for users and builders.
