Flashbots Bundles Explained: Private MEV Execution

Answer first — A Flashbots bundle is an ordered group of transactions submitted via eth_sendBundle to a builder relay (Flashbots, Titan, beaverbuild, rsync-builder) for atomic inclusion in a target block. The whole bundle either lands together or none of it does — there's no partial fill. Submission is sealed (other searchers can't see your bundle in any public mempool) and can include hints like revertingTxHashes (tx that's allowed to revert without invalidating the bundle), targetBlockNumber / maxBlockNumber (inclusion window), replacementUuid (resubmission of same logical bundle), and refundRecipient (where MEV-Share kickbacks go). The single most common mistake is conflating the user-protection RPC (Flashbots Protect, for normal wallet users) with the searcher relay (relay.flashbots.net, for eth_sendBundle) — they're different products with different endpoints, different auth, and different semantics. Both have "Flashbots" in the name; only one accepts bundles.

Mastery path

• Advanced ETH arbitrage strategies
• Institutional MEV backrunning (2026)
• Flashbots bundles explained (current)
• Best Ethereum private RPCs
• Private RPC guide
• MEV profitability (2026)

What a bundle actually contains

A bundle is a JSON envelope sent over HTTPS to a relay. The minimum payload:

• txs — array of signed RLP-encoded transactions, in execution order.
• blockNumber — target block (hex). This is the block the bundle targets for inclusion.

Optional but commonly used:

• minTimestamp / maxTimestamp — tighten the inclusion window to a real-time band.
• revertingTxHashes — list of tx hashes that are allowed to revert. Without this, any revert in any tx invalidates the entire bundle.
• replacementUuid — replace a previously-submitted bundle with same UUID (not all relays support).
• refundRecipient — for MEV-Share-aware bundles; where to send any kickback.
• refundPercent — what fraction of MEV to share back to the trigger user.

Each tx in txs is just a normal signed Ethereum transaction. The bundle itself is not a transaction — it's a wrapper instructing the builder how to handle the txs collectively.

The bundle lifecycle

1. Searcher constructs the bundle — typically: signed trigger reference + signed strategy tx(s).
2. Searcher simulates with eth_callBundle against the next-block target. If unprofitable, drop.
3. Searcher submits with eth_sendBundle to one or more relays. Sealed at the relay layer.
4. Relay validates schema + runs simulation + forwards to participating builders.
5. Builders evaluate whether including the bundle improves their block value over the next-best alternative. If yes, include.
6. Proposer (validator) chooses which builder's block to publish — they pick whichever pays them the most.
7. Bundle lands if the chosen builder's block contained it. Otherwise: not included.

A bundle that doesn't land in the target block is just gone — there's no retry by default. Searchers either accept the miss or resubmit (with the same or updated parameters) for a later target block.

Why "private" doesn't mean what most people think

A bundle is private at the public-mempool layer. It's still visible to:

• The relay you submitted to (Flashbots, Titan, etc.).
• The builders the relay forwards to (each relay forwards to a different set).
• The validator that proposes the block, once a builder includes the bundle.

So "private" means "not in eth_subscribe('newPendingTransactions')." Other searchers don't see it; the relay's builder set does. This matters: if you're submitting to a single relay with a single builder, you're trusting that builder and that relay with your strategy in a way that the public mempool would not have required.

The relay-vs-RPC distinction

The Flashbots ecosystem confusingly has two endpoints with similar branding:

A eth_sendBundle to the user RPC fails. A wallet swap sent to the relay also fails. The two products serve different audiences and aren't interchangeable. The full discussion is in Best Ethereum private RPCs.

Multi-builder fan-out is now the default

Flashbots is no longer the only block builder. As of 2026 the major builders include:

• Flashbots — historically dominant, still significant share.
• Titan — among the largest by current block share.
• beaverbuild — high share for high-priority blocks.
• rsync-builder — reliable secondary.
• bloXroute — commercial relay with global infrastructure.

Single-relay submission means you're betting that your relay's builder wins the next slot. That's a 30–60% blind spot depending on the day. Modern serious searchers fan-out: same bundle submitted to four+ builders simultaneously, with the first inclusion winning. The FRB Agent does this fan-out automatically with weights that adjust based on per-relay inclusion success.

MEV-Share: the OFA layer

MEV-Share is a separate Flashbots-built protocol for Order Flow Auctions. It exposes pre-execution hints about pending transactions (a swap is happening, here's the rough size and pool, but not the exact details) so searchers can build OFA-aware bundles that reward the original user with a refund.

Key MEV-Share concepts:

• Hints — partial info about pending txs published to a hint stream. Searchers subscribe to the hints, not the full transactions.
• Bundles referencing hints — your bundle includes the trigger user's hashed tx ID as a backrun reference; the relay matches it on inclusion.
• Refund — when the bundle lands, a fraction of MEV is returned to the trigger user via refundRecipient / refundPercent.

MEV-Share is its own subscription endpoint with its own schema. Submitting an MEV-Share-style bundle to a regular Flashbots relay (or vice versa) silently fails. Different products, different rules, but conceptually adjacent.

Common bundle mistakes

• Forgetting revertingTxHashes. A multi-tx bundle where one tx is expected to possibly revert (e.g., probe-and-retry) gets the whole bundle invalidated unless those txs are flagged.
• Wrong targetBlockNumber. Off-by-one or hex-vs-decimal confusion. The relay rejects.
• Submitting to a relay your tx fee is uncompetitive for. Builders prioritise by value. A bundle with 1 gwei priority fee on top of a packed block won't be included regardless of which relay forwarded it.
• Single-relay submission. Leaves 30–60% of block share unreachable.
• Re-submitting at same block without replacementUuid. Some relays treat resubmission as a new bundle; some treat it as duplicate. Use replacementUuid if the relay supports it; otherwise track which bundles are pending for which target block manually.
• Confusing eth_sendBundle and eth_sendRawTransaction. Different methods, different endpoints, different intent.

Working configuration

A modern searcher's bundle path:

1. Build bundle with appropriate hints (revertingTxHashes, refundRecipient if MEV-Share, target block, max block).
2. Simulate via eth_callBundle against the target block. Drop if unprofitable.
3. Fan-out via eth_sendBundle to Flashbots + Titan + beaverbuild + rsync-builder simultaneously.
4. Wait one block. If not included, re-evaluate (state may have moved): drop or resubmit.
5. Log inclusion source per bundle.

FRB Agent implements this end-to-end with per-relay inclusion tracking that auto-tunes the fan-out weights over time.

References

• Flashbots: understanding bundles
• Flashbots eth_sendBundle reference
• MEV-Share documentation