Aptos Activates Opt-In Encrypted Mempool; Payload Privacy Is Not Anonymity

BTCLiveETHLiveSOLLiveXRPLiveBNBLiveDOGELiveADALiveAVAXLive
CHARTING PARTNERTradingViewAdvanced charts, indicators and market tools.OPEN CHARTS →
Start with today’s trader mapBefore you leave: see the cross-asset levels, confirmations, invalidations and catalysts NetNapz is tracking for the next session.DAILY TRADER BRIEF →STRATEGY DESK →

Aptos Activates Opt-In Encrypted Mempool; Payload Privacy Is Not Anonymity

Aptos official encrypted mempool mainnet illustration showing protected transaction ordering
Official Aptos encrypted-mempool launch artwork. Source: Aptos Foundation announcement; copyright retained by Aptos Foundation, reproduced for source-matched editorial reporting. No endorsement implied.

Aptos has activated AIP-144’s opt-in encrypted mempool on mainnet, allowing transaction payloads to remain hidden while validators determine ordering. Sender addresses and fee data remain visible, completed transactions become public onchain, and the feature costs more than a standard submission.

13 October 2026 · Aptos · MEV protection · Source-checked report

Status: live on Aptos mainnet and available transaction by transaction. Petra is the first wallet named with native signing-flow support, while broader protection depends on wallet, SDK and application adoption. This is pre-execution payload confidentiality, not anonymous or permanently private settlement.

What changed on mainnet

Aptos Foundation announced on 12 October that the encrypted mempool described in accepted core proposal AIP-144 is live. A user who opts in encrypts the transaction payload on the client before submission. The block proposer can order that transaction without seeing the called function or its arguments; validators collectively reconstruct the plaintext only after consensus finalises the block, then execute it.

The decryption shares are held by the same validator set responsible for Aptos consensus. According to Aptos, no single validator—or group below the network’s two-thirds honest-stake threshold—can decrypt a pending payload. A new encryption key is generated for each epoch through a distributed-key-generation process.

The feature is intended to reduce the information advantage used for harmful maximal extractable value strategies such as front-running and sandwich attacks. Hiding the payload before ordering makes it harder for a block proposer or observing bot to see the exact trade and place a transaction around it.

What remains visible

Encrypted does not mean anonymous. The sender account and gas-fee fields remain visible when the transaction enters the network. After finalisation, validators decrypt the payload for execution and the completed transaction is recorded on the public ledger. AIP-144 explicitly places sender and other metadata privacy outside the scope of this first version.

The protection is also optional rather than universal. An application or wallet that submits a conventional plaintext transaction receives no benefit from the encrypted path. Petra exposes encryption in its signing flow, and Aptos says Decibel plans to use it for private order submission, but neither statement proves broad user adoption across Aptos trading venues.

Costs and integration limits

Aptos TypeScript SDK v7.0.0 and later can fetch the current epoch encryption key, encrypt the payload and submit it. Existing Move contracts do not need to change, but wallets and applications must support the encrypted transaction format.

The developer documentation sets a minimum gas-unit price of 200 Octas for encrypted transactions—twice the network base minimum—and charges a flat additional 375 gas units for decryption. Direct simulation of encrypted payloads is unsupported. Aptos warns that simulating a plaintext twin immediately before submitting the encrypted equivalent can let observers correlate the two and infer the hidden transaction.

Aptos reports roughly 20 milliseconds of added latency per block in a 50-node benchmark against its production AptosBFT implementation. That is a controlled benchmark, not a measurement of every production-mainnet workload. The practical result should be assessed with live throughput, failure-rate and latency data after adoption grows.

The security review deserves context

ZKSecurity conducted a four-week review covering the cryptography and consensus integration. The published report records several high- and medium-severity findings, with linked remediation pull requests for the principal issues. It also lists acknowledged privacy limitations and other lower-severity or known issues.

The existence of a public audit and fixes strengthens the evidence trail, but it is not proof that the production system cannot fail. Users and infrastructure operators should track the deployed code version, the status of acknowledged findings and any post-launch incident disclosures rather than relying on the word “audited” as a guarantee.

NetNapz assessment

Fact: Aptos now offers protocol-native, opt-in payload encryption before ordering and post-consensus decryption by its existing validator set. Assessment: that is a material infrastructure improvement for order privacy, but its economic value depends on adoption by wallets, exchanges and trading applications.

The constructive case is that Petra, Decibel and other applications make the encrypted route easy or default, producing measurable reductions in sandwiching and front-running without degrading throughput. The adverse case is fragmented support, higher fees or operational edge cases that leave most order flow visible and limit the feature to a narrow set of users.

The APT token link is indirect. Validators secure the threshold-decryption process through the same stake-weighted trust model used for consensus, but AIP-144 does not create a new APT issuance schedule or automatic fee-demand mechanism. A durable token thesis requires evidence of higher activity, validator participation and fee generation—not the activation headline alone.

Confirmation: broader wallet and venue support, rising encrypted-transaction share, stable production latency and evidence that harmful MEV falls. Invalidation or delay: low adoption, repeated failed decryptions, material latency or availability problems, or unresolved security findings affecting the deployed implementation.

What to watch

  • How many wallets and applications add native encrypted signing.
  • Whether Decibel’s planned integration reaches production and how much order flow uses it.
  • Production latency, encrypted-transaction failure rates and validator participation.
  • Any update to the ZKSecurity findings or remediation status.
  • Evidence that sandwiching and front-running decline rather than merely shifting to visible metadata.
  • Whether higher gas requirements discourage routine use.

Sources

Published 13 October 2026. Confirmed facts are drawn from the dated primary sources above. The NetNapz assessment is analysis, not investment advice.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top