Timeboost FAQ

What's an ELI5 on Timeboost?

Timeboost is a new transaction ordering policy for Arbitrum chains where any participant can bid for the right to have their transactions sequenced slightly faster than other transactions.

Notably, user transactions will remain private until they are sequenced, meaning no one can front-run or sandwich other users. Timeboost bid proceeds are collected by the Arbitrum DAO in either ETH or ARB, depending on DAO approval.

As a typical user, will I notice any difference in my experience?

The only difference users should experience is a slight delay when submitting their transactions. The default configuration for this delay is 200ms, and the DAO can change it.

This delay gives the express lane controller an advantage, as they can include transactions slightly quicker than others. Importantly, user transactions will remain private until they are sequenced, meaning that the Express Lane Controller cannot frontrun or sandwich other users.

Where does the Timeboost income stream come from?

Timeboost employs a sealed bid and second-price auction to assign the rights to a winner to control the express lane, giving the winner an advantage for transaction inclusion and allowing them to capture arbitrage and backrunning opportunities. Proceeds from the auction are at the discretion of the Arbitrum DAO, with two main options outlined in the proposal: collecting bids in ETH or collecting bids in ARB.

What is the difference between the two options above?

This AIP proposes two main options the community can vote on if it adopts Timeboost. Governance can change these options at any time.

• Option 1: Collect bids in ETH and send the proceeds to the DAO treasury.
• Option 2: Collect bids in ARB and burn the proceeds.

Depending on which option the Arbitrum DAO chooses, the auction contract can transfer the proceeds to a designated account or burn them. As of Sept 19, 2024, the Arbitrum DAO has signaled a preference for Option 1 (collecting bids in ETH) in the temperature check vote on Snapshot here.

How can I participate in Timeboost directly?

Interested parties can participate in the Timeboost auctions by depositing funds in the auction contract and sending bids to the autonomous auctioneer. We will have docs with more information.

The Timeboost auction is open to everyone; however, since auctions require a non-zero bid to win, we believe that only parties who can return from capturing arbitrage opportunities, backrunning opportunities, or reselling the express lane rights will benefit from participating.

The Timeboost protocol works behind the scenes with minimal impact on regular users while generating revenue for the Arbitrum DAO and opening up an additional revenue stream for sophisticated searchers.

How much estimated revenue will this drive to the DAO?

Estimating how much revenue Timeboost will generate is complex and is based on many factors. There are no ways to confidently estimate the amount of arbitrage or backrunning opportunities that currently exist or will exist on Arbitrum chains in the future. The expectation is that the revenue will be significant on Arbitrum One due to the high amount of DeFi activity.

What is the goal of Timeboost?

e, all while preserving best-in-class user experience with both fast block times and protecting users from harmful MEV (e.g., front-running/sandwich attacks).

Any proposed change, technical or otherwise, to Arbitrum One and Nova should prioritize ensuring the best user experience and optimal chain functioning ahead of other priorities. Timeboost explicitly embodies this principle in 3 ways:

1. Arbitrum One and Nova block times will remain industry-leading at 250ms even after Timeboost. What will change with Timeboost is that some transactions, specifically those not in the express lane, will be delayed to the next block. If there is an Express Lane controller for a given round, users will wait, at most, 450ms for their transactions to be sequenced (200ms proposed delay, plus 250ms block time). Furthermore, the time for a user's transaction to be sequenced will fall back to 250ms (or 100ms for Orbit chains) if there is no express lane controller. All of these values for Arbitrum One and Nova, both the block time and the nominal delay for non-express lane transactions, are controlled by governance and are far shorter than the block times seen on other child chains and even rival alternative parent chains (like Solana's 400ms block times).

2. Timeboost is purely supplemental to Arbitrum chains. The chain will fall back to the current FCFS ordering policy if (1) Timeboost is turned "off" (trivial, controlled by governance) or (2) if there is no express lane controller for the given round.

3. With Timeboost, the mempool for transactions will continue to be private, which means user protections will continue from harmful MEV-like front-running and sandwich attacks, ensuring a great user experience.

Does it work with Orbit chains?

Orbit chains can adopt Timeboost, and Orbit chain owners can also choose to use any ERC20 token for making bids. For example, a chain could accept its token for the auction.

How does Timeboost affect Orbit chains that settle to Arbitrum One or Arbitrum Nova?

will introduce a (proposed) 200 ms delay on non-express lane transactions and grant a time advantage/privilege of immediate sequencing of transactions sent by the auction winner. This delay is a new Transaction Ordering Policy at the Sequencer level, and, as with many other Nitro tech features, this will be available for Orbit chains to adopt, including those that settle on Arbitrum One or Arbitrum Nova.

However, there's probably no meaningful time advantage for the L3's batched transactions data or assertion here. There could be a world where an Orbit chain is incredibly time-sensitive and participates in the Timeboost auctions because they want a faster confirmation that their data and/or assertion gets sequenced on the parent chain. Still, we're talking about a 200 ms difference between the non-express and express lanes.

Does this vote to pass automatically mean that all orbit chains will have Timeboost implemented?

No, Timeboost implementations are at the sequencer level, so if the DAO passes this vote, Timeboost will roll out to the sequencer for Arbitrum One and Nova. This approach is the same strategy for ArbOS upgrades since Orbit chains can choose to adopt Timeboost if they want to - of the voting outcome for adoption on Arbitrum One and Nova.

Technically, the vote passing will mean Orbit L3s settling to Arbitrum One, and Nova will have their batched transaction data and assertions in the parent chain's non-express lane or express lane. Still, Orbit teams can decide whether they want their Orbit chain's sequencer to implement Timeboost. Your chain, your rules.

Does it mean we expect searchers to bid continuously in advance, expecting opportunities to happen 1 minute later, rather than "in real time" opportunities (I see something → I submit an arbitrage tx with priority)?

Before answering this question, it is worth clarifying that the participant will likely attempt to predict the amount of MEV generated between 15s and 1min 15s in the future - not 1 minute later. This prediction is because the auction is closed and resolved at a maximum of 15 seconds before the start of the next round (in the current proposal).

Participants will bid continuously for the right to use the express lane in advance so that they (the participant) can profit from both (1) MEV opportunities they predict between 15s and 1min 15s in the future and (2) MEV opportunities in real-time during the period that the participant is in control of the express lane that they didn't otherwise predict in advance (proposed duration: 1 minute). If the participant does not win control of the express lane, opportunities that they see in real-time are still exploitable, but with a 200ms delay like all other txs (since only the express lane controller's transactions get sequenced with no delay).

When it comes to the implementation and integration, are there any references to Fastlane?

We acknowledge FastLane's work and the perceived similarity in approach. We believe the design of Timeboost is fundamentally different from FastLane's design. We further believe that both designs aim to solve different problems. We understand that FastLane sold advantage separately for each AMM market and in peer-to-peer transaction propagation. Timeboost, on the other hand, sells an advantage in transaction inclusion timing and, therefore, sells the opportunity to profit from MEV altogether.

Delphi Research, a member of the Arbitrum Research and Development Committee (ARDC), has published a great article comparing the transaction ordering policies of various solutions on child chains, including Timeboost, Optimism's Priority Gas Auctions (PGA), Polygon's FastLane, and OEV Network. Here is the link if you're curious to learn more!

Will the changes [the special rights being asked to be granted to the current sequencer operator] be made without community discussion or through on-chain voting?

This AIP is proposing that the current sequencer operator has the autonomy to make the following changes only in circumstances where doing so would enhance Timeboost's long-term stability, preserve or improve the user experience for those using Timeboost-enabled Arbitrum chains, increase the security posture, resiliency, or stability of the chain, and/or otherwise help increase revenue for the ArbitrumDAO.

Although Timeboost improves the fairness of the network, the complicated sorting mechanism may affect the transaction experience of some users. It is recommended that Timeboost be implemented with a clearer user interface that allows users to understand the logic of how their transactions are sorted, as well as an optional setting to adjust the sensitivity to the time factor. Are there efforts to address this?

On having a clearer user interface:

• Users can subscribe to the sequencer feed to view, in real-time, the final order of transactions. This sequencer feed is usable today and in a world where the DAO adopts Timeboost (should the vote pass). Arbitrum chains currently operate with a single sequencer with no public mempool. Today, the logic used to sort transactions is "first-come-first-serve" or FCFS.
• With Timeboost, the logic changes so that transactions signed by the express lane controller get sequenced immediately (similar to FCFS), while other types of transactions get sequenced with a 200ms (proposed) delay. We believe using the sequencer feed is a sufficient solution for helping users understand the logic behind sorting their transactions. Documentation and diagrams will be forthcoming to help illustrate this workflow.
• On having an optional setting to adjust the sensitivity to the time factor: In this proposal, the ArbitrumDAO can, via governance, change the amount of time that non-express lane transactions get delayed. This parameter, defined as the NonExpressDelayMsec, is denominated in milliseconds and is proposed to be 200ms to start.

Will there be a testnet for Timeboost?

Timeboost will be rolled out on private testing-focused devnets and public testnets like Arbitrum Sepolia before Arbitrum One and Nova.

What are the different variations of Timeboost?

Timeboost is implemented via changes to the sequencer to add an express lane. An autonomous auctioneer service gets deployed to facilitate the auction (sealed-bid, second-price) for temporary rights to control said express lane.

Other variations of Timeboost are possible but have not yet been fully designed or developed. These are setups where the sequencer is decentralized but uses a trusted single autonomous auctioneer service or another setup where the sequencer is decentralized and the autonomous auctioneer is trustless (potentially through decentralization or by other means).

The current proposal before the ArbitrumDAO is to implement Timeboost with a centralized sequencer and a single, trusted autonomous auctioneer, which we can define as "Centralized Timeboost." This decision to propose Centralized Timeboost now, without those other variations being ready for production, was made to deliver a form of Timeboost earlier to quickly gather and iterate on feedback received from the market.

Will Timeboost work with future decentralized Arbitrum Sequencers?

Yes. Timeboost is compatible with the current centralized sequencer and a future design that allows Arbitrum chains to benefit from a decentralized group of sequencers. The current proposal will enable us to deliver Timeboost sooner rather than waiting until the decentralized sequencer design and implementation are complete.

Will there be plans for a clean user interface that allows users to understand the logic of how their transactions are sorted, as well as an optional setting to adjust the sensitivity to the time factor?

The first point about a clearer user interface is that users can subscribe to the sequencer feed to view, in real time, the final order of transactions. This sequencer feed is usable both today and in a future world where the DAO adopts Timeboost (should the vote pass) to understand the logic of how transactions get sorted.

Arbitrum chains currently operate with a single sequencer with no public mempool. Today, the logic for sorting transactions is "first-come-first-serve," or FCFS. With Timeboost, the logic changes so that transactions signed by the express lane controller are sequenced immediately (similar to FCFS). In contrast, other types of transactions get sequenced with a 200ms (proposed) delay.

We believe using the sequencer feed is a sufficient solution for helping users understand the logic behind how their transactions get sorted. Documentation and diagrams will be forthcoming to help illustrate this workflow.

The second point: in this proposal, the ArbitrumDAO can, via governance, change the amount of delay that non-express lane transactions receive. This parameter, defined as the NonExpressDelayMsec, is denominated in milliseconds and is proposed to be 200ms to start.

How will Timeboost affect block time finality on Arbitrum chains? Does this mean that an Arbitrum chain's new block time will be 450ms?

Recall that Arbitrum chains have two types of finality: (1) a trusted or soft confirmation and (2) Ethereum-equivalent finality. A trusted or soft confirmation for a user's transaction relies on the user trusting the sequencer and the near-instant transaction receipt issued by the sequencer, which takes approximately 250ms. For (2), the user can use the Ethereum-equivalent finality heuristic once their child chain transaction gets finalized on the parent chain as part of a batch of transactions posted to Ethereum, which can take two epochs or roughly 13 minutes in today's Proof-of-Stake Ethereum. Read more about these two types of finality here.

If Timeboost gets implemented on an Arbitrum chain, both of these finality timelines for non-express lane transactions (250ms for soft finality and ~13minutes for Ethereum-equivalent finality) will get extended by the default 200ms delay proposed in Timeboost, which will be roughly ~450ms and ~13 minutes & 0.2 seconds for soft finality and Ethereum-equivalent finality, respectively. There will be no impact on transaction finality for express lane transactions, meaning that finality will remain at 250ms and ~13 minutes for soft finality and Etheruem-equivalent finality, respectively.

When is it going live?

The potential adoption of Timeboost for Arbitrum One and Arbitrum Nova depends on a DAO vote. Currently, the Timeboost proposal has passed a temperature check vote on Snapshot. This temperature check aims to get a sentiment check on whether Timeboost should be adopted and, if so, whether the DAO wants to collect Timeboost bids in ETH or ARB. A subsequent on-chain vote (constitutional AIP) on Tally's platform will need to be created and voted on by the DAO to ratify its decision on whether Timeboost adoption should occur on Arbitrum One and Arbitrum Nova mainnets.

Collecting feedback from potential participants and the community is essential throughout the governance process. Based on feedback, design and/or implementation changes are possible but could impact the timelines.

Should revenue generated for the DAO come at the expense of a chain's DEX volume and LPs?

The decisions regarding what strategies to use and how to use them to generate revenue from available MEVs on Arbitrum One and Nova are entirely in the hands of Arbitrum DAO. Whether or not this revenue comes at the expense of DEX volume and to what extent is unknown. Without real-world data, it is difficult to predict what will happen accurately.

Collection and monitoring of key metrics will be crucial to evaluating Timeboost's performance and downstream impacts over time. Insights from the analysis could inform how the Arbitrum DAO fine-tunes the various parameters of Timeboost, including the nominal delay for non-express lane transactions (200ms) and the auction duration (1 minute). To support this effort, the AIP states that the following data sources will be saved and made available after Timeboost goes live on Arbitrum One and Arbitrum Nova if this proposal passes:

• Historical bid data for auction participants outside of the two highest bids (that are otherwise posted on-chain)
• A way to label/identify which transactions were sequenced in the express lane (i.e., Timeboosted transactions)

Also mentioned in the AIP is that the long-term performance of Timeboost can only truly be evaluated with real-world data - data that can help hone and fine-tune Timeboost's design for the benefit of the Arbitrum DAO.

Could Timeboost "break" the chain or reduce its performance or user experience?

As mentioned in another response, Timeboost is purely additive to an Arbitrum chain's infrastructure. As a result, Timeboost does not pose a risk of "breaking" the chain. A Timeboost-enabled Arbitrum chain will fall back to the current FCFS ordering policy if (1) Timeboost is turned "off" (trivial, controlled by governance) or (2) if there is no express lane controller for the given round. As for your comment about reducing performance or user experience, Arbitrum One and Nova block times will continue to be industry-leading with Timeboost.

Furthermore, this AIP proposes granting the current sequencer operator a few rights to make adjustments from time to time for a period of two (2) years in circumstances where doing so would enhance Timeboost's long-term stability, preserve or improve the user experience for those using Timeboost-enabled Arbitrum chains, increase the security posture, resiliency, or stability of the chain, and/or otherwise help increase revenue for the ArbitrumDAO.

Modifications to other Timeboost parameters, including values outside the specified ranges and those not already listed above, but which are otherwise listed in the design specification, will require a constitutional governance vote, per the ArbitrumDAO Constitution.

Additionally, it is important to emphasize that for Arbitrum One and Arbitrum Nova, the DAO-elected Arbitrum Security Council can, at any time, perform either Emergency Actions or Non-Emergency Actions to execute software upgrades, perform routine maintenance, and other parameter adjustments to Timeboost, in each case by its existing powers. These actions can include, but are not limited solely to, exercising the rights proposed above for the current sequencer operator. More information about the Arbitrum Security Council and their scope of powers can be found in the ArbitrumDAO Constitution.

What factors are considered when modifying the Timeboost parameters mentioned in the AIP? Are there plans to have some kind of A/B test system to try different parameters to evaluate the key metrics?

As stated in the AIP, the mentioned rights will "only be exercised in circumstances where doing so would enhance Timeboost's long-term stability, preserve or improve the user experience for those using Timeboost-enabled Arbitrum chains, increase the security posture, resiliency, or stability of the chain, and/or otherwise help increase revenue for the Arbitrum DAO." To determine these circumstances, both (1) holistic and data-based analyses and (2) careful incorporation of valuable feedback and insights from the community will be used to understand the usage of Timeboost and how Timeboost impacts the user experience and the broader Arbitrum One and Nova ecosystem. No "A/B test" system is planned to try different parameters.

As with any MEV strategy or implementation, there are trade-offs and no such thing as a "completely perfect" solution. The trade-off space includes various stakeholders and aspects, such as Arbitrum DAO revenue from bid proceeds, robust security and stability of the chain, preserving an excellent user experience, and downstream effects on the DeFi ecosystem.

It is important that the Arbitrum DAO works collaboratively together with the ecosystem to help monitor and ultimately fine-tune Timeboost over time to strike the right balance of trade-offs alongside Offchain Labs. We further hope that members of the community, including the Arbitrum Research & Development Committee (ARDC) and other teams, will conduct thorough research and analyses on Timeboost's performance over time to support and review proposals to change the Timeboost parameters (if at all).

It is important to emphasize again that:

1. Modifications to other Timeboost parameters, including values outside the specified ranges and those not already listed in the AIP but which are otherwise listed in the design specification, will require a constitutional governance vote, per the Arbitrum DAO Constitution.

2. For Arbitrum One and Arbitrum Nova, the DAO-elected Arbitrum Security Council can, at any time, perform either Emergency Actions or Non-Emergency Actions to execute software upgrades, perform routine maintenance, and other parameter adjustments to Timeboost, in each case by its existing powers. These actions can include but are not limited solely to, exercising the rights proposed for the current sequencer operator. More information about the Arbitrum Security Council and their scope of powers can be found in the Arbitrum DAO Constitution.

What if a single entity monopolizes the express lane (or multiple whales collude) and deprives smaller arbitrageurs from MEV opportunities? Could this lead to those arbitrageurs to leave Arbitrum?

rum DAO must work with the ecosystem of users, builders, and the ARDC to help monitor and, if necessary, fine-tune Timeboost over time to strike the right balance of trade-offs. It is important to state again that if you control the express lane, it does not guarantee that you can and will capture 100% of the MEV opportunities. If you win the Timeboost auction, you win a time advantage for transaction inclusion. You do not win the right to re-order transactions, see other people's transactions, or be the first transaction in every block. Therefore, opportunities not already captured by the express lane controller can be captured by other arbitrageurs since the ordering policy will remain FCFS (but with a 200ms delay for non-express lane transactions). In the case where a single express lane controller is able to capture a large majority (or all) of available MEV on the chain, then this would be fine so long as they are bidding fairly in the auction, which may be competitive, leading to sustained and higher DAO revenue.

Lastly, competition between searchers to bid for express lane control is an improvement over the current FCFS environment where searchers invest wastefully in hardware and infra to win latency races with spam. This spam contributes to network congestion with no value captured by the Arbitrum DAO. Timeboost aims to address this spam and value capture gap.

How do I change my bid or cancel my bid after I have submitted a bid?

The autonomous auctioneer will consider only an address's most recent bid, which means that if you have placed a bid and wish to change it, you may re-submit a bid to "update it." If you wish to cancel a bid, simply place a new bid significantly lower than your first bid or just bid below the minimum reserve price. Remember that a maximum of five bids per round per address is required to mitigate DDoS risks.