NewsCryptoAptos Activates Encrypted Mempool on Mainnet, Hiding Trades Until Block Ordering Is Locked

Aptos Activates Encrypted Mempool on Mainnet, Hiding Trades Until Block Ordering Is Locked

Author: Coindoo·

Key Takeaways

  • •Aptos's encrypted mempool went live on mainnet per its October 12 announcement, hiding pending transaction payloads until their block position is finalized.
  • •The AIP-144 proposal defines three stages: clients encrypt payloads at submission, validators order the block while instructions remain unreadable, and decryption plus execution follow consensus.
  • •Validators jointly generate encryption keys each epoch, decryption requires enough stake-weighted shares instead of a separate committee, and the design includes a one-time trusted setup ceremony.
  • •The Petra wallet lets users encrypt individual transactions, developers can submit encrypted payloads via the Aptos TypeScript SDK from version 7.0.0 with no changes needed to existing Move contracts, and Decibel plans to adopt the feature.
  • •Aptos reports roughly 20 milliseconds of additional latency per block in 50-node benchmarks, and ZKSecurity's independent review covered the encryption scheme and key management but excluded gasing and does not guarantee protection from all trading risks.
Aptos Activates Encrypted Mempool on Mainnet, Hiding Trades Until Block Ordering Is Locked

Aptos announced in its October 12 announcement that encrypted mempool is live on mainnet, allowing users to conceal the contents of pending transactions until their position in a block has been finalized.

A mempool holds pending transactions before they are included in a block. When their contents are visible, outside observers can inspect instructions before execution. Consider a hypothetical swap large enough to move a token's price: a bot that sees the pending order could buy first, let the user's swap push the price higher, then sell afterward. This sequence, known as a sandwich attack, can leave the sender with worse execution, and it depends on seeing the instruction while there is still time to trade around it. Extraction of value from visible pending orders—a family of strategies commonly discussed under the umbrella of MEV (maximal extractable value)—is a longstanding concern on public blockchains with transparent mempools, and designs ranging from private submission channels to threshold encryption have been explored across the industry as mitigations. Aptos's approach targets the exposure at the ordering stage itself.

Encryption removes that view of the transaction's payload—the function being called and its arguments—during ordering. It does not promise a particular execution price: an encrypted swap can still face ordinary market movement, limited liquidity, or restrictive slippage settings.

Ordering Comes Before the Instructions Are Revealed

The AIP-144 protocol proposal describes three stages:

  • Submission: The client encrypts the payload before sending the transaction.
  • Ordering: Validators agree on the block while its encrypted instructions remain unreadable.
  • Decryption and execution: Validators reveal the payloads after consensus, then execute the transactions.

Finality in this context means agreement on the block and its transaction order. By separating that agreement from execution, Aptos allows instructions to remain concealed until their position is fixed. The sender account and gas-fee fields remain visible at submission, and completed activity is recorded publicly afterward. As with other approaches to blockchain privacy, concealing selected details does not make an account anonymous.

The Validators Also Handle Decryption

Validators jointly generate encryption keys for each epoch, a period during which the validator set is fixed. Decryption requires enough stake-weighted shares—pieces of the decryption capability—rather than access by a single validator. Aptos therefore relies on its consensus validators instead of appointing a separate decryption committee.

The proposal also specifies a one-time trusted setup ceremony, meaning the security picture must account for the cryptographic setup as well as validator behaviour, rather than treating the absence of an external committee as the entire trust model.

An independent review by ZKSecurity examined the encryption scheme, key-management components, and integration with transaction processing. Gas metering was outside its scope. The review provides implementation evidence, but it should not be presented as a guarantee against every failure or trading risk.

How Users Enable It—and What the Benchmark Shows

According to Aptos, the Petra wallet exposes encryption in its signing flow, letting users choose it for individual transactions. Decibel, the Aptos perpetual-futures exchange, plans to use the feature; the announcement does not establish that its integration is already operating. That leaves several near-term questions open, including when Decibel's integration goes live, how the reported overhead behaves under production load, and whether wallets beyond Petra make encryption a routine choice.

Developers can submit encrypted payloads through the Aptos TypeScript SDK, with support from version 7.0.0. Existing Move contracts require no changes.

Aptos reports roughly 20 milliseconds of additional latency per block in 50-node benchmarks. That figure measures processing overhead, not savings for traders or production performance during congestion. Encryption conceals instructions during ordering; whether a trade receives a better price still depends on market and the application executing it.

This article is provided for informational purposes only and does not constitute financial or investment advice. Blockchain privacy tools can reduce selected forms of information exposure without guaranteeing anonymity or protection from all trading risks.