Front-Running
Front-running is observing a pending transaction and submitting a similar transaction with higher priority so that it executes first. 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 order their own swap ahead of it to profit from the price move the pending swap will cause.
References: Front-Running
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, seeing a large pending swap signals which way the price is about to move and by roughly how much. That visibility is the raw material front-running depends on.
References: Mempool, Understanding Subnets
The Sandwich Pattern
The best-known front-running pattern is the sandwich attack: placing transactions before and after a target transaction to profit from the price movement that target causes. An attacker who sees a pending buy places their own buy first, lets the victim’s order push the price up, then sells into that higher price. The victim’s trade is wrapped, or sandwiched, between the attacker’s two trades, and the extra slippage the victim pays is the attacker’s gain. Front-running is the front half of that pattern.
References: Sandwich Attack, Slippage
What Defends Against It
Two mechanisms reduce the payoff. 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 front-runner’s inflated price, which caps how much can be extracted. 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 nothing readable to trade ahead of.
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 front-running, that sequence changes how readers should interpret mempool visibility and price-protection examples.
In localnet, front-running mechanics can be tested in an isolated environment. Localnet pending transaction visibility does not represent production ordering behavior.
On testnet, MEV-related flows can be exercised in a shared non-production network. Testnet pool and mempool conditions are separate from mainnet state.
On mainnet, front-running concerns live production subnet pools and the protections traders use on the public network (MEV Shield).
The Bittensor Networks reference separates mainnet, testnet, and localnet. A front-running example from one environment should not be read as representing production transaction behavior in another environment.
Relationship to Yuma Consensus
Front-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, front-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 front-run. Whether front-running is profitable in a given moment depends on live pool depth, pending order flow, and the protections in force, all of which change continuously. The durable point is the relationship: visible pending transactions plus price-moving pools create the opening, and price protection and the MEV shield are what narrow it.
References: Price Protection
Pending Staking Also Moves Pool Prices
Understanding Slippage describes staking and unstaking as conversions that pass through subnet pool reserves, not only standalone swaps. A pending stake or unstake that sits in the mempool can signal an upcoming shift in the TAO-to-alpha ratio before it lands.
Front-running therefore is not limited to swap extrinsics. Any pending conversion large enough to move the pool can reveal direction and size to someone watching the mempool, which is the visibility this page describes as the opening for ordering ahead (Understanding Subnets).
References: Understanding Slippage, Mempool
Back-Running Takes the Slot After the Target
Front-Running and Back-Running both depend on seeing a pending conversion, but they sit on opposite sides of it. Front-running executes before the target to profit from the move it is about to cause; back-running executes immediately after to profit from the move it just caused.
A sandwich attack combines both legs around one victim trade. Read alone, front-running names only the first leg that worsens the target’s fill price, while back-running names the follow-up trade that captures the dislocation left behind (Sandwich Attack).
References: Back-Running, Sandwich Attack
Slippage Measures the Pool Move Being Traded On
Slippage names the difference between expected and received amounts when a conversion moves through subnet pool reserves. Front-running targets that movement: the attacker orders ahead because the pending transaction will change the ratio and therefore the price the next trader receives.
Price protection and the MEV shield reduce how much can be extracted, but slippage vocabulary describes the underlying pool shift that makes ordering ahead profitable in the first place (Understanding Slippage).
References: Understanding Slippage, Price Protection
Weight Copying Is an Analogous Timing Problem, Not Trading Front-Running
Weight Copying describes a validator reading the publicly available weight matrix and copying, or deriving from, other validators’ work instead of independently evaluating miners. It is a separate, non-trading problem, not a form of front-running itself.
The two share a timing shape rather than a mechanism: both depend on someone else’s information becoming visible before a result is finalized. Commit Reveal addresses weight copying the way encryption addresses front-running, by keeping submitted weights concealed until a designated reveal point so there is nothing public to copy before consensus runs.
References: Weight Copying, Commit Reveal