Aptos rolls out Encrypted Mempool to blunt frontrunning bots

Aptos has begun rolling out an Encrypted Mempool, an optional feature that hides transaction details until their order is finalized. The stated purpose is to stop bots from exploiting trades that are still pending, which is where most of the value leaks out of public mempools today. Both frontrunning and sandwich attacks depend on a bot reading a submitted transaction before it lands on chain, then trading against it.

What Aptos rolled out and how it works

The design rests on a simple observation about mempools. When a pending transaction sits in a readable queue, a searcher can copy it, resubmit with a higher gas bid, and trade against the price move that follows. The original user ends up paying more than quoted, often without learning why. The Aptos approach does not try to outbid the bots or reorder the queue. It removes the information advantage by keeping transaction details hidden until the order is finalized, so nothing useful sits in the open while the trade waits.

Opt-in is the detail that will decide how far this travels. No user is forced into the encrypted path.

In practice, coverage will depend on how many users route transactions through private submission and how much value that represents. If a meaningful share of swaps stays in an open queue, searchers keep a smaller pool to attack. If most large trades move out of view, the exposed pool shrinks and the economics of sandwiching get worse for the bots running them. Neither outcome arrives by itself, which is the reason to treat this as infrastructure work rather than a finished product.

Nothing in the rollout forces existing dapps to change how they submit transactions.

Why does an encrypted mempool matter for traders?

It closes the information gap that retail and mid-size traders have been losing money to for years. A sandwich attack runs in a fixed order: the attacker sees an incoming swap, buys ahead of it, lets the victim trade at a worse average price, and sells immediately after. The victim's loss is the attacker's gain. Hiding pending orders breaks that first step for anyone watching from outside, including searchers who have treated public mempools as a free, real-time data feed.

There is a second-order effect worth naming. When a queue stops broadcasting intent, the price discovery that normally happens between submission and inclusion becomes less visible to everyone, not only to bots. Market makers and routing tools that relied on watching the queue to quote tighter spreads lose that shortcut too. That is a reasonable trade for most users, but it means execution quality on an encrypted route may not match execution quality on a public one until dedicated tooling catches up.

Nobody claims this eliminates MEV. Encryption removes one channel, not the whole discipline.

Traders who keep routing in the open are still paying the tax the feature was built to avoid.

What led here: how frontrunning became an industry

Frontrunning predates Bitcoin. Order book traders have raced to the front of queues for as long as queues have existed, and the tactic moved to blockchains once transactions became public. Decentralized exchanges in the late 2010s scaled it up, because automated market makers let a searcher estimate the slippage a victim's trade would create before placing anything. Ethereum's shift to proof of stake added a second layer: proposer-builder separation formalized a market for ordering blocks, and searchers paid for the best position.

That market turned MEV into an industry rather than an annoyance. Research dashboards, searcher infrastructure, and auction mechanisms all grew out of it, and the revenue involved made it one of the most studied cost centers in crypto. Responses have included auction-based ordering and proposals to return some value to the user who created it. Each reshaped the economics without closing the gap, because the problem sits in the window between when a user signs and when the transaction lands.

Aptos launched its mainnet in 2022 on the Move language, out of the abandoned Diem project's lineage. It inherited the standard public-mempool default.

How does Aptos' approach compare with what other chains are doing?

The industry has tried three broad approaches. The first protects users at the wallet or RPC layer, where a private endpoint relays a transaction to a builder without exposing it to a public pool. The second changes who orders blocks, which is what Ethereum's proposer-builder model formalized and what rollup sequencers extend. The third is protocol-level encryption, where Aptos now sits. Each shifts where trust sits: RPC protection trusts the relay, sequencer changes trust the ordering party, protocol encryption trusts the decrypting nodes.

Protocol-level encryption is the more durable of the three because it does not depend on every user making the right choice at the wallet. A feature built into the chain is inherited by every integrator whether or not they understand the threat model. That is a meaningful difference from documentation and best-practice guidance, which tends to lose a large share of its audience at the first wallet update.

The limit is the same in all three cases: hiding a transaction before inclusion says nothing about the information that becomes public once it settles.

Cross-chain routing sits outside all three approaches entirely.

What could slow this down

Adoption is the obvious risk. Encryption only helps when both sides of a trade cooperate. A user routing through a private path against a counterparty whose transaction sits in an open queue buys less protection than the setup implies, and users rarely know which side of that split they are on. Wallets and dapps have to make the choice visible, and developers have to stop logging, simulating, or broadcasting transactions in ways that quietly undo it.

Key management is the second problem. Encrypted payloads need keys that ordinary nodes can eventually use and outsiders cannot use beforehand. Threshold schemes, hardware-backed custody, and trusted execution environments are all being explored across the industry for exactly this reason, and each one trades off decentralization, latency, and operational complexity. Any of them adds an attack surface that has to be reviewed before the feature counts as mature infrastructure.

Then there is coordination: features like this compete with the simpler playbook of running a private relay and accepting what you get.

What should traders and developers watch next?

Coverage numbers matter far more than announcement language. The useful metric is the share of transaction value routed through private or encrypted submission, measured chain-wide, not wallet by wallet. If that share climbs while slippage on large swaps improves, the feature is working. If it stalls in the low single digits, the effect on MEV revenue and user losses stays marginal however good the cryptography is. Builder behavior is the second signal worth tracking, since changing visibility forces routing tools and aggregators to adapt.

Watch whether major wallets make the option prominent and whether dapps enable it by default, since those two choices drive most of the volume. Also watch whether the feature stays optional or gets folded into default protocol behavior, because that would move the security model from a user decision into a chain-level guarantee. For anyone trading Aptos today, the practical takeaway is simpler than it looks: encrypted submission only pays off for you when the counterparty side is using it too.

Short version: track inclusion share, not headlines.