Encrypted Mempool, Now on Aptos Mainnet
There are several ways to shield a transaction before it executes on a public blockchain. Until now, every one of them has meant trusting someone new: a private builder, a hardware enclave, or an external committee.
Encrypted mempool is now live on Aptos mainnet, the first protocol-native implementation that operates under the same trust assumption as the chain itself. This means no additional trust. The validators who order transactions are the same validators who hold the decryption shares. Encryption is opt-in per transaction, and transaction data is recorded on-chain once the block is finalized. The feature is specified in AIP-144
How it works
When you opt in to use encrypted mempool, your address and the fee you're paying stay visible. The contents of your transaction are not.
A user encrypts the transaction payload on the client side, using an encryption key that the validator set jointly generates each epoch. The transaction enters the mempool encrypted. The block leader proposes an ordering while blind to the transaction's payload, the function being called and its arguments. After consensus finalizes the block, validators collectively reconstruct the decrypted transactions, and the transactions execute.
No single validator can decrypt a pending transaction, and neither can any subset of validators below the chain's two-thirds honest-stake threshold. Decryption requires the same stake-weighted majority that produces every block on Aptos, the same trust assumption you already accept by using the chain.
Reaching production-scale efficiency required new cryptography: a batched threshold encryption scheme that decrypts an entire block with constant-size communication per validator, regardless of batch size. The scheme adds roughly 20ms of latency overhead per block in 50-node benchmarks against the production AptosBFT implementation. Aptos blocks finalize in under a second, so the additional overhead is a small fraction of the total. The full construction is described in a paper currently under submission to ACM CCS.
The implementation has undergone independent security review by ZKSecurity .
The trust spectrum
Every production approach to MEV (maximal extractable value) protection answers a single question: which party can read your transaction before it executes?
| Approach | Trust Required |
|---|---|
| Trusted builders and private RPCs (Flashbots Protect, Polygon Private Mempool) | The builder or RPC operator, who sees full transactions in plaintext |
| TEE-based private execution (NEAR Confidential Intents) | The hardware enclave and the permissioned validator set operating it |
| External threshold committees (Gnosis Chain / Shutter) | A keyper committee, separate from the chain's own validators |
| Protocol-native encryption (Aptos) | The chain's validator set, the same set already trusted for consensus |
Each of the first three approaches introduces a new party. Flashbots Protect and Polygon route to trusted builders who still see transactions in plaintext. NEAR routes through a TEE-secured shard whose confidentiality depends on enclave integrity. Recent academic work has demonstrated practical extraction attacks against current-generation TEEs at hardware cost under $1,000 ( WireTap and TEE.fail , both ACM CCS 2025). Gnosis Chain integrates Shutter via an external keyper committee, separate from the chain's validator set and operating as a bolt-on rather than in-protocol.
In Aptos, batched threshold encryption is integrated directly into AptosBFT. Every other approach requires you to trust someone new. The Aptos approach requires you to trust only who you were already trusting.
Using it
When you send a transaction on any major chain today, anyone watching the network can see the details before it executes, the function you're calling, the assets and amounts involved, and the contracts you're interacting with. Bots use that visibility to trade against you or copy your strategy. Encrypted mempool changes this: your transaction is encrypted on your device before it's sent, ordered while still encrypted, and decrypted only after the block is final.
Encryption is opt-in per transaction. Petra is the first wallet to surface encryption directly in the signing flow, letting users encrypt any pending transaction with a single option at signature. Decibel , a perpetual futures exchange built on Aptos, will use encrypted mempool to keep orders private until they execute.
The Aptos TypeScript SDK (v7.0.0 and later) fetches the current epoch encryption key, encrypts the payload on the client side, and submits it encrypted. Existing Move smart contracts require no changes.
The first version of the system encrypts the transaction payload (the function being called and its arguments). The sender account and gas-fee fields remain visible at submission, and the chain remains auditable. See the Aptos developer documentation for SDK integration.
Related Articles.
View allSign up to receive industry news, helpful resources, exclusive access to upcoming events and more.
- 1. Aptos Foundation is committed to protecting and respecting your privacy, and we'll only use your personal information to administer your account and to provide the products and services you requested from us. From time to time, we would like to contact you about our products and services, as well as other content that may be of interest to you. If you consent to us contacting you for this purpose, please tick the box to say how you would like us to contact you.
- 2. You can unsubscribe from these communications at any time. For more information on how to unsubscribe, our privacy practices, and how we are committed to protecting and respecting your privacy, please review our Privacy Policy.
- 3. By clicking the submit button, you consent to allow Aptos Foundation to store and process the personal information submitted above to provide you the content requested.
- 4. This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.