MEV on TON: Does It Exist and How to Defend in 2026

MEV — Maximal Extractable Value — is the value extractable through reordering, inserting, or censoring transactions within a block. On Ethereum it is a multi-billion-dollar market: sandwich bots, arbitrageurs, liquidators, and MEV searchers compete via Flashbots and private mempools. On TON the picture is radically different — the asynchronous message model and sharded architecture break the assumptions underlying classical MEV.

But “different” doesn’t mean “absent”. This article unpacks which forms of value extraction actually work on TON, why classic sandwiches don’t, what a DEX user should do about slippage and routing, and where the ecosystem is heading on the defense side.

What MEV is: a quick primer

On EVM chains MEV exists because:

1. Every transaction lands in a public mempool before block inclusion.
2. The validator/block-builder sees them and may order them at will.
3. Transactions within a block execute atomically and synchronously — you can insert your own between others.

Three classical vectors follow:

• Sandwich attack — the bot sees a victim’s large swap, front-runs by buying the same asset, lets the victim trade at a worse price, then sells in the immediate next transaction.
• Front-running — the bot beats someone else’s transaction (liquidation, NFT mint, arb) and pockets the profit.
• JIT liquidity / back-running — the bot adds LP exactly around someone’s swap and pulls it immediately, harvesting fees.

All of this depends on a public mempool, clear ordering, and atomic execution.

Why TON is different

TON is built on different primitives:

• Asynchronous messages. Transactions on TON are chains of messages between contracts. A STON.fi swap spawns several internal messages executed in different blocks, often across shards.
• Sharded mempool. There is no single global mempool — there are queues at individual shard validators. A transaction sent to shard A isn’t visible to validators of shard B until inclusion.
• No atomic multi-call. On EVM a sandwich is one transaction doing three things. On TON “one transaction” doesn’t work that way — buy → victim swap → sell is spread across time and space.

As a result, building an atomic sandwich that guarantees front-run and back-run around someone else’s swap is extremely hard — and there is no guarantee of ordering.

What MEV-like extraction actually works on TON

Despite the architectural differences, value extraction does happen on TON. Things observed on mainnet:

1. DEX swap front-running. Bots monitor external messages routed to STON.fi / DeDust / TONCO. They see a large swap and submit a faster competing one (via direct validator submission, bypassing public RPC). On low-liquidity pools the execution difference is meaningful.
2. Jetton launch sniping. On fresh listings, bots race for first position in the queue — the classic “buy first, dump in 30 seconds” pattern. Especially pronounced for Telegram meme tokens.
3. NFT sniping. When a collection is listed on Getgems / Disintar at floor below market, bots scoop instantly. Not strictly MEV but the same latency-arb family.
4. Liquidation racing. On EVAA Protocol and DAOlama, liquidators race for profitable positions — first transaction wins the bonus. Healthy form of extraction from the protocol’s perspective.
5. Cross-DEX arbitrage. Prices between STON.fi and DeDust diverge; bots close the gap, banking the spread. This is “benign MEV” — it improves market efficiency.

Some of this is “toxic MEV” (harmful to users), some is “benign MEV” (helpful to the system).

MEV comparison: TON vs Ethereum

The key difference isn’t whether MEV exists but its scale and composition. On TON it’s mostly latency games around swaps and listings, not complex multi-leg sandwiches.

What users can do: practical defense

If you trade DEXs actively, several techniques materially reduce losses from front-running and slippage:

1. Tight slippage. For TON/USDT, TON/NOT, USDT/jUSDT, and other liquid pairs — 0.3–0.5%. For illiquid meme jettons you’ll need higher, but then chunk the order.
2. Limit orders. STON.fi and swap.coffee offer limit orders — you set the exact price and the swap fires only when reached. Front-running becomes pointless.
3. TWAP for large size. Trading equivalent of 50k+ USDT? Split into 10–20 pieces with 1–5 minute intervals. Bots cannot “learn” your flow quickly enough.
4. Aggregator routing. swap.coffee and peers aggregate liquidity across DEXs and split the order. This reduces price impact and complicates front-running.
5. OTC for very large amounts. Past $100k it pays to go OTC (via TON Foundation partners or a liquidity provider) — this bypasses the public book entirely.
6. Avoid first-minute trading on fresh listings. Snipers already took the floor; the average user buys the pump and exits the dump.

What protocols and the network can do

At the infrastructure level the TON community is discussing several directions:

• Batched execution on DEXs. Idea: collect swaps in a window (say 6 seconds) and execute them all at a single price derived from the pool’s entry/exit state. This fully kills sandwiches and front-running. Prototypes are being discussed, nothing in production on major DEXs yet.
• Commit-reveal schemes. User submits a hash first, then reveals the parameters. Bots cannot read content before reveal. Hard on UX but doable.
• Validator-MEV separation. Analog of Ethereum PBS, where “builder” assembles blocks separately from “proposer”. On TON this would require protocol-level changes — not a short-term outcome.
• Private mempools / direct-to-validator submission. Already used by large players (direct connections to the validator pool) but not as a public Flashbots-style service.

2025–2026 cases: what was actually observed

Notable episodes from the past year in TON DeFi:

• STON.fi launchpad sniping. Each major listing (especially Telegram-related memecoins) sees its first 30–60 seconds dominated by bots. A retail user entering in minute one regularly pays +30–50% over the opening price.
• NOT large-swap front-running. During NOT volatility (notably September 2025) sequences appeared where large client swaps received higher-than-expected price impact.
• EVAA liquidation race. During the February 2026 drawdown, TON-collateral liquidations cleared at 1–2 transactions per second, with roughly half the bonus pool flowing to 3–4 top bots.

Not catastrophic, but real money leaving regular users’ pockets.

What this means for users: checklist

A practical summary:

1. Don’t use slippage above 1% on liquid pairs.
2. For swaps above $5k — limit orders or aggregators.
3. For $50k+ — TWAP or OTC.
4. Skip first 3–5 minutes of new listings.
5. Active DeFi users can review their own transactions in an explorer and analyze price impact post-factum.
6. Remember: TON has no private mempool — RPC submission still gives bots seconds to react.

Deeper: why async specifically breaks the sandwich

To see the difference mechanically rather than as “different architecture,” let’s walk through how a sandwich is actually assembled on Ethereum and why on TON that assembly loses its reliability.

On Ethereum the sandwich bot does:

1. Watches the public mempool and identifies a “victim” swap V with expected price impact exceeding its costs.
2. Sends its front-run transaction F with higher gas price.
3. Immediately sends back-run B with gas price lower than F but higher than V.
4. The validator/builder orders them F → V → B within one block.
5. F moves the pool price; V executes at the moved price; B unwinds F and pockets the spread.

The attack works because (a) there’s a unified mempool, (b) ordering is deterministically priced via gas (or MEV auction), (c) execution inside a block is atomic.

On TON none of that holds. The mempool isn’t unified, ordering of messages inside a shard isn’t directly determined by gas price (there is a deterministic processing order, but “paying more” doesn’t reorder), and execution is spread across message chains. The bot may try to send F before V, but then V may enter a block before B — and the sandwich falls apart. Practically, TON-side bots typically do only front-run (one transaction before the victim) without reliable back-run. This reduces both bot profit and victim risk but doesn’t eliminate the attack.

Validator behavior: what they can and can’t do

On Ethereum validators (via builder-relay) explicitly earn from MEV — it’s a legitimate revenue line. On TON validators earn block fees and system rewards; there’s no direct MEV-bundle auction.

This doesn’t mean validators are angels — a large validator could theoretically order messages to their own benefit, but (a) shards limit the surface, (b) reputational risk is high, (c) no infrastructure exists to monetize this in production. So MEV extraction is currently dominated by external bots competing on speed of message delivery into shard mempools, not by validators.

In the longer run the ecosystem will need to explicitly decide whether validators may participate in MEV auctions, and if so how — otherwise we get an uncontrolled shadow emergence of that role.

Conclusion

MEV exists on TON, but qualitatively differently. The async-message architecture largely eliminates EVM-style sandwiches, yet front-running, sniping, and latency arbitrage remain — collectively eating a noticeable share of user value on DEXs and launches. Defense is almost entirely on the user side: tight slippage, limit orders, large-order splitting, aggregators.

Longer term, the ecosystem needs batched DEXs and/or validator-MEV separation. Until then, execution discipline is your best tool.

For more depth, see our reviews: STON.fi vs DeDust, swap.coffee as an aggregator, Storm Trade for perpetuals, plus TON on-chain activity metrics.