Inclusion Probability 101: Thinking About Failures

Answer first — Inclusion probability is the share of bundles you submit that actually land on-chain. In 2026 it's measured, not assumed: a working bundle path on Ethereum mainnet with multi-builder fan-out and a competitive priority fee typically lands a high majority of bundles, but the absolute number depends on your strategy's contention level, the builder coverage your fan-out reaches, and the freshness of your fee model — all of those vary by chain and time of day. The expected-value formula is EV = (Reward − Cost) × P_inc − (Failure_Penalty × (1 − P_inc)), and on private-relay paths the failure penalty is roughly zero (no on-chain gas for not-included bundles), which makes raising P_inc the highest-leverage knob you have. The trap operators fall into is treating P_inc as a single global number — it's a per-strategy, per-relay, per-time-of-day distribution, and that's how it should be measured.

Mastery path

• What is MEV?
• Private vs public mempool
• Backrun vs sandwich strategy
• Inclusion probability (current)
• Fixing failed bundles guide
• Mempool scanning 101

The expected-value framing

Every MEV opportunity is a bet on whether your bundle lands and is profitable when it does:

EV = (Reward − Cost) × P_inc − (Failure_Penalty × (1 − P_inc))
Copy

Where:

• Reward = profit if the bundle lands and the strategy works.
• Cost = gas paid + priority fee + relay fees (if any) + builder kickback.
• P_inc = probability of inclusion in the target block.
• Failure_Penalty = on-chain gas paid if the bundle was submitted but didn't land profitably.

For private-relay paths (eth_sendBundle), Failure_Penalty ≈ 0 — bundles that aren't included don't burn gas. That collapses the formula to roughly EV ≈ (Reward − Cost) × P_inc, which makes raising P_inc the highest-leverage knob.

For public-mempool sends, Failure_Penalty is the full gas of every reverted attempt. That's why public-mempool MEV operators bleed even when individual successful trades are profitable — the rejected attempts compound.

What drives P_inc

Three primary factors, ordered by typical impact:

1. Builder coverage of your relay fan-out. Single-relay submission reaches whatever fraction of next blocks that relay's builders win. On Ethereum that's commonly 30–60%. Fan-out across Flashbots + Titan + beaverbuild + rsync-builder pushes coverage close to 95%+. Most operators get the biggest P_inc improvement by simply adding relays to their fan-out.
2. Priority fee competitiveness. A bundle whose priority fee is below the cleared price for that block doesn't get included regardless of which relay forwarded it. Builders sort bundles by value-per-gas; uncompetitive bids lose every time.
3. Latency to relay. Builders close their inclusion list at some point before the slot. Bundles arriving after that deadline can't be included even if they pay well. On 12-second mainnet slots, sub-150 ms RTT to your relay is plenty; sub-50 ms doesn't help further.

Secondary factors:

• Hint correctness. Missing revertingTxHashes invalidates bundles that probably should have landed.
• Bundle simulation that diverges from reality. A bundle that simulates green but reverts in production wasn't actually includable — sim drift hides the inclusion problem.
• Strategy-side competition. When other searchers see the same opportunity, the auction-cleared bid rises; some bundles that would have landed in a quiet block don't in a contested one.

How to measure your real inclusion rate

Per-strategy daily numbers, persisted to a dashboard:

• Bundles submitted.
• Bundles included. Cross-check against the actual block your bundle targeted, not against "did any tx of mine land somewhere."
• Inclusion rate by relay. Per-relay attribution — which relay's path delivered each successful bundle.
• Inclusion rate by time-of-day band. Different hours, different congestion, different P_inc.
• Realised vs simulated profit per included bundle. A persistent gap means sim is lying.

The "by relay" breakdown is the most actionable. After a few hundred bundles you can see which relays consistently deliver for your specific strategy and which are dead weight; reweight the fan-out toward winners.

Where to act when P_inc slips

If your measured P_inc drops 20%+ from baseline:

1. Look at relay-by-relay first. If one relay's contribution has collapsed, that relay's builder coverage has changed (lost a major builder, etc.) — drop or down-weight it.
2. Then latency. A regression in p95 latency to your relays often correlates with P_inc collapse. Cloud-provider weirdness, regional routing changes, ISP issues.
3. Then fee model freshness. During fee-regime shifts (post-fork, blob-fee era starts), a stale model under-bids for weeks until you notice.
4. Last, the strategy. Often what looks like "the strategy stopped working" is actually one of the above; investigating in this order saves time.

Improving P_inc

• Fan-out across at least four relays. Single-relay submission is leaving 30–50% of inclusion on the table.
• Refresh fee state immediately before signing. Stale fees lose contested blocks.
• Co-locate your sender in the relay's region if latency from your current location is over 150 ms.
• Use proper hints. revertingTxHashes for any tx that may revert; targetBlockNumber and maxBlockNumber to bound the inclusion window.
• Track per-relay performance and re-weight. FRB Agent does this automatically.

References

• Flashbots: understanding bundles
• Best Ethereum private RPCs
• Fixing failed bundles guide