Why TON's Mempool-Less Design Kills Classic MEV

A sandwich attack needs three things: a public queue of pending transactions, a way to guarantee your two transactions land on either side of the victim's, and atomic execution within a single block. Ethereum gives you all three. Solana gives you a weaker version of all three (plus priority fees and Jito tips to fight over ordering). TON gives you none of them, and that's not an accident — it's a direct consequence of how the chain moves messages around.

If you've built MEV infrastructure on EVM chains or worked with Jito bundles on Solana, your instinct when you first look at TON is to go looking for the mempool. There isn't one, at least not in the form you're used to. Understanding why requires understanding what a "transaction" actually is on TON, because it isn't what you think it is.

TON doesn't have transactions, it has message chains

On Ethereum, a transaction is a single atomic unit: it enters the mempool, a builder picks it up, it executes top to bottom in one block, and it either succeeds or reverts as a whole. That atomicity is exactly what frontrunning depends on — you can see the pending state change and insert your own trades before and after it in the same block, guaranteed.

TON is built on the actor model. Every smart contract is its own isolated actor with its own persistent state and its own message inbox. Nothing calls another contract directly. Instead, a contract processes one incoming message, updates its own state, and optionally emits new outgoing messages to other contracts. Those outgoing messages don't execute now — they get queued, routed, and processed whenever the destination contract's shard gets around to them. Usually that's the next block. Sometimes it's several blocks later if the message crosses shard boundaries.

So a "swap" on a TON DEX like STON.fi or DeDust isn't one execution — it's a chain of asynchronous hops:

1. External message: user's wallet signs and submits
2. Internal message: wallet -> jetton wallet contract (transfer)
3. Internal message: jetton wallet -> DEX pool contract (notify)
4. Internal message: pool contract -> router (execute swap logic)
5. Internal message: pool -> user's jetton wallet (send output tokens)

Each arrow can be a separate block, and steps 2–5 can even land on different shardchains, because TON uses infinite sharding — accounts are deterministically distributed across shards by address, and shards split or merge dynamically based on load. There is no single block where the "swap" happens. There's a settlement pipeline that finalizes over roughly 4–5 blocks at TON's ~5 second block time, meaning a full swap can take 15–25 seconds to fully settle end to end, even though the user perceives the first confirmation almost immediately.

Why this kills classic sandwiching

Frontrunning requires seeing the victim's trade before it lands and inserting yourself ahead of it with certainty. On TON, external messages do get gossiped to validators before inclusion, so there's a brief window where a validator (or someone with a validator's view) can see an incoming message. But that visibility doesn't buy you what it buys you on Ethereum, for two structural reasons:

No guaranteed same-block co-location. Your "buy" and the victim's "swap" aren't necessarily eligible for the same block on the same shard. If the victim's swap touches the pool contract on shard A but your funds are routed through shard B first, you cannot force both legs into a deterministic order relative to theirs. You're racing a pipeline, not a queue.

The state change isn't visible until it's already committed. The actual price-moving step — the internal message hitting the pool contract — only becomes observable once it's included in a block. By the time you can react to it, it's already final on that shard. There's no pre-commit peek at pending pool state the way there is with an Ethereum mempool full of unconfirmed swaps sitting there for you to simulate against.

Put together: you can't reliably buy-before, and you can't cheaply guarantee sell-after either, because your own transaction faces the same multi-hop, multi-block settlement delay as the victim's. The tight two-sided bracket that makes a sandwich profitable just doesn't have a slot to occupy.

What still works (this isn't a free lunch for users)

TON kills classic sandwiching and mempool-sniping, but it doesn't kill MEV outright — it just narrows the surface to strategies that don't depend on pre-execution visibility:

• Cross-DEX arbitrage is alive and well. Once a swap settles on STON.fi, the price gap versus DeDust or another pool is public information anyone can act on in the next available block. This is closer to the "benign" arb work we do for clients running our Solana MEV/arb bot infrastructure than to toxic sandwich flow.
• Backrunning is still viable. If you're watching outgoing internal messages as they propagate, you can react to a large swap's effects one block after they land — you just can't get in front of it. This is a legitimate, much less predatory strategy compared to what's possible with visible mempools on EVM chains, where our EVM MEV bot work often has to account for adversarial searchers doing exactly the opposite.
• Validator-level reordering is theoretically possible for whoever is collating a given shard's block, since they see all pending external messages destined for that shard before finalizing it. This is a much narrower, permissioned version of the block-builder MEV that Jito auctions and Flashbots bundles formalized on other chains — worth understanding if you've read our breakdowns of how Jito's block engine auction works or compared Jito bundles against Flashbots bundles.

Building for it

If you're porting MEV or arbitrage logic from EVM or Solana to TON, the mental model has to change from "beat the mempool" to "beat the settlement pipeline." That means tracking message propagation across shards, understanding which shard an address will land on, and building latency-aware infrastructure that reacts to committed state rather than pending state — a very different data problem than polling pending transactions or subscribing to a gRPC mempool stream the way our Yellowstone gRPC vs Solana RPC latency comparison covers for Solana. Real edge on TON comes from shard-aware routing and low-latency validator connectivity, not mempool surveillance.

For a chain with no mempool to watch and settlement measured in message hops instead of blocks, custom data and infrastructure tooling built specifically for TON's shard topology is what separates a working arb bot from a bot that's perpetually one block too slow.

If you're evaluating whether an MEV or arbitrage strategy survives contact with TON's architecture, talk to us about building infra-data pipelines suited to how the chain actually settles state.