
A MEV bot is software that watches a blockchain for value created by the order transactions land in, and tries to capture it. MEV stands for Maximal Extractable Value: the profit available to whoever can insert, reorder or exclude a transaction in a block. In practice that means closing price gaps between exchanges, repaying undercollateralised loans for the liquidation incentive, or trading immediately after a large public swap. This guide explains how each of those works, what infrastructure they need, and where the money usually goes instead of into your pocket.
Want to run this instead of reading about it? Vexor's MEV bot applies strategy profiles, capital and slippage limits and per-cycle analytics — and its Solana sniper bot covers new launches.
The five things people call MEV
"MEV" is used as a single label for behaviours that are technically and ethically very different. Separating them is the first step to understanding the topic.
Arbitrage. The same token trades at $1.02 on one DEX and $1.00 on another. A bot buys on the cheaper pool and sells on the richer one inside a single transaction, pocketing the spread minus fees. If the transaction reverts, nothing is exchanged — only gas is lost. This is the most common and least contested form of MEV.
Liquidations. Lending protocols let anyone repay an undercollateralised loan in exchange for a bonus, usually 5–10% of the position. Bots track health factors across borrowers and fire the moment a position crosses the threshold. The protocol *wants* this to happen; it is how solvency is maintained.
Back-running. A large public swap moves a pool's price. A bot places its own transaction immediately after, capturing the resulting imbalance. Nothing is displaced — the original trade executes exactly as submitted — which is why back-running is usually grouped with arbitrage rather than with predatory strategies.
Sandwich trading. A bot sees a pending swap with loose slippage tolerance, buys ahead of it to push the price up, lets the victim's trade execute at the worse price, then sells into it. The profit comes directly out of another user's execution. This is the strategy most often described as an attack, and it is the one most exposed to legal and reputational risk.
Frontrunning. Racing ahead of a known pending transaction to take the opportunity it was going to capture. In traditional finance the word carries a specific meaning tied to a broker's duty to a client, which does not map cleanly to an anonymous public mempool — but the mechanics are the same: someone else's information becomes your trade.
If you are weighing which of these to run, where the legal lines sit matters as much as whether the code works.
Why most MEV attempts lose money
The category has a reputation for easy profit that the mechanics do not support.
Gas and priority fees eat the edge. On Ethereum, competing for the same opportunity means bidding up priority fees until the marginal bidder captures almost nothing. This is a priority gas auction, and the winner is frequently the participant who overpaid.
Failed transactions still cost. A reverted arbitrage costs gas. Run hundreds of speculative attempts a day and the failure rate, not the win rate, decides whether the operation is profitable.
The latency floor is professional. Serious operators run co-located nodes, custom clients and direct relay connections measured in single-digit milliseconds. A hobby bot on a shared public RPC is structurally last in line for every contested opportunity.
The obvious opportunities are already taken. Simple two-pool arbitrage on major pairs is saturated. What remains is long-tail: thin liquidity, unusual routes, and higher exposure to slippage and bad tokens.
None of this makes MEV unworkable. It means the realistic question is not "how much can I extract" but "which narrow category can I compete in, at what cost, with what failure rate".
Private transaction pools and relay networks
The public mempool is a broadcast channel: anything you submit is visible to every other participant before it is included. For MEV strategies that is a structural problem, because a competitor can copy your transaction and outbid you on fees.
Private order flow solves this. Instead of broadcasting, you submit directly to a builder or relay that keeps the transaction unseen until a block is built. Flashbots Protect is the best-known example on Ethereum; it also protects ordinary users, since a transaction that never enters the public mempool cannot be sandwiched.
The trade-off is dependence. You rely on the relay's inclusion behaviour, its uptime, and its policies. Most operators connect to several rather than one.
Bundles: what they actually are
A bundle is a list of transactions submitted together with two guarantees: they execute in the order given, or none of them execute at all.
That atomicity is what makes multi-step strategies possible. A three-hop arbitrage across three pools only works if all three legs land in sequence; if the second leg fails, you do not want the first leg's position sitting in your wallet. A bundle makes the whole sequence conditional.
Bundle construction in practice means: simulate the sequence against the current state, calculate the profit after gas, decide what share of that profit to pay the builder as an inclusion bid, and submit. Simulation is not optional — an unsimulated bundle is a guess, and guesses fail expensively.
Gas strategy is a real part of the design. Bid too little and the bundle is never included. Bid too much and the opportunity is included but unprofitable. Most of the engineering effort in a mature MEV operation goes into this pricing decision rather than into finding opportunities.
The infrastructure a working setup needs
- Chain data. A node you control, or a low-latency provider. Shared public RPC endpoints are not competitive for contested strategies.
- Simulation. The ability to execute a candidate transaction against current state before committing it.
- Submission paths. Public mempool, one or more private relays, or both — chosen per strategy.
- Risk limits. Position caps, slippage bounds, per-token blocklists, and a maximum daily loss.
- Records. Per-attempt logs of cost, outcome and realised profit. Without them you cannot tell a profitable strategy from a lucky week.
Risk controls that matter more than speed
Speed decides who wins a contested opportunity. Risk controls decide whether winning was worth it.
Token screening. A profitable-looking arbitrage on an unknown token can be a honeypot: the buy succeeds, the sell reverts. Screening for transfer restrictions, mint authority and holder concentration prevents the most common trap.
Position sizing. Size each attempt against its expected value and worst case, not against your balance. A single oversized attempt on a thin pool can lose more than a month of small wins.
Kill switches. Automatic pause on abnormal failure rates, degraded RPC latency or unusual chain conditions. Most large MEV losses are a bug running unattended, not a single bad trade.
Where this leaves you
MEV is a real market structure, not a trick. It is also a competitive, capital-intensive and infrastructure-heavy one where the median participant does not profit. Understand which category you are actually running, price the cost of failure honestly, and treat legal and token risk as first-order concerns rather than footnotes.
If you would rather run these strategies with per-cycle controls — strategy profiles, capital and slippage limits, token screening and per-attempt analytics — than build the stack yourself, that is what the Vexor MEV engine is for.


