Encrypted Mempool

What Is an Encrypted Mempool?

An encrypted mempool is a proposed modification to blockchain transaction processing where pending transactions are encrypted before entering the network's transaction pool. Block builders, validators, and other network participants cannot read the contents of these transactions until after their ordering within a block has been committed. Only then are the transactions decrypted and executed.

The concept addresses a fundamental tension in public blockchains: the mempool is transparent by design, allowing anyone to verify pending transactions before confirmation. But this transparency also enables extractive strategies. Searcher bots monitor the mempool for profitable opportunities, then manipulate transaction ordering to capture value at the expense of ordinary users. On Ethereum alone, cumulative MEV extraction has surpassed $1.8 billion, with sandwich attacks accounting for roughly 51% of all MEV volume.

An encrypted mempool breaks this dynamic by ensuring that transaction contents remain opaque during the critical window between broadcast and block inclusion. If block builders cannot see what a transaction does, they cannot profitably reorder, insert, or remove transactions to extract value.

How It Works

The core idea is straightforward: encrypt transactions before they enter the mempool, commit to their ordering while still encrypted, and only decrypt after the ordering is finalized. Several cryptographic techniques can achieve this, each with different trust models and performance characteristics.

Threshold Encryption

Threshold encryption is the most widely implemented approach. A committee of keyholders (sometimes called "Keypers") collectively manage a shared decryption key using threshold cryptography. The process works as follows:

1. A committee of keyholders generates a shared public encryption key using a distributed key generation ceremony. No single member holds the complete decryption key.
2. Users encrypt their transactions with the committee's public key before broadcasting them to the network
3. Encrypted transactions enter the mempool. Block builders can see that transactions exist and include them in blocks, but cannot read their contents.
4. After a block's transaction ordering is committed on-chain, a threshold of keyholders (for example, two-thirds of the committee) each provide a decryption share
5. The combined shares decrypt all transactions in the block, which are then executed in the committed order

This is the approach used by Shutter Network, which deployed the first live encrypted mempool implementation on Gnosis Chain in mid-2024. Shutter's Keyper committee manages the threshold keys and provides decryption shares after each block is committed.

Commit-Reveal Schemes

A simpler alternative uses a two-phase protocol based on commitment schemes:

1. Commit phase: the user submits a cryptographic hash of their transaction (the commitment) along with a deposit or fee. The hash reveals nothing about the transaction's contents.
2. Reveal phase: in a subsequent block, the user submits the actual transaction data. The network verifies it matches the earlier commitment and executes it.

Commit-reveal schemes are conceptually simple and require no trusted committee, but they add at least one block of latency because the reveal must come after the commit is confirmed. They also require the user to stay online for the reveal phase: if they fail to reveal, the commitment expires and any deposit may be forfeited.

Timelock Puzzles (Delay Encryption)

Timelock puzzles encrypt transactions such that decryption requires a fixed amount of sequential computation that cannot be parallelized. After a predetermined time period, anyone can decrypt the transaction by solving the puzzle.

# Simplified timelock puzzle concept
# Encryption: lock data behind T sequential squarings

# Setup
p, q = large_primes
n = p * q
T = target_time_steps  # calibrated to block time

# Encrypt
puzzle = encrypt(transaction, key)
# key is recoverable only after T sequential squarings mod n

# Decrypt (after T sequential operations)
for i in range(T):
    result = result^2 mod n
# result reveals the decryption key

The advantage of timelock puzzles is that they require no trusted committee: decryption is guaranteed by mathematical properties alone. The challenge is calibrating the delay correctly. If the puzzle is too easy, attackers with faster hardware can decrypt early. If it is too hard, legitimate decryption takes longer than the block time, adding latency. The drand network's Timelock.zone service explores this approach for practical use.

Trusted Execution Environments

A fourth approach uses hardware-based trusted execution environments (TEEs) to process encrypted transactions. Transactions are submitted to a TEE enclave (such as Intel SGX or AMD SEV) that processes them in encrypted memory. The enclave can order and execute transactions without exposing their contents to the host machine's operator.

Flashbots uses this approach in BuilderNet, a decentralized block building network that went live in November 2024. BuilderNet runs block construction inside TEEs, preventing builders from inspecting or manipulating individual transactions during the building process. As of early 2026, BuilderNet produces approximately 25% of Ethereum blocks. However, TEE-based approaches inherit hardware trust assumptions and are potentially vulnerable to side-channel attacks.

Current Implementations

Encrypted mempools are still an emerging technology. Most implementations are either in early production or research stages:

Shutter's deployment on Gnosis Chain represents the first live encrypted mempool using threshold encryption on a production blockchain. Transactions submitted through Shutter's interface are encrypted with the Keyper committee's public key, included in blocks in encrypted form, and decrypted only after the block is committed. This prevents any form of MEV extraction that depends on reading pending transaction contents.

Use Cases

Eliminating Front-Running and Sandwich Attacks

The primary use case is protecting DEX traders from MEV extraction. When transactions are encrypted, searcher bots cannot identify large swaps, calculate price impact, or construct sandwich attacks. The attacker cannot determine what asset is being traded, the direction of the trade, or its size: all the information required to build a profitable front-running transaction.

For context on the scale of this problem, see the research on fee market dynamics and how transaction ordering creates extractive opportunities.

Fair Ordering for DeFi Protocols

Beyond preventing explicit attacks, encrypted mempools enable fairer ordering for all DeFi interactions. Lending protocol liquidations, oracle updates, and governance votes can all benefit from ordering that is independent of transaction content. When block builders cannot see what a transaction does, they cannot prioritize or deprioritize it based on its profitability.

Sealed-Bid Auctions

On-chain auctions (for NFTs, domain names, or block space itself) are vulnerable to bid sniping when bids are visible in the mempool. Encrypted mempools enable true sealed-bid auctions where participants submit encrypted bids that are revealed simultaneously after the auction closes, preventing last-second outbidding based on observing competitors' submissions.

Private Transaction Submission

Users who want to execute large trades, rebalance portfolios, or interact with sensitive contracts benefit from not broadcasting their intent publicly. While services like Flashbots Protect already offer private submission by routing transactions directly to builders, an encrypted mempool provides this privacy at the protocol level rather than relying on trusted intermediaries.

Why Bitcoin Is Less Affected

Bitcoin's architecture makes encrypted mempools far less urgent than on Ethereum. Several structural differences limit MEV exposure on the base layer:

• Bitcoin's UTXO model means transaction outcomes are independent of ordering. Reordering two Bitcoin transfers does not change their execution results the way reordering two Ethereum AMM swaps does.
• Bitcoin Script is intentionally limited and not Turing-complete. There are no AMMs, lending protocols, or composable DeFi applications on the base layer that would create the state-dependent execution opportunities MEV searchers exploit.
• Miners order transactions by simple fee rate (satoshis per virtual byte). The block template algorithm is straightforward: include the highest-fee-rate transactions that fit in the block.
• The Lightning Network uses onion-routed private channels with no public mempool, making transaction observation structurally impossible.

Bitcoin does see limited MEV-like dynamics in specific scenarios: Ordinals and Runes minting events can trigger fee-rate wars, and on-chain swap protocols using HTLCs or PSBTs may expose swap details in the mempool. But these represent a tiny fraction of the MEV surface area compared to Ethereum's DeFi ecosystem.

Layer 2 solutions go even further. As a Bitcoin Layer 2, Spark processes transfers entirely off-chain without exposing them to any public ordering queue. There is no mempool to encrypt because there is no mempool at all: transactions settle directly between parties, eliminating the MEV attack surface by design.

Risks and Considerations

Latency Overhead

Every encrypted mempool scheme adds some delay. Threshold encryption requires keyholders to come online and provide decryption shares after each block commitment. Commit-reveal schemes add at least one full block of latency. Timelock puzzles add computation time. For networks where block times are already measured in seconds, any additional delay can degrade user experience and reduce throughput.

Validator and Keyholder Collusion

Threshold encryption depends on the assumption that fewer than the required threshold of keyholders will collude. If a sufficient number of keyholders cooperate, they can decrypt transactions before block commitment and extract MEV just as they would with a transparent mempool. The security guarantee is only as strong as the committee's decentralization.

Censorship Concerns

Validators may be reluctant to include transactions they cannot inspect. Encrypted transactions could contain spam, invalid state transitions, or even malicious payloads. Without the ability to validate transaction contents before inclusion, validators take on the risk of including transactions that waste block space or fail execution. This could lead to validators preferring transparent transactions over encrypted ones, undermining adoption.

Denial-of-Service Vectors

Because encrypted transactions cannot be fully validated before decryption, they create new DoS vectors. An attacker could flood the network with encrypted transactions that appear valid but decrypt to invalid or spam transactions. Traditional mempool defenses (like checking transaction validity before relay) cannot work on data they cannot read. Mitigations include requiring deposits or proof-of-work alongside encrypted submissions.

Liveness Requirements

Threshold encryption schemes require a sufficient number of keyholders to be online and responsive for decryption. If too many keyholders go offline, blocks cannot be decrypted and the chain stalls. This introduces a new liveness dependency beyond the existing validator set, adding a potential single point of failure.

Incomplete Protection

Encrypted mempools do not eliminate all forms of MEV. Cross-domain MEV (extracting value from transaction ordering across multiple chains), statistical analysis of encrypted transaction metadata (size, timing, destination contract), and time-based strategies remain viable even with encryption. They also do not protect against MEV from backrunning opportunities that arise from on-chain state changes visible after block execution.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.