Sandwich Attack

How a sandwich attack names a transaction ordering exploit that wraps a target transaction between two adversarial ones in Bittensor.

A sandwich attack is a transaction ordering exploit where an attacker places two transactions around a target transaction — one before and one after — to profit from the price movement the target transaction causes (Glossary: Sandwich attack).

The term is a specific form of MEV (Maximal Extractable Value) in Bittensor pool operations. It is not a network consensus attack or a validator scoring issue.

Mechanism Overview

In a sandwich attack, the attacker observes a pending target transaction that will move a pool price. The attacker submits a transaction ahead of the target to take a position, allows the target to execute and move the price, then submits a second transaction to close the position at the improved rate (Glossary: Sandwich attack).

The two adversarial transactions wrap around the target — hence the sandwich framing. The attacker extracts the price movement that the target transaction creates in the pool.

MEV Relationship

A sandwich attack is one type of MEV. MEV names the broader category of value extractable through transaction ordering. A sandwich attack is the specific pattern where the extraction uses a before-and-after pair of transactions around the victim (Glossary: MEV).

MEV Shield addresses mempool-visibility risk more broadly. The sandwich attack is the specific threat pattern that uses a two-sided wrap rather than a single front-running transaction (Understanding Slippage).

Pool Context

Sandwich attacks are most relevant in subnet pool operations where large transactions move alpha prices. The attacker profits from the pool’s price sensitivity to transaction size (Understanding Slippage).

This keeps the term in pool-operation vocabulary. Sandwich attack risk is specific to operations that interact with subnet pool pricing and require mempool visibility.

Development Stage Context

The Introduction to Bittensor describes subnet development as moving from localnet to testnet and then mainnet. For sandwich attacks, that sequence changes how readers should interpret mempool visibility and pool-ordering examples.

In localnet, sandwich 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, sandwich attack 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 sandwich attack example from one environment should not be read as representing production transaction behavior in another environment.

Reader Boundary

Sandwich attack is concept vocabulary for a transaction-ordering exploit in pool operations. It should not be read as a consensus failure, a validator scoring issue, or a description of normal slippage (Glossary: Sandwich attack).

The term describes adversarial behavior that exploits pool price sensitivity. Normal slippage from pool size differences is a separate concept without the adversarial ordering component.

Visible Stake Activity Can Be Sandwiched

Official Managing Your Stakes documentation describes a Glossary: Sandwich Attack in which an observer buys subnet alpha before a visible victim trade and sells after it. That two-sided sequence extracts value from the victim’s execution rather than from ordinary reserve movement alone.

The Glossary: MEV (Maximal Extractable Value) states that MEV attacks can affect both Glossary: Staking and Glossary: Unstaking operations when knowledge of pending transactions lets another party manipulate token prices. Sandwich vocabulary therefore names a documented ordering threat around stake and unstake flows, not a generic pool label detached from participant actions.

Those operations move value through subnet pool pricing while details may still be readable in the Glossary: Mempool waiting period. Sandwich attack reading stays with that visible pending stake and unstake context rather than with every pool conversion that simply returns a different amount than a static quote.

References: Managing Your Stakes, Glossary: Unstaking

Price Protection Limits Losses Without Hiding Pending Trades

Official Managing Your Stakes documentation draws a separate line between Glossary: Price Protection and defenses against sandwich attacks. Price protection caps how much adverse price movement a staking or unstaking action will accept, which can limit losses when execution lands at a worse rate than expected.

The same guidance states that price protection does not prevent sandwich attacks entirely, while MEV Shield does so by encrypting sensitive pending transaction contents until block inclusion. A sandwich attack still depends on observing pending trade details before settlement; price protection reacts when movement is measured at execution time rather than hiding those details from observers.

Price Protection documentation describes strict, partial, and unsafe handling when measured movement exceeds a selected tolerance. Those choices govern how the action proceeds after pool movement is known, not whether another party could see the pending trade and order around it. Sandwich attack vocabulary stays with ordering foreknowledge; price protection vocabulary stays with tolerated execution outcomes.

References: Price Protection, MEV Shield

Back-Running Uses Only the After Side

The Glossary: MEV (Maximal Extractable Value) lists three common ordering attack shapes alongside sandwich attacks. Glossary: Front-Running names observing a pending transaction and submitting a similar one with higher priority to execute first. Back-running names submitting immediately after a target transaction to capitalize on its effects.

A sandwich attack requires both sides of the victim trade — entry before and exit after — to profit from the price movement the victim causes when the pool absorbs the larger trade. Back-running adds only the after side and does not wrap the target between two adversarial transactions.

Front-running covers the before-only case, sandwich attack covers the before-and-after pair, and back-running covers the after-only shape named in the same glossary list. Keeping those labels separate prevents reading every post-trade ordering profit as a sandwich pattern.

References: Glossary: MEV (Maximal Extractable Value), Glossary: Front-Running

Relationship to MEV Shield

Sandwich attack and MEV Shield are related but different parts of Bittensor transaction-protection vocabulary. Sandwich attack names an ordering exploit that profits from a victim trade’s price impact, while MEV Shield names encrypted mempool protection that hides sensitive transaction details before block inclusion (Glossary: Sandwich attack, MEV Shield).

For readers, sandwich attack describes adversarial ordering around a visible trade, and MEV Shield describes a mitigation that reduces mempool visibility for protected submissions. One is exploit vocabulary; the other is pre-inclusion protection vocabulary. They belong to the same MEV risk domain but name different roles.

References: Glossary: Sandwich attack, MEV Shield, Glossary: MEV (Maximal Extractable Value)

Further Reading

Topics SafetyTransactionsTokenomics