How Sandwich Bots Extracted Value from Every Stake on Bittensor
On Bittensor, for a certain period, every time a user staked/unstaked their tokens, a bot was ready to profit from it. It wasn't an exploit in the classic sense, no code vulnerability, no direct theft. It was MEV: Maximal Extractable Value. Value extracted from the ordering and visibility of transactions, without anything you could do about it.
This article explains how these attacks worked on Bittensor, why the Substrate architecture made them possible in a specific way, and how they were eliminated, first with protocol fixes, then with MEV Shield: every transaction travels encrypted until the moment of block proposal, where it is decrypted and included atomically, with no exploitable visibility window.
Bittensor and its mempool
Bittensor is a solo-chain built using the Substrate framework. Like all Substrate chains, user transactions pass through a public mempool before being selected and included in a block.
The mempool is public by design: anyone running a node can see pending transactions. This is normal and not inherently a problem, but it becomes one when someone can use that visibility to react before your transaction is executed.
Worth noting: on Bittensor, staking and unstaking are not simple transfers, they execute as swaps under the hood, which is precisely what makes them attractive targets for MEV.
One important thing to clarify upfront: Bittensor operates with a Proof of Authority (PoA) model, with known and selected validators and no open competition to produce blocks. This excludes by design the MEV extracted by the validator itself. The relevant MEV here is that of external actors, bots.
Why the mempool was exploitable
The attack exploited three elements that combined in a particularly effective way.
Transaction visibility. The mempool was open. A bot monitoring nodes could see every stake or unstake transaction before it was included in a block, with all the necessary information: wallet, subnet, direction, size.
The separate EVM channel. Substrate handles transactions through a system of dispatch classes and priority. Dispatch classes define categories of transactions with different behaviors in terms of inclusion and ordering. A bug allowed EVM transactions to operate on a separate priority channel, meaning they could be included ahead of native transactions regardless of when they arrived in the mempool. For a bot, this was equivalent to a deterministic front-running tool: send your EVM transaction, it will be included before the target.
The nonce-replace mechanism. In Substrate, as in Ethereum, every transaction is identified by a nonce. It was possible to replace a pending transaction with another at the same nonce by sending a new transaction with a higher dispatch class, even at minimal cost. Bots exploited this to make nearly free speculative bets: they pre-positioned on multiple assets simultaneously, and once they identified which subnet was actually involved, they kept that position. For all the others, where no user transaction had arrived, they sent a replace at minimal cost. The risk was almost zero: either you collected the sandwich, or you exited spending a tiny fraction of a fee.
Anatomy of the attack
Combined, these three elements produced a classic sandwich attack, but with specific characteristics.
The bot monitors the mempool
It detects a stake transaction on a subnet
It sends a buy transaction on the same asset (front-run) → uses the EVM channel to guarantee execution before the target
The user's transaction is executed → moves the price in the expected direction
The bot sells immediately after (back-run) → captures the price difference
Wrong bets on other assets are cancelled via nonce-replace.
In a Proof of Stake chain, the validator proposing the block could theoretically extract MEV from the decrypted content before executing it. On Bittensor, the PoA model and the accountability of known validators make this scenario substantially different from an anonymous competitive system.
How the protocol responded
The Bittensor team introduced a series of targeted fixes, each of which closed one of the three elements of the attack.
Removal of the separate EVM channel. The bug that allowed EVM transactions to operate on a distinct priority channel was removed. All EVM transactions now have lower priority.
Nonce-replace blocking. The node now blocks by default the replacement of transactions with the same nonce. Without this mechanism, speculative bets become costly: every transaction sent is a real commitment, not a cancellable bet.
Time-based ordering. For transactions with equal dispatch class and priority, ordering is now based on arrival time.
MEV Shield: decrypt-at-proposal
With the structural fixes in place, Bittensor introduced the MEV Shield pallet.
The principle is simple: the transaction travels through the mempool as opaque ciphertext, no bot and no external node can see its contents. Decryption happens exclusively at the moment of block proposal, and the transaction is included atomically in the same block. There is no time window between the moment the content becomes visible and the moment it is executed.
A key note on the PoA model: in a Proof of Stake chain, the validator proposing the block could theoretically extract MEV from the decrypted content, it would see the transaction before it was executed and could act accordingly.
On Bittensor this scenario does not apply: the PoA model implies known and accountable validators, with a substantially different risk profile and incentive structure compared to an anonymous validator in a competitive system.
How much MEV was extracted and how much remains
Measuring historically extracted MEV is difficult without a specific on-chain analysis. It is however possible to estimate maximum user exposure from on-chain data.
Based on on-chain data from the five Bittensor subnets with the highest market cap, an average $10,000 trade produces a price impact between 0.01% and 0.04%. With a slippage tolerance of 1%, which many UIs apply by default, the residual gap represents the user's maximum MEV exposure — i.e., how much an attacker could have extracted in the worst case.
Conservative estimate: ~0.9% per stake/unstake operation.
In practical terms: on $10,000 staked without protection, a user was exposed to a potential loss of up to $90 per operation. With MEV Shield active and structural fixes in place, this vector is eliminated.
What remains
The reactive and structural vectors are eliminated. MEV Shield removes visibility, the protocol fixes remove the abusable ordering mechanisms.
What remains is a surface that no encryption or ordering system can structurally close: publicly observable behavioral patterns. A wallet that always operates at the same time, a strategy whose direction is inferable from on-chain history.
Those who are unpredictable are substantially safe. Those who are not still offer a surface, small, uncertain, but present.
Conclusion
The runtime fixes and MEV Shield operate at distinct levels and complement each other.
Without both, one alone is not enough, a correct ordering system leaves the reactive vector open, and transaction encryption alone is not sufficient if the ordering mechanisms remain exploitable.
The result is an architecture where classic MEV, the kind based on visibility and ordering abuse, no longer has any operational space.
