flashbots

What Is an MEV Searcher? What They Do and How They Get Paid --- title: "What Is an MEV Searcher? What They Do and How They Get Paid" published: true description: "What MEV searchers do on Ethereum, how they work with builders, how they get paid, and how to start as one." tags: ethereum, blockchain, web3, mev canonical_url: mevdao.org --- Originally published on MEV DAO. By Merunas Grincalaitis, founder of MEV DAO and a developer who builds MEV, sniping and trading bots on Ethereum. Last updated: Oct 30, 2026. TL;DR: An MEV searcher is a person or team that runs bots to find profitable transaction orderings on Ethereum, like arbitrage between DEXes or liquidations on lending protocols, and then sends those transactions to block builders as bundles. Searchers don't produce blocks. They compete to get included, and they pay builders (and through them, validators) a share of the profit, usually with a direct ETH transfer to block.coinbase. Most of the money a searcher finds ends up paid to the builder, which is why the job is about speed, accuracy and a small edge, not about luck. People ask me what I actually do when I say I build MEV bots. The short answer is that I'm a searcher, and I write software for other searchers. "Searcher" is the job title Flashbots uses in its documentation: the bot operators who look for opportunities like arbitrage and liquidations. This article explains the role from the inside: what a searcher does all day, how searchers fit into the block supply chain, how they get paid and how people get started. What does an MEV searcher do? A searcher watches the chain for moments where the order of transactions creates profit, then builds and sends the transactions that capture it before anyone else does. MEV stands for maximal extractable value: the value that can be taken by including, excluding or reordering transactions in a block (ethereum.org overview). In practice a searcher's day looks like software engineering plus monitoring: 1. Ingest data. New blocks, pending transactions from the public mempool, and hints from order flow auctions such as MEV-Share. 2. Keep state. Pool reserves, tick data, lending positions and token balances, updated every block. 3. Search. Run a strategy over that state to find a profitable trade, for example a price difference between two pools. 4. Simulate. Execute the candidate trade against the latest state to make sure it really pays after gas. 5. Submit. Package it as a bundle and send it to one or more block builders. 6. Review. Check what landed, what lost, and why. Then fix the bot. The term itself goes back to the 2019 paper "Flash Boys 2.0" by Daian and others, which documented bots fighting over arbitrage in public "priority gas auctions" by raising their gas prices again and again. Flashbots and private bundles came later, partly to move that competition off the public mempool. Which strategies do MEV searchers run? Most searchers specialize in one or two strategies, because each one needs its own data, contracts and tuning. These are the common ones on Ethereum: | Strategy | What the bot does | Main skill needed | |---|---|---| | DEX arbitrage | Buys on one pool and sells on another in one transaction | Fast pricing across many pools and fee tiers | | Backrunning | Trades right after a large swap that moved a price | Reading pending transactions or MEV-Share hints | | Liquidations | Repays unhealthy loans on Aave, Compound and similar protocols for a bonus | Tracking positions and oracle updates | | Sniping | Buys a token in the first block it can be traded | Detecting launches and filtering scams | | Sandwiching | Trades before and after a victim's swap | Same as backrunning, but it harms users | I don't build sandwich bots and I don't recommend them. They take money directly from the user being sandwiched. The other strategies either keep prices in line across markets or clean up bad debt, and those are the ones worth building a business on. If you want the money side, I broke it down in how MEV bots make money on Ethereum and who keeps the profit. How is a searcher different from a builder and a validator? Searchers find opportunities, builders assemble blocks from many searchers' bundles, and validators propose the block that pays them the most. Since the Merge, most Ethereum blocks are produced through MEV-Boost, which separates these roles. I covered the mechanics in what is MEV-Boost: builders, relays and proposers explained. | Role | What they do | How they get paid | |---|---|---| | Searcher | Finds MEV and sends bundles | Keeps whatever profit is left after paying the builder | | Builder | Merges bundles and transactions into the most valuable block | Keeps the difference between what it receives and what it bids | | Relay | Passes blocks from builders to validators and checks them | Usually not paid per block | | Validator (proposer) | Picks the highest bid and proposes the block | The winning builder's bid | You can see which builders win the most blocks on public dashboards like mevboost.pics. That matters for a searcher, because sending a bundle to a builder that rarely wins blocks means it rarely lands. How do MEV searchers get paid? A searcher keeps the profit from its own trade, minus gas and minus the payment it makes to the builder to win inclusion. The standard pattern is a smart contract that does the trade, checks that it made money, and then sends part of it to block.coinbase, the address receiving fees for that block. Flashbots' coinbase payment docs show an example contract that requires its WETH balance to grow by more than the coinbase payment, so the whole transaction reverts if it doesn't make money. That design is the heart of the business: - No profit, no cost (mostly). If the trade fails inside a bundle, the bundle isn't included and you don't pay gas for it. - Competition sets your margin. When two searchers see the same arbitrage, the one that pays the builder more usually wins. On popular opportunities, most of the profit ends up with the builder and the validator. - Edge comes from being different. Searchers who earn consistently tend to find opportunities others miss, price them more accurately, or have lower costs. One detail from the same docs catches people out: sometimes block.coinbase is a smart contract instead of a normal wallet, which makes the transfer cost more gas than many searchers expect. How do searchers send bundles to builders? Searchers sign their bundles and send them over JSON-RPC to builder endpoints, such as the Flashbots relay at https://relay.flashbots.net. Per the Flashbots quick start, every request is signed with a separate authentication key. That key doesn't hold funds. It identifies you, builds reputation over time, and that reputation can help your bundles get handled during congestion. For testing, Flashbots runs a Sepolia endpoint at https://relay-sepolia.flashbots.net. Most serious searchers send the same bundle to several builders, since no single one wins every block. Before sending, they simulate with eth_callBundle to catch reverts and check profit. I wrote practical guides on sending bundles with eth_sendBundle and why they don't land and on simulating a bundle with eth_callBundle. How do you become an MEV searcher? Start with one simple strategy, run it on a mainnet fork until it's correct, then go live with small size and study every loss. This is the path I'd follow if I were starting today: 1. Learn the basics of the EVM and DEX math. You need to read Solidity and calculate Uniswap V2 and V3 swap outputs without calling the chain. 2. Read open-source bots. Flashbots' simple-arbitrage is an old but clear TypeScript example of cross-DEX arbitrage. Paradigm's Artemis is a Rust framework built around collectors, strategies and executors. 3. Pick one strategy. Two-pool arbitrage or MEV-Share backrunning is a good first choice. I explained the second in backrunning bot on Ethereum: a first MEV-Share strategy. 4. Test on a fork. Replay real blocks with Anvil so mistakes cost nothing. See how to test an MEV bot on a mainnet fork with Anvil. 5. Go live small. Use a fresh executor wallet, keep little ETH in the contract, and log everything. 6. Measure. Track how many opportunities you saw, how many you sent, how many landed and what you paid the builder. Analytics sites like EigenPhi show what competing bots earned on the same kinds of trades. 7. Join the community. Flashbots points searchers to its Discord and a searcher self-support forum in the quick start docs. Language choice matters less than people think at the start. Rust is common for speed-critical bots, which I covered in Rust MEV bot in 2026: the Alloy, Reth and Artemis stack, but a correct TypeScript bot beats a buggy Rust one. Is being an MEV searcher still worth it? It can be, but the easy opportunities are gone and most new searchers don't make money at first. The obvious trades are taken by teams with fast infrastructure, so new searchers do better in niches: new protocols, long-tail tokens, other chains or order-flow sources. I went through the numbers and trade-offs in is MEV bot arbitrage still profitable in 2026? Frequently asked questions Is an MEV searcher the same as an MEV bot? Mostly. The searcher is the person or team, and the MEV bot is the software they run. Flashbots uses "searcher" for the bot operator. Do MEV searchers need to run a validator? No. Searchers send bundles to builders, and builders deal with validators through MEV-Boost relays. You only need reliable node access and builder endpoints. What programming languages do MEV searchers use? Rust, Go and TypeScript are the most common for the bot, with Solidity (sometimes hand-optimized) for the on-chain executor contract. Do searchers pay gas when their bundle fails? Not when the bundle simply isn't included. Builders drop bundles that revert, unless you mark a transaction as allowed to revert. How do MEV searchers find opportunities? They keep a live copy of pool and protocol state, read new blocks, pending transactions and MEV-Share hints, and run strategies that search for profitable trades on every update. Related guides - MEV bot meaning: 60 terms every searcher should know - How to create a MEV bot: from mempool to first bundle - What is MEV-Share? How Flashbots pays users back for their order flow - How to hire an MEV bot developer: scope and red flags Being a searcher is mostly patient engineering: better data, better simulation, and honest review of every lost bundle. If you'd rather have a bot built for a specific strategy, that's what I do through custom MEV bot development at MEV DAO.

4/ Surgical 16-line diff eliminating slot stalls. PR: rbuilder#939 Issue: rbuilder#853 cc @flashbots @BertMiller_ @hasufl @shemnon #MEV #Ethereum #RustLang

Flashbots Bundles Explained: How to Send eth_sendBundle and Why Yours Isn't Landing --- title: "Flashbots Bundles Explained: How to Send eth_sendBundle and Why Yours Isn't Landing" published: true description: "How Flashbots bundles work, how to send one with eth_sendBundle, and a checklist for the 5 reasons a bundle doesn't get included on Ethereum." tags: ethereum, web3, blockchain, tutorial canonical_url: mevdao.org --- Almost every MEV bot on Ethereum, whether it's an arbitrage bot, a sniper or a rescue script, ends up sending bundles. And almost every developer who sends their first bundle has the same experience: the request returns a bundle hash, everything looks fine, and nothing ever shows up on-chain. This guide covers what a bundle is, how to send one properly, and a practical checklist for figuring out why yours isn't landing. What a bundle is A bundle is an ordered list of signed transactions that you send privately to a block builder instead of broadcasting them to the public mempool. The builder will include the whole bundle, in exactly that order, in one block, or it won't include any of it. Flashbots popularized this. Their Quick Start describes the flow: searchers send bundles to builders, builders simulate them to make sure they don't revert, build full blocks, and deliver those blocks to validators through mev-boost relays. Validators running mev-boost pick the most valuable block offered to them. Three properties make bundles so useful: - Atomic. All of the transactions land together or none do. That's what makes things like sponsored wallet rescues possible, where one transaction funds an account and the next ones spend that ETH in the same block. I covered that in how to rescue tokens from a compromised wallet with a sweeper bot. - Ordered. You control the sequence, which is how backruns and same-block snipes work. - Private and revert-protected. Bundles aren't visible in the public mempool before inclusion, and failed bundles don't land on-chain, so you don't pay gas for a trade that didn't work. How to send a bundle The endpoints Flashbots has two main endpoints on mainnet, and mixing them up is a common first mistake. Per the Flashbots guide on sending transactions and bundles: - rpc.flashbots.net is Flashbots Protect, a drop-in wallet RPC for regular users. It takes normal eth_sendRawTransaction calls. It does not take bundles. - relay.flashbots.net is for searchers and bots. It accepts bundles and private transactions through Flashbots-specific methods. It does not support regular Ethereum RPC methods, so you still need a normal node for nonces, gas estimates and receipts. For testing, there's also a Sepolia relay at relay-sepolia.flashbots.net. The signing key Every request to the relay is signed with an ECDSA key that identifies you as a searcher. The signature goes in the X-Flashbots-Signature header as address:signature, where the signature is over the JSON body. This key doesn't hold funds and shouldn't be your trading key. Flashbots uses it to build a reputation for you over time, and higher-reputation searchers get better access when the network is congested. So reuse the same identity key instead of generating a new one every run. The eth_sendBundle request The JSON-RPC docs describe the payload. The core fields are: - txs: an array of signed raw transactions, in order. - blockNumber: the hex block number this bundle is valid for. - Optional: minTimestamp and maxTimestamp, revertingTxHashes (transactions that are allowed to revert without killing the bundle), replacementUuid (to replace or cancel a bundle later) and builders (a list of other registered builders that should also receive the bundle). The same docs list limits of 100 transactions and 300,000 bytes per bundle. A minimal request body looks like this: { "jsonrpc": "2.0", "id": 1, "method": "eth_sendBundle", "params": [ { "txs": ["0x02f8...", "0x02f8..."], "blockNumber": "0x1499a2c" } ] } If you're in JavaScript, the official ethers-provider-flashbots-bundle library handles signing and gives you simulate() and sendBundle() helpers. Note that its README says it's designed for an existing ethers.js v5 installation. Target the next block, and resubmit every block A bundle is valid for one block. If you target block N+1 and it isn't included there, it's gone. The library README is explicit that if your bundle should be valid until it's mined, you need to resubmit for every block, and the target should always be a future block, never the current one. Resubmitting each block is also your chance to re-check the opportunity, update fees to the new base fee, and re-sign with the correct nonce. mev_sendBundle and MEV-Share Flashbots also has mev_sendBundle, a newer format that supports MEV-Share, where you can backrun user transactions that are only partially revealed through hints. Their MEV-Share searcher writeup explains the strategies. If you're just starting, eth_sendBundle is the simple option and is what most examples use. Always simulate first Before you send anything, simulate it with eth_callBundle (the library's simulate() method). The simulation runs your signed transactions in order on top of a given block and returns gas used, fees paid and coinbase payments for each transaction. This catches the majority of problems before they cost you an opportunity. The Flashbots troubleshooting guide recommends simulating, logging the results, and keeping a record of every bundle and its signed transactions, because a bundle that fails leaves no trace on Etherscan to debug from. Why your bundle isn't being included: the checklist The Flashbots troubleshooting guide lists five reasons a bundle doesn't land, in the order you should check them. 1. A transaction in the bundle reverts If any transaction reverts (and isn't listed in revertingTxHashes), the whole bundle is dropped. Common causes: wrong nonce, insufficient balance, a stale price that makes your slippage check fail, a deadline that's already passed, or a token transfer that the token contract blocks. Fix: simulate against the block you're targeting and read the per-transaction results. 2. You're not paying enough for the blockspace Your transactions must pay at least the base fee, or the block would be invalid. Beyond that, the builder compares what your bundle pays with what it would earn from other transactions using the same gas. The docs give a simple example: if your bundle pays a 1 gwei priority fee but the cheapest transaction in the block pays 2 gwei, the builder is better off leaving your bundle out. What matters is the effective priority fee: everything the bundle pays the builder (priority fees plus any direct ETH transfers to the block's coinbase), divided by the gas it uses. Fix: pay more, or use less gas for the same result. Gas optimization is a bid in disguise. 3. A competitor bid more for the same opportunity Builders roughly simulate each bundle at the top of the block, sort by effective priority fee, and then add bundles one by one as long as they still work. If another bundle that touches the same state goes first, yours may revert, collide on a nonce, or pay less than it did in isolation. Then it's dropped. The auction is blind, so you can't see competing bids in advance. You can look afterward: the library's getConflictingBundle() helper re-simulates the target block to find which bundle conflicted with yours and how much it paid. Fix: compare your effective priority fee with the winner's. If you're consistently outbid, the opportunity may be too competitive. In that case, a less crowded strategy beats a higher bid. My take on that is in how to build a profitable MEV arbitrage bot. 4. Your bundle arrived too late Your bundle has to reach the builder, get simulated, go into a block, and get through a relay to the validator, all before the slot. The troubleshooting guide notes each of those steps can take around 1 to 2 seconds. There's also a window where your node still thinks the chain is at block X while the rest of the network has already seen X+1, so you're targeting a block that's already been built. Fix: cut your own processing time, use low-latency, well-synced nodes, and send your bundle as early as you can in the slot. 5. The validator isn't running mev-boost mev-boost is opt-in. If the validator for a slot doesn't run it, or isn't connected to a relay your builder submits to, no bundle will land in that block. Research on the builder market, such as this 2024 study, found that the large majority of blocks since the Merge come through mev-boost, but not all of them. Fix: nothing to fix. Resubmit for the next block. Send to more than one builder Flashbots is one builder among several. The builder market is concentrated in a handful of players, and their share changes over time. You can see current relay and builder shares on relayscan.io and slot-level data on mevboost.pics. If you only send to one builder, you only get into blocks that builder wins. You can use the builders field to have Flashbots share your bundle with other registered builders, and many builders run their own bundle endpoints. Check each builder's documentation for its exact API before relying on it. Get refunds when you overpay Eligible bundles that land in blocks built by BuilderNet (the block-building network Flashbots operates together with partners) can earn refunds of part of what they paid, based on how much they contributed to the block's value. The rules are in the BuilderNet refunds documentation. The Flashbots RPC docs include flashbots_getFeeRefundsByRecipient and related methods so you can see what you've earned, and flashbots_setFeeRefundRecipient to send refunds to a different address. It's worth checking, especially if you bid aggressively. The short version 1. Use relay.flashbots.net for bundles, with a stable identity key. 2. Simulate with eth_callBundle every time. 3. Target the next block and resubmit every block. 4. Check the five failure reasons in order: reverts, fee too low, outbid, too late, no mev-boost. 5. Send to multiple builders. If you'd rather not build all of this yourself, the MEVDAO Sniper Bot and Token Rescue Bot already handle bundle building, simulation and submission for sniping and wallet rescues. They're included in the MEVDAO subscription with a 3-day free trial. For more guides like this, join the free MEV Secrets email list below. And if you want a custom MEV bot built, message me on Telegram. --- Originally published on the MEV DAO blog.