In the public blockchain environment of Web3, transparency has always been one of its defining characteristics. After a user submits a transaction, it typically enters the Mempool, where it waits for validators or block producers to order it and include it in a block. Before the transaction is actually executed, observers on the network can often see some or all of its information, including the contract being called, call parameters, assets involved, and transaction size. Public visibility enables verification, but it also exposes trading strategies to searchers, arbitrage bots, and other market participants.
This transparency is especially important in DeFi. A user may simply want to make a swap, adjust a position, or submit a complex on-chain operation. However, before the transaction is executed, other participants can already observe the user's intent and take action based on that information. As a result, front-running, sandwich attacks, and the broader issue of maximal extractable value (MEV) have long been important problems for on-chain trading infrastructure to address.
The concept behind an encrypted Mempool is to add a layer of cryptographic protection to transaction content after it enters the Mempool but before the block is finalized. The user encrypts the transaction Payload on the client side, and the transaction enters the Mempool in ciphertext form and remains hidden during transaction ordering. Only after the block reaches consensus do validators jointly decrypt and execute it. Aptos deployed a protocol-native encrypted Mempool to mainnet in October 2026 and designed it as a feature that can be enabled on a per-transaction basis.
More importantly, an encrypted Mempool is not simply about “hiding transactions.” It fundamentally redefines information visibility throughout the blockchain transaction lifecycle: who can see a transaction, when they can see it, who is responsible for ordering it, who is responsible for decryption, and how public verifiability can be maintained while reducing the leakage of transaction intent. For Web3, this makes the encrypted Mempool an important technological direction connecting transaction privacy, MEV protection, and blockchain infrastructure design.
Key Takeaways
- An encrypted Mempool encrypts transaction Payloads to keep transactions unreadable before execution
- Transactions can enter the Mempool and participate in ordering in ciphertext form, then be decrypted after the block is finalized
- Threshold encryption prevents a single validator from independently reading pending transactions, reducing the risk of transaction intent leakage
- An encrypted Mempool primarily provides “pre-execution privacy” and does not constitute a fully anonymous blockchain
- This mechanism may change how MEV protection, on-chain trading, and DeFi infrastructure are designed in Web3
What Is an Encrypted Mempool: From a Public Transaction Pool to an Encrypted Transaction Pool
To understand an encrypted Mempool, you first need to understand the role of the Mempool in a blockchain. After a user submits a transaction, it does not immediately become part of the final block. Instead, it first enters a pool of transactions waiting to be processed. Validators or block producers select and order pending transactions, then use consensus to include them in a block. The Mempool can therefore be understood as an important intermediary layer between “user submission” and “block confirmation.”
The core characteristic of a traditional public Mempool is the high visibility of transaction content. After a user signs and broadcasts a transaction, other network participants can observe the relevant information and analyze its intent before the transaction is officially executed. For example, a large swap may reveal which asset the user is preparing to buy or sell, while a complex DeFi operation may expose the strategy the user is executing. For automated searchers, this information can serve as a basis for taking action in advance.
An encrypted Mempool changes the visibility of information during this stage. When this mechanism is used, the user first encrypts the transaction Payload on the client side and then sends the encrypted transaction to the network. After the transaction enters the Mempool, block producers can still see the necessary account and fee information, but they cannot directly read the functions being called or the specific parameters. The transaction can be ordered while remaining encrypted, then enter the decryption and execution phase after the block is finalized. Aptos currently uses this transaction flow.
Therefore, an encrypted Mempool does not hide transactions permanently. Instead, it moves the point at which “transaction content becomes public” to a later stage. Transactions can still ultimately be recorded on-chain and publicly verified. However, before a transaction is finalized, observers no longer have access to its complete intent in advance. This design makes an encrypted Mempool closer to a mechanism for “pre-execution privacy” than to a traditional anonymous transaction system.
How an Encrypted Mempool Protects Transaction Content Through Threshold Encryption
The key to an encrypted Mempool is not simply using an ordinary encryption key. It must solve a more complex problem: If only one entity has the ability to decrypt transactions, that entity could itself become a new trust risk. The protocol therefore needs to distribute decryption capabilities among multiple validators while preventing any individual validator from reading transactions in advance.
Aptos currently uses a threshold encryption mechanism. The user obtains the encryption public key corresponding to the current Epoch, encrypts the transaction Payload, and submits it. After the transaction enters the Mempool, the block leader can participate in transaction ordering but cannot see which functions the transaction calls or which parameters it contains. Only after the block reaches consensus do validators jointly reconstruct the decryption capability and allow the transaction to enter the execution phase.
Here, “threshold” means that decryption capabilities are distributed among multiple validators. Under Aptos' design, a single validator cannot independently decrypt pending transactions, and a subset of validators controlling less than two-thirds of the honest stake on-chain cannot complete the decryption process. In other words, the stake-weighted majority required to trigger decryption is consistent with the consensus security assumptions that Aptos relies on to produce blocks.
The core value of this design is that it avoids introducing a centralized “gatekeeper” solely for transaction privacy. If a transaction must first be handed to a private relay, third-party builder, or external committee for decryption, the user is effectively transferring trust from the blockchain validators to another institution. Protocol-native threshold encryption instead seeks to establish transaction privacy directly on the blockchain's own validator and consensus system.
This is particularly important from the perspective of Web3's design philosophy. Privacy is not just about “no one being able to see anything.” It also involves asking, “To obtain privacy, do I have to trust a new centralized party?” One core area of exploration for encrypted Mempools is to keep privacy protection as consistent as possible with the existing consensus security model.
Why an Encrypted Mempool Can Reduce MEV and Front-Running Risks
One important source of MEV is the observable window that exists before a transaction is executed. When a user's transaction has been broadcast but has not yet entered the final block, searchers can analyze its content and attempt to profit by reordering transactions, inserting transactions, or adjusting the position of their own transactions.
For example, in a public transaction pool, a large swap may reveal a clear trading direction. After detecting the transaction, a bot may attempt to buy the relevant asset in advance, allow the user's transaction to move the price, and then complete a reverse transaction. This is the typical concept behind front-running and sandwich attacks. For users, the problem may not come from the smart contract itself, but from the information structure in which “transaction intent is made public in advance.”
An encrypted Mempool does not directly eliminate MEV. Instead, it reduces one source of information on which certain types of MEV depend. When the transaction Payload remains encrypted during the ordering stage, searchers cannot know in advance which function the user is calling, which assets are being traded, or which parameters are being used. This limits opportunities to position themselves in advance based on transaction content. Aptos also identifies reducing front-running, sandwich attacks, and transaction value leakage as important application areas for this mechanism.
However, it is important to avoid a common misconception: An encrypted Mempool does not mean that all MEV will disappear. MEV has many sources, including block ordering, liquidations, arbitrage, and other market-structure factors. If a form of MEV does not depend on the transaction Payload being publicly visible before execution, simply hiding the transaction content will not eliminate it. More precisely, an encrypted Mempool primarily reduces MEV based on observing and acting on the content of pending transactions in advance.
This also distinguishes it from traditional MEV protection mechanisms. Private RPCs, trusted transaction builders, TEEs, and external key committees can also reduce transaction-content leakage, but each corresponds to a different trust model. The focus of an encrypted Mempool is to place this protection directly at the protocol layer.
Why “Protocol-Native” Is a Key Design Principle for Encrypted Mempools
In blockchain privacy solutions, one frequently overlooked question is whether protecting transactions introduces new trust assumptions. Users may be willing to hide their transaction content, but if doing so requires handing the plaintext transaction to a new institution, the privacy protection itself may create a new attack surface.
Traditional private transaction routes typically send transactions to a specific RPC, builder, or relay service. This prevents other participants on the public network from seeing the transaction directly, but the service provider may still be able to view the plaintext transaction. For ordinary users, this is a practical solution, but privacy depends on the behavior and security of the third-party operator.
Another approach is to use a trusted execution environment (TEE) to keep transactions confidential within a specific hardware environment. A TEE can provide strong isolation, but its security also depends on the underlying hardware, firmware, and operating environment. An external threshold committee distributes decryption rights among an independent committee, which can reduce single-point risk but introduces trust requirements related to off-chain governance and committee operations.
Aptos' encrypted Mempool instead seeks to integrate threshold encryption directly into AptosBFT, allowing the validators responsible for transaction ordering to also participate in managing decryption capabilities. The purpose is not to claim that “trust is no longer required,” but to reuse, as much as possible, the blockchain consensus trust assumptions that users already need to accept. Aptos officially defines this as a protocol-native implementation and emphasizes that it uses the same trust assumptions as the chain itself.
From the perspective of Web3 infrastructure development, this design is significant. Privacy protection in decentralized systems should not be evaluated only by asking whether something can be encrypted. It is also necessary to ask whom users must trust after encryption is introduced. The value of a protocol-native design lies in its attempt to reduce additional trust layers and make privacy capabilities part of the underlying blockchain infrastructure.
At the theoretical level, encrypting transactions is not difficult. The real challenge is enabling encrypted transactions to operate at scale on a high-performance blockchain. Encryption prevents nodes from directly reading transaction content, but the transaction must ultimately be decrypted and executed correctly. If every transaction requires extensive communication among many nodes, the performance cost of encryption could offset the blockchain's throughput advantages.
Therefore, one key issue for a production-grade encrypted Mempool is how to keep threshold encryption scalable when a large number of transactions enter a block simultaneously. Aptos addresses this by using a batch threshold encryption scheme that enables an entire block to be decrypted in batches while keeping the communication volume required by each validator relatively stable. Aptos' published benchmark using 50 nodes showed that the scheme added approximately 20 milliseconds of block latency compared with AptosBFT in a production environment, while Aptos blocks could reach finality in less than one second.
At the same time, an encrypted Mempool does not attempt to hide all transaction information. In the current version of Aptos, information such as user addresses and Gas Fees remains visible, while the transaction Payload—that is, the functions being called and their parameters—remains encrypted before execution. After the block is finalized, the transaction content can be recorded on-chain, allowing the chain to retain public auditability.
This creates a design approach that differs from fully anonymous systems. Rather than making transactions permanently invisible, it controls the visibility of transaction information at different stages of the lifecycle. For DeFi systems that require public settlement and verifiability, this type of “staged privacy” may be more practical than completely hiding transactions.
From an infrastructure perspective, this is also what makes encrypted Mempools worth attention. They do not simply add a privacy switch. Instead, they redesign the complete transaction lifecycle, from submission and propagation to ordering, consensus, and execution.
How an Encrypted Mempool Connects Gate's Encrypted Trading and the Web3 Ecosystem
Although an encrypted Mempool is a form of underlying blockchain infrastructure, the core problem it addresses—the exposure of transaction intent before execution and the resulting front-running, sandwich attacks, and MEV—is closely related to trading infrastructure in the crypto industry. For users participating in DeFi, DEXs, on-chain perpetual contracts, and other on-chain financial applications, trading is not as simple as “submitting and completing a transaction.” Instead, it involves multiple stages, including broadcasting, entering the Mempool, ordering, consensus, and execution. Understanding encrypted Mempools is effectively a way to understand when information is visible to other participants as a crypto asset transaction moves from creation to final execution.
This also creates a direct conceptual connection with the crypto trading scenarios encountered by Gate users. Gate provides a range of crypto asset trading services, including spot and futures trading. The trading mechanisms, liquidity structures, and information visibility that users encounter differ across trading environments. On centralized trading platforms, orders are typically processed by the platform's matching engine, while on-chain markets such as DEXs rely directly on the blockchain's transaction propagation, ordering, and execution mechanisms. Understanding “why a transaction can be seen,” “who can influence transaction ordering,” and “why MEV occurs” can help users further understand the fundamental structural differences between centralized and on-chain trading.
For participants in the crypto industry within the Gate ecosystem, this understanding is not limited to DEXs. As on-chain perpetual contracts, DeFi, and other on-chain financial applications continue to develop, users increasingly need to understand the different risk structures of centralized and on-chain trading. For example, in a centralized trading environment, users primarily need to consider matching mechanisms, liquidity, platform risk, and order execution. In on-chain trading, they must also consider Gas, block space, transaction ordering, Mempool visibility, and MEV. An encrypted Mempool sits at the intersection of these issues, extending “transaction execution risk” beyond price and liquidity considerations into the blockchain infrastructure layer.
From this perspective, an encrypted Mempool is also an important entry point for understanding the next stage of crypto trading infrastructure. As a platform covering multiple crypto assets and trading scenarios, Gate serves users who are engaging with both centralized markets and an expanding on-chain ecosystem. The concept of “pre-execution privacy” represented by encrypted Mempools may become an important direction for the continued evolution of on-chain trading infrastructure: enabling users to achieve better execution while reducing the possibility that their strategies will be read in advance by other participants before they are actually executed. For crypto industry users, understanding encrypted Mempools is not only about understanding a blockchain technology. It is also about understanding how future trading markets may seek a balance among transparency, privacy, efficiency, and fairness.
Limitations and Future Development of Encrypted Mempools
An encrypted Mempool is not a universal privacy solution. First, it primarily addresses the leakage of transaction content before execution. Once a block is finalized and decryption is complete, the transaction content can still be publicly recorded and audited. Therefore, if users need to keep transaction amounts, account balances, or participant identities hidden over the long term, additional privacy technologies will still be required.
Second, encrypting the transaction Payload does not mean that all metadata is hidden. In Aptos' current implementation, information such as the sender address and Gas Fee remains visible. This means network observers can still obtain partial information about transaction activity, even though they cannot directly read the complete transaction intent before execution.
In addition, protocol-native threshold encryption still relies on the blockchain's validator set and consensus security assumptions. It reduces additional trust; it does not eliminate all trust. If the network's consensus security model itself is compromised, the transaction privacy mechanism may also be affected. Therefore, evaluating an encrypted Mempool requires an understanding of its cryptographic design, validator set, and consensus mechanism.
Future development may involve combining multiple layers of privacy capabilities. An encrypted Mempool can protect transaction intent, account-level privacy can further protect balances and amounts, and zero-knowledge proofs can prove transaction validity without revealing the underlying data. Different technologies address different layers of the problem, ultimately forming more complete on-chain privacy infrastructure.
From Public Transparency to Controlled Transparency: The Significance of Encrypted Mempools for Web3
Public transparency was once an important characteristic distinguishing blockchain systems from traditional financial systems. However, as the scale of on-chain finance has grown, this transparency has also exposed new problems. The fact that all transactions can be observed does not mean that every transaction should be fully disclosed before execution.
The direction represented by encrypted Mempools is to move blockchain from “all information is immediately public” toward “different information is disclosed at different times and in different ways.” Transactions can still ultimately be recorded and verified, while participants can preserve their strategic flexibility before execution is complete.
This is effectively an approach based on “controlled transparency.” It does not reject Web3's principle of public verification. Instead, it seeks a new balance between public settlement and transaction privacy. For DeFi, on-chain trading, and increasingly complex financial applications in the future, this balance may become more important.
Aptos' integration of an encrypted Mempool directly into its protocol and consensus system also shows that on-chain privacy is gradually moving from application-layer tools into underlying infrastructure design.
Across the Web3 industry, the value of encrypted Mempools lies not only in solving a single front-running transaction. It also encourages the market to reconsider a fundamental question: When should a blockchain disclose what information? When transaction privacy becomes an underlying protocol capability, transparency and privacy in Web3 may no longer be mutually exclusive choices. Instead, they can become different design layers within the same infrastructure.
FAQ
What Is an Encrypted Mempool?
An encrypted Mempool is a blockchain mechanism that encrypts transaction content after a transaction enters the Mempool. Transactions can be propagated and ordered in encrypted form, then decrypted and executed after the block is finalized, reducing the risk that transaction intent will be exposed before execution.
What Is the Difference Between an Encrypted Mempool and a Regular Mempool?
In a regular Mempool, network observers can typically read the detailed content of pending transactions. An encrypted Mempool hides the transaction Payload, keeping the transaction unreadable before final confirmation while still allowing it to participate in block ordering and consensus.
Can an Encrypted Mempool Completely Eliminate MEV?
No. An encrypted Mempool primarily targets MEV that depends on reading transaction content in advance, such as certain types of front-running and sandwich attacks. Other forms of MEV arising from mechanisms such as liquidations, arbitrage, and block ordering will not automatically disappear because the transaction Payload is encrypted.
Is an Encrypted Mempool the Same as Anonymous Trading?
No. An encrypted Mempool primarily protects transaction content before execution and does not constitute complete anonymity. In Aptos' current implementation, for example, the sender address and Gas Fee remain visible. After the transaction is finalized, it is also decrypted and recorded, preserving on-chain auditability.
Why Is Threshold Encryption Necessary?
Threshold encryption distributes decryption capabilities among multiple validators and prevents a single validator from independently reading pending transactions. This protects transaction content while allowing privacy security to follow the blockchain's existing consensus trust model as closely as possible.
Where Could Encrypted Mempools Be Used in the Future?
They are particularly suitable for Web3 scenarios involving trading competition and strategy-sensitive transactions, including decentralized trading, perpetual contracts, complex DeFi strategies, and other on-chain applications that need to reduce transaction intent leakage. Aptos has disclosed that Decibel will use this mechanism to protect the pre-execution privacy of perpetual contract orders.
