MEV Strategy Selection: The Can-Do vs Should-Do Framework

The Strategy Menu Is Longer Than I Thought

Now that the circular arbitrage pipeline runs end-to-end — scanning, simulation, bundle submission, dynamic trade caps — I keep catching myself daydreaming about what comes next. Sandwich attacks. Liquidations. CEX-DEX arbitrage. JIT liquidity. The bot can do other things now that the plumbing exists. The question is whether it should.

This is the trap I want to write about today. The MEV menu is enormous and most of it sounds achievable. But "achievable" and "good idea for this team, on this chain, at this moment" are two different things, and conflating them is how solo searchers burn six months on a strategy where the winners are paying staff at million-dollar salaries.

Where I Am When I Open the Menu

To set the stage: the bot currently does on-chain circular arbitrage on Solana. The execution path is Rust. Streaming signals come over Yellowstone-compatible gRPC. A custom on-chain program handles atomic execution. Simulation gates and dynamic risk caps sit on top. None of this was a foregone conclusion six months ago. The first version chased phantom profits at a 0% success rate, and rebuilding the math, the simulation, and the execution path consumed most of the year.

So when I sit down and look at the menu — what other MEV strategies could I plug into this stack? — the honest answer is "more than I expected, fewer than the menu suggests." That gap is what I want to spend this post mapping out.

It feels a little like standing in a Costco with the doors just unlocked. Aisles in every direction, samples on every endcap, and the immediate temptation is to grab a cart and start filling it. The trouble is that this Costco charges you not in dollars but in months of engineering time. Picking up the wrong pallet means the right pallet doesn't get loaded.

The Three Questions I Keep Asking Myself

The framework I've landed on has three questions. They aren't original — practitioners and research firms have been writing variations of these for years — but they're the ones that survive contact with my actual constraints.

1. How much of my infrastructure carries over?
2. How crowded is the lane?
3. Can I actually verify this works before I bet money on it?

Let me walk through each.

Question 1: Infrastructure Reuse — What Actually Carries Over

Building MEV infrastructure is like opening a food truck. The fixed costs — the truck, the generator, the permits, the commissary kitchen — are roughly the same whether you serve tacos or burgers. The variable cost is the menu itself. The smart move is to plan a menu that reuses the kitchen you already paid for.

Looking at my current stack, several components are strategy-agnostic. The streaming feeds, the simulation gates, the on-chain atomic execution program, the bundle submission path — none of these care whether the opportunity I'm executing is an arbitrage cycle or a liquidation or something else. They just want a sequence of instructions that adds up to "more SOL out than SOL in." The Monoceros MEV Book makes this point in detail: simulation engines, mempool connectivity, bundle construction, and gas optimization are shared infrastructure across all MEV strategies. Once they exist, the marginal cost of adding a second strategy is the detection and routing logic, not the entire stack.

So far, so good. The temptation is to read that and conclude that everything on the menu is a low-cost extension of what I already have. That's where the reasoning breaks down.

Each strategy has strategy-specific infrastructure that doesn't come for free. Per the same Monoceros analysis, CEX-DEX arbitrage needs low-latency exchange connectivity and an inventory management system across venues. Liquidations need oracle update monitoring and either flash loan integration or pre-positioned capital — Dwellir's infrastructure guide puts the capital requirement for JIT liquidity work at over $100,000. Generalized frontrunning requires "replicating 50-block transaction histories" before execution, per the same source. These are not small bolt-ons. These are second restaurants.

The practical screen I run is: does this strategy need a component I don't have, and if so, is that component reusable for future strategies or a single-use sink? Adding liquidation monitoring is cheap because oracle-watching is reusable. Adding CEX-DEX arbitrage means building exchange API integrations, custody for inventory at centralized venues, hedge logic, and a whole new failure surface that the on-chain stack never sees. That's not an extension of the kitchen. That's signing a second lease.

There's also the latency floor. Dwellir's data is brutal here: sub-100 millisecond latency is required for production MEV bots, opportunities need to be spotted and submitted within 200 milliseconds total, and operations above the 200-millisecond threshold capture less than 10% of opportunities. One documented case in the guide describes a team running at 400 milliseconds losing 40% of potential arbitrage captures — and improving from roughly 60 to 85 profitable trades per 100 attempts after switching to a lower-latency setup. The latency investment is non-negotiable, but it's already a sunk cost for me. Whatever I do next, that floor is already paid for.

What this means in practice: any strategy that lives entirely on-chain inherits my latency floor for free. Any strategy that depends on an external venue inherits a new latency floor I haven't paid yet, and the cheapest such floor (managed dedicated nodes) is far from free. According to Dwellir's published ranges, monthly cost for managed dedicated nodes runs into the low four figures, while serious operations easily exceed five figures per month. That's a number I look at and ask: would this new strategy generate enough incremental profit to cover this incremental cost? If the answer requires squinting, the answer is no.

Question 2: Competition Level — Short-Tail vs Long-Tail

The most useful mental model I've borrowed comes from a post on mteam.space that splits MEV into short-tail and long-tail strategies. The framing has stuck with me because it predicts who wins each lane.

Short-tail MEV — the well-known stuff like simple DEX arbitrage and sandwich attacks — is described in that piece as a competition to "hit" an opportunity. Everyone sees the same opportunities; the win comes from execution speed, gas optimization, and latency. The author writes that bribe rates for short-tail MEV exceed 99.5% of extracted value paid to validators or block producers, and that sandwich attacks push that figure above 99.99%. Long-tail MEV, by contrast, is "competition to find opportunities" — bribe rates run anywhere from 0% to 80% before the alpha leaks to the broader searcher community.

The implications for someone in my position are uncomfortable but clear. The author of that post notes that successful short-tail teams operate at salary levels comparable to top-tier hedge funds — the jaredfromsubway.eth operation on Ethereum being a frequently cited example. Helius's Solana MEV report makes the same point on Solana: a single sandwich operator identified as Vpe executed 1.55 million sandwiches in a 30-day window, with an 88.9% success rate, generating roughly $13.43 million in profit. The same source notes that Vpe is responsible for "nearly half of all sandwich attacks on Solana."

This is what winner-take-all looks like in MEV. It's less like a marketplace and more like the rankings at a NASCAR Cup Series race: the front of the pack is a handful of teams with custom-built equipment that the rest of the field genuinely cannot match in a straight fight. If I decide to enter the Solana sandwich market today, I am not competing against scattered solo bots. I am competing against a near-monopolist with private infrastructure and validator-level stake — PANews's deep-dive reports a single DeezNode-operated validator with 811,604 SOL of delegated stake, valued at roughly $168.5 million when the article was written. The same source notes that "wide or 'blind' sandwiching increased from about 1% to 30%" of sandwich attacks recently, which translates to: the dominant players got more aggressive, not less.

So the short-tail headline numbers are deceiving. Yes, the absolute profits are enormous. No, those profits are not available to new entrants without massive infrastructure and stake advantages.

The other side of the framing is more interesting for someone in my situation. An arXiv paper from July 2024 on searcher competition modeled MEV-Share order flow auction data from late 2023 through early 2024. The authors observed roughly 125 active searchers in that dataset and showed that with a typical 1% discovery probability per opportunity, approximately two-thirds of opportunities have fewer than two competing bundles. That's a striking number. The narrative says MEV is omnipresent dog-eat-dog competition. The data says most opportunities go uncontested. The catch is that the contested ones are the ones everyone talks about and writes case studies on.

The takeaway I keep returning to: competition is a function of how well-known the opportunity is, not how much value is on the table. The same paper formalizes this — a searcher's allocation is bounded by their marginal contribution to the winning block. If three other searchers find the same opportunity, you keep almost nothing. If you're the only one who finds it, you keep almost everything.

This recasts the strategy selection question. The interesting screen isn't "which strategy generates the most aggregate value." It's "which strategy has the highest expected value for the marginal searcher entering today." For sandwich attacks on Solana, that number is bleak — the marginal searcher is competing with a dominant operator backed by exclusive infrastructure. For some unglamorous corner of atomic arbitrage involving a pool type that hasn't been integrated by anyone else yet, that number can be quite reasonable.

Question 3: Verifiability — Can I Actually Tell If This Works?

The third question is the one I keep underrating, then re-learning every time I underrate it. Can I fully simulate the strategy before committing? Can I verify the outcome after the fact?

Monoceros's framework splits this along an atomic vs. non-atomic axis. Atomic strategies — single-leg, all-or-nothing — succeed or revert as one transaction. DEX-to-DEX arbitrage on Solana, executed through a single bundle, is atomic. The simulation either says "this would have netted N lamports" or it doesn't, and the on-chain execution either nets that amount or nothing. There's no halfway state where you bought one leg and got stuck holding it.

The price you pay for atomicity is competition. Per Monoceros, atomic liquidations on Ethereum pay validators 99.9% of extracted revenue. Simple atomic arbitrage pays similarly steep tribute. Non-atomic strategies — CEX-DEX arbitrage being the canonical example — let searchers retain 35-75% of revenue because execution risk creates a natural barrier to entry. You can't simulate the centralized exchange leg with on-chain tools. You can't perfectly simulate the latency between your on-chain execution and your off-chain hedge.

A16z's MEV Explained frames a fourth category — speculative MEV, where you submit transactions designed to execute if sequenced favorably and revert otherwise. The economic logic is "if transaction costs are low relative to the potential gains from the MEV opportunity, it might be worthwhile for the searcher to attempt many speculative MEV transactions, even if most of them fail." That's a pure probability play and it requires entirely different infrastructure — bid-shaping rather than opportunity-finding.

The verifiability hierarchy looks roughly like this in practice:

• DEX-to-DEX atomic arbitrage and on-chain liquidations sit at the top — fully simulatable, revert if unprofitable. This is where my current stack lives.
• Backrunning on price impacts is partially verifiable. The price impact size has uncertainty, but the leg itself is atomic.
• CEX-DEX arbitrage and cross-chain MEV are low-verifiability. Execution risk on external venues; backtesting requires reconstructing centralized exchange state alongside chain state.
• Speculative MEV is the limit case — you don't verify anything, you just play the odds.

Verifiability matters because it determines what kind of team you need to be. Fully verifiable strategies let small teams operate safely — simulation is the risk system. Lower verifiability strategies require dedicated risk infrastructure: real-time inventory tracking, hedge desks, exchange failure handling, position reconciliation. The Monoceros framework calls some of this "Moloch EV" — value lost to coordination failures in non-atomic strategies. Translated to my situation: I do not have a risk desk. I have a simulator and a kill switch. That makes me a fully-verifiable-strategy team by default, whether I like it or not.

A way to think about it: an atomic strategy is a vending machine. You put the dollar in, you get the soda out, or you get the dollar back and walk away. Nothing about the transaction has weird tail behavior. A non-atomic strategy is more like ordering from a food delivery app while halfway through a Zoom meeting. The order goes out. Now you wait. Maybe the driver makes it before the meeting ends; maybe traffic spikes; maybe the restaurant misplaces the ticket. None of these tail outcomes are visible at the moment you place the order, and managing them is its own job. If you don't have someone whose job it is to manage that uncertainty, you don't have the right business model for non-atomic strategies.

Putting the Three Questions Together

The combination of all three questions points in a fairly consistent direction. The strategy with maximum infrastructure reuse, lowest competition, and highest verifiability is something close to "stay in atomic on-chain arbitrage but expand the search surface" — more DEXes, more token pairs, more cycle structures. That's the boring answer. The exciting answers — sandwiches, CEX-DEX, JIT liquidity — fail at least one of the three questions and usually two.

This isn't an argument that the boring answer is correct. It's an argument that "I can build this" is not enough justification to build this. Helius's data tells the same story with numbers I find sobering. The average profit per arbitrage on Solana over a 12-month window was $1.58. Total successful arbitrage transactions in that same window: more than 90 million. Total arbitrage profits across the ecosystem: $142.8 million. Arbitrage is a high-volume, thin-margin business on Solana — a Walmart, not a boutique. The Medium economic analysis of Jito puts it bluntly: "Being an MEV searcher becomes akin to a low-margin business unless one innovates."

The "unless one innovates" clause is doing all the work in that sentence. Innovation in this context doesn't necessarily mean a new strategy category. It can mean a new pair, a new pool type that competitors haven't integrated yet, a faster simulation path, a lower-gas execution program, a smarter scanner. The two-thirds-uncontested figure from the academic paper applies here. Most of the value isn't in the famous strategies. It's in the unglamorous corners of well-known strategies that haven't been picked clean yet.

There's a related observation hiding in the tip-rate asymmetry. According to the same PANews analysis, sandwich bots on Solana pay only 15-20% of profits as tips to validators, while arbitrage bots pay 50-60%. The gap is enormous and tells a story: sandwich operators have moats (private order flow, dedicated stake) that let them retain more of the value, while arbitrage operators are running a much more competitive auction. Which means the same dollar of headline profit yields different take-home depending on which lane you're in. A new entrant in arbitrage is not just competing on opportunity discovery; they're also competing on tip efficiency, which is itself a function of infrastructure and routing quality. None of these are equal.

What This Changes About My Roadmap

Sitting where I sit today, the three-question screen produces a clear short list and a clear deferred list.

On the short list: expanding the search surface within atomic arbitrage. Adding more DEX integrations is a known cost — every new venue takes integration time, custom error handling, and validation, as the Token-2022 migration and the DEX-by-DEX work has already taught me. But each addition reuses the existing infrastructure and adds non-trivial coverage. Same for adding cycle structures the current scanner doesn't reach — longer cycles, asymmetric weight scanning, patterns that hint at imbalances before they fully materialize.

On the deferred list: anything that requires off-chain venues, dedicated risk infrastructure, or a different competition profile. Liquidations are deferred not because they're bad — they pass the verifiability test — but because the capital requirement is meaningful and the lending protocol integrations are non-trivial. CEX-DEX arbitrage is deferred because it fails infrastructure reuse and verifiability simultaneously. Sandwich attacks are off the list entirely; even setting aside the ethical dimension of extractive MEV, the competitive moat from validator stake and private order flow makes it a category where new entrants lose by definition.

The hardest part of writing this list is admitting that "I could build this in a month" is not the right tiebreaker. The right tiebreaker is "does this addition improve my expected value on the strategies I already run, or does it fragment my attention across strategies I'm not the natural winner of." That's a much harder question, and the honest answer for most of the menu is "fragment."

The analogy that keeps coming back to me is a small-town diner trying to decide whether to add a sushi menu. Sushi is profitable. Plenty of people would order it. But the kitchen isn't set up for it, the supplier relationships don't exist, the staff isn't trained, and the existing burger menu — which actually pays the rent — would suffer from the divided attention. Adding sushi is achievable. Adding sushi is not a good idea.

What I'm Sitting With

I keep coming back to the same observation. The MEV menu is large because the universe of value flows on a public blockchain is large. But the menu is not a buffet I can graze at the same rate as a well-capitalized team. For a small operation, strategy selection is the highest-leverage decision I make. Picking the wrong lane costs me months, and months of opportunity cost in a thin-margin business are months of runway.

The three-question framework — infrastructure reuse, competition level, verifiability — is not the answer to "which strategy is best." It's the answer to "which strategies are even appropriate for me to consider." Everything that fails the three questions is a strategy where I'd be the prey, not the predator. Everything that passes the three questions still has to compete with my existing strategy for engineering time. The screen is necessary but not sufficient. It's the bouncer at the door, not the seating chart.

For now, the practical conclusion is to deepen the lane I'm in rather than open a new one. Whether that's the right call several months from now, I genuinely don't know. The chain evolves, the competitive landscape evolves, and what's a long-tail opportunity today might be picked clean by next quarter. But sitting here today, with the infrastructure I have and the constraints I face, the boring answer is the one that survives the three questions.

One thing I've been chewing on while writing this: the impulse to add strategies is at least partly an emotional response to slow progress on the strategy I already run. It feels productive to start something new. It feels less productive to keep grinding on cycle discovery, DEX integration, and execution optimization. But the data doesn't actually support that emotion. The data says most value lives in the long tail of strategies people already run, not in the famous new strategy I haven't tried yet. The work is the work.

Key Takeaways

• "Can I build this" is the wrong question. The right questions are about infrastructure reuse, competition level, and verifiability. Most of the MEV menu sounds achievable but fails at least one of these.
• Infrastructure reuse is the cheapest moat a small team has. Adding a strategy that reuses your existing kitchen is dramatically cheaper than opening a second restaurant. Anything requiring off-chain venues, dedicated risk infrastructure, or new competitive dynamics is a second restaurant.
• Short-tail MEV is winner-take-all. Sandwich attacks and the most-traded simple arbitrage paths are dominated by teams paying near-100% of value as tips and operating with infrastructure new entrants can't match. The headline profit numbers don't apply to newcomers.
• Most MEV opportunities are not contested. Academic data suggests roughly two-thirds of opportunities have fewer than two competing bundles. The value is in the long tail of well-known strategies, not in famous strategy categories.
• Verifiability determines what kind of team you can be. Atomic, fully-simulatable strategies let small teams operate safely. Non-atomic, off-chain-dependent strategies require risk infrastructure that small teams don't have. Pick the strategy that matches your actual operating model, not the one you wish you ran.