Flashbots MEV-Share on EVM: Building an Orderflow Backrunner

MEV-Share pays you to not frontrun the user. That inversion is the whole point, and it trips up most people coming from a raw-mempool background. Instead of racing to sandwich a swap you saw in the public pool, you subscribe to a stream of partial transaction hints, find a profitable backrun, and submit a bundle where a slice of your profit is kicked back to the wallet that originated the trade. Flashbots calls it orderflow auction; in practice it's a refund market where the user, the searcher, and the builder all take a cut.

This guide walks through the mechanics of building a backrunner against the MEV-Share event stream on Ethereum mainnet, the failure modes nobody warns you about, and where this sits relative to fully dark private orderflow.

What actually comes down the wire

You subscribe over SSE to the MEV-Share node at mev-share.flashbots.net. Each event is a hint — a deliberately partial view of a pending transaction. The user (or the wallet/RPC that submitted on their behalf) chooses how much to reveal. A minimal hint might give you nothing but a transaction hash and a logs array with topic hashes. A generous one exposes to, functionSelector, and full logs including the swap amounts.

Here's the shape of a typical hint after JSON parsing:

{
  "hash": "0x9f...",
  "logs": [
    { "address": "0x88e6...c640",
      "topics": ["0xd78ad9...", "0x00..from", "0x00..to"],
      "data": "0x..." }
  ],
  "txs": [{ "to": "0xE592...1564", "functionSelector": "0x5ae401dc", "callData": null }]
}

Notice callData is null. You almost never get the raw calldata. Your job is to reconstruct enough of the trade's effect from the logs to know whether backrunning it is worth gas. A Uniswap V3 Swap event leaks the pool address and, if the user opted in, the amount0/amount1 deltas. From the pool address you resolve the token pair and fee tier; from the deltas you know the direction and size. That's enough to simulate.

If the hint only carries topic hashes and no data, you're guessing. Plenty of searchers just skip those — the expected value of simulating a blind hint is usually negative once you price in the CPU.

The backrun loop

The core loop is: hint arrives, decide if it's actionable, build a candidate backrun transaction, simulate the two-transaction bundle, and if profitable, submit it back to Flashbots.

async for hint in mev_share.subscribe():
    pool = extract_pool(hint.logs)
    if pool is None or pool not in WATCHED_POOLS:
        continue

    # Build a backrun that arbs the price impact the user's swap left behind
    backrun_tx = build_arb(pool, direction=infer_direction(hint.logs))

    bundle = {
        "version": "v0.1",
        "inclusion": {"block": next_block, "maxBlock": next_block + 2},
        "body": [
            {"hash": hint.hash},            # the user's tx, referenced by hash
            {"tx": signed(backrun_tx), "canRevert": False},
        ],
        "privacy": {"hints": ["hash", "logs"]},
    }

    sim = await client.sim_bundle(bundle)
    if sim.profit - sim.gas_cost > MIN_PROFIT_WEI:
        await client.send_bundle(bundle)

Three things in there matter more than they look.

Referencing by hash, not raw tx. Your bundle body lists the user's transaction as {"hash": ...}. You never had their signed transaction — MEV-Share substitutes it at match time. This is how the protocol keeps the originating tx private while still letting you bundle behind it. It also means your backrun must come strictly after; you cannot reorder around a tx you can't see.

canRevert: false on your own leg. If your arb reverts, the whole bundle is dropped and you pay nothing, but you also don't want a half-executed position. Keep it atomic.

maxBlock slack. Giving the builder a two- or three-block window materially raises inclusion odds during congested periods, at the cost of a slightly staler price assumption. On a fast-moving pair I keep it tight; on a stable stablecoin pool I let it ride.

Simulation is where the money leaks

mev_sendBundle sim against the pending state tells you the delta, but the pending state you simulate against is not the state your bundle lands in. Between your sim and inclusion, other searchers land their own backruns on the same hint. MEV-Share broadcasts to everyone simultaneously, so a fat, obvious backrun gets bid down to nearly nothing by competition. The realistic edge lives in hints that are cheap to parse but expensive for others to act on — odd pools, multi-hop routes, pairs where your infra already has warm state.

This is the same latency-and-state-freshness problem searchers fight on other chains. The Solana crowd obsesses over it through validator-side shred streaming for a raw latency edge and Geyser gRPC mempool streaming; on EVM the auction structure hides some of it, but the underlying race is identical. If you're building this class of system across chains, the MEV infrastructure and data pipeline is what determines whether your sim reflects reality.

The refund math

MEV-Share splits your backrun profit. The default is 90% back to the user, 10% to you as the searcher — though the exact split is set by the orderflow originator and you'll see wildly different terms depending on the RPC that submitted the user's tx. Ninety-ten sounds brutal until you remember the alternative: on the public mempool that same opportunity gets sandwiched to zero by a dozen bots, and you were probably one of the losers. A guaranteed 10% of a real arb beats a lottery ticket on a gas war.

Your MIN_PROFIT_WEI threshold has to be set after the refund and after the priority fee you bid to the builder. I've seen backrunners that were nominally profitable in sim and net-negative in production purely because the builder tip ate the margin. Bid the tip as a fraction of realized profit, not a flat number.

MEV-Share versus dark orderflow

MEV-Share is translucent orderflow: the user reveals just enough to attract a backrun and captures most of the value. Fully dark private orderflow is the opposite — the transaction is routed to a single builder or a closed searcher set and never hinted publicly at all. Exclusive orderflow deals (a wallet piping all its swaps to one integrated searcher) extract more per trade but require a business relationship and volume commitments. MEV-Share is permissionless; anyone can subscribe and compete.

The tradeoff is edge durability. In a dark exclusive arrangement your competition is zero because nobody else sees the flow. On MEV-Share your competition is everyone, and margins compress toward the cost of capital and gas. Most independent searchers I know run both: MEV-Share for volume and baseline flow, private deals for the fat pipes. If you're standing up the searcher side of this, an EVM MEV bot built for the orderflow auction and a tuned EVM arbitrage engine are the two halves you need in place.

A few gotchas worth internalizing before you ship:

• Nonce and account isolation. Run backruns from a dedicated hot wallet with a single in-flight nonce per builder, or you'll clobber your own pending bundles.
• Log parsing is your moat. The searchers who win parse more event types faster. A V3 Swap is easy; a Balancer batch swap or a 1inch aggregated route is where the uncontested profit hides.
• Bundle stats, not sim, are ground truth. Poll flashbots_getBundleStats to learn whether you were even considered by the builder. Sim profit that never lands is a modeling bug.
• Reorgs and uncle risk. A backrun landed in an uncled block is a landmine if your arb left you holding inventory. Keep positions flat within the bundle.

The cross-chain lesson holds: the same instincts that make JIT liquidity provision on Solana DLMM pools work — read the flow, price the impact, be first with correct state — are what make an EVM backrunner work, and the searchers who move between Solana MEV and arbitrage systems and EVM tend to build the sharpest EVM bots because they've already had the latency lesson beaten into them.

If you want a backrunner that clears the refund-and-tip hurdle instead of just looking green in sim, that's exactly the kind of EVM MEV system we build end to end.