Back-Running
Back-running is observing a pending transaction and submitting your own transaction so that it executes immediately after it, to profit from the state change the first transaction causes. In Bittensor it appears around a subnet’s automated market maker pool: a swap that is waiting to execute is visible before it lands, and another trader can line up a swap to run right behind it and capture the price move the pending swap leaves in the pool.
References: Sandwich Attack, Mempool
Why It Is Possible
A transaction does not execute the instant it is submitted. It first sits in the mempool, the temporary holding area where pending and unconfirmed transactions wait before being included in a block, and there its contents can be observed. Because a subnet prices alpha through a pool whose price moves with every swap, a large pending swap signals that the pool is about to be pushed away from its prior price, and the moment after it lands is when that dislocation is largest. A back-runner races to be the next transaction so it can act on that fresh price before anyone else.
References: Mempool, Understanding Subnets
How It Differs From Front-Running
Front-running and back-running both depend on seeing a pending swap, but they sit on opposite sides of it. Front-running orders ahead of the target to profit from the move it is about to cause; back-running orders behind the target to profit from the move it has just caused. Front-running worsens the price the target receives, while back-running acts only on the state the target already left behind.
References: Front-Running, Mempool
The Sandwich Connection
The sandwich attack places transactions before and after a target to profit from the price movement it causes, wrapping the victim’s trade between the attacker’s two trades. Back-running is the back half of that pattern: the closing trade that sells into, or buys back from, the price the victim’s order moved. On its own, a back-run is often plain arbitrage that pushes a dislocated pool back toward a fair price; combined with a front-run, it becomes the exploitative half of a sandwich.
References: Sandwich Attack, Slippage
What Defends Against It
The same two mechanisms that blunt front-running also limit the harmful form of back-running. Price protection lets a trader set a tolerance on the price they will accept, so a swap that would execute worse than that limit fails or only partially fills rather than completing at a manipulated price, which caps how much a surrounding pair of trades can extract. The MEV shield attacks the information itself: transaction data is encrypted with a public key from the blockchain validator and decrypted only just before the transaction is finalized, so a pending swap’s details stay hidden until it is already on-chain and there is little for a back-runner to read and react to.
References: Price Protection, MEV Shield
Development Stage Context
The Introduction to Bittensor describes subnet development as moving from localnet to testnet and then mainnet. For back-running, that sequence changes how readers should interpret mempool visibility, pool-price moves, and MEV shield examples.
In localnet, back-running mechanics can be tested in an isolated environment. Localnet mempool and pool behavior do not represent production transaction ordering.
On testnet, back-running and price-protection flows can be exercised in a shared non-production network. Testnet pending-transaction visibility is separate from mainnet subnet state.
On mainnet, back-running concerns live production subnet pools and the protections traders use on the public network. Observed ordering and slippage depend on live pool depth and the protections in force (MEV Shield).
The Bittensor Networks reference separates mainnet, testnet, and localnet. A back-running example from one environment should not be read as representing production transaction behavior in another environment.
Relationship to Yuma Consensus
Back-Running and Yuma Consensus describe related parts of Bittensor’s incentive system. Yuma Consensus is the on-chain process that aggregates validator weight signals within a subnet into miner incentives and validator dividends, applying consensus clipping, bonding, and emission calculation (Yuma Consensus).
For readers, back-running names a specific part of that incentive picture, while Yuma Consensus names the consensus process that turns validator weights into the resulting incentives and dividends.
Reader Boundary
This page defines the concept at a high level and is not trading advice or a claim that any specific trade was back-run. Back-running can be harmless arbitrage that improves pool pricing or the closing slice of an extractive sandwich, and which one applies depends on live pool depth, pending order flow, and the protections in force, all of which change continuously.
References: Sandwich Attack, Mempool
Staking and Unstaking Also Move Pool Reserves
Understanding Slippage describes staking and unstaking as conversions that pass through subnet pool reserves, not only standalone swaps. When such a conversion executes, the TAO-to-alpha ratio in the pool changes the same way it does after a swap.
The Glossary: Back-Running defines back-running as ordering immediately after a target transaction to act on the state change that transaction caused. Pool-moving conversions therefore fit the same ordering vocabulary as swap-based examples on this page (Understanding Slippage).
References: Understanding Slippage, Glossary: Back-Running
Slippage Names the Gap After a Pool Move
Slippage is the difference between expected and received amounts when a trade moves through subnet pool reserves. After a large conversion lands, the next trader can face a different ratio than the one visible before execution.
That post-move gap is the dislocation back-running vocabulary describes trading on. It does not, by itself, say whether the follow-up trade is harmless arbitrage or part of a sandwich (Understanding Slippage).
References: Understanding Slippage, Sandwich Attack
MEV Shield Hides Pending Details Back-Runners Need
MEV Shield encrypts sensitive transaction contents while pending and reveals them only when the chain can process the transaction. Managing Your Stakes guidance adds that block producers cannot read or front-run a shielded transaction while it remains pending because decryption follows inclusion rather than mempool broadcast.
Back-running depends on observing a pending conversion before it lands. Shielding removes that pending visibility for eligible coldkey-signed submissions rather than changing the pool ratio after execution. Price protection remains a separate tolerance on the trader’s own acceptable execution rate.