Timeboost for Arbitrum chains
This document is currently in public preview and may change significantly as feedback is captured from readers like you. Click the Request an update button at the top of this document or join the Arbitrum Discord to share your feedback.
AEP fees will apply here in the future.
Launch details and key dates
- Status: Alpha - not formally supported yet for deployments on Arbitrum chains
- Arbitrum Sepolia: Feb 12, 2025
- Arbitrum One: April 17, 2025
- Arbitrum Nova: April 17, 2025
tldr;
Arbitrum Timeboost is a novel transaction ordering policy that can be optionally deployed and enabled for any Arbitrum chain. Timeboost allows a chain owner to capture some of the available Maximum Extractable Value (MEV) on their blockchain and reduces latency-related spamming, in exchange for a small impact on user response times (despite block times not changing). It is therefore recommended that chains only consider deploying and enabling Timeboost if there is substantial DeFi and related MEV activity (e.g. liquidations, arbitrage, backrunning) on the chain. Please read the gentle introduction to Timeboost to learn more about how Timeboost works.
As with all features on the Arbitrum stack, Arbitrum chains can adopt Timeboost at their own discretion and on their own timeline. To deploy and enable Arbitrum Timeboost on your chain, please refer to this guide on how to deploy and configure Timeboost.
Recommended adoption path
It is recommended that most Arbitrum chains do not deploy Arbitrum Timeboost, as the benefits do not outweigh the trade-offs in most cases. The primary reason behind this recommendation is based on cost and user experience considerations. The only instances in which Timeboost might make sense are for chains with significant DeFi and related MEV activity, as the potential revenue from bids may outweigh the costs and possible impact on user experience.
Again, Arbitrum chains can adopt Timeboost at their discretion and on their timeline, so this is only a recommendation.
Benefits of adopting Timeboost
Timeboost enables a chain owner to capture a portion of the available MEV on their blockchain, reducing latency-related spam while preserving the built-in protections and UX benefits that Arbitrum users have come to know and enjoy. A more in-depth overview of the benefits of Timeboost is explored in the gentle introduction to Timeboost, and also a paper on how Timeboost is more profitable for arbitrageurs compared to other forms of MEV capture, like Priority Gas Auctions (PGA) here.
Fair(er) MEV capture
Timeboost provides sophisticated actors (e.g., searchers) with the ability to purchase a fixed time advantage over a specified number of blocks to perform various MEV activities, such as backrunning, liquidations, or arbitrage. This design preserves the use of a private mempool that all Arbitrum chains have by default, and it does not impact block times. This approach protects users from harmful types of MEV (e.g., frontrunning) while maintaining the same block times.
Potential revenue capture for chain owners
The auction, run at a fixed cadence, is held off-chain. Bids can be made in any asset the chain owner designates, including custom ERC-20 tokens. Furthermore, the chain owner has full discretion over how to use the bid proceeds. For example, chain owners may decide to burn the bid proceeds or use the bid proceeds to support the chain in other ways.
It stands to reason that sophisticated actors (e.g., searchers) will bid up to the amount they believe they can profit or realize from the time advantage. Therefore, at equilibrium, one could reasonably expect that the bid proceeds will approach or equal the amount of available MEV on a Timeboost-enabled chain.
Potential reduction in latency-based spam
As explained earlier, searchers will be incentivized to bid on-chain for the time advantage, rather than spending money on off-chain hardware to win latency races. Therefore, at equilibrium, one could reasonably expect that the amount of latency-based spam should reduce on a Timeboost-enabled chain. To learn more about this phenomenon, please check out this analysis on how the Timeboost ordering policy impacts backrunning strategies: TimeBoost and Backrunning: Probabilistic Strategies.
Trade offs with adopting Timeboost
As mentioned earlier, chain owners should consider several trade-offs when deciding whether to adopt Timeboost. We will cover two of them below.
Cost
As explained in the guide on how to deploy and configure Timeboost, there are are three core components to Timeboost:
- An off-chain auctioneer (responsible for receiving and validating bids, and resolving express lane auctions),
- An on-chain smart contract (to manage the express lane auction), and
- A new configuration on the sequencer is implemented to take advantage of the express lane time.
Often times, the cost required to set up, configure, and maintain the infrastructure above (especially the auctioneer) will exceed that of the potential revenue that Timeboost brings in. Most importantly, the revenue that Timeboost can generate for the chain is not guaranteed either.
User experience
As explained in the gentle introduction to Timeboost, the Timeboost express lane time advantage is implemented by imposing an artificial delay (default: 200ms) on all non-express lane transactions whenever there is an express lane controller for a round (default: 1 minute). While Timeboost does not change the default Arbitrum blocktimes (default: 250ms), this artificial delay does mean that the average response time for a user in the non-express lane is the sum of the artificial delay and the block time of the chain. Note that this artificial delay is only applied when there is an express lane controller for a round, meaning there is no change in user experience if nobody is using Timeboost, even though it is enabled (for the duration of that round).
Configuring Timeboost's Parameters
Below is a table of the configurable parameters and how to think about adjusting their values, should you choose to deploy and enable Timeboost for your chain.
| Parameter name | Description | Considerations |
|---|---|---|
roundDurationSeconds | Time during which the sequencer will honor the express lane privileges for transactions signed by the current round’s express lane controller. Default: 60 seconds | The larger this value, the more powerful and valuable controlling the express lane will be. Higher values may incentivize more participation and demand for the express lane time advantage. |
auctionClosingSeconds | Time before the start of the next round. The autonomous auctioneer will not accept bids during this time interval. Default: 15 seconds | The larger the value, the more difficult it is for participants to predict the value of the future express lane round, and therefore, their ability and confidence in being able to place an accurate/fair bid for the time advantage. However, a value that is too small may not allow the auctioneer sufficient time to resolve the auction on time during periods of high activity. |
beneficiary | An address where proceeds from the Timeboost auction are sent to when flushBeneficiaryBalance() gets called on the auction contract. Default: An address controlled by the chain's owner | Can be any address, including the burn address, that the chain owner designates or controls. |
_biddingToken | Address of the token used to make bids in the Timeboost auction. It can be any ERC-20 token, including the gas token of the network, provided the chosen token address does not have fee-on-transfer, rebasing, transfer hooks, or otherwise non-standard ERC-20 logic. Default: WETH | This asset should ideally be liquid and easily obtainable for your auction participants. Furthermore, the less volatile this asset is, the more consistent your auction will be. |
nonExpressDelayMsec | The artificial delay applied, by the sequencer, to the arrival timestamp on non-express lane transactions before the non-express lane transactions eventually get sequenced. Default: 0.2 seconds, or 200 milliseconds | The larger this value, the greater the time advantage will be for the express lane controller, making it easier for the express lane controller to capture MEV opportunities (e.g., backrunning, liquidations, or arbitrage) and therefore the more valuable. However, increasing this value comes at the expense of slower response times for user transactions in the non-express lane. |
reservePrice | The minimum bid amount accepted by the auction contract for Timeboost auctions, denominated in _biddingToken. Default: None | This value should be left empty and only be changed to raise the minimum bid post-deployment of the auction contract (see below). |
_minReservePrice | A value that must be equal to or below the reservePrice to act as a "floor price" for Timeboost bids. Enforced by the auction contract. Default: 0.001 WETH | A value that is low enough to make the auction worth while participating in, but not high enough to pose a significant barrier to entry (i.e. ideally, chain owners will want a fair, competitive market for the timeboost time advantage). This value can also be set high such that if someone does bid, the bid proceeds could offset some of the costs spent on running the autonomous auctioneer. |