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.

Chain-Specific Inclusion Characteristics

P_inc mechanics differ substantially across chains — the same strategies used to improve inclusion on Ethereum don't always translate directly.

Ethereum (12-second slots): The multi-builder PBS ecosystem means builder coverage is the dominant factor. With Flashbots + Titan + beaverbuild fan-out, coverage reaches 90%+. The second factor is the competitive bid level — Ethereum has the most active searcher market, so fee competitiveness matters more here than on any other chain.

Solana (sub-second slots): Jito Block Engine bundles go directly to validator leaders via tip-based ordering. P_inc on Solana is largely determined by whether you're submitting to enough regional Jito endpoints (NY, Frankfurt, Tokyo, Amsterdam) and whether your tip is at or above the current 80th-percentile cleared tip. Builder coverage as a concept doesn't apply — there's no builder intermediary.

Arbitrum and L2s: Sequencer-based inclusion means your P_inc window is narrower. The sequencer processes transactions in arrival order within its queue (~100–250ms batching delay). Fan-out doesn't help the same way it does on Ethereum because there's only one sequencer. Latency to the sequencer is the primary lever.

BNB Chain: No mature private relay equivalent. P_inc improvements come almost entirely from direct-to-validator submission and competitive priority fees. Multi-relay fan-out has limited benefit — most inclusion happens through the standard mempool path.

The key takeaway: don't carry your inclusion optimization strategy across chains. What raises P_inc on Ethereum (more relays) doesn't directly translate to Solana (more regional endpoints), and neither translates to Arbitrum (lower latency to sequencer).

References

• Flashbots: understanding bundles
• Best Ethereum private RPCs
• Fixing failed bundles guide
• Profitability vs Risk: Gas & Budget Caps
• Mempool Scanning, Filters & Latency