Aptos has activated a protocol-native encrypted mempool on mainnet, giving users an optional way to hide transaction details until block ordering is finalized. According to an official announcement, the feature targets a longstanding problem in decentralized finance (DeFi): frontrunning and sandwich attacks carried out by MEV bots against visibly pending transactions. MEV, or maximal extractable value, refers to profit that can be captured by reordering, inserting, or censoring transactions within a block.

Encrypting Transactions Before They Enter the Mempool

When the feature is enabled, a transaction's payload is encrypted on the client side before it is sent to the network. Sensitive information such as the function call and its arguments is hidden, while the sender address and gas fee remain visible.

Validators can then confirm the ordering of transactions without viewing the payment message itself. Once consensus has agreed on the block, the validators collectively decrypt the transactions, execute them, and add them to the blockchain record.

No Single Validator Can Unlock a Pending Transaction

Aptos implements threshold encryption directly on top of its current set of validators. No single validator is able to decode a pending transaction, nor is any group whose combined stake falls below the required threshold. In threshold designs, decryption power is split across multiple parties, so who holds those keys — and whether they introduce new trust assumptions — becomes central to the design. Encryption-based schemes that add a dedicated decryption committee, a private block builder, or trusted hardware bring new parties into that equation, a concern the announcement addressed directly: "We do not create any additional decryption committee or any private block builder or trusted hardware provider in Aptos. Rather than that, AQUA token conversion is handled by the same validators that facilitate the Aptos consensus."

Encrypted Mempool Targets Frontrunning and Sandwich Bots

Public mempools display transaction data before execution, giving automated trading bots an opening to spot large transactions and copy them, or to execute trades immediately before and after another trader. With the payload kept secret and the final ordering confirmed only through consensus, Aptos removes much of the information these bots need to disrupt trades.

The protection may be particularly relevant for institutional orders, large DeFi trades, and automated agents, since early disclosure of transaction intent can translate into execution risk.

Petra is the first wallet to make the feature available as part of its signing process, letting users opt to encrypt a transaction at sign time. Separately, Decibel, a perpetual futures exchange built on Aptos, will use the encrypted mempool infrastructure to ensure that orders remain off-chain until they are executed. Together, the two integrations put the mainnet launch into production at both the consumer wallet and application layers, and they stand as the clearest near-term reference points for how the feature is used in practice.

Privacy With About 20ms of Extra Latency

Running threshold encryption at blockchain scale increases the computation required, but Aptos says the performance impact is minimal. Its batched encryption design allows an entire block to be decrypted with constant-size communication per validator, regardless of how many transactions the batch contains.

Testing with 50 nodes produced an additional 20 milliseconds of latency per block over the production version of AptosBFT. The project considers the delay insignificant given that Aptos blocks are finalized in less than a second.

Limits and Developer Support

The restrictions in the initial implementations mean the feature does not deliver complete transaction anonymity. Sender addresses and gas information remain visible — and because addresses are public on-chain, transactions can still be associated with specific accounts once they execute — while the transaction payload itself stays encrypted until block finalization.

Existing Move smart contracts do not require any changes, and support is available through the Aptos TypeScript SDK version 7.0.0 and later. That places broader availability in the hands of wallet and application integrations rather than contract upgrades, following the signing-time pattern Petra has shipped.

Source: Crypto Ninjas