Mempool Scanning 101: Filters, Latency & Inclusion

Answer first — Mempool scanning in 2026 is two distinct problems: getting clean signal in (low-latency subscription + filters that don't kill recall) and acting on it inside the available window (simulation + signing + send fast enough to land before the next searcher). Most operators over-tune the filters and under-tune the action loop, which is the wrong direction — a well-filtered stream that you process slowly is just a different kind of useless. The working framework: subscribe to a well-peered node (eth_subscribe('newPendingTransactions') on chains that have a public mempool, sequencer-feed WSS on Arbitrum, op-node gossip on OP Stack chains); apply minimum filters (pool allowlist, value floor, router allowlist); profile every stage of your loop until you know where the milliseconds are going. Then iterate on whichever stage is the worst offender — it's almost never the filter set.

Mastery path

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

"Mempool scanning" doesn't mean the same thing on every chain

The term is borrowed from Ethereum mainnet where there's a literal peer-to-peer broadcast layer. On other chains the mechanism is different and the term is sloppy:

• Ethereum, BSC, Polygon, Avalanche, etc. — real public mempool. eth_subscribe('newPendingTransactions') against any well-peered node gives you the live stream.
• Arbitrum — no public mempool. The equivalent signal is the sequencer feed WebSocket, which broadcasts accepted txs before they land in confirmed blocks.
• Optimism, Base — no Ethereum-style public mempool, but the sequencer accepts JSON-RPC sends and gossips them; a well-connected op-node sees them via standard subscription.
• Solana — no mempool concept; transactions are forwarded directly to validators. The "scanning" job is more about Geyser plugin streaming or block-engine subscriptions.

What you subscribe to and what counts as "an opportunity in the mempool" depends on which chain you're on. The latency budgets and filter shapes follow accordingly.

The filter-recall trade-off

The intuition trap: "tighter filters → less noise → faster decisions → better inclusion." It's wrong because filters don't reduce processing latency — they reduce opportunity recall.

A filter that drops 90% of pending txs makes your decision loop run on 10% of the data. If your filter is over-tight, you're missing real opportunities to avoid noise that wouldn't have made you slower anyway. The right calibration is:

1. Pool allowlist: the pools your strategy actually trades. New ones added explicitly, not by inference.
2. Value floor: below this trigger-tx size, the math doesn't work for backruns no matter what. (Below ~$1k notional on Ethereum, ~$200 on cheap chains.)
3. Router allowlist: the routers your strategy can actually compose with. Token-attached or unfamiliar routers go to a separate "research" stream, not the main hot path.

That's it for hot-path filters. Anything more aggressive is over-tuning that costs recall.

The latency budget

Decompose total time-from-trigger-to-send into stages and profile each:

If any one of these is in the "typical bad" range, that's where to optimise — not your filter set. The state-fetch stage is the most common hidden offender; many bots fetch state via per-tx round-trip JSON-RPC calls when they could be maintaining a local mirror that updates from the same WSS subscription.

Inclusion vs false positives

Two separate metrics, often conflated:

• Inclusion rate: of bundles I submitted, what fraction landed? Below 60% on a strategy that expects 80%+ is an infra problem (latency, fee model, builder coverage).
• False positive rate: of mempool events that passed my filter, what fraction turned out to not be real opportunities? High false-positive doesn't matter as long as the downstream simulator catches them — it just means your filter is loose. Loose filter is fine; expensive downstream is the problem.

Operators sometimes tighten filters to chase the wrong metric. If your inclusion rate is low, the answer is rarely a tighter filter.

What to measure

Per-strategy daily numbers to keep:

• Subscription staleness alarms (events older than 500 ms threshold).
• Per-stage latency percentiles (above table's stages).
• Filter pass rate (events passing per minute).
• Profitable post-sim rate (passed sim per minute).
• Submitted-to-included rate.
• Inclusion-by-relay (for chains with multi-relay).

These six numbers, on a daily dashboard, tell you where the bot is healthy and where it's losing. Without them, debugging is guesswork.

Common scanning mistakes

• Single subscription, no cross-check. A second subscription against a different provider validates that you're seeing what's actually on the network. Without it, silent missed coverage looks like "the strategy isn't finding opportunities."
• WSS reconnect storms wiping subscription state. Some providers reset connections every 30–60 minutes for load balancing. If your subscriber doesn't replay subscriptions on reconnect, you'll miss seconds at a time.
• JSON parsing on the hot path. Naïve JSON.parse of full pending-tx envelopes adds milliseconds per event. Streaming parsers that pull only the fields you need (to/from/value/data prefix) save real time at peak rates.
• Cross-region subscription that quietly halves the edge. A "redundant" setup that fails over from us-east to ap-southeast adds 100+ ms each direction. Alarm on latency, not just on hard failures.
• Trusting one provider's coverage without validation. Especially on BSC, some commercial providers have weakly-peered nodes that lag silently. Cross-check periodically.

Working configuration

The minimum viable mempool subscriber:

1. Two parallel WSS subscriptions (provider A + provider B), used for cross-coverage validation.
2. Filter set: pool allowlist + value floor + router allowlist. No deeper filtering on the hot path.
3. State maintained as a local mirror updated from the WSS stream itself, not re-fetched per-tx.
4. Latency profiling instrumented per stage with percentiles persisted daily.
5. Reconnect-with-replay logic that re-subscribes within 200 ms of disconnect.

The FRB Agent implements all of these by default; the parts that matter for self-built systems are the same regardless.

References

• Reth WSS subscription guide
• Arbitrum sequencer feed
• WSS latency test tool