Arbitrum Playbook: Reliable Private Bundle Execution

Answer first — On Arbitrum One, private bundle execution does not work the way it does on Ethereum mainnet. Arbitrum has no public mempool: every transaction goes directly to the centralised sequencer operated by Offchain Labs. Reliable execution in 2026 means three things working together — bidding into the Timeboost express lane when the trade margin justifies sub-block priority, submitting through a low-latency endpoint (private commercial RPC or your own Nitro node) instead of a pooled public RPC, and gating every send with fork simulation so you catch L2-specific revert paths and gas-oracle surprises before they cost real ETH. There is no eth_sendBundle here — atomicity comes from packing your route into a single transaction or contract call that reverts on partial failure.

Mastery path

• Arbitrum MEV latency & routing
• Base MEV strategies
• Optimism execution playbook
• Lowest-latency Reth RPC for MEV

What "private bundle" actually means on Arbitrum

The phrase is borrowed from Ethereum mainnet, where Flashbots and MEV-Share let you submit a sealed transaction set that bypasses the public mempool and lands atomically with the next block. Arbitrum does not have a public mempool to bypass. Transactions skip directly to the sequencer.

So when a searcher says "private bundle on Arbitrum," what they need is usually:

1. Speed to the sequencer — milliseconds still matter, but the leverage shifts from frontrunning the mempool to being the first one accepted by the sequencer in a given window.
2. Atomicity inside one transaction — multi-leg trades must be encoded as a single contract call (a custom executor contract) that reverts on partial failure, not as two separate top-level sends.
3. Order priority through Timeboost — paying for the express lane when round-economics justify it.

Timeboost: the priority mechanism that replaced PGA

Arbitrum's Timeboost launched in 2024 and is now the primary tool for fee-priority MEV on the chain. The mechanics that matter for searchers:

• Searchers bid in a sealed-bid auction for control of an "express lane" that is sequenced first within a short rolling window.
• The auction runs on a continuous schedule — you bid per round, not per transaction.
• Losing the auction does not mean your transaction fails. It means you are sequenced after the express-lane winner during that round.

Practical implication: build a round-economics model, not a per-trade model. A round of express-lane control costs the auction-clearing price; the profitable opportunities you see during that round must collectively cover that price plus gas to make bidding worthwhile. Most amateur Arbitrum operations bid blindly per-trade and bleed the auction premium.

The sequencer feed is where the signal lives

Arbitrum publishes a sequencer feed over WebSocket. The feed broadcasts every transaction the sequencer has accepted before it lands in a confirmed L2 block. This is your closest analogue to Ethereum's mempool.

Two things to internalise:

• A transaction visible in the feed is already accepted by the sequencer. You cannot frontrun it. You can only backrun, by submitting a follow-up transaction quickly enough that it sequences in the same window.
• For latency-sensitive backruns, co-locate your feed subscriber in the same region as the sequencer endpoint. Cross-region latency wipes most backrun opportunities outright.

The feed is read-only. Writes still go through your normal RPC endpoint.

Endpoint selection in 2026

If you are doing serious volume, the answer is to run your own Nitro node and subscribe to the feed locally. Below roughly $5,000/day of attributable opportunity, a tier-2 commercial private RPC is the sane choice. Use the WSS latency test to benchmark candidate endpoints from your actual deployment region before committing.

Pre-trade simulation

There is no eth_callBundle equivalent on Arbitrum. The closest substitute is an Arbitrum fork in Anvil or Foundry (anvil --fork-url <arb-rpc>), where you replay the candidate transaction against current state and inspect the revert reason and post-state.

This step matters more than on Ethereum because Arbitrum's gas oracle is not identical to L1 EIP-1559 — calldata pricing comes from the parent chain and can spike independently of L2 conditions. The FRB Agent simulator runs an Arbitrum fork locally before every candidate send for exactly this reason.

Runbook: shipping a reliable Arbitrum trade

1. Verify endpoint health. Round-trip eth_blockNumber against your selected RPC; reject the route if p95 latency exceeds your threshold.
2. Subscribe to the sequencer feed. Confirm you are receiving accepted-tx broadcasts at the expected steady cadence — staleness over ~500 ms means every opportunity you see is already taken.
3. Simulate against an Arbitrum fork. Replay the candidate path; reject unless the simulated profit clears gas + Timeboost bid (if applicable) + safety margin.
4. Choose a lane. Trades above your round-economics threshold go through the express lane. Below it, submit through your private RPC at a competitive priority fee.
5. Set a budget cap per send. Arbitrum confirms in ~250 ms. If your transaction is not sequenced within ~2 expected blocks, kill the path and re-evaluate — do not retry blindly.
6. Log every outcome. Sequence number, gas paid, realised vs simulated PnL, latency to inclusion. Feed the result back into filter ranking so the next round prioritises higher-yield paths.

Common failure modes

• Sequencer outage. Arbitrum's centralised sequencer has had multi-hour outages historically. Maintain a fallback that submits through the delayed inbox on L1 — slower confirmation and higher cost, but censorship-resistant.
• Calldata-cost surprise. L1 calldata fees can briefly make Arbitrum routes uneconomic during ETH gas spikes. Gate the send on a fresh fee estimate, not a stale one cached from minutes ago.
• Stale feed subscriber. If your WebSocket subscriber falls behind, every "opportunity" you see is already executed. Detect staleness and force-reconnect rather than continuing to act on dead signal.
• Atomicity assumed but not enforced. Two separate top-level sends can be sequenced apart. If your strategy relies on both legs landing together, encode both legs into one contract call that reverts on partial fill.

When private RPC is the wrong question

Searchers often reach for "private RPC" on Arbitrum out of habit because that's the right answer on Ethereum. On Arbitrum the right question is usually "how do I get earlier into the sequencer's queue?" The tools for that are Timeboost, low-latency endpoints, and tight single-tx encoding — not bundle relays.

References

• Arbitrum Timeboost documentation
• Running an Arbitrum Nitro node
• Arbitrum sequencer & forced inclusion