Skip to main content

Why choose to enable Timeboost for your Arbitrum chain

Enabling Timeboost refers to activating a novel transaction ordering policy that modifies the default first-come-first-served (FCFS) mechanism to allow chain owners to capture a portion of Maximum Extractable Value (MEV) through timed auctions. This protocol introduces an "express lane" where auction winners gain a temporary time advantage (default 200ms) for submitting transactions, enabling them to potentially extract MEV (e.g., arbitrage or liquidations) more efficiently, while proceeds from the auction flow to the chain owner or designated beneficiary. Timeboost is designed to reduce latency-based spam from MEV searchers (who might otherwise invest in hardware for speed advantages) and preserve user protections against harmful MEV, such as frontrunning or sandwich attacks, by maintaining a private mempool and not granting reordering rights. It does not create new MEV types but adjusts how existing MEV is accessed and monetized.

Enabling it is an owner-level decision, typically for chains with significant DeFi activity where MEV opportunities justify the trade-offs, and it can be done without halting operations (falling back to FCFS if no auction winner).

It's ideal for DeFi-heavy chains with substantial MEV (e.g., arbitrage opportunities), as low-MEV chains may see costs outweigh benefits. Once enabled, searchers bid continuously (predicting MEV 15s-1m15s ahead), and users experience a minor delay on non-express transactions (~450ms average soft finality vs. ~250ms), but with no impact if no winner.

Key Concepts​

  • MEV in Arbitrum: MEV refers to the profit extractable from transaction ordering, such as through arbitrage, liquidations, or backrunning. Under default FCFS, MEV often goes to searchers via latency races (e.g., faster hardware), leading to network spam and no revenue for the chain. Timeboost internalizes this by auctioning a time-based edge, diverting competition to bids while limiting harmful MEV via no reordering or visibility into other transactions.
  • Express Lane: A special sequencer endpoint (timeboost_sendExpressLaneTransaction) where the auction winner (controller) can submit transactions without an artificial delay. Non-express transactions get a default 200ms delay added to their arrival timestamp, potentially pushing them to the next block (but block times remain ~250ms). The controller gets no guarantees of top-of-block positioning or profitability—value comes from predicted MEV during the round (default 60s).
  • Offchain Auction: A sealed-bid, second-price auction (winner pays the second-highest bid) run by an autonomous auctioneer every round. Bids use a configurable ERC-20 token (e.g., WETH; no fee-on-transfer or rebasing tokens) and must meet a minimum reserve price (default 0.001 WETH). Auctions close 15s before the round starts, with bids verifiable on-chain. Limit of 5 bids per address per round to prevent DDoS.
  • Auction Contract: Deployed on-chain, it handles deposits (withdrawable after ~2 minutes), bid resolution, and proceeds transfer to a beneficiary (e.g., chain owner or burn address) via flushBeneficiaryBalance().

Compatibility​

Works with any Arbitrum chain (L2/L3), all DA modes (Rollup, AnyTrust, Alt-DA), gas tokens (native ETH or custom), and validation (BoLD or permissioned). Compatible with centralized or future decentralized sequencers; no prerequisites beyond a bid token and infrastructure. Not formally supported yet.

Pros​

  • Revenue generation for chain owners. Proceeds can fund ecosystems or burn tokens.
  • Reduces spam/congestion from latency races; fairer, predictable MEV access for searchers.
  • Maintains security (no harmful MEV increase) and fast blocks; open auctions prevent monopolies.

Cons​

  • Adds ~200ms delay to non-express user transactions (~450ms average response), potentially impacting UX.
  • Setup/maintenance costs (e.g., auctioneer servers, Redis) may exceed revenue on low-MEV chains.
  • No guaranteed revenue; ineffective without MEV activity. Minor risks like bid limits for DDoS mitigation.

Examples​

  • Arbitrum One and Nova: Generates revenue from MEV auctions while protecting users.
  • Custom Orbit Chains: DeFi-focused L3s enable it for revenue (e.g., using custom tokens for bids), while low-activity chains skip it.

How to configure​

  1. Deploy Auction Contract: Use Orbit scripts (e.g., from orbit-actions repo) with a .env file specifying addresses (e.g., proxy admin, bid token like WETH, beneficiary). Run forge script to deploy and verify.
  2. Run Auctioneer Services: Set up Redis for coordination; run bid validator (verifies bids) and auction server (resolves auctions) using the autonomous-auctioneer binary from Nitro (Docker or local build).
  3. Configure Sequencer: Update node config to enable timeboost and auctioneer APIs, pointing to the contract and Redis.
  • Verify via logs (e.g., "New express lane auction round") and test bids/submissions.
  • Post-enable, adjust parameters like round duration (60s default) or delay (200ms) via owner privileges.

This feature enhances Arbitrum's modularity for MEV-aware chains but requires careful evaluation. For details, consult the official docs, or your RaaS; a list of RaaSes is on the Third-party providers page.