A gentle Introduction: Timeboost

Arbitrum Timeboost is a novel transaction ordering policy for Arbitrum chains that enables chain owners to capture the Maximal Extractable Value (MEV) on their chain, reduce spam, and preserve fast block times, all while protecting users from harmful types of MEV, such as sandwich attacks and front-running.

Timeboost is the culmination of over a year of research and development by the team at Offchain Labs. It is currently live on Arbitrum One and Arbitrum Nova, and is available for Arbitrum Orbit chains, whose owners can adopt and customize it as they choose.

Why do Arbitrum chains need Timeboost?

In the past, Arbitrum chains ordered incoming transactions on a "First-Come, First-Serve (FCFS)" basis. This ordering policy is simple to understand and implement, enabling fast block times (starting at 250ms and down to 100ms if desired), and protecting users from harmful types of MEV, such as front-running & sandwich attacks.

However, there are a few downsides to an FCFS ordering policy. Under FCFS, searchers have incentives to participate in and attempt to win latency races by investing in offchain hardware. This "race" means that for searchers on Arbitrum chains, generating a profit from arbitrage and liquidation opportunities involves a lot of spam, placing stress on the chain infrastructure and contributing to congestion. Additionally, all captured MEV on an Arbitrum chain under FCFS is allocated to searchers, returning none of the available MEV to the chain owner or the applications on the chain.

What is Timeboost

Timeboost retains most FCFS benefits while addressing FCFS limitations.

Timeboost is a transaction ordering policy. It's a set of rules that the sequencer of an Arbitrum chain is trusted to follow when ordering transactions submitted by users. In the near future, multiple sequencers will be able to enforce those rules with decentralized Timeboost.

For Arbitrum chains, the sequencer’s sole job is to take arriving, valid transactions from users, place them into an order dictated by the transaction ordering policy, and then publish the final sequence to a real-time feed and in compressed batches to the chain’s data availability layer. Before Timeboost, the transaction ordering policy was FCFS, and Timeboost is a modified FCFS ordering policy.

Timeboost preserves the great UX that Arbitrum chains are known for

• The default block time for Arbitrum chains continues to be industry-leading at 250ms, even with Timeboost. With Timeboost, some transactions not in the express lane may experience a delay to the next block.

With Timeboost, Arbitrum chains will continue to protect users from harmful types of MEV

• Timeboost only grants the auction winner a temporary time advantage - not the power to view or reorder incoming transactions or to be the first in every block. Furthermore, the transactions' mempool will continue to be private, which means users with Timeboost enabled will remain protected from harmful MEV-like front-running and sandwich attacks.

Timeboost unlocks a new value accrual path for chain owners

• Chain owners may use Timeboost to capture a portion of the available MEV on their chain that would have otherwise gone entirely to searchers. There are many flavors of this, too—including custom gas tokens and/or redistribution of these proceeds back to the applications and users on the chain.

Timeboost may help reduce spam and congestion on a network

• By introducing the ability to “purchase a time advantage” through the Timeboost auction, it is expected that rational, profit-seeking actors will spend on auctions instead of investing in hardware or infrastructure to win latency races. We expect that this diversion of resources will reduce FCFS MEV-driven spam on the network.

How does it work?

Timeboost uses three separate components that work together:

• A special “express lane” which allows valid transactions to be sequenced as soon as the sequencer receives them for a given round.
• An offchain auction to determine the controller of the express lane for a given round. This auction gets managed by an autonomous auctioneer.
• An auction contract deployed on the target chain to serve as the canonical source of truth for the auction results and handling of auction proceeds.

To start, the default duration of a round is 60 seconds. Transactions not in the express lane will be subject to a default 200-millisecond artificial delay in their arrival timestamp before being sequenced, which means that some non-express lane transactions may be delayed to the next block. It’s important to note that the default Arbitrum block time will remain at 250 milliseconds (which can be adjusted to 100 milliseconds if desired). Let’s dive into how each of these components works.

The express lane

The express lane implementation uses a special endpoint on the sequencer, formally titled timeboost_sendExpressLaneTransaction. This endpoint is special because transactions submitted to it will be sequenced immediately by the sequencer, hence the name "express lane." The sequencer will only accept valid transaction payloads to this endpoint if they are signed correctly by the current round’s express lane controller.

Transactions submitted to the sequencer normally will be considered non-express lane transactions and will, therefore, have their arrival timestamp delayed by 200 milliseconds. It is important to note that transactions from both the express and non-express lanes will eventually get sequenced into a single, ordered stream of transactions for the sequencer to post to a data availability layer (and for node operations to construct the chain's state then). The express lane controller does not:

• Have the right to reorder transactions.
• Have a guarantee that their transactions will always be first at the “top-of-the-block.”
• Guarantee a profit at all.

The value of the express lane will be the sum of how much MEV the express lane controller predicts they can extract during the upcoming round (i.e., MEV opportunity estimates made before the auction closes) plus the amount of MEV extracted by the express lane controller while they are in control (that they otherwise did not predict). Understanding how the value of the express lane is determined can be useful for chain owners when adjusting to the artificial delay and the time before the auction closes.

The Timeboost auction

Determining control of the express lane in each round (default: 60 seconds) happens by a per-round auction, which is a sealed-bid, second-price auction. This auction occurs to determine the express lane controller for the next round. In other words, determining the express lane controller can happen at any point in time in the previous auction round. Bids for the auction can be made with any ERC-20 token, in any amount, and can be collected by any address—at the full discretion of the chain owner.

The auction for a round has a closing time that is auctionClosingSeconds (default: 15) seconds before the beginning of the round. This closing time means that, in the default parameters, parties have 45 seconds to submit bids before the auction will no longer accept bids. In the 15 seconds between when bidding is over and when the new round begins, the autonomous auctioneer will verify all bids, determine the winner, and make a call to the on-chain auction contract to formally resolve the auction.

Auction contract

Before placing a bid in the auction, a party must deposit funds into the Auction Contract. At any time, you can make a deposit or add additional funds to an existing deposit. These deposits are fully withdrawable, with a nominal delay (two rounds or two minutes by default), to prevent impacting the outcome of an existing round. There is no minimum deposit amount, but a starting minimum bid of 0.001 WETH (the default amount and token) is required, known as the "minimum reserve price".

The chain owner sets the minimum reserve price, which can be updated at any time up to 30 seconds (default) before the start of the next round, ensuring that auction participants always know the reserve price at least 30 seconds before they must submit their bids. A reserve price can also be set by the chain owner (or by an address designated by the chain owner) as a way to raise the minimum bid, as the Auction Contract enforces that the reserve price is never less than the minimum reserve price.

Once the autonomous auctioneer determines an auction winner, the Auction contract will deduct the second-highest bid amount from the account of the highest bidder and transfer those funds to a beneficiary account designated by the chain owner by default. The expressLaneControllerAddress specified in the highest bid will become the express lane controller for the round.

Default parameters

Below are a few of the default Timeboost parameters mentioned earlier. All these parameters and more are configurable by the chain owner.

Parameter name	Description	Recommended default value
roundDurationSeconds	Duration of time that the sequencer will honor the express lane privileges for transactions signed by the current round’s express lane controller.	60 seconds
auctionClosingSeconds	Time before the start of the next round. The autonomous auctioneer will not accept bids during this time interval.	15 seconds
beneficiary	Address where proceeds from the Timeboost auction are sent to when flushBeneficiaryBalance() gets called on the auction contract.	An address controlled by the chain's owner
_biddingToken	Address of the token used to make bids in the Timeboost auction. It can be any ERC-20 token (assuming the token chosen does not have fee-on-transfer, rebasing, transfer hooks, or otherwise non-standard ERC-20 logic).	WETH
nonExpressDelayMsec	The artificial delay applied to the arrival timestamp of non-express lane transactions before the non-express lane transactions are sequenced.	0.2 seconds, or 200 milliseconds
reservePrice	The minimum bid amount accepted by the auction contract for the current Timeboost auction, denominated in _biddingToken.	None
_minReservePrice	A value that must be equal to or below the reservePrice to act as a "floor minimum" for Timeboost bids. Enforced by the auction contract.	0.001 WETH

Who is Timeboost for, and how do I use it?

Timeboost is an optional addition to an Arbitrum chain’s infrastructure, meaning that enabling Timeboost is at the discretion of the chain owner and that an Arbitrum chain can fully function normally without Timeboost.

When enabled, Timeboost serves different groups of parties with varying degrees of impact and benefits. Let’s go through them below:

For regular users:

Timeboost will have a minimal impact. Non-express lane transactions will experience a nominal delay of 200ms, which means that, to the average user, their transactions will take approximately 450ms to be sequenced and included in a block (up from approximately 200ms). All users will remain protected from harmful MEV activity, such as sandwich attacks and front-running, through the continued use of a private mempool.

For chain owners:

Timeboost represents a unique way to accrue value for its token and generate revenue for the chain. Explicitly, chain owners can set up their Timeboost auction to collect bid proceeds in the same token used for gas on their network and then choose what to do with these proceeds afterward.

For searchers/arbitrageurs:

Timeboost adds a unique twist to your existing or prospective MEV strategies that may become more profitable than before. For instance, purchasing the time advantage offered by Timeboost’s auction may end up costing less than the costs of investing in hardware and winning latency races. Another example is the potential new business model of reselling express lane rights to other parties on a time slot or per-transaction basis.

Special note on Timeboost for chain owners

As with many new features and upgrades to Arbitrum Nitro, Timeboost is an optional feature that chain owners may choose to deploy and customize however they see fit. Deploying and enabling/disabling Timeboost on a live Arbitrum chain will not halt or impact the chain but will instead influence the chain's transaction ordering policy. An Arbitrum chain will, by default, fall back to FCFS in scenarios where Timeboost is deployed but disabled, or if there is no express lane controller for a given round.

We recommend that Arbitrum chains holistically assess the applicability and use cases of Timeboost for their chain before deploying and enabling Timeboost. This assessment is necessary because some Arbitrum chains may not have that much MEV (e.g., arbitrage) to begin with. Furthermore, we recommend that Arbitrum chains start with the default parameters recommended by Offchain Labs and closely monitor the results and impacts on their chain’s ecosystem over time before considering any adjustments to the parameters.