Aptos users can hide the contents of pending orders to reduce exposure to front-running and sandwich attacks. Encryption is selected for each transaction and carries an additional gas cost.
Aptos has launched a mainnet mempool that keeps pending transaction contents encrypted until a block is finalized. In its October 12 announcement, the project said users can enable the protection for individual transactions. The feature aims to reduce the advantage of bots that inspect an order before it executes and place trades ahead of it.
Transactions are ordered before their contents are revealed
A mempool holds transactions submitted to a network that have not yet been included in a block. In a public pool, a bot can spot a large swap and buy ahead of it. A sandwich attack places trades immediately before and after a user’s order, potentially leaving the user with a worse execution price.
Under Aptos’s design, a wallet or application encrypts the transaction payload before submission. The validator proposing a block orders transactions without reading the call’s details. After the network reaches consensus on the block, validators jointly decrypt the contents and the transactions execute. No single validator holds the complete decryption key; protection relies on the network’s stake-weighted honest-validator assumption.
The feature is built into the protocol and does not require changes to existing Move smart contracts. Aptos reports roughly 20 milliseconds of additional latency in its own 50-node benchmark. That is the team’s result in a test environment, rather than a guarantee of the delay every application will experience.
Sender and fee information remains public
Encryption covers the pending stage. Sender addresses and gas information remain visible on the network. Contents are revealed after block finalization; completed transactions do not gain permanent anonymity.
zkSecurity’s technical review also identifies visible metadata such as sequence numbers, expiration times and ciphertext size. An optional field can disclose the target contract and function in advance.
How users opt in, and what it costs
Petra was announced as the first wallet to offer encryption in its signing flow. Developers can use version 7.0.0 or later of the TypeScript SDK. Aptos says Decibel will also use the feature.
According to the SDK documentation updated on October 13, encrypted transactions require a minimum gas unit price of 200 Octas, twice the network’s normal minimum. Decryption adds a flat charge of 375 gas units. The transaction’s own computation cost is added as well; total gas use and the chosen unit price determine the final fee.
The SDK does not currently support Keyless, federated Keyless or account-abstraction signers for encrypted transactions. Direct simulation of an encrypted payload is also unsupported. The documentation warns that simulating a plaintext version first could let observers link it to the encrypted transaction and discover the contents the sender intended to hide.
Aptos’s official encrypted mempool announcement
The post loads from X when you open it.
