Most blockchain transactions are public and visible in the mempool before they are finalized and executed. This is useful for transparency and propagation, but it also gives searchers, block builders, and validators time to react. If a transaction reveals a profitable trade, liquidation, NFT mint, or bridge action, someone else may be able to copy it, front-run it, sandwich it, or censor it before it lands on chain, which is known as miner extractable value (MEV).
Encrypted mempools are one of the promising approaches to this problem. The idea is simple: users submit encrypted transactions, validators order them without seeing the plaintext, and the transaction is decrypted only after its order has been fixed, right before execution. In the ideal case, the transaction's intent becomes visible only when it is too late to reorder against it.
This is a powerful idea, but it also adds more security assumptions to the transaction pipeline. An encrypted mempool is not just a normal mempool with encryption added to the payload. It changes the transaction lifecycle because the protocol now has to decide exactly how and when an encrypted transaction is allowed to be decrypted.
In this post, we discuss the security considerations for encrypted mempools: what properties they need, how they interact with consensus and execution, and where things can go wrong if decryption happens at the wrong time or in the wrong context.
How Does Encrypted Mempool Works
In an encrypted mempool, the user encrypts the transaction locally and submits a ciphertext. Validators propagate, batch, and order it without reading it. Once the block is finalized and its ordering is irreversible, the encrypted transactions can be decrypted. Validators work together to decrypted the block, right before execution.
A common way to instantiate this is threshold encryption. The validator set jointly controls the decryption key. No single validator can decrypt a pending transaction alone. Only when enough validators contribute their shares can the full decryption key for a block be reconstructed. This usually requires a distributed key generation (DKG) protocol. The validators need to jointly create key material such that no single validator knows the full secret key and a threshold of validators can decrypt when the protocol allows it.
It is clear that the underlying cryptographic primitives must be sound. But that is not enough. They also need to be integrated securely into the rest of the blockchain pipeline. An encrypted mempool touches many parts of the system: mempool admission, consensus proposals, validator key shares, epoch changes, transaction authentication, and execution. Even if the encryption scheme itself is secure, the system can still leak transaction intent if these pieces do not preserve the intended timing of decryption.
So below, we will focus not only on the encryption scheme, but also on the integration details that decide whether the encrypted mempool actually provides the privacy it promises.
Security Goal
To protect users from MEV, an encrypted mempool should preserve one core rule: a transaction should not be decrypted until its order is finalized, and once it is decrypted, the protocol should be ready to execute it.
There are two parts to this. First, the transaction must remain hidden while it's not included in a block or its ordering can still change. Second, after the transaction becomes plaintext, it should not be silently dropped or exposed without a final outcome. If that happens, the user's intent becomes public without the execution result they expected.
There are a few things the system needs to get right.
The cryptography must be sound. The threshold encryption scheme, DKG, and key derivation process are the foundation. Validators should not be able to decrypt before the threshold is reached, key shares should be generated correctly, and the encryption scheme should be secure against ciphertext manipulation.
The ciphertext must be bound to its context. An encrypted transaction should only be valid for the sender, chain, epoch, authentication material, and transaction format it was created for. Otherwise, an adversary may be able to copy, replay, or reinterpret someone else's encrypted transaction. In a normal mempool, copying a transaction usually creates a trivial duplicate. In an encrypted mempool, it may become a way to reveal someone else's intent.
Decryption must happen at the right time. Even a secure encryption scheme does not help if decryption shares are released too early, old key material is accepted, or some code path allows validators to decrypt before finality. If a transaction has not been finalized, it should not be decrypted.
Decryption must not become a liveness bottleneck. Validators need to produce and aggregate decryption shares reliably. A malicious validator should not be able to block reconstruction, inject invalid shares, or keep the network stuck. Since decryption sits directly before execution, a failure in the decryption path can become a failure of the whole block pipeline.
Where Things Can Go Wrong
The rule for encrypted mempool is easy to say: keep the transaction encrypted until finality, then decrypt it for execution. The implementation is where things get subtle. An encrypted mempool crosses many parts of the system, so small integration mistakes can turn into privacy breaks.
The ciphertext must be hard to tamper with. The encryption scheme should be Chosen Ciphertext Attack(CCA) secure. Chosen Plaintext Attack (CPA) security is not enough here: if an attacker can take a valid ciphertext and craft a related ciphertext that decrypts to a modified plaintext, they may be able to front-run the user with a tampered transaction without ever learning the original plaintext. CCA security is meant to prevent this by rejecting ciphertexts that were not honestly generated.
But CCA security only protects the ciphertext itself. It does not stop someone from copying an intact ciphertext and submitting it in the wrong context. For example, an attacker may copy another user's encrypted transaction, wrap it in their own transaction, and sign it with their own key. Even if execution later rejects it, the copied ciphertext may still be decrypted, leaking the original user's intent.
So the ciphertext needs to be authenticated with the sender's context: sender identity, signing key or authentication material, chain ID, epoch, and any other public fields that define where the transaction is valid.
Decryption must be tied to finality. Validators should not release decryption shares just because they see a proposal. A proposal is not final. If transactions can be decrypted at the proposal stage, a malicious proposer can try multiple blocks and learn the contents of transactions without committing to any of them.
The trigger for releasing decryption shares should be the protocol's finality condition. Before that point, validators may be able to do harmless precomputation, but they should not release anything that makes plaintext recovery possible.
Decryption should imply execution. Once a transaction is decrypted, the user's intent is public. The protocol should not then silently discard it.
This can happen in normal-looking edge cases. Many blockchains have per-block resource limits, such as gas limits or state update limits. If a block runs out of capacity, transactions near the end may be skipped even though they were included. A malicious proposer can exploit this by filling the block with expensive transactions and placing a target encrypted transaction near the end. The target gets decrypted, but not executed. After that, the encrypted transaction may still be included in future block so that others can explit it like plaintext transaction.
Epoch boundaries can create a similar problem. Some protocols stop executing normal transactions after an epoch-change event, and an encrypted transaction placed after that event may be decrypted and then skipped. Again, the plaintext is revealed without the user getting the expected execution outcome.
A good encrypted mempool design should avoid this class of behavior. If a valid encrypted transaction is decrypted, it should either execute or fail in a final, explicit way.
Be careful with transactions that are invalid now but valid later. Some transactions fail only because of the current state. For example, suppose a user submits two transactions with nonces N and N + 1. The second transaction is invalid until the first one executes.
A proposer could include the N + 1 transaction first. It decrypts successfully, then fails the nonce check. Now the proposer knows its contents. Later, once transaction N lands, the N + 1 transaction may become valid, and the proposer can use the revealed plaintext to front-run it.
The lesson is that the network should perform a thorough check before decryption and reject a transaction early. This will reduce the case that an (currently) invalid transaction to be decrypted. Besides, if a decrypted transaction fails after decryption, it should generally become a final on-chain outcome rather than remaining available for retry. Otherwise, the system gives attackers a way to reveal transactions now and exploit them later.
Key reconstruction must tolerate bad validators. Decryption depends on collecting enough key shares from validators. Some validators may be offline, slow, or malicious. They may withhold shares or submit invalid ones.
Threshold secret sharing helps here: the system should not need every validator to participate. A sufficiently large subset should be enough to reconstruct the key. But the aggregation logic also needs to be robust. Invalid shares should be detected and excluded, and one bad share should not corrupt the reconstructed key or keep honest validators stuck in a retry loop.
Encrypted transactions should not introduce new DoS risks. Because the payload is encrypted, validators cannot fully simulate the transaction before decryption. This makes resource accounting harder than in a normal mempool.
The system should reject malformed ciphertexts as early as possible. It should check signatures, fees, transaction size, supported payload types, and ciphertext well-formedness before decryption. A bad encrypted transaction should not be able to crash the decryption pipeline or stall block execution.
Failed decryption should also not be free. If an attacker can submit undecryptable ciphertexts at no cost, encrypted transactions become an easy way to spam validators or probe edge cases in the decryption logic.
Encrypted mempools reduce MEV, but they do not eliminate it. They mainly protect against MEV that relies on seeing transaction contents before ordering, such as front-running and sandwiching. They do not prevent censorship, latency games, metadata leakage, or application-level leakage.
A proposer can still choose not to include encrypted transactions. Observers may still learn useful information from the sender, timing, gas parameters, transaction size, or public routing hints. And once the transaction is decrypted, validators and other observers will still see its contents.
So the goal is not full transaction privacy. The goal is narrower, but still very useful: keep transaction intent hidden until the order is fixed. Because of this, networks should clearly document what encrypted mempools do and do not protect. Users need to understand the capability and limitations of the feature so they do not treat it as full transaction privacy or use it in ways the protocol was not designed to protect.
Conclusion
Encrypted mempools are a promising direction for reducing transaction-ordering MEV, but their security is not just about choosing the right encryption scheme. The hard part is preserving the intended information flow across the whole transaction lifecycle.
A transaction should stay hidden while its order can still change. Once it becomes plaintext, the protocol should be ready to handle it as a final event: execute it, charge for failure, or reject it in a way that cannot be abused. This requires coordination across client encryption, mempool admission, consensus, key reconstruction, execution, and failure handling. This is what makes encrypted mempools such an interesting design space.
Looking forward, encrypted mempools are likely to become an important part of the MEV mitigation design space. As more teams experiment with these designs, careful security review will be essential. We have audited encrypted mempool implementations in production, including threshold encryption schemes, DKG integration, and the decryption-to-execution boundary, and are excited to continue securing this new class of protocols.