Worked example · 2024-06
Solana validator-coordinated sandwich-attack MEV cohort and Foundation delegation-program removal — Solana — 2024-06
OAK Techniques observed:
- OAK-T9.x (proposed) — Solana-native validator-coordinated MEV extraction, structurally adjacent to but distinct from the EVM OAK-T14.002 (mev-boost-relay-attack) class. The cohort is the Solana-specific analogue of EVM private-mempool / mev-boost MEV extraction but operates within Solana's leader-schedule-driven block-production model rather than EVM's proposer-builder separation. T14.002 is anchored on the EVM mev-boost relay surface; the Solana cohort needs a sibling sub-Technique to capture validator-and-private-mempool cooperation as a distinct primitive.
- OAK-T5.004 (Sandwich / MEV Extraction) — primary on-chain extraction primitive; each sandwich transaction front-runs and back-runs the victim's trade, extracting the MEV spread between the victim's execution price and the true market price. At cohort scale (1.55M sandwich transactions extracting ~65,880 SOL in a 30-day window), T5.004 is the dominant per-block extraction shape on Solana.
- OAK-T17.001 (Cross-Venue Arbitrage-Driven Price-Discovery Distortion — the T17 tactic page cross-references sandwich MEV as T17↔T5.004: each sandwich transaction distorts the victim's execution price relative to the true market price, constituting a per-block market-manipulation primitive; at cohort scale (1.55M sandwich transactions extracting ~65,880 SOL in a 30-day window), the aggregate price-discovery distortion across 112 of 150 DeFi tokens is a structural T17.001 surface exercised through validator-and-private-mempool cooperation rather than through conventional cross-venue arbitrage).
- OAK-T8.001 (Cluster Reuse) at the operator-cluster layer — DeezNode operates a single sandwich-bot program responsible for ~50% of cohort-scale extraction; the program-cluster fingerprint is stable across the 2024-2025 window. Cohort-aggregate methodology (Helius MEV report, Solana Compass scale-or-die analysis) attributes cohort-level extraction to a small set of validator-and-private-mempool operator clusters rather than to a long-tail of distinct operators.
- OAK-T6 (Defense Evasion) as a layered modifier — the private-mempool surface is structurally opaque to retail traders, who route transactions through wallet / aggregator UX layers that do not surface validator-cluster-level routing risk. The defender-side intervention surface is at the foundation-policy layer (Solana Foundation delegation-program removal) rather than at the protocol-runtime layer.
Summary
Solana's transaction-execution model differs structurally from EVM-side proposer-builder-separation: instead of a public mempool feeding a relay layer that constructs blocks for validators, Solana operates a leader-schedule-driven block-production model where the active-leader validator has direct discretion over transaction inclusion and ordering during their slot (~400ms per slot). The ecosystem's MEV substrate evolved through several phases:
Pre-March 2024 (Jito public-mempool era). Jito Labs operated a public mempool ("Jito Block Engine") that aggregated MEV-bid-augmented transactions and submitted them to leader validators via the Jito-Solana validator client. The public-mempool nature provided some structural transparency to MEV activity but also lowered operator-side coordination costs for sandwich extraction.
March 2024 (Jito public-mempool shutdown). Jito suspended its public mempool, citing concerns about harmful MEV practices including sandwich attacks. The shutdown immediately reduced some MEV-extraction practices but encouraged the rise of alternative private mempools operated by other infrastructure providers, with reduced transparency and exclusive validator-side access.
March 2024 → June 2024 (private-mempool proliferation). Several alternative private-mempool operators emerged, offering validator-side participation in MEV-extraction profits in exchange for transaction-inclusion preference. DeezNode, the largest of these, offered participating validators 50% of the MEV-extraction profits.
June 2024 (Solana Foundation delegation-program removal). The Solana Foundation removed 30+ validator operators from its flagship delegation program for repeated sandwich activity. The removal is a foundation-policy intervention — the affected validators retain their validator status on the network but lose the foundation-side stake-subsidy, which is the foundation's primary economic-incentive lever. The intervention is structurally distinct from a protocol-runtime change.
2024-Q4 (DeezNode peak window). In the 30-day window from December 7, 2024 to January 5, 2025, DeezNode's sandwich-bot program executed 1.55M sandwich transactions with 88.9% success rate, extracting
65,880 SOL ($13.43M) — approximately $2,200 SOL per day average extraction. DeezNode alone was responsible for nearly 50% of all sandwich attacks observed on Solana during the window.2025-Q1 (Helius MEV report). A January 2025 Helius MEV report counted sandwich attacks in 112 of 150 DeFi tokens traded that week, indicating cohort prevalence at the broader-token-universe scale despite the foundation-policy intervention.
The cohort is the canonical 2024-2025 Solana-side worked example of validator-coordinated MEV extraction. The structural pattern — validator-side block-construction discretion + private-mempool-operator-side transaction-inclusion-preference economics + retail-trader-side opaque routing — is the Solana-native analogue of the EVM mev-boost / Flashbots ecosystem but operates within a different protocol-runtime substrate.
Why this is structurally significant
The Solana validator-coordinated sandwich-attack cohort sits at three structurally distinct intersections:
Solana's protocol-runtime model does not provide a clean defense against validator-coordinated MEV. Unlike EVM's proposer-builder separation (which provides a trust-substrate boundary that the mev-boost relay layer sits within and that protocol-side defenses can target), Solana's leader-schedule-driven block production gives the active-leader validator direct discretion over transaction inclusion and ordering during their slot. Protocol-runtime-level interventions (e.g., enforcing block-level ordering invariants) are not currently feasible without substantial runtime changes. The defender-side intervention surface is therefore at the layer above the runtime — foundation policy, not protocol code. This is structurally distinct from EVM's T14.002 (mev-boost relay) class, where the relay layer is the trust-boundary and protocol / governance / vendor changes can target it directly.
Foundation-policy as the binding defender-side lever is a structurally weak-form defense. The Solana Foundation's delegation-program removal is an economic-incentive lever, not a protocol-runtime constraint. Removed validators retain the ability to operate on the network and to participate in private-mempool MEV extraction — they lose only the foundation-side stake-subsidy. The intervention raises the cost of sandwich-MEV participation (the foregone delegation-program payouts) but does not eliminate it. The structural ceiling on this defense is the foundation's economic-incentive footprint relative to the cohort-scale MEV-extraction economics — DeezNode's ~$2,200/SOL/day extraction is high enough that foregoing foundation-side stake-subsidy may be economically rational for the validator-and-operator cohort.
The Solana sandwich-MEV cohort is structurally similar to but distinct from the EVM mev-boost cohort. Both cohorts produce retail-trader MEV losses at industrial scale; both operate through a private-mempool-style routing surface; both have a defender-side cohort (Flashbots Protect on EVM, Jito MEV Protect / Helius / Anza coverage on Solana) that competes for retail flow. The structural distinction is the trust-substrate locus: on EVM, the relay layer is the trust boundary, and changes to relay-side policy can target the cohort directly; on Solana, there is no equivalent relay layer, and the trust boundary is at the foundation-policy layer, which is structurally weaker. The cohort therefore deserves a Solana-native sub-Technique sibling to T14.002, not an extension of T14.002 itself.
Timeline (UTC)
| When | Event | OAK ref |
|---|---|---|
| Pre-2024-03 | Jito Labs operates public mempool ("Jito Block Engine") with MEV-bid-augmented transaction routing to leader validators; sandwich-MEV operators participate via the public mempool surface | (genesis surface) |
| 2024-03 | Jito Labs shuts down its public mempool, citing concerns about harmful MEV practices; immediate reduction in some sandwich activity but creates space for alternative private mempools | Defender response — vendor-policy |
| 2024-03 → 2024-06 | Alternative private mempools emerge; DeezNode, the largest, offers participating validators 50% of MEV-extraction profits in exchange for transaction-inclusion preference | (private-mempool proliferation) |
| 2024-06-10 | CoinDesk publishes "Solana Heavyweights Wage War Against Private Mempool Operators" coverage of the cohort dynamics and the foundation's emerging response | (forensic surface — initial) |
| 2024-06 | Solana Foundation removes 30+ validator operators from flagship delegation program for repeated sandwich activity; affected validators retain validator status but lose foundation-side stake-subsidy | Defender response — foundation-policy |
| 2024-06 onward | Cointelegraph, Coingape, Gate Learn, Bitget News publish secondary-source coverage of the foundation's delegation-program intervention | (forensic recurrence) |
| 2024-12-07 → 2025-01-05 | DeezNode peak window: 1.55M sandwich transactions, 88.9% success rate, |
T8.001 cohort-scale operator-cluster signature |
| 2025-01 | Helius MEV report identifies sandwich attacks in 112 of 150 DeFi tokens traded that week; cohort prevalence at broader-token-universe scale | (continuing forensic surface) |
| 2025 onward | Cohort persists despite foundation-policy intervention; Solana Compass / Helius / Anza published research continues to track operator-cluster shape; retail-side MEV-protection products (Jito MEV Protect, Helius MEV Protect, others) compete for retail-flow | (continuing surface) |
What defenders observed
- Pre-event (operator-cluster layer): the operator-cluster fingerprint is observable on-chain via wallet-cluster analysis on the sandwich-extraction wallets. DeezNode's operator-cluster is publicly identified through its sandwich-bot program signature (a single program responsible for ~50% of cohort-scale extraction). Cohort-aggregate methodology — wallet-cluster analysis + sandwich-pattern correlation across validator slots — is the canonical defender-side analysis pattern; Helius and Solana Compass are the principal vendor-side substrate. Defender lesson: cohort-level analytics are mature; per-incident detection is mature; the binding constraint is the intervention surface, not the detection surface.
- At-event (block-construction layer): sandwich-MEV is structurally observable on-chain — a sandwich is a triple of transactions (front-run buy, victim swap, back-run sell) within a single validator slot, with the front-run and back-run wallets clustered to a single operator. The signal is detectable with sub-second latency; the cohort-level prevalence statistics (Helius's 112-of-150-tokens figure) are derived from the same signal aggregated across slots. Defender lesson: the at-event signal is mature; the gap is in the user-layer intervention (whether retail traders route through MEV-protected aggregators) and the foundation-policy intervention (whether the foundation maintains the delegation-program removal posture against the cohort).
- At-event (foundation-policy layer): the foundation's June 2024 delegation-program removal is the canonical defender-side intervention; the affected validators retain validator status but lose foundation-side stake-subsidy. The intervention is observable at the public-record layer (foundation-published delegation-program records) but its operational effect on cohort-scale MEV-extraction is bounded — the cohort persists post-intervention per the December 2024 - January 2025 DeezNode peak window. Defender lesson: foundation-policy interventions raise the cost of cohort-scale MEV participation but do not eliminate it; the structural ceiling is the foundation's economic-incentive footprint relative to the cohort-scale extraction economics.
- At-event (retail-trader-routing layer): retail traders route through wallet / aggregator UX layers that do not uniformly surface validator-cluster-level routing risk. Phantom, Jupiter, BonkBot, and other major Solana retail-trader-routing surfaces have varying degrees of MEV-protection integration (some through Jito-style protected-transaction submission, others without). Defender lesson: retail-side MEV-protection is a UX-layer surface that requires per-vendor adoption to be cohort-effective; the Solana ecosystem lacks a dominant MEV-protection-default analogous to Flashbots Protect's role on EVM.
- Post-event (cohort-persistence layer): the cohort persists despite the foundation-policy intervention. The structural reason is the economic-incentive asymmetry: cohort-scale MEV-extraction at ~$2,200/SOL/day is high enough that foregoing foundation-side stake-subsidy may be rational for the operator cluster. Defender lesson: economic-incentive interventions at a single layer are insufficient when the cohort-scale extraction economics dominate the foregone-subsidy economics; the binding intervention requires either (a) a deeper foundation-policy intervention (e.g., direct sanctioning of validator operators), (b) a runtime-level intervention (deeper protocol-runtime change), or (c) a retail-side intervention that diverts cohort-scale flow away from non-MEV-protected routing.
What this example tells contributors writing future Technique pages
- Solana-native MEV-extraction is structurally distinct from EVM mev-boost MEV-extraction; the OAK Technique surface should reflect this. Future T14.002-adjacent contributors should treat Solana-native validator-coordinated MEV as a sibling sub-Technique, not as an extension of the EVM mev-boost class. The trust-substrate locus — relay-layer on EVM, foundation-policy on Solana — is the load-bearing structural distinction.
- Foundation-policy is the canonical 2024 Solana-side defender-tooling layer; OAK should record foundation-policy interventions as a first-class observable. Future Solana-native worked examples that involve foundation-policy interventions (delegation-program removal, validator stake-subsidy adjustments, validator client-distribution policy) should preserve the foundation-policy layer as a discrete observable, separate from runtime-protocol changes.
- Cohort-aggregate methodology generalises across MEV cohorts. The Helius / Solana Compass methodology — wallet-cluster analysis + sandwich-pattern correlation across validator slots — is the v0.x detection primitive for cohort-scale MEV-extraction analysis on Solana. Future cohort-aggregate analysis (Pump.fun rug-republic, M3M3, MEV-extraction) should apply the same methodology.
- Operator-cluster persistence post-foundation-policy-intervention is informative for defender-tooling priorities. The DeezNode cohort's persistence through the foundation's June 2024 delegation-program removal demonstrates that foundation-policy interventions raise but do not eliminate cohort-scale MEV-extraction costs. Defender-tooling-investment framing should treat foundation-policy as one layer in a multi-layer defense, not as a sufficient stand-alone defense.
- Distinction from EVM mev-boost cohort matters for the OAK Technique surface. Future Solana validator-coordinated MEV worked examples should explicitly cross-reference EVM mev-boost coverage (see
examples/2023-04-mev-boost-equivocation.mdandexamples/2023-02-jaredfromsubway-mev.md) and preserve the structural distinction at the trust-substrate level.
Public references
[heliussolanamev2024](proposed) — Helius, "Solana MEV Report: Trends, Insights, and Challenges": https://www.helius.dev/blog/solana-mev-report[heliussolanamevintro2024](proposed) — Helius, "Solana MEV: An Introduction": https://www.helius.dev/blog/solana-mev-an-introduction[coindesksolanaprivatemempool2024](proposed) — CoinDesk, "Solana Heavyweights Wage War Against Private Mempool Operators": https://www.coindesk.com/business/2024/06/10/solana-heavyweights-wage-war-against-private-mempool-operators[coingapesolanasandwich2024](proposed) — Coingape, "Solana Takes Action Against Validators Involved In Sandwich Attacks": https://coingape.com/solana-takes-action-against-validators-involved-in-sandwich-attacks/[gatesolanasandwich2024](proposed) — Gate Learn, "Solana Foundation Ousts Validators for Sandwich Attacks Against Retail Traders": https://www.gate.com/learn/articles/solana-foundation-ousts-validators-for-sandwich-attacks-against-retail-traders/3373[solanacompassmev2025](proposed) — Solana Compass, "Solana MEV Exposed: Sandwich Attacks, Arbitrage, and Validator Behavior Analysis": https://solanacompass.com/learn/accelerate-25/scale-or-die-at-accelerate-2025-the-state-of-solana-mev[unchainedsolanamev2024](proposed) — Unchained, "Solana Is Trying to Solve MEV in a Radically Different Way Than Ethereum": https://unchainedcrypto.com/solana-is-trying-to-solve-mev-in-a-radically-different-way-than-ethereum/[cryptonewsdeeznode2025](proposed) — Cryptonews coverage of DeezNode's $13M+ sandwich extraction: https://cryptonews.net/news/security/30712979/[arcazeshadyvalidators2024](proposed) — Arcaze (Anarcaze) on Medium, "Spotting Shady Validators on Solana: A Friendly Guide": https://anarcaze.medium.com/spotting-shady-validators-on-solana-a-friendly-guide-f39ef8b32a00
Discussion
The Solana validator-coordinated sandwich-MEV cohort is OAK's canonical 2024-2025 worked example for non-EVM-L1 validator-coordinated MEV extraction. The case sits at the intersection of OAK-T14.002 (mev-boost-relay-attack: adjacent EVM Technique), OAK-T8.001 (cluster reuse: at the operator-cluster layer), and OAK-T6 (defense evasion: at the foundation-policy layer).
The structural distinguishing feature of the case is the trust-substrate-locus distinction between Solana and EVM. EVM's proposer-builder separation provides a relay-layer trust-substrate that defender-side intervention can target directly (Flashbots Protect, mev-boost relay-policy changes). Solana's leader-schedule-driven block production does not provide a comparable trust-substrate; the binding defender-side intervention is at the foundation-policy layer (delegation-program removal). This is a structurally weaker defense locus, and the cohort's persistence through the June 2024 intervention provides empirical confirmation.
For OAK's broader cohort coverage, this case + the EVM mev-boost cases (examples/2023-02-jaredfromsubway-mev.md, examples/2023-04-mev-boost-equivocation.md) collectively establish that MEV-extraction is a chain-substrate-class with structurally distinct sub-surfaces per chain ecosystem. The two cohorts converge on the retail-trader-loss-shape but diverge on the trust-substrate-locus and the binding defender-intervention layer. OAK's T14.x v0.x development should preserve this taxonomy and add a Solana-native sibling sub-Technique.
The case also generalises beyond Solana to other non-EVM L1s with leader-schedule-driven block-production models (Sui, Aptos, Sei, Monad). Each of these chains will likely produce its own validator-coordinated MEV cohort as the chain's DeFi ecosystem matures; the Solana case is the canonical 2024-2025 reference for what those cohorts will look like and what the defender-side intervention surface will be. OAK's chain-coverage v0.x work should anticipate this and ensure the framework's MEV-cohort coverage scales beyond the EVM-side framing.