UPDATE as of MONDAY, 10/7/2024
Timeboost Implementation Adjustments
Timeboost’s design is the culmination of over a year of research and development by the team at Offchain Labs. While the on-chain implementation will be independently audited by Trail of Bits before the Tally vote, 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 ArbitrumDAO.
To that end, although the auctioneer will function autonomously, this AIP proposes granting the current sequencer operator the below rights to make the following adjustments from time to time for a period of two (2) years. The rights described below are expected to 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 ArbitrumDAO:
- The right to adjust the
NonExpressDelayMsec
parameter, which is the default delay that non-express lane transactions would be subject to. The default is 200ms, but adjustments could be to any value between 100ms & 500ms, inclusive.- The right to change the
maxBidsPerSenderInRound
parameter, a limit on the number of bids per participant per auction round, to mitigate against active or perceived Denial-of-Service (DoS) attacks on the auctioneer. The starting default will be 5.- The right to change the
reservePrice
to respond quickly to opportunities to increase the DAO revenue from Timeboost bid proceeds and/or to mitigate the risks of bidders colluding. To start, thereservePrice
will simply be the minReservePrice.- The ability to rotate the auctioneer’s key for submitting bids and the reserve price setter key for changing reservePrice.
- The right to pause the acceptance and verification of bids. This is to allow the current sequencer operator to provide reliable, consistent UX and maximize infrastructure stability.
- The right to disable Timeboost entirely in the event of a security risk or otherwise malicious attempt to harm Arbitrum One and Arbitrum Nova node operators, existing deployed applications, and/or end users. The Arbitrum Foundation and Offchain Labs commits to sharing publicly post-mortems and analyses should this scenario arise.
Modifications to other Timeboost parameters, including to values outside the specified ranges and to those not already listed above, but which are otherwise listed in the design specification, will require a constitutional governance vote, in accordance with the ArbitrumDAO Constitution. In cases where the ArbitrumDAO wishes to pause or disable Timeboost, the ArbitrumDAO may use the outcome of a Snapshot vote to do so (since Timeboost has an off-chain component). This special provision allows the ArbitrumDAO to react to market conditions quicker than what a Tally, on-chain vote would allow (~14 days as opposed to ~30 days).
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 in accordance with 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.
Submitted by: The Arbitrum Foundation
Category: Constitutional, Software Upgrade
Abstract
This AIP proposes the adoption of Timeboost, a new transaction ordering policy for Arbitrum One and Nova. Timeboost enables auctions for the rights to an express lane, giving the winner a time advantage for transaction inclusion and allowing them to potentially capture arbitrage and backrunning opportunities. Proceeds from the auction are at the discretion of the Arbitrum DAO, with two main options outlined in this proposal: collecting bids in ETH or collecting bids in ARB.
Motivation
Arbitrum Chains currently order transactions on a First-Come First-Served basis (FCFS). The motivation to implement FCFS was threefold:
- Easy to understand and implement,
- Replicate Web2 user experience for instant transaction confirmation,
- Protect users against front-running,
Unfortunately, relying solely on first-come first-served transaction ordering is not an ideal long-term solution.
When opportunities to profitably arbitrage across exchanges arise on Arbitrum, “MEV Searchers” race to get their transaction included before anyone else so that they can capture this profit. This latency race involves a lot of spam, placing stress on chain infrastructure and causing searchers to wastefully invest in faster hardware. Furthermore, none of the MEV generated is captured by the chain and instead all profits are collected by searchers.
Timeboost is a new transaction ordering policy that retains many of the great benefits currently in place for Arbitrum chains, including frontrunning protection and fast block times, while allowing the chain to reduce negative externalities from the racing behavior induced by MEV searchers. Additionally, it can socialize the benefits of the transaction sequencing market back to the ArbitrumDAO.
Rationale
Sustainable: Timeboost offers the ArbitrumDAO an opportunity to capture additional revenue that does not come at the expense of users, since the value being captured already exists.
Technically-Inclusive: Rather than capturing arbitrage opportunities by having the fastest hardware, participants can win these opportunities by bidding in an auction.
Neutral and Open: The auction for the express lane is permissionless and participation is open to everyone, where the highest bid wins.
Empowerment: The Arbitrum DAO can configure all aspects of Timeboost, including enabling or disabling it, the auction’s design, and how to handle proceeds.
Key Terms
Express Lane: A separate path for submitting transactions to the sequencer that has priority access compared to normally submitted transactions.
MEV: Maximal extractible value. In the context of Timeboost, MEV refers to the maximum amount of profit someone could make by including their transactions slightly faster than anyone else.
Specifications
The full specification for the Timeboost auction can be found here: GitHub - OffchainLabs/timeboost-design.
The implementation consists of an auction contract and autonomous auctioneer:
- Auction contract - Prospective bidders must deposit funds into the auction contract before bidding in the auction. The contract is also responsible for verifying bidders’ signatures, checking auction contract account balances, deducting the second-highest bid amount from the account of the highest bidder, and handling the proceeds.
- Autonomous auctioneer - An offchain program that receives bids from participants and resolves the top two bids to the auction contract. This AIP proposes that the current sequencer operator provision and set up the autonomous auctioneer, if Timeboost is adopted.
Timeboost changes the guarantees around transaction submission and introduces two different paths:
- Normal path - Transactions in the normal path will experience a short delay (defaulted to 200ms), but will otherwise remain unchanged.
- Express lane - Transactions in the express lane do not experience any delay.
Nearly all users will continue to submit transactions using the normal path. Timeboost introduces an express lane that can be purchased by sophisticated actors (like searchers) via an auction every minute, with each auction closing 15 seconds before the next round begins.
All bids in the auction are kept private until after the bid submission deadline and the auction winner will pay the same price as the second-highest bid of that round. A bid will only be accepted if it is at or above a minimum bid (the reservePrice
). The autonomous auctioneer has the right to change the reservePrice
, but it cannot be lower than the minReservePrice
, which can only be changed by the ArbitrumDAO. Note, the reservePrice
does not represent the expected value of a bid for the express lane, it is just a minimum bid that will be accepted.
We propose setting the minReservePrice
to either 0.001 ETH or 3 ARB depending on which currency the DAO votes to collect bids in.
The ArbitrumDAO can configure the currency in which bids are collected and how the remaining 97% of auction proceeds are handled. This AIP proposes two main options that the community can vote on if it decides to adopt Timeboost. Governance can change these options at any time.
- Collect ETH - Collect bids in ETH and send the proceeds to the DAO treasury.
- Burn ARB - Collect bids in ARB and burn the proceeds.
Depending on which option the Arbitrum DAO chooses, the auction contract can either transfer the proceeds to a designated account or burn them.
The following data sources will eventually 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).
Finally, the proposed version of Timeboost is compatible with a centralized sequencer. However, the Timeboost policy will also be compatible with proposals for a decentralized sequencer. 3% of auction proceeds would be set aside for the Arbitrum Developer Guild, which helps fund core Arbitrum development.
Timeboost Implementation Adjustments
Timeboost’s design is the culmination of over a year of research and development by the team at Offchain Labs. While the on-chain implementation will be independently audited by Trail of Bits before the Tally vote, 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 ArbitrumDAO.
To that end, although the auctioneer will function autonomously, this AIP proposes granting the current sequencer operator the below rights to make the following adjustments from time to time for a period of two (2) years. The rights described below are expected to 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 ArbitrumDAO:
- The right to adjust the
NonExpressDelayMsec
parameter, which is the default delay that non-express lane transactions would be subject to. The default is 200ms, but adjustments could be to any value between 100ms & 500ms, inclusive. - The right to change the
maxBidsPerSenderInRound
parameter, a limit on the number of bids per participant per auction round, to mitigate against active or perceived Denial-of-Service (DoS) attacks on the auctioneer. The starting default will be 5. - The right to change the
reservePrice
to respond quickly to opportunities to increase the DAO revenue from Timeboost bid proceeds and/or to mitigate the risks of bidders colluding. To start, thereservePrice
will simply be the minReservePrice. - The ability to rotate the auctioneer’s key for submitting bids and the reserve price setter key for changing reservePrice.
- The right to pause the acceptance and verification of bids. This is to allow the current sequencer operator to provide reliable, consistent UX and maximize infrastructure stability.
- The right to disable Timeboost entirely in the event of a security risk or otherwise malicious attempt to harm Arbitrum One and Arbitrum Nova node operators, existing deployed applications, and/or end users. The Arbitrum Foundation and Offchain Labs commits to sharing publicly post-mortems and analyses should this scenario arise.
Modifications to other Timeboost parameters, including to values outside the specified ranges and to those not already listed above, but which are otherwise listed in the design specification, will require a constitutional governance vote, in accordance with the ArbitrumDAO Constitution. In cases where the ArbitrumDAO wishes to pause or disable Timeboost, the ArbitrumDAO may use the outcome of a Snapshot vote to do so (since Timeboost has an off-chain component). This special provision allows the ArbitrumDAO to react to market conditions quicker than what a Tally, on-chain vote would allow (~14 days as opposed to ~30 days).
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 in accordance with 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.
Steps to Implement
If the ArbitrumDAO approves the AIP, the path would consist of:
-
Discussion of the proposal on the forum (this post) and governance call(s).
-
A vote on Snapshot to decide between*
- Option 1 (collect ETH),
- Option 2 (burn ARB), or
- Option 3 (decline to adopt Timeboost)
-
Sufficient time for testing on a public testnet, such as Arbitrum Sepolia
-
A third-party, independent audit of the Timeboost auction contract by Trail of Bits and subsequent fixing of any issues found, alongside publication of the audit report.
-
An on-chain vote to deploy the upgrade on Arbitrum One and Arbitrum Nova.
FAQs
Here is a compilation of FAQs based on questions received from the community.
If there are questions that are not covered in this FAQ document, please add them as a comment to this forum post, and they will be added to the FAQ document accordingly.