If you have read anything about MEV, you have met the word “searcher”. It is the working job title of everyone actually running the bots: the arbitrageur closing a price gap between two DEX pools, the liquidator watching health factors on a lending market, the operator whose bundle landed one block ahead of yours. The term gets used constantly and defined rarely. This post fixes that. It covers what a MEV searcher actually is, where they sit in Ethereum’s block-building pipeline, which strategies they run, what their infrastructure looks like in practice, and then the question almost everyone asks next: do you need to run your own node to compete?
What a MEV searcher is, and where they sit
MEV, maximal extractable value, is the value that can be captured by choosing which transactions go into a block and in what order. A MEV searcher is the party at the front of that pipeline. Searchers watch the chain and the mempool for opportunities, construct the transactions that capture them, and bid for the right to have those transactions included in a favorable position. What searchers do not do is just as defining: they do not assemble blocks and they do not propose them.
Since Ethereum adopted proposer-builder separation through MEV-Boost, the supply chain splits into three roles. The searcher finds an opportunity and packages it as a bundle, an ordered list of transactions plus a bid expressing how much they will pay for placement. The builder collects bundles and ordinary transactions from many searchers and assembles the most profitable block it can. The proposer, a validator whose turn it is, commits to the winning block without seeing its contents first, then collects the bid. A relay sits between builder and proposer to make that blind handoff trustable. The searcher’s edge lives entirely upstream of the builder: seeing the opportunity earlier, pricing it better, and getting the bundle delivered before everyone else who saw the same thing.
That pipeline is itself in motion. ePBS, specified in EIP-7732, moves the proposer-builder handoff out of bolted-on relay infrastructure and into the protocol itself, which reshuffles the timing of the build window in ways that matter to anyone bidding into it. We are not going to re-explain it here; our ePBS explainer covers what changes and what does not. The short version is that the searcher’s seat survives the redesign. Someone still has to find the value before it can be auctioned.
The strategy families
Nearly everything searchers do falls into three families, and they are not morally equivalent, so it is worth being precise about them.
Arbitrage is the workhorse. The same asset trades at different prices on two venues, so a searcher buys on the cheap one and sells on the expensive one, usually atomically inside a single transaction that either profits or reverts. It is brutally competitive and generally considered healthy: arbitrageurs are the reason prices across DEXes agree with each other at all. If you came here looking for a MEV bot tutorial you can actually run, this is also the right strategy to start with, and our hands-on arbitrage bot tutorial builds one end to end. For the graph theory behind finding multi-hop cycles, detecting arbitrage with Bellman-Ford goes deeper.
Liquidations are the second family. Lending protocols pay a bonus to whoever repays the debt of an underwater position, so searchers watch collateral ratios and the oracle updates that move them, racing to be first when a position tips. Like arbitrage, this is work the protocol actively wants done; without liquidators, lending markets accumulate bad debt.
Sandwiches are the third family, and the honest description is that they are extractive. A searcher spots a large pending swap in the mempool, buys the same asset just before it to push the price up, lets the victim’s swap execute at the worse price, then sells right after. The profit comes directly from degrading another user’s execution; nothing is made more efficient. Sandwiching is a large part of why private order flow exists: wallets and RPC endpoints increasingly route user transactions straight to builders precisely so the public pool never sees them. We describe the strategy because you cannot understand the mempool race, or the countermeasures reshaping it, without it. That is not the same as recommending it.
Around the edges sit backruns, transactions placed immediately after a known state change such as an oracle update, which capture value without touching anyone’s execution price and increasingly flow through order flow auctions rather than open mempool competition.
What MEV infrastructure actually looks like
Strip away the strategy and every serious searcher runs the same four-part stack.
The first part is the feed. A searcher needs to see pending transactions and new blocks as early as possible, which in practice means a WebSocket subscription to a node’s mempool and head events. The quality of this layer is measured in two things: how much of the public pool you see, and how early you see it. Both depend on the node behind the subscription and your distance from it. The mechanics, from eth_subscribe through hydrating hashes into full transactions and decoding their calldata, are covered in how to access the Ethereum mempool.
The second part is simulation. Once a candidate opportunity appears, the searcher forks current state, replays the prospective bundle against it, and computes exact profit after gas. That number sets the bid, and getting it wrong in either direction is expensive: bid too little and a competitor takes the slot, bid too much and you win a trade that loses money. Simulation is state-read heavy, which is exactly why its speed is dominated by how far away the node holding that state is.
The third part is submission. Bundles go to builders, typically via eth_sendBundle or a builder’s private endpoint, and serious searchers submit to several builders at once because no single builder wins every block. Submission has a hard deadline in every slot; a bundle that arrives after the builder seals its block was never in the auction at all.
The fourth part runs alongside the other three: monitoring. Inclusion rate per builder, latency percentiles on the feed and the submission path, profit and loss per strategy, and a kill switch for when behavior drifts. It is the least glamorous layer and the one most new searchers skip, which is why most new searchers cannot tell whether they are losing to better strategies or to a degraded feed.
The latency budget, briefly
Every one of those layers spends from the same budget: the time between an opportunity appearing and a block being sealed. The trigger has to reach your code, every state read during simulation is a round-trip to wherever your node is, and the finished bundle has to travel to builders. When the node is remote, those round-trips are paid per call, not per opportunity, so the cost compounds with the complexity of the strategy; and because MEV is competitive at the tail, the p99 spikes that hit exactly during volatile moments matter more than any average. We took that budget apart line by line in why MEV is a latency game, so here we will keep it to the conclusion: strategy decides whether a play is worth making, latency decides whether you are the one who makes it, and the infrastructure share of that latency is the only part you can actually remove.
Do MEV searchers need to run their own node?
This is the question behind most searches that land on a post like this, and the honest answer has two halves. You unavoidably need node-grade access. Whether you personally operate the node is a separate decision.
Node-grade access means the things a shared RPC gateway structurally cannot give you. Hosted gateways serve thousands of tenants through load balancers, so your mempool subscription is a second-hand copy of whatever their fleet saw, arriving after an internet hop. Many disable the txpool namespace or do not serve newPendingTransactions at all, and the ones that do apply rate limits that a hydration loop hits within seconds during busy periods. A searcher on a shared gateway is watching a delayed, filtered replay of the pool their competitors read directly. For discretionary trading that is fine; for MEV it is disqualifying.
The traditional fix is running your own node, and it genuinely delivers: your own peering, your own txpool configuration, your choice of client, an unfiltered pool, and no per-request accounting from anyone. The cost is that you have taken on an infrastructure job. A mainnet node wants serious NVMe storage, plenty of RAM, and real bandwidth; initial sync takes days; execution and consensus clients both need timely upgrades on every hard fork; and peering, disk growth, and client health need monitoring that pages someone. None of this is impossible, plenty of searchers do it, but it is permanent operational overhead that competes for the attention your strategies need. If you require custom client patches, exotic peering arrangements, or chains nobody hosts for you, this is still the right path.
The middle path is co-location: run your code on someone else’s node, on the same physical host, rather than across the internet from it. That is the model BLAZED.sh is built on. Your Docker container or Node.js script deploys onto a host running a fully synced Ethereum mainnet node and talks to it over a local socket (ws://eth:8545), so round-trips are sub-10ms, the mempool subscription is the node’s own unfiltered view, and the txpool namespace is actually there when you call it. You get the proximity and visibility of self-hosting without owning sync, upgrades, or disks. The honest constraints: Ethereum mainnet is the only chain live today (other networks are planned); usage is metered as per-request credits from a monthly allowance, where most methods cost one credit and heavy calls like txpool_content cost four, so a high-volume loop still draws credits rather than being free; and archive-depth history is Enterprise-only, with Beta plans running against tip-of-chain nodes, which is what live searching needs but not what deep backtesting needs.
Framed as a decision: if your bottleneck is control over the node itself, run your own and budget the ops time honestly. If your bottleneck is proximity and an unfiltered pool, co-location gets you both without the pager.
Where to go from here
A searcher is not a mysterious job title; it is a feed, a simulator, a submission path, and the discipline to measure all three. Start by reading the pool with the mempool access guide, build your first strategy with the arbitrage bot tutorial, and when the loop works, put it on the node instead of across the internet from one; the deployment docs cover containers and scripts. The strategies will keep evolving and the pipeline around them will too, but the constant is the one this post keeps returning to: the searcher who sees state first, and acts on it fastest, is the one who gets paid.