Aptos Encrypted Mempool Is Live On Mainnet, Hides Payloads Only

The Aptos encrypted mempool is now live, and it lets users send transactions whose contents stay sealed until the block order is fixed. The network's developer documentation lists the encrypted mempool as live on devnet, testnet and mainnet. A public Aptos mainnet node now returns the encryption key that developers are told to look for. That check comes before they build one of these transactions. The feature is optional, so ordinary transactions keep working exactly as before.

What the Aptos encrypted mempool hides

Behind the feature sits Aptos improvement proposal 144, which Rex Fernando of Aptos Labs authored and which now reads as Accepted in the proposal text on GitHub. It describes a user encrypting the payload on their own device. The block leader then orders the transaction without being able to read it.

Validators only decrypt after consensus on the block is finished, just before execution. The key is rebuilt through a threshold vote weighted by stake. The proposal says that adds no new trust assumption beyond the ones the chain already runs on. Each epoch gets a fresh encryption key from a distributed key generation step.

Proposal 144 on GitHub, with its Accepted status and the Encrypted Mempool summary. Source: Aptos Foundation AIPs repository.

The scope of the Aptos encrypted mempool is narrow on purpose. The proposal says the first version hides payloads, meaning the function being called and the amounts involved. The sender address and other metadata stay visible, and hiding them is listed as out of scope.

Costs and limits in the documentation

Privacy here is not free. The documentation says encrypted transactions pay a minimum gas price of 200 Octas per gas unit, double the network's base minimum. Each one also carries a flat charge of 375 gas units for decryption, on top of whatever its own payload uses.

The cost note from Aptos' TypeScript SDK documentation. Source: Aptos developer docs.

Simulation is where developers can trip up. The SDK rejects encrypted payloads in its simulate calls. A workaround exists, which is to simulate a plaintext twin and then submit the encrypted version, but the documentation strongly discourages it. A simulation sent in the clear can be followed soon after by an encrypted transaction with the same payload. An observer could then link the two and infer what was hidden.

Throughput, latency and the failure case

The proposal expects the system to handle more than 1,000 transactions per second at launch. It also admits that the ceiling for encrypted transactions is lower than the chain's ceiling for plain ones. Because the feature is optional, the chain's overall maximum is unaffected.

On latency, the proposal estimates a net effect of under 10 milliseconds, and says blocks with no encrypted transactions skip the decryption work entirely. It is also frank about the downside. The system sits inside consensus, so a failure could in the worst case halt the chain. In that case validators can switch it off while a fix is prepared.

The practical reading of the Aptos encrypted mempool is modest. It is a privacy option, not a full shield. Traders who worry about sandwich bots reading a pending swap now have an opt-in way to hide its details, at a higher gas price. Anyone who needs the sender hidden as well will not get that from this release, and developers should plan around the extra fee.