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
NonExpressDelayMsecparameter, 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
maxBidsPerSenderInRoundparameter, 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
reservePriceto respond quickly to opportunities to increase the DAO revenue from Timeboost bid proceeds and/or to mitigate the risks of bidders colluding. To start, thereservePricewill 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
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.
Arbitrum Chains currently order transactions on a First-Come First-Served basis (FCFS). The motivation to implement FCFS was threefold:
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.
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.
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.
The full specification for the Timeboost auction can be found here: https://github.com/OffchainLabs/timeboost-design.
The implementation consists of an auction contract and autonomous auctioneer:
Timeboost changes the guarantees around transaction submission and introduces two different paths:
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.
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:
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’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:
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.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.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, the reservePrice will simply be the minReservePrice.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.
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*
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.
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.
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
NonExpressDelayMsecparameter, 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
maxBidsPerSenderInRoundparameter, 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
reservePriceto respond quickly to opportunities to increase the DAO revenue from Timeboost bid proceeds and/or to mitigate the risks of bidders colluding. To start, thereservePricewill 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
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.
Arbitrum Chains currently order transactions on a First-Come First-Served basis (FCFS). The motivation to implement FCFS was threefold:
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.
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.
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.
The full specification for the Timeboost auction can be found here: https://github.com/OffchainLabs/timeboost-design.
The implementation consists of an auction contract and autonomous auctioneer:
Timeboost changes the guarantees around transaction submission and introduces two different paths:
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.
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:
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’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:
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.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.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, the reservePrice will simply be the minReservePrice.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.
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*
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.
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.
https://forum.arbitrum.foundation/t/constitutional-aip-proposal-to-adopt-timeboost-a-new-transaction-ordering-policy/25167/66
we prefer bids are collected in ETH
https://forum.arbitrum.foundation/t/constitutional-aip-proposal-to-adopt-timeboost-a-new-transaction-ordering-policy/25167/73
https://forum.arbitrum.foundation/t/constitutional-aip-proposal-to-adopt-timeboost-a-new-transaction-ordering-policy/25167/72?u=ocandocrypto
https://forum.arbitrum.foundation/t/constitutional-aip-proposal-to-adopt-timeboost-a-new-transaction-ordering-policy/25167/71?u=tane
https://forum.arbitrum.foundation/t/constitutional-aip-proposal-to-adopt-timeboost-a-new-transaction-ordering-policy/25167/70?u=bruce
Democratising lobbyism, on-chain. Check out lobbyfi.xyz
https://forum.arbitrum.foundation/t/seed-latam-delegate-communication-thread/13895/47?u=seedgov
https://forum.arbitrum.foundation/t/griff-green-delegate-communication-thread/25040/36?u=griff
https://forum.arbitrum.foundation/t/constitutional-aip-proposal-to-adopt-timeboost-a-new-transaction-ordering-policy/25167/28?u=blockworksre
https://forum.arbitrum.foundation/t/constitutional-aip-proposal-to-adopt-timeboost-a-new-transaction-ordering-policy/25167/64?u=euphoria
https://forum.arbitrum.foundation/t/constitutional-aip-proposal-to-adopt-timeboost-a-new-transaction-ordering-policy/25167/65
I’d prefer to keep using eth as much as possible for revenue. Other utility is in the way for arb
https://forum.arbitrum.foundation/t/constitutional-aip-proposal-to-adopt-timeboost-a-new-transaction-ordering-policy/25167/59
https://forum.arbitrum.foundation/t/constitutional-aip-proposal-to-adopt-timeboost-a-new-transaction-ordering-policy/25167/58?u=tekr0x.eth
https://forum.arbitrum.foundation/t/constitutional-aip-proposal-to-adopt-timeboost-a-new-transaction-ordering-policy/25167/57?u=0x_ultra
https://forum.arbitrum.foundation/t/constitutional-aip-proposal-to-adopt-timeboost-a-new-transaction-ordering-policy/25167/56?u=pennblockcha
https://forum.arbitrum.foundation/t/constitutional-aip-proposal-to-adopt-timeboost-a-new-transaction-ordering-policy/25167/53?u=0xdonpepe
https://forum.arbitrum.foundation/t/constitutional-aip-proposal-to-adopt-timeboost-a-new-transaction-ordering-policy/25167/10?u=0xtalvo.eth_
https://forum.arbitrum.foundation/t/constitutional-aip-proposal-to-adopt-timeboost-a-new-transaction-ordering-policy/25167/46?u=jojo
https://forum.arbitrum.foundation/t/constitutional-aip-proposal-to-adopt-timeboost-a-new-transaction-ordering-policy/25167/40?u=duokongcrypt
1. Build Treasury. 2 Optionality for MEV rev share with apps 3. ETH alignment 4. ARB Staking better option for utility
https://forum.arbitrum.foundation/t/constitutional-aip-proposal-to-adopt-timeboost-a-new-transaction-ordering-policy/25167/31?u=mehdi_eth
https://forum.arbitrum.foundation/t/constitutional-aip-proposal-to-adopt-timeboost-a-new-transaction-ordering-policy/25167/3?u=ezr3al
https://forum.arbitrum.foundation/t/constitutional-aip-proposal-to-adopt-timeboost-a-new-transaction-ordering-policy/25167/43?u=larva
https://forum.arbitrum.foundation/t/constitutional-aip-proposal-to-adopt-timeboost-a-new-transaction-ordering-policy/25167/66
we prefer bids are collected in ETH
https://forum.arbitrum.foundation/t/constitutional-aip-proposal-to-adopt-timeboost-a-new-transaction-ordering-policy/25167/73
https://forum.arbitrum.foundation/t/constitutional-aip-proposal-to-adopt-timeboost-a-new-transaction-ordering-policy/25167/72?u=ocandocrypto
https://forum.arbitrum.foundation/t/constitutional-aip-proposal-to-adopt-timeboost-a-new-transaction-ordering-policy/25167/71?u=tane
https://forum.arbitrum.foundation/t/constitutional-aip-proposal-to-adopt-timeboost-a-new-transaction-ordering-policy/25167/70?u=bruce
Democratising lobbyism, on-chain. Check out lobbyfi.xyz
https://forum.arbitrum.foundation/t/seed-latam-delegate-communication-thread/13895/47?u=seedgov
https://forum.arbitrum.foundation/t/griff-green-delegate-communication-thread/25040/36?u=griff
https://forum.arbitrum.foundation/t/constitutional-aip-proposal-to-adopt-timeboost-a-new-transaction-ordering-policy/25167/28?u=blockworksre
https://forum.arbitrum.foundation/t/constitutional-aip-proposal-to-adopt-timeboost-a-new-transaction-ordering-policy/25167/64?u=euphoria
https://forum.arbitrum.foundation/t/constitutional-aip-proposal-to-adopt-timeboost-a-new-transaction-ordering-policy/25167/65
I’d prefer to keep using eth as much as possible for revenue. Other utility is in the way for arb
https://forum.arbitrum.foundation/t/constitutional-aip-proposal-to-adopt-timeboost-a-new-transaction-ordering-policy/25167/59
https://forum.arbitrum.foundation/t/constitutional-aip-proposal-to-adopt-timeboost-a-new-transaction-ordering-policy/25167/58?u=tekr0x.eth
https://forum.arbitrum.foundation/t/constitutional-aip-proposal-to-adopt-timeboost-a-new-transaction-ordering-policy/25167/57?u=0x_ultra
https://forum.arbitrum.foundation/t/constitutional-aip-proposal-to-adopt-timeboost-a-new-transaction-ordering-policy/25167/56?u=pennblockcha
https://forum.arbitrum.foundation/t/constitutional-aip-proposal-to-adopt-timeboost-a-new-transaction-ordering-policy/25167/53?u=0xdonpepe
https://forum.arbitrum.foundation/t/constitutional-aip-proposal-to-adopt-timeboost-a-new-transaction-ordering-policy/25167/10?u=0xtalvo.eth_
https://forum.arbitrum.foundation/t/constitutional-aip-proposal-to-adopt-timeboost-a-new-transaction-ordering-policy/25167/46?u=jojo
https://forum.arbitrum.foundation/t/constitutional-aip-proposal-to-adopt-timeboost-a-new-transaction-ordering-policy/25167/40?u=duokongcrypt
1. Build Treasury. 2 Optionality for MEV rev share with apps 3. ETH alignment 4. ARB Staking better option for utility
https://forum.arbitrum.foundation/t/constitutional-aip-proposal-to-adopt-timeboost-a-new-transaction-ordering-policy/25167/31?u=mehdi_eth
https://forum.arbitrum.foundation/t/constitutional-aip-proposal-to-adopt-timeboost-a-new-transaction-ordering-policy/25167/3?u=ezr3al
https://forum.arbitrum.foundation/t/constitutional-aip-proposal-to-adopt-timeboost-a-new-transaction-ordering-policy/25167/43?u=larva
When Timeboost goes live?
When Timeboost goes live?
On behalf of Gains Network (gTrade) – Voting AGAINST on Tally
We’d like to thank the contributors behind this proposal, especially the Entropy team, for pushing forward important conversations around MEV mitigation and sustainable ecosystem revenue.
On behalf of Gains Network (gTrade) – Voting AGAINST on Tally
We’d like to thank the contributors behind this proposal, especially the Entropy team, for pushing forward important conversations around MEV mitigation and sustainable ecosystem revenue.
After reviewing the Timeboost proposal in detail and conversations with the proposers, we have decided to vote AGAINST this implementation in its current form.
Our perspective is based primarily on expected negative implications for user experience, and a lack of sufficient offsetting benefits.
Key concerns:
Worsened UX due to increased transaction latency.
Timeboost introduces up to 500ms of potential delay for non-express lane transactions. For a PerpDEX like gTrade, where timing matters and gas spikes already cause significant issues for users, this added latency is concerning. While 100–200ms might not seem like much in isolation, it's a step backward in the broader competitive landscape — especially when compared to L2s that are optimizing for speed and low latency.
Unclear benefit to regular users.
While the proposal highlights potential ecosystem revenue and a more efficient arbitrage market, it's unclear how this directly benefits everyday users or protocols. There’s no guarantee that this will lead to lower gas fees, nor is there strong evidence that arbitrage markets will improve meaningfully. Without tangible upside for regular users, the trade-off in UX feels unjustified.
Favors well-capitalized actors.
While we agree that the current MEV environment is extractive and needs reform, Timeboost shifts the dynamic toward larger market makers and statistically driven MEV players. This risks reducing competition and excluding smaller or independent actors — creating a system that’s less open, not more.
No coordination with base fee reductions.
Some of our concerns might have been mitigated if Timeboost had been paired with a reduction in base gas fees to offset the UX degradation. Without such balancing measures, we view this as a net negative for the user experience and protocol operations.
We recognize the argument that the parameters are configurable, and that analytics will be in place to assess the impact. However, we believe it would be more prudent to explore other UX-friendly paths to MEV recapture — especially those that don’t increase transaction latency or concentrate power among fewer players.
Should a revised proposal emerge in the future with a clearer positive-sum outcome for users, or a holistic approach that includes fee reductions, we would be eager to reconsider.
Pros:
Increases DAO revenue.
Reduces spam.
Cons:
Pros:
Increases DAO revenue.
Reduces spam.
Cons:
Increased slippage, as previously stated.
Nearly doubles transaction response time. With the growing competition among public chains, fast response time is Arbitrum's greatest advantage and brings great UX. Artificially diminishing this advantage significantly reduces Arbitrum's competitiveness(eg. compared to solana) and limits the potential improvements driven by hardware advancements.
Potential monopoly. The design of the Timeboost mechanism grants a leading advantage for all transactions in the following minute through a single bid, which is highly likely to result in monopolization. The consequence of such monopolization is that a single team could dominate all arbitrage transactions, forcing other teams out and ultimately rendering the auction mechanism ineffective.
An additional point to be made here is that the on-chain monitoring will not be for monopolistic behavior, but for the bid amounts compared to the available MEV on an Arbitrum chain.
Additionally, considering arbitrage transactions between CEX and DEX, I believe it is very challenging to estimate "the available MEV on an Arbitrum chain."
It sounds like a trial-and-error process with a lot of uncertainties.
Thank you for taking the time to provide such a detailed explanation. I'd like to continue sharing my thoughts.
The point you raised about "a single express lane controller capture a large majority of MEV, while bidding fairly in the auction" is impossible. This is because capital has a time cost, and other arbitrage competitors will leave, leading to a monopoly. Before the monopoly, whales will raise prices, but after the monopoly, bids will be as low as possible. On-chain monitoring for monopolistic behavior maybe also impossible because they can always use multiple accounts to take turns controlling the express lane (or do we have a better way to monitor this?).
As an active liquidity provider, I believe that the 200ms delay introduced by Timeboost is a huge challenge and will likely cause my liquidity operations to lag significantly behind those express lane controllers. Compared to all other chains, Arbitrum's FIFO and 250ms transaction responsiveness are my favorite features, as they allow me to avoid gas wars with arbitrageurs. However, this advantage will disappear with Timeboost, and increased slippage is almost inevitable.
Timeboost aims to address spams, but I personally haven't felt the severe impact of spams. Does the spam frequently cause congestion on Arbitrum?
On behalf of Gains Network (gTrade) – Voting AGAINST on Tally
We’d like to thank the contributors behind this proposal, especially the Entropy team, for pushing forward important conversations around MEV mitigation and sustainable ecosystem revenue.
On behalf of Gains Network (gTrade) – Voting AGAINST on Tally
We’d like to thank the contributors behind this proposal, especially the Entropy team, for pushing forward important conversations around MEV mitigation and sustainable ecosystem revenue.
After reviewing the Timeboost proposal in detail and conversations with the proposers, we have decided to vote AGAINST this implementation in its current form.
Our perspective is based primarily on expected negative implications for user experience, and a lack of sufficient offsetting benefits.
Key concerns:
Worsened UX due to increased transaction latency.
Timeboost introduces up to 500ms of potential delay for non-express lane transactions. For a PerpDEX like gTrade, where timing matters and gas spikes already cause significant issues for users, this added latency is concerning. While 100–200ms might not seem like much in isolation, it's a step backward in the broader competitive landscape — especially when compared to L2s that are optimizing for speed and low latency.
Unclear benefit to regular users.
While the proposal highlights potential ecosystem revenue and a more efficient arbitrage market, it's unclear how this directly benefits everyday users or protocols. There’s no guarantee that this will lead to lower gas fees, nor is there strong evidence that arbitrage markets will improve meaningfully. Without tangible upside for regular users, the trade-off in UX feels unjustified.
Favors well-capitalized actors.
While we agree that the current MEV environment is extractive and needs reform, Timeboost shifts the dynamic toward larger market makers and statistically driven MEV players. This risks reducing competition and excluding smaller or independent actors — creating a system that’s less open, not more.
No coordination with base fee reductions.
Some of our concerns might have been mitigated if Timeboost had been paired with a reduction in base gas fees to offset the UX degradation. Without such balancing measures, we view this as a net negative for the user experience and protocol operations.
We recognize the argument that the parameters are configurable, and that analytics will be in place to assess the impact. However, we believe it would be more prudent to explore other UX-friendly paths to MEV recapture — especially those that don’t increase transaction latency or concentrate power among fewer players.
Should a revised proposal emerge in the future with a clearer positive-sum outcome for users, or a holistic approach that includes fee reductions, we would be eager to reconsider.
Pros:
Increases DAO revenue.
Reduces spam.
Cons:
Pros:
Increases DAO revenue.
Reduces spam.
Cons:
Increased slippage, as previously stated.
Nearly doubles transaction response time. With the growing competition among public chains, fast response time is Arbitrum's greatest advantage and brings great UX. Artificially diminishing this advantage significantly reduces Arbitrum's competitiveness(eg. compared to solana) and limits the potential improvements driven by hardware advancements.
Potential monopoly. The design of the Timeboost mechanism grants a leading advantage for all transactions in the following minute through a single bid, which is highly likely to result in monopolization. The consequence of such monopolization is that a single team could dominate all arbitrage transactions, forcing other teams out and ultimately rendering the auction mechanism ineffective.
An additional point to be made here is that the on-chain monitoring will not be for monopolistic behavior, but for the bid amounts compared to the available MEV on an Arbitrum chain.
Additionally, considering arbitrage transactions between CEX and DEX, I believe it is very challenging to estimate "the available MEV on an Arbitrum chain."
It sounds like a trial-and-error process with a lot of uncertainties.
Thank you for taking the time to provide such a detailed explanation. I'd like to continue sharing my thoughts.
The point you raised about "a single express lane controller capture a large majority of MEV, while bidding fairly in the auction" is impossible. This is because capital has a time cost, and other arbitrage competitors will leave, leading to a monopoly. Before the monopoly, whales will raise prices, but after the monopoly, bids will be as low as possible. On-chain monitoring for monopolistic behavior maybe also impossible because they can always use multiple accounts to take turns controlling the express lane (or do we have a better way to monitor this?).
As an active liquidity provider, I believe that the 200ms delay introduced by Timeboost is a huge challenge and will likely cause my liquidity operations to lag significantly behind those express lane controllers. Compared to all other chains, Arbitrum's FIFO and 250ms transaction responsiveness are my favorite features, as they allow me to avoid gas wars with arbitrageurs. However, this advantage will disappear with Timeboost, and increased slippage is almost inevitable.
Timeboost aims to address spams, but I personally haven't felt the severe impact of spams. Does the spam frequently cause congestion on Arbitrum?
Thank you for taking the time to provide such a detailed explanation. I'd like to continue sharing my thoughts.
The point you raised about "a single express lane controller capture a large majority of MEV, while bidding fairly in the auction" is impossible. This is because capital has a time cost, and other arbitrage competitors will leave, leading to a monopoly. Before the monopoly, whales will raise prices, but after the monopoly, bids will be as low as possible. On-chain monitoring for monopolistic behavior maybe also impossible because they can always use multiple accounts to take turns controlling the express lane (or do we have a better way to monitor this?).
As an active liquidity provider, I believe that the 200ms delay introduced by Timeboost is a huge challenge and will likely cause my liquidity operations to lag significantly behind those express lane controllers. Compared to all other chains, Arbitrum's FIFO and 250ms transaction responsiveness are my favorite features, as they allow me to avoid gas wars with arbitrageurs. However, this advantage will disappear with Timeboost, and increased slippage is almost inevitable.
Timeboost aims to address spams, but I personally haven't felt the severe impact of spams. Does the spam frequently cause congestion on Arbitrum?
I believe Arbitrum's current performance is excellent, offering a relatively fair competitive environment. It ranks among the top public chains in terms of transaction volume. Although I hope that the Timeboost can help the DAO accumulate value, given such a significant mechanism change, perhaps impact on all participants of current ecosystem should be more carefully considered.
Sharing Chaos Labs' perspectives on some points raised in this discussion.
to start with the most obvious point, simply because adding an additional cost to the process will naturally reduce arbitrage.
Sharing Chaos Labs' perspectives on some points raised in this discussion.
to start with the most obvious point, simply because adding an additional cost to the process will naturally reduce arbitrage.
It could be argued that a reduction in spam transactions will lower gas prices, lowering transaction costs. The fixed upfront cost of the express lane, with no marginal costs for the controller, would also motivate them to maximize arbitrage trading and profits to most effectively monetize.
We acknowledge that in cases where access to the express lane is sold on secondary markets, that there is a potential for usage based access and a marginal cost for arbitrageurs “renting” access should these markets develop in this way. It is unclear that this would result in lower volumes however.
For instance, could we see some arbitrageurs slowing down or simply halting their activities on Arbitrum?
Arbitrageurs are not performing arbitrages as a public good, but because they can make money from price mismatches between exchanges. It is also unclear whether Timeboost will affect the frequency of price mismatches between exchanges.
As previously mentioned, adding a 200ms delay would naturally increase LVR
Loss versus rebalancing is the value leaked by the AMM pool to arbitrageurs. Quoting from Automated Market Making and Loss-Versus-Rebalancing, the paper proposing LVR: “LVR captures costs incurred by AMM LPs due to stale prices that are picked off by better informed arbitrageurs.” In short LVR, the measure of cost for LPs, is unaffected by latency or block times, but the ability to monetize these opportunities could be affected by block times, affecting LP fees. Since LP economics are fees less costs, this deserves further unpacking.
Recent research into the impact of block times on potential arbitrage fee revenues for LPs found that this theoretically increases in the order of the square root of block times. This empirical follow up found that the actual results were about half as much as theoretically predicted.
As clarified by @BlockworksResearch above, block times are not increasing under Timeboost, there is simply a latency added for non-express lane users. It is unclear why the express lane owner would choose to ignore profitable arbitrage, rather than monetize them themselves or provide access for others to do so. We do not conclude that DEX volumes should be affected in either direction by a change in arbitrage behavior under Timeboost. It is extremely likely that the express lane will be used for arbitrage predominantly, as this is the major cause of spam MEV transactions currently.
Chaos Labs agrees with the conclusion of @BlockworksResearch here that arbitrage activity could increase under Timeboost, increasing DEX LP fees. Taken together, we do not expect LP fees to reduce as a result of Timeboost ordering.
In summary, we find no reason that arbitrage DEX volumes or costs (LVR) will be negatively affected by Timeboost, and LP fees could potentially increase.
As mentioned in our original post, there are multiple ways the microstructure of MEV could evolve under this upgrade and we strongly recommend close monitoring to ensure that the auction process remains competitive, and user experience is not harmed.
I think this is a really interesting mechanism but I would love to see more discussion on the following scenario from the @chaoslabs report:
I think this is a really interesting mechanism but I would love to see more discussion on the following scenario from the @chaoslabs report:
Wouldn't this create a massive risk for anyone holding a leveraged position or a stop-loss order?
Also worth noting that MEV in general thrives when there is a lot of chaos and volatility in the market. When a single player can capture all MEV for a full 240 blocks on Arbitrum One, doesn't this provide a big incentive to create chaos onchain (breaking stablecoins, liquidation cascades, etc)?
I fully realize that I may be missing something here but I'd love to know if these kinds of attacks have been considered.
Timeboost is essentially a auction for 'god trader', who can then do as they please. Wintermute loves it. Good luck, guys!
Agreed, Timeboost only benefits to DAO value, but destroys the arbitrum eco-system totally. Slow down everyone by 200 ms to give one party advantage, It kills user experience, and prevent the chain to benefit from potential squencer hardware upgrade. And it will drive away arbitrage traders , and reduce trading volumes. For liquidity providers, they are unable to win the auction, they have to increase price slippage to compensate for the 200ms latency. We should really care about the eco-system instead of income.
The primary use of Timeboost will be for executing arbitrage operations. However, with the current auction mechanism, Timeboost is highly likely to turn into a game dominated by a single whale (or multiple whales colluding together), leaving smaller arbitrageurs with no opportunity, forcing them to leave the Arbitrum chain. This monopolistic game would undermine the competitive ecosystem of Arbitrum and could also lead to a reduction in auction revenue.
Hi all,
As an intro, I am an Ethereum researcher and this is in my first time engaging with the Arbitrum DAO, I wasn't aware of this proposal until I saw a post from Max about it (below).
Hi all,
As an intro, I am an Ethereum researcher and this is in my first time engaging with the Arbitrum DAO, I wasn't aware of this proposal until I saw a post from Max about it (below).
https://x.com/maxresnick1/status/1836984910952698363
I am very surprised that Timeboost is being pushed by the Arbitrum team and also has unaminous DAO support, without almost any consideration for the actual economic impact it could have. This is a core protocol level change, and yet all of the discussion is around revenue, and not the impact it would have on trading, arbitrage, or basically anything else.
I am new to the DAO so I could be missing something, but the paid (?) research also doesn't go into the detail of the challenges or potential downsides... I am quite perplexed how one of the biggest chains in the space (and largest L2) could consider such a serious change with such little basic information available?
I have been a supporter of Arbitrum from afar for its L2 efforts, but this seems like a serious misstep. It is a deeply technical proposal which has almost 0 push back or discussion, which I am disappointed in seeing.
I can only assume that delegates are just unaware of the actual implications here, but I am still left confused by the process in which this is being implemented. Concerned enough that I feel like I needed to actually make a post just to share the thoughts from other people in the Ethereum community.
In short, given the lack of economic analysis and lack of in-depth research, this is a proposal that could break the chain or reduce its performance or user experience, just to optimise DAO revenue.
Maybe I have missed some of the thorough research and impact analysis, I would love to read if there are any. What blockworks and delphi have shared is basic at best.
https://x.com/txsequencer/status/1836896052768854337
https://x.com/joshuagunnn/status/1836980065088815220
https://x.com/0xballoonlover/status/1836961863013474787
Thanks, MevAintFree
Thank you for taking the time to provide such a detailed explanation. I'd like to continue sharing my thoughts.
The point you raised about "a single express lane controller capture a large majority of MEV, while bidding fairly in the auction" is impossible. This is because capital has a time cost, and other arbitrage competitors will leave, leading to a monopoly. Before the monopoly, whales will raise prices, but after the monopoly, bids will be as low as possible. On-chain monitoring for monopolistic behavior maybe also impossible because they can always use multiple accounts to take turns controlling the express lane (or do we have a better way to monitor this?).
As an active liquidity provider, I believe that the 200ms delay introduced by Timeboost is a huge challenge and will likely cause my liquidity operations to lag significantly behind those express lane controllers. Compared to all other chains, Arbitrum's FIFO and 250ms transaction responsiveness are my favorite features, as they allow me to avoid gas wars with arbitrageurs. However, this advantage will disappear with Timeboost, and increased slippage is almost inevitable.
Timeboost aims to address spams, but I personally haven't felt the severe impact of spams. Does the spam frequently cause congestion on Arbitrum?
I believe Arbitrum's current performance is excellent, offering a relatively fair competitive environment. It ranks among the top public chains in terms of transaction volume. Although I hope that the Timeboost can help the DAO accumulate value, given such a significant mechanism change, perhaps impact on all participants of current ecosystem should be more carefully considered.
Sharing Chaos Labs' perspectives on some points raised in this discussion.
to start with the most obvious point, simply because adding an additional cost to the process will naturally reduce arbitrage.
Sharing Chaos Labs' perspectives on some points raised in this discussion.
to start with the most obvious point, simply because adding an additional cost to the process will naturally reduce arbitrage.
It could be argued that a reduction in spam transactions will lower gas prices, lowering transaction costs. The fixed upfront cost of the express lane, with no marginal costs for the controller, would also motivate them to maximize arbitrage trading and profits to most effectively monetize.
We acknowledge that in cases where access to the express lane is sold on secondary markets, that there is a potential for usage based access and a marginal cost for arbitrageurs “renting” access should these markets develop in this way. It is unclear that this would result in lower volumes however.
For instance, could we see some arbitrageurs slowing down or simply halting their activities on Arbitrum?
Arbitrageurs are not performing arbitrages as a public good, but because they can make money from price mismatches between exchanges. It is also unclear whether Timeboost will affect the frequency of price mismatches between exchanges.
As previously mentioned, adding a 200ms delay would naturally increase LVR
Loss versus rebalancing is the value leaked by the AMM pool to arbitrageurs. Quoting from Automated Market Making and Loss-Versus-Rebalancing, the paper proposing LVR: “LVR captures costs incurred by AMM LPs due to stale prices that are picked off by better informed arbitrageurs.” In short LVR, the measure of cost for LPs, is unaffected by latency or block times, but the ability to monetize these opportunities could be affected by block times, affecting LP fees. Since LP economics are fees less costs, this deserves further unpacking.
Recent research into the impact of block times on potential arbitrage fee revenues for LPs found that this theoretically increases in the order of the square root of block times. This empirical follow up found that the actual results were about half as much as theoretically predicted.
As clarified by @BlockworksResearch above, block times are not increasing under Timeboost, there is simply a latency added for non-express lane users. It is unclear why the express lane owner would choose to ignore profitable arbitrage, rather than monetize them themselves or provide access for others to do so. We do not conclude that DEX volumes should be affected in either direction by a change in arbitrage behavior under Timeboost. It is extremely likely that the express lane will be used for arbitrage predominantly, as this is the major cause of spam MEV transactions currently.
Chaos Labs agrees with the conclusion of @BlockworksResearch here that arbitrage activity could increase under Timeboost, increasing DEX LP fees. Taken together, we do not expect LP fees to reduce as a result of Timeboost ordering.
In summary, we find no reason that arbitrage DEX volumes or costs (LVR) will be negatively affected by Timeboost, and LP fees could potentially increase.
As mentioned in our original post, there are multiple ways the microstructure of MEV could evolve under this upgrade and we strongly recommend close monitoring to ensure that the auction process remains competitive, and user experience is not harmed.
I think this is a really interesting mechanism but I would love to see more discussion on the following scenario from the @chaoslabs report:
I think this is a really interesting mechanism but I would love to see more discussion on the following scenario from the @chaoslabs report:
Wouldn't this create a massive risk for anyone holding a leveraged position or a stop-loss order?
Also worth noting that MEV in general thrives when there is a lot of chaos and volatility in the market. When a single player can capture all MEV for a full 240 blocks on Arbitrum One, doesn't this provide a big incentive to create chaos onchain (breaking stablecoins, liquidation cascades, etc)?
I fully realize that I may be missing something here but I'd love to know if these kinds of attacks have been considered.
Timeboost is essentially a auction for 'god trader', who can then do as they please. Wintermute loves it. Good luck, guys!
Agreed, Timeboost only benefits to DAO value, but destroys the arbitrum eco-system totally. Slow down everyone by 200 ms to give one party advantage, It kills user experience, and prevent the chain to benefit from potential squencer hardware upgrade. And it will drive away arbitrage traders , and reduce trading volumes. For liquidity providers, they are unable to win the auction, they have to increase price slippage to compensate for the 200ms latency. We should really care about the eco-system instead of income.
The primary use of Timeboost will be for executing arbitrage operations. However, with the current auction mechanism, Timeboost is highly likely to turn into a game dominated by a single whale (or multiple whales colluding together), leaving smaller arbitrageurs with no opportunity, forcing them to leave the Arbitrum chain. This monopolistic game would undermine the competitive ecosystem of Arbitrum and could also lead to a reduction in auction revenue.
Hi all,
As an intro, I am an Ethereum researcher and this is in my first time engaging with the Arbitrum DAO, I wasn't aware of this proposal until I saw a post from Max about it (below).
Hi all,
As an intro, I am an Ethereum researcher and this is in my first time engaging with the Arbitrum DAO, I wasn't aware of this proposal until I saw a post from Max about it (below).
https://x.com/maxresnick1/status/1836984910952698363
I am very surprised that Timeboost is being pushed by the Arbitrum team and also has unaminous DAO support, without almost any consideration for the actual economic impact it could have. This is a core protocol level change, and yet all of the discussion is around revenue, and not the impact it would have on trading, arbitrage, or basically anything else.
I am new to the DAO so I could be missing something, but the paid (?) research also doesn't go into the detail of the challenges or potential downsides... I am quite perplexed how one of the biggest chains in the space (and largest L2) could consider such a serious change with such little basic information available?
I have been a supporter of Arbitrum from afar for its L2 efforts, but this seems like a serious misstep. It is a deeply technical proposal which has almost 0 push back or discussion, which I am disappointed in seeing.
I can only assume that delegates are just unaware of the actual implications here, but I am still left confused by the process in which this is being implemented. Concerned enough that I feel like I needed to actually make a post just to share the thoughts from other people in the Ethereum community.
In short, given the lack of economic analysis and lack of in-depth research, this is a proposal that could break the chain or reduce its performance or user experience, just to optimise DAO revenue.
Maybe I have missed some of the thorough research and impact analysis, I would love to read if there are any. What blockworks and delphi have shared is basic at best.
https://x.com/txsequencer/status/1836896052768854337
https://x.com/joshuagunnn/status/1836980065088815220
https://x.com/0xballoonlover/status/1836961863013474787
Thanks, MevAintFree
OpenZeppelin, the Security Member of the ARDC, reviewed the proposal to adopt Timeboost for security and implementation risks. We found no security issues with the proposed design at this time.
There is no code or decentralized version today, but community approval would grant Offchain Labs and Espresso Systems the runway to develop those things. Those details are where most of our security concerns will be so we look forward to reviewing their work when it’s available.
OpenZeppelin, the Security Member of the ARDC, reviewed the proposal to adopt Timeboost for security and implementation risks. We found no security issues with the proposed design at this time.
There is no code or decentralized version today, but community approval would grant Offchain Labs and Espresso Systems the runway to develop those things. Those details are where most of our security concerns will be so we look forward to reviewing their work when it’s available.
More on our Security Analysis here:
https://forum.arbitrum.foundation/t/timeboost-security-analysis/26832?u=openzeppelin
Quick note for everyone here: we just published an analysis of Timeboost vs other MEV solutions for L2s as a part of our engagement with the DAO via the ARDC. Linking it below.
OpenZeppelin, the Security Member of the ARDC, reviewed the proposal to adopt Timeboost for security and implementation risks. We found no security issues with the proposed design at this time.
There is no code or decentralized version today, but community approval would grant Offchain Labs and Espresso Systems the runway to develop those things. Those details are where most of our security concerns will be so we look forward to reviewing their work when it’s available.
OpenZeppelin, the Security Member of the ARDC, reviewed the proposal to adopt Timeboost for security and implementation risks. We found no security issues with the proposed design at this time.
There is no code or decentralized version today, but community approval would grant Offchain Labs and Espresso Systems the runway to develop those things. Those details are where most of our security concerns will be so we look forward to reviewing their work when it’s available.
More on our Security Analysis here:
https://forum.arbitrum.foundation/t/timeboost-security-analysis/26832?u=openzeppelin
Quick note for everyone here: we just published an analysis of Timeboost vs other MEV solutions for L2s as a part of our engagement with the DAO via the ARDC. Linking it below.
Hey team!
I have a question about how the formula used to get the timeboost value came about. According to your outdated article, the formula looks like a reversed exponential decay function.
I am wondering if there are any technical details about how this function was created. Was it a simple design choice, or were there specific reasons for not choosing a sigmoid function or something similar?
Hey team!
I have a question about how the formula used to get the timeboost value came about. According to your outdated article, the formula looks like a reversed exponential decay function.
I am wondering if there are any technical details about how this function was created. Was it a simple design choice, or were there specific reasons for not choosing a sigmoid function or something similar?
Thanks in advance.
When its going live? I will be voting for 2. Option.
It depens , there are offesting incoming unlocks to be liquidate as well , dear @cp0x burning is also a tools , that keep EIP1559 monetary policies align with the interest of the ultrasound features of gaz . Think more like tools that is can be use as monetary policies when it is needed (for contraction & expansion of the supply). To keep stuff in check .
I don't see much difference. If ARB is burned, arb gains value and the amount of ARB that will go from Dao decreases again. As a result, payments are made on a certain $ scale. For example, need $100M and $arb is $1. Then you need to spend 100M $arb. If $arb is $2 then you will spend 50M $arb.
On the other hand, the collection of fees as $eth will create a second topic of discussion. What should we do with the collected $eth, should we distribute it to stakers, should we buy arb, should we buy $arb and burn it? There will be a lot of discussion. Instead, burning $arb is simpler and will contribute to the value gain and block to spend much arb from Dao.
Hey team!
I have a question about how the formula used to get the timeboost value came about. According to your outdated article, the formula looks like a reversed exponential decay function.
I am wondering if there are any technical details about how this function was created. Was it a simple design choice, or were there specific reasons for not choosing a sigmoid function or something similar?
Hey team!
I have a question about how the formula used to get the timeboost value came about. According to your outdated article, the formula looks like a reversed exponential decay function.
I am wondering if there are any technical details about how this function was created. Was it a simple design choice, or were there specific reasons for not choosing a sigmoid function or something similar?
Thanks in advance.
When its going live? I will be voting for 2. Option.
It depens , there are offesting incoming unlocks to be liquidate as well , dear @cp0x burning is also a tools , that keep EIP1559 monetary policies align with the interest of the ultrasound features of gaz . Think more like tools that is can be use as monetary policies when it is needed (for contraction & expansion of the supply). To keep stuff in check .
I don't see much difference. If ARB is burned, arb gains value and the amount of ARB that will go from Dao decreases again. As a result, payments are made on a certain $ scale. For example, need $100M and $arb is $1. Then you need to spend 100M $arb. If $arb is $2 then you will spend 50M $arb.
On the other hand, the collection of fees as $eth will create a second topic of discussion. What should we do with the collected $eth, should we distribute it to stakers, should we buy arb, should we buy $arb and burn it? There will be a lot of discussion. Instead, burning $arb is simpler and will contribute to the value gain and block to spend much arb from Dao.
Does grounded governance models in general align with Offchain Labs' MEV vision for Arbitrum? This requires a nuanced answer:Alignment in Principle, But Not a Direct Overlap:
Does grounded governance models in general align with Offchain Labs' MEV vision for Arbitrum? This requires a nuanced answer:Alignment in Principle, But Not a Direct Overlap:
How They Intersect:
In Conclusion:
Your original analysis is valuable because it provides a toolkit for thinking about these complexities. Now, the discussion needs to shift towards how those tools are applied specifically within the context of Arbitrum's MEV goals.
If, according to your plan, the treasury still needs to operate for up to a dozen more years to finally achieve linear release and bring rights to holders, what is the current function of the ARB token? Is it for voting or just a tool for the team to raise funds? Everyone is well aware of who holds absolute power, which leads to retail investors’ indifference towards voting rights. If this situation continues, why issue ARB? If you can take money from your own pocket during the next token incentive to offset the token sell pressure from monthly team and VC unlocks, as well as ecosystem incentives, then I would absolutely support your view. The formation of a “big government” mentality due to the ever-growing treasury and declining governance participation is what should be cautioned against
Distributing the proceeds to Stakers creates selling pressure. Typically, stakers sell their staking income, such as salary, at the end of the month. However, if there is a constantly burning supply, it activates the holding psychology more and people theoretically hold it as if they were Staking, without receiving Stake income. Burning is more positive for pricing. I think the staking mechanism should be placed at the center of Bold in the future when price stability is achieved. @cp0x @0xTALVO.ETH_MTY
There is only one option: consume arb A good ecosystem is a positive cycle. Arbitrum should use arb as the center of the ecosystem to spread outward. The current competitive landscape of L2 is unclear. The functions of each other are not irreplaceable. Doing something well is not about doing it well, but about making it different. I believe this is a good start.
We should start to think about how to drive value back to the Arb token with new initiatives like this. I propose two possible solutions:
Great post! This is @yusufxzy from Delphi Digital. A couple of questions-
Its helpful to have prospective bidders place a deposit in order to bids. I assume this mechanism is in place to avoid spam from searchers. How is this deposit value quantified?
What does block construction look like when the Time Boost is in place? Does the sequencer have to place the express bundles atop other, normal bundles? What if there is a delay in receiving the express bundle? Does it delay the block building process? What are some mechanisms in place to avoid such situations?
What would happen in case the autonomous auctioneer goes offline? Would Arbitrum revert to FCFS as a fall back immediately? What measures do we have to protect against the autonomous auctioneer down-time? Who would manage this auctioneer?
Please refer to the more recent and combined Timeboost+NovaFeeSweep AIP for the latest language and proposal data for Timeboost.
The primary change is that the following paragraph from this original Timeboost proposal:
Please refer to the more recent and combined Timeboost+NovaFeeSweep AIP for the latest language and proposal data for Timeboost.
The primary change is that the following paragraph from this original Timeboost proposal:
"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)."
Has been updated to the following in the new Timeboost+NovaFeeSweep proposal:
"Should this vote pass, 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). The transfer of express lane rights will not be supported by the Arbitrum Nitro node software in the initial launch and may be implemented at a future date via a regular node upgrade. A round’s express lane controller, at their choice, can still sign transactions on behalf of others on a per-transaction basis."
Does grounded governance models in general align with Offchain Labs' MEV vision for Arbitrum? This requires a nuanced answer:Alignment in Principle, But Not a Direct Overlap:
Does grounded governance models in general align with Offchain Labs' MEV vision for Arbitrum? This requires a nuanced answer:Alignment in Principle, But Not a Direct Overlap:
How They Intersect:
In Conclusion:
Your original analysis is valuable because it provides a toolkit for thinking about these complexities. Now, the discussion needs to shift towards how those tools are applied specifically within the context of Arbitrum's MEV goals.
If, according to your plan, the treasury still needs to operate for up to a dozen more years to finally achieve linear release and bring rights to holders, what is the current function of the ARB token? Is it for voting or just a tool for the team to raise funds? Everyone is well aware of who holds absolute power, which leads to retail investors’ indifference towards voting rights. If this situation continues, why issue ARB? If you can take money from your own pocket during the next token incentive to offset the token sell pressure from monthly team and VC unlocks, as well as ecosystem incentives, then I would absolutely support your view. The formation of a “big government” mentality due to the ever-growing treasury and declining governance participation is what should be cautioned against
Distributing the proceeds to Stakers creates selling pressure. Typically, stakers sell their staking income, such as salary, at the end of the month. However, if there is a constantly burning supply, it activates the holding psychology more and people theoretically hold it as if they were Staking, without receiving Stake income. Burning is more positive for pricing. I think the staking mechanism should be placed at the center of Bold in the future when price stability is achieved. @cp0x @0xTALVO.ETH_MTY
There is only one option: consume arb A good ecosystem is a positive cycle. Arbitrum should use arb as the center of the ecosystem to spread outward. The current competitive landscape of L2 is unclear. The functions of each other are not irreplaceable. Doing something well is not about doing it well, but about making it different. I believe this is a good start.
We should start to think about how to drive value back to the Arb token with new initiatives like this. I propose two possible solutions:
Great post! This is @yusufxzy from Delphi Digital. A couple of questions-
Its helpful to have prospective bidders place a deposit in order to bids. I assume this mechanism is in place to avoid spam from searchers. How is this deposit value quantified?
What does block construction look like when the Time Boost is in place? Does the sequencer have to place the express bundles atop other, normal bundles? What if there is a delay in receiving the express bundle? Does it delay the block building process? What are some mechanisms in place to avoid such situations?
What would happen in case the autonomous auctioneer goes offline? Would Arbitrum revert to FCFS as a fall back immediately? What measures do we have to protect against the autonomous auctioneer down-time? Who would manage this auctioneer?
Please refer to the more recent and combined Timeboost+NovaFeeSweep AIP for the latest language and proposal data for Timeboost.
The primary change is that the following paragraph from this original Timeboost proposal:
Please refer to the more recent and combined Timeboost+NovaFeeSweep AIP for the latest language and proposal data for Timeboost.
The primary change is that the following paragraph from this original Timeboost proposal:
"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)."
Has been updated to the following in the new Timeboost+NovaFeeSweep proposal:
"Should this vote pass, 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). The transfer of express lane rights will not be supported by the Arbitrum Nitro node software in the initial launch and may be implemented at a future date via a regular node upgrade. A round’s express lane controller, at their choice, can still sign transactions on behalf of others on a per-transaction basis."
In anticipation of Timeboost progressing to an on-chain vote before the end of the month, Offchain Labs has created this explainer and expectations post to help educate voting delegates.
In anticipation of Timeboost progressing to an on-chain vote before the end of the month, Offchain Labs has created this explainer and expectations post to help educate voting delegates.
Timeboost is a novel transaction ordering policy developed for Arbitrum chains. Designed through extensive research and collaboration with over 20+ teams from DeFi Projects, traders, MEV searchers and infrastructure builders, Timeboost aims to address key challenges such as spam inefficiencies and Maximal Extractable Value (MEV) while providing significant value to the ArbitrumDAO and the Arbitrum One and Nova chains. With engineering testing nearing completion and audits finalized, it is poised for consideration as a transformative feature for each chain.
Timeboost is not just a technical innovation but a new paradigm for balancing fairness, efficiency, and economic value within the Arbitrum ecosystem.
Learn More: If you have questions, visit the Timeboost FAQ page for additional information and quick answers.
Based on feedback and additional engineering work, the following updates have been made to the Timeboost implementation adjustments section that covers the temporary rights that are requested to be granted to the current sequencer operator:
Based on feedback and additional engineering work, the following updates have been made to the Timeboost implementation adjustments section that covers the temporary rights that are requested to be granted to the current sequencer operator:
Removed the right to impose a minimum balance/deposit for Timeboost auction participants, as this right is no longer considered to be necessary to help mitigate Denial of Service (DoS) attacks. Alternative, more robust mechanisms have been developed and will be put in place instead.
Added 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 above changes will continue to be temporary and granting of these rights (to the current sequencer operator) are ultimately subject to the ArbitrumDAO’s approval.
Modifications to any Timeboost parameter by anyone else will continue to require a constitutional governance vote. The DAO-elected security council will continue to possess the right to 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 herein for the current sequencer operator. More information about the Arbitrum Security Council and their scope of powers can be found in the ArbitrumDAO Constitution.
Additionally, a new privilege has been added to the proposal text that proposes that the ArbitrumDAO be granted the right to pause or disable Timeboost, for any reason, using the outcome of a vote on Snapshot, rather than a full Constitutional Vote. 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).
Please find below the responses to the points you’ve raised:
We acknowledge that, over time, a single actor could begin to bid accurately/fairly before deciding to lower their bids. However, we don’t believe that this behavior will allow the single actor to maintain control of the Express Lane over the long term for two reasons. First, the bids submitted to the autonomous auctioneer are private, meaning that the single actor would need to make bids without knowing what other people are bidding and always bid more than the other, unknown parties. This scenario is a game of incomplete information or a Bayesian game where the optimal strategy for the single actor is to bid to maximize their expected profit given the information they have. In other words, a rational, profit-seeking actor would only bid what they are willing to pay and up to the amount that they believe the Express Lane time advantage is worth to them. All participants in this game have incomplete information (what other participants have bid) and so it is not in the best interest of participants to lower their bids or else they risk losing the auction. Secondly, if a single actor was bidding low (relative to the value they were able to extract while in control of the Express Lane) and were still winning the auction, then the Arbitrum DAO or the current sequencer operator can act to raise the minimum bid to compensate for this behavior. An additional point to be made here is that the on-chain monitoring will not be for monopolistic behavior, but for the bid amounts compared to the available MEV on an Arbitrum chain. We believe that so long as the bid amounts are close to the available MEV of the chain, then it does not materially make a difference if there is 1 auction participant or 1000 participants or if there is monopolistic behavior occurring.
This is valuable feedback, thank you! In the current proposal that is subject to the DAO’s approval, either the current sequencer operator, the Arbitrum DAO, or the Security Council could intervene to pause Timeboost or decrease the nominal delay on non-Express Lane transactions if there is conclusive evidence that chain’s UX has been negatively impacted or has been materially degraded because of Timeboost. As a result, close monitoring of user behavior and UX impacts from Timeboost (if Timeboost is approved) will be critical and a top priority for Offchain Labs. We hope that other members of the ecosystem will contribute to this type of analysis and subsequent discussions as well! The results of these analyses will be instrumental in determining how best to adjust or fine-tune Timeboost’s parameters in the long run.
One of Timeboost’s goals is to reduce spam. The expectation is that, for searchers, using the Express Lane will be both cheaper and yield better returns than investing in off-chain hardware and strategies to win latency races. As a result of this, searchers are incentivized to participate in Timeboost auctions instead of resorting to spamming. One thing to point out is that Timeboost is not meant or expected to eliminate spam. Spam, and all transactions generally, all contribute to network congestion. This congestion manifests itself as higher L2 gas prices once the network has reached the speed target of 7 MGas/s (the default for Arbitrum chains). In other words, each time the L2 base fee rises, some form or amount of spam is contributing to that rise - regardless of who the spam is coming from. A reduction in the spam happening on the network should ultimately result in less congestion, allowing for more transactions to be executed at lower gas prices (because congestion pricing kicks in later).
There is currently no data to suggest that this will happen. However, if this behavior is positively identified and the whale(s) is bidding unfairly low, the reservePrice can be increased by the DAO (or the Security Council in cases where doing so is permitted in accordance to the Arbitrum DAO Constitution) to financially disincentivize and deter this behavior. Determining the right value of the reservePrice in this situation, however, will not be straightforward. Therefore, it is important that the Arbitrum DAO works collaboratively together 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 are in control of 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.
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 how Timeboost is being used 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.
Timeboost is purely additive to an Arbitrum chain’s infrastructure, and does not pose a risk to “break” the Arbitrum chains. A Timeboost-enabled Arbitrum chain will fall back to the current FCFS ordering policy if (1) Timeboost is turned “off” (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.
The first aspect that remains unclear is the exact scope of the Timeboost initiative, from the DAO perspective: is it first intended to address spam transactions stemming from FCFS arbitrage (which inadvertently increases gas fees and adds congestion to the network), or is it designed to generate revenue for the DAO? While the answer could be both, understanding the primary objective is crucial for determining the best mechanisms and parameters to implement. This ties into a fundamental principle we cannot overlook: we must prioritize ensuring the best user experience and the optimal functioning of the chain, for users and protocols, before seeking revenue. Ultimately, it seems that for many of us the proposal appears to be more revenue-focused, and much of the discussion has been shaped by this perspective.
To help address some of the common misunderstandings we've seen around Timeboost, Offchain Labs has published a blog by Ed Felten entitled "Debunking Common Misconceptions About Timeboost".
The original blog can be found at:
https://medium.com/offchainlabs/debunking-common-misconceptions-about-timeboost-92d937568494
To help address some of the common misunderstandings we've seen around Timeboost, Offchain Labs has published a blog by Ed Felten entitled "Debunking Common Misconceptions About Timeboost".
The original blog can be found at:
https://medium.com/offchainlabs/debunking-common-misconceptions-about-timeboost-92d937568494
To more easily facilitate discussion of the topics in the blog with the Arbitrum community, Offchain Labs is also cross-posting the blog content here in its entirety.
We look forward to your feedback and answering any additional questions.
===[begin]===
Debunking Common Misconceptions About Timeboost
By: Ed Felten
As the DAO discusses Timeboost, a new transaction ordering policy for Arbitrum chains, there has been some confusion around what Timeboost actually does. As with anything new, we understand there are bound to be misunderstandings, so we wanted to clarify some of the most common misconceptions.
Misconception #1:
Arbitrum uses the same model for transaction ordering and block building as Ethereum L1, so L1 MEV issues automatically apply to Arbitrum.
The reality:
Arbitrum’s sequencing method is substantially different from Ethereum L1’s. Arbitrum uses a First-Come, First-Served (FCFS) model to determine transaction ordering, meaning that transactions are sequenced in the order in which they arrive. Arbitrum sequencing is also done continuously, rather than building each block all at once. This misunderstanding of Arbitrum transaction ordering leads to other misunderstandings of how Timeboost works.
Misconception #2:
Timeboost Creates New Types of MEV Extraction.
The reality:
Timeboost does not create new types of Maximum Extractable Value (MEV). Instead, it introduces slight adjustments to when and how existing forms of MEV operate. Timeboost is designed to strike a balance between capturing MEV value for the chain without introducing additional externalities.
For example, Timeboost does not enable transaction reordering in a way that facilitates sandwich attacks. The protocol does allow users to try to get their transactions processed earlier by gaining control of the express lane, but it doesn’t allow them to manipulate the order in which trades occur relative to others in the same block. This means the fast lane controller [at any given time] cannot be certain of how their transactions are ordered relative to others’ transactions.
Misconception #3:
Timeboost gives the auction winner an unfair amount of power around transaction ordering.
The reality:
Winning a Timeboost auction gives you a time advantage — specifically, a proposed 200ms “head start” — but it does not ensure your transaction will always be the first in every block. The perceived value of the express lane is pre-determined by its holder and how much they chose to bid to win control of it: it’s a use it or lose it privilege. Let’s be clear on what Timeboost does not do:
Misconception #4:
Timeboost will definitely be monopolized by powerful, centralized entities that ultimately harm the Arbitrum ecosystem.
The reality:
Timeboost is designed as an auction-based system that encourages open competition. Although the idea of a monopoly can be scary, the auction process is still competitive. If one player dominates, they will be required to continuously outbid other users, which prevents complete static control. Additionally, the express lane only gives a 200ms time advantage**.** The system is designed to incentivize rational actors to participate when they believe there is an advantage to controlling the express lane and only bid up to the value they are willing to pay for that advantage (since it is a sealed-bid auction).
Finally, we want to stress that Timeboost is entirely optional, meaning that Arbitrum chains can still function normally without it. Should Timeboost need to be disabled, the network would smoothly revert to FCFS transaction ordering, maintaining its current security and efficiency. Every chain can make its own decision about whether to enable Timeboost–your chain, your rules.
Misconception #5:
The goal of Timeboost is to capture all MEV value and completely eliminate spam.
The reality:
As stated in the AIP, Timeboost’s goal is to provide a way for chain owners to capture a significant share of the MEV on their chain and reduce spam from FCFS arbitrage, all while preserving a best-in-class user experience with fast block times and protection against harmful MEV.
===[end]===
In anticipation of Timeboost progressing to an on-chain vote before the end of the month, Offchain Labs has created this explainer and expectations post to help educate voting delegates.
In anticipation of Timeboost progressing to an on-chain vote before the end of the month, Offchain Labs has created this explainer and expectations post to help educate voting delegates.
Timeboost is a novel transaction ordering policy developed for Arbitrum chains. Designed through extensive research and collaboration with over 20+ teams from DeFi Projects, traders, MEV searchers and infrastructure builders, Timeboost aims to address key challenges such as spam inefficiencies and Maximal Extractable Value (MEV) while providing significant value to the ArbitrumDAO and the Arbitrum One and Nova chains. With engineering testing nearing completion and audits finalized, it is poised for consideration as a transformative feature for each chain.
Timeboost is not just a technical innovation but a new paradigm for balancing fairness, efficiency, and economic value within the Arbitrum ecosystem.
Learn More: If you have questions, visit the Timeboost FAQ page for additional information and quick answers.
Based on feedback and additional engineering work, the following updates have been made to the Timeboost implementation adjustments section that covers the temporary rights that are requested to be granted to the current sequencer operator:
Based on feedback and additional engineering work, the following updates have been made to the Timeboost implementation adjustments section that covers the temporary rights that are requested to be granted to the current sequencer operator:
Removed the right to impose a minimum balance/deposit for Timeboost auction participants, as this right is no longer considered to be necessary to help mitigate Denial of Service (DoS) attacks. Alternative, more robust mechanisms have been developed and will be put in place instead.
Added 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 above changes will continue to be temporary and granting of these rights (to the current sequencer operator) are ultimately subject to the ArbitrumDAO’s approval.
Modifications to any Timeboost parameter by anyone else will continue to require a constitutional governance vote. The DAO-elected security council will continue to possess the right to 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 herein for the current sequencer operator. More information about the Arbitrum Security Council and their scope of powers can be found in the ArbitrumDAO Constitution.
Additionally, a new privilege has been added to the proposal text that proposes that the ArbitrumDAO be granted the right to pause or disable Timeboost, for any reason, using the outcome of a vote on Snapshot, rather than a full Constitutional Vote. 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).
Please find below the responses to the points you’ve raised:
We acknowledge that, over time, a single actor could begin to bid accurately/fairly before deciding to lower their bids. However, we don’t believe that this behavior will allow the single actor to maintain control of the Express Lane over the long term for two reasons. First, the bids submitted to the autonomous auctioneer are private, meaning that the single actor would need to make bids without knowing what other people are bidding and always bid more than the other, unknown parties. This scenario is a game of incomplete information or a Bayesian game where the optimal strategy for the single actor is to bid to maximize their expected profit given the information they have. In other words, a rational, profit-seeking actor would only bid what they are willing to pay and up to the amount that they believe the Express Lane time advantage is worth to them. All participants in this game have incomplete information (what other participants have bid) and so it is not in the best interest of participants to lower their bids or else they risk losing the auction. Secondly, if a single actor was bidding low (relative to the value they were able to extract while in control of the Express Lane) and were still winning the auction, then the Arbitrum DAO or the current sequencer operator can act to raise the minimum bid to compensate for this behavior. An additional point to be made here is that the on-chain monitoring will not be for monopolistic behavior, but for the bid amounts compared to the available MEV on an Arbitrum chain. We believe that so long as the bid amounts are close to the available MEV of the chain, then it does not materially make a difference if there is 1 auction participant or 1000 participants or if there is monopolistic behavior occurring.
This is valuable feedback, thank you! In the current proposal that is subject to the DAO’s approval, either the current sequencer operator, the Arbitrum DAO, or the Security Council could intervene to pause Timeboost or decrease the nominal delay on non-Express Lane transactions if there is conclusive evidence that chain’s UX has been negatively impacted or has been materially degraded because of Timeboost. As a result, close monitoring of user behavior and UX impacts from Timeboost (if Timeboost is approved) will be critical and a top priority for Offchain Labs. We hope that other members of the ecosystem will contribute to this type of analysis and subsequent discussions as well! The results of these analyses will be instrumental in determining how best to adjust or fine-tune Timeboost’s parameters in the long run.
One of Timeboost’s goals is to reduce spam. The expectation is that, for searchers, using the Express Lane will be both cheaper and yield better returns than investing in off-chain hardware and strategies to win latency races. As a result of this, searchers are incentivized to participate in Timeboost auctions instead of resorting to spamming. One thing to point out is that Timeboost is not meant or expected to eliminate spam. Spam, and all transactions generally, all contribute to network congestion. This congestion manifests itself as higher L2 gas prices once the network has reached the speed target of 7 MGas/s (the default for Arbitrum chains). In other words, each time the L2 base fee rises, some form or amount of spam is contributing to that rise - regardless of who the spam is coming from. A reduction in the spam happening on the network should ultimately result in less congestion, allowing for more transactions to be executed at lower gas prices (because congestion pricing kicks in later).
There is currently no data to suggest that this will happen. However, if this behavior is positively identified and the whale(s) is bidding unfairly low, the reservePrice can be increased by the DAO (or the Security Council in cases where doing so is permitted in accordance to the Arbitrum DAO Constitution) to financially disincentivize and deter this behavior. Determining the right value of the reservePrice in this situation, however, will not be straightforward. Therefore, it is important that the Arbitrum DAO works collaboratively together 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 are in control of 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.
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 how Timeboost is being used 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.
Timeboost is purely additive to an Arbitrum chain’s infrastructure, and does not pose a risk to “break” the Arbitrum chains. A Timeboost-enabled Arbitrum chain will fall back to the current FCFS ordering policy if (1) Timeboost is turned “off” (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.
The first aspect that remains unclear is the exact scope of the Timeboost initiative, from the DAO perspective: is it first intended to address spam transactions stemming from FCFS arbitrage (which inadvertently increases gas fees and adds congestion to the network), or is it designed to generate revenue for the DAO? While the answer could be both, understanding the primary objective is crucial for determining the best mechanisms and parameters to implement. This ties into a fundamental principle we cannot overlook: we must prioritize ensuring the best user experience and the optimal functioning of the chain, for users and protocols, before seeking revenue. Ultimately, it seems that for many of us the proposal appears to be more revenue-focused, and much of the discussion has been shaped by this perspective.
To help address some of the common misunderstandings we've seen around Timeboost, Offchain Labs has published a blog by Ed Felten entitled "Debunking Common Misconceptions About Timeboost".
The original blog can be found at:
https://medium.com/offchainlabs/debunking-common-misconceptions-about-timeboost-92d937568494
To help address some of the common misunderstandings we've seen around Timeboost, Offchain Labs has published a blog by Ed Felten entitled "Debunking Common Misconceptions About Timeboost".
The original blog can be found at:
https://medium.com/offchainlabs/debunking-common-misconceptions-about-timeboost-92d937568494
To more easily facilitate discussion of the topics in the blog with the Arbitrum community, Offchain Labs is also cross-posting the blog content here in its entirety.
We look forward to your feedback and answering any additional questions.
===[begin]===
Debunking Common Misconceptions About Timeboost
By: Ed Felten
As the DAO discusses Timeboost, a new transaction ordering policy for Arbitrum chains, there has been some confusion around what Timeboost actually does. As with anything new, we understand there are bound to be misunderstandings, so we wanted to clarify some of the most common misconceptions.
Misconception #1:
Arbitrum uses the same model for transaction ordering and block building as Ethereum L1, so L1 MEV issues automatically apply to Arbitrum.
The reality:
Arbitrum’s sequencing method is substantially different from Ethereum L1’s. Arbitrum uses a First-Come, First-Served (FCFS) model to determine transaction ordering, meaning that transactions are sequenced in the order in which they arrive. Arbitrum sequencing is also done continuously, rather than building each block all at once. This misunderstanding of Arbitrum transaction ordering leads to other misunderstandings of how Timeboost works.
Misconception #2:
Timeboost Creates New Types of MEV Extraction.
The reality:
Timeboost does not create new types of Maximum Extractable Value (MEV). Instead, it introduces slight adjustments to when and how existing forms of MEV operate. Timeboost is designed to strike a balance between capturing MEV value for the chain without introducing additional externalities.
For example, Timeboost does not enable transaction reordering in a way that facilitates sandwich attacks. The protocol does allow users to try to get their transactions processed earlier by gaining control of the express lane, but it doesn’t allow them to manipulate the order in which trades occur relative to others in the same block. This means the fast lane controller [at any given time] cannot be certain of how their transactions are ordered relative to others’ transactions.
Misconception #3:
Timeboost gives the auction winner an unfair amount of power around transaction ordering.
The reality:
Winning a Timeboost auction gives you a time advantage — specifically, a proposed 200ms “head start” — but it does not ensure your transaction will always be the first in every block. The perceived value of the express lane is pre-determined by its holder and how much they chose to bid to win control of it: it’s a use it or lose it privilege. Let’s be clear on what Timeboost does not do:
Misconception #4:
Timeboost will definitely be monopolized by powerful, centralized entities that ultimately harm the Arbitrum ecosystem.
The reality:
Timeboost is designed as an auction-based system that encourages open competition. Although the idea of a monopoly can be scary, the auction process is still competitive. If one player dominates, they will be required to continuously outbid other users, which prevents complete static control. Additionally, the express lane only gives a 200ms time advantage**.** The system is designed to incentivize rational actors to participate when they believe there is an advantage to controlling the express lane and only bid up to the value they are willing to pay for that advantage (since it is a sealed-bid auction).
Finally, we want to stress that Timeboost is entirely optional, meaning that Arbitrum chains can still function normally without it. Should Timeboost need to be disabled, the network would smoothly revert to FCFS transaction ordering, maintaining its current security and efficiency. Every chain can make its own decision about whether to enable Timeboost–your chain, your rules.
Misconception #5:
The goal of Timeboost is to capture all MEV value and completely eliminate spam.
The reality:
As stated in the AIP, Timeboost’s goal is to provide a way for chain owners to capture a significant share of the MEV on their chain and reduce spam from FCFS arbitrage, all while preserving a best-in-class user experience with fast block times and protection against harmful MEV.
===[end]===
There is currently no data to suggest that this will happen. However, if this behavior is positively identified and the whale(s) is bidding unfairly low, the reservePrice can be increased by the DAO (or the Security Council in cases where doing so is permitted in accordance to the Arbitrum DAO Constitution) to financially disincentivize and deter this behavior. Determining the right value of the reservePrice in this situation, however, will not be straightforward. Therefore, it is important that the Arbitrum DAO works collaboratively together 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 are in control of 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 being captured by the Arbitrum DAO. Timeboost aims to address this spam and value capture gap.
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 how Timeboost is being used 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:
Timeboost is purely additive to an Arbitrum chain’s infrastructure, and does not pose a risk to “break” the Arbitrum chains. A Timeboost-enabled Arbitrum chain will fall back to the current FCFS ordering policy if (1) Timeboost is turned “off” (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 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.
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.
The first aspect that remains unclear is the exact scope of the Timeboost initiative, from the DAO perspective: is it first intended to address spam transactions stemming from FCFS arbitrage (which inadvertently increases gas fees and adds congestion to the network), or is it designed to generate revenue for the DAO? While the answer could be both, understanding the primary objective is crucial for determining the best mechanisms and parameters to implement. This ties into a fundamental principle we cannot overlook: we must prioritize ensuring the best user experience and the optimal functioning of the chain, for users and protocols, before seeking revenue. Ultimately, it seems that for many of us the proposal appears to be more revenue-focused, and much of the discussion has been shaped by this perspective.
As stated in the AIP, the goal of Timeboost is to give chain owners a way to capture available MEV on their chain and reduce spam from FCFS arbitrage all while preserving best-in-class user experience with both fast block times and protection for users from harmful MEV (e.g. frontrunning/sandwich attacks). That being said, any MEV strategy comes with trade-offs though and it is important that the DAO works collaboratively together with the ecosystem to monitor and fine-tune Timeboost over time to strike the right balance of trade-offs.
Any proposed change, technical or otherwise, to Arbitrum One and Nova should prioritize ensuring the best user experience and optimal functioning of the chain ahead of other priorities. Timeboost explicitly embodies this principle in 3 ways through deliberate design decisions outlined below:
Last but not least, some considerations regarding the parameters should be addressed. It doesn’t seem like any specific rationale has been provided for the proposed initial setup (15 seconds auction, 60 seconds monopoly, and 200ms block time delay). How were these parameters chosen, and what will be their broader impact on the ecosystem?
Timeboost’s design is the culmination of over a year of research and development by the team at @offchainlabs , as well as discussions with teams that would be affected by Timeboost. 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 and all Arbitrum builders and users.
The proposed values in this Timeboost proposal were chosen as starting parameters that we believe would strike a fair balance/approach for both arbitrageurs and regular users of Arbitrum chains. All of these parameters, including the ability to disable Timeboost, are controlled by Governance, and can be adjusted (within limits) if experience with Timeboost suggests that is beneficial.
Chaos Lab and Delphi very rightly pointed out the risk that a 60s monopoly could carry, mentioning the potential creation of secondary markets – and the risk of having entities colluding to control arbitrage on the chain. We already mentioned the potential consequences we can foresee for dexes and their users, but could other critical sectors of our chain, such as lending or gambling apps, be impacted by the introduction of this 200ms delay – and if yes, how?
Other sectors of the chain will be impacted by the introduction of the proposed 200ms delay for non-express lane transactions. It remains to be seen what exactly that impact will entail as these sorts of behaviors are incredibly hard to predict ahead of time.
One fact that deserves emphasizing here is that even with Timeboost, Arbitrum One and Nova block times will continue to be industry leading at 250ms. What will change is that some transactions not in the express lane will be delayed to the next block. Preserving the property of fast block times contributes to the great user experience that Arbitrum chains have and continue to be known for. We believe that the property of fast block times, alongside protection against harmful MEV, will continue to attract and retain both users and the pioneering builders behind next-gen applications, including gaming and prediction markets - especially now with Stylus live on mainnet.
should revenue generated for the DAO come at the expense of the chain’s DEX volume (a key metric for any L2) and LPs? If yes, to which extent will this happen, or should this be accepted? We believe having metrics and estimates to refer to and evaluate the potential consequences should be a hard requirement before voting in favor of any proposal of that type.
The decisions around what strategies to use and how to use them to generate revenue from available MEV on Arbitrum One and Nova are entirely in the hands of the DAO. Whether or not this revenue comes at the expense of DEX volume, and to what extent, remains to be seen. Without real-world data, it is difficult to accurately predict exactly what will happen.
Collection and monitoring of key metrics will be crucial to evaluating Timeboost’s performance and downstream impacts, over time. The insights gained from such analyses can also be used to inform how the 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:
Also mentioned in the AIP is the fact 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 DAO.
The results are in for the Constitutional AIP: Proposal to adopt Timeboost, a new transaction ordering policy off-chain proposal.
See how the community voted and more Arbitrum stats: https://dhive.io/proposal/1371
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 L2 transaction has been finalized on L1, as part of a batch of transactions posted to Ethereum, which can take 2 epochs or roughly 13 minutes in today’s Proof-of-Stake Ethereum. Read more about these two types of finality here: https://docs.arbitrum.io/how-arbitrum-works/tx-lifecycle.
If Timeboost is enabled 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 be 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. For express lane transactions, there will be no impact on transaction finality, meaning that finality will remain at 250ms and ~13minutes for soft finality and Etheruem-equivalent finality, respectively.
Thank you for your feedback. For your first point about a clearer user interface: users can subscribe to the sequencer feed to view, in live time, the final order of transactions. This sequencer feed can be used both today and in a future world where Timeboost is adopted by the DAO (should the vote pass) to understand the logic of how transactions are sorted.
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 is changed so that transactions signed by the express lane controller are sequenced immediately (similar to FCFS) while other types of transactions are sequenced with a 200ms (proposed) delay.
There is currently no data to suggest that this will happen. However, if this behavior is positively identified and the whale(s) is bidding unfairly low, the reservePrice can be increased by the DAO (or the Security Council in cases where doing so is permitted in accordance to the Arbitrum DAO Constitution) to financially disincentivize and deter this behavior. Determining the right value of the reservePrice in this situation, however, will not be straightforward. Therefore, it is important that the Arbitrum DAO works collaboratively together 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 are in control of 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 being captured by the Arbitrum DAO. Timeboost aims to address this spam and value capture gap.
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 how Timeboost is being used 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:
Timeboost is purely additive to an Arbitrum chain’s infrastructure, and does not pose a risk to “break” the Arbitrum chains. A Timeboost-enabled Arbitrum chain will fall back to the current FCFS ordering policy if (1) Timeboost is turned “off” (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 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.
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.
The first aspect that remains unclear is the exact scope of the Timeboost initiative, from the DAO perspective: is it first intended to address spam transactions stemming from FCFS arbitrage (which inadvertently increases gas fees and adds congestion to the network), or is it designed to generate revenue for the DAO? While the answer could be both, understanding the primary objective is crucial for determining the best mechanisms and parameters to implement. This ties into a fundamental principle we cannot overlook: we must prioritize ensuring the best user experience and the optimal functioning of the chain, for users and protocols, before seeking revenue. Ultimately, it seems that for many of us the proposal appears to be more revenue-focused, and much of the discussion has been shaped by this perspective.
As stated in the AIP, the goal of Timeboost is to give chain owners a way to capture available MEV on their chain and reduce spam from FCFS arbitrage all while preserving best-in-class user experience with both fast block times and protection for users from harmful MEV (e.g. frontrunning/sandwich attacks). That being said, any MEV strategy comes with trade-offs though and it is important that the DAO works collaboratively together with the ecosystem to monitor and fine-tune Timeboost over time to strike the right balance of trade-offs.
Any proposed change, technical or otherwise, to Arbitrum One and Nova should prioritize ensuring the best user experience and optimal functioning of the chain ahead of other priorities. Timeboost explicitly embodies this principle in 3 ways through deliberate design decisions outlined below:
Last but not least, some considerations regarding the parameters should be addressed. It doesn’t seem like any specific rationale has been provided for the proposed initial setup (15 seconds auction, 60 seconds monopoly, and 200ms block time delay). How were these parameters chosen, and what will be their broader impact on the ecosystem?
Timeboost’s design is the culmination of over a year of research and development by the team at @offchainlabs , as well as discussions with teams that would be affected by Timeboost. 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 and all Arbitrum builders and users.
The proposed values in this Timeboost proposal were chosen as starting parameters that we believe would strike a fair balance/approach for both arbitrageurs and regular users of Arbitrum chains. All of these parameters, including the ability to disable Timeboost, are controlled by Governance, and can be adjusted (within limits) if experience with Timeboost suggests that is beneficial.
Chaos Lab and Delphi very rightly pointed out the risk that a 60s monopoly could carry, mentioning the potential creation of secondary markets – and the risk of having entities colluding to control arbitrage on the chain. We already mentioned the potential consequences we can foresee for dexes and their users, but could other critical sectors of our chain, such as lending or gambling apps, be impacted by the introduction of this 200ms delay – and if yes, how?
Other sectors of the chain will be impacted by the introduction of the proposed 200ms delay for non-express lane transactions. It remains to be seen what exactly that impact will entail as these sorts of behaviors are incredibly hard to predict ahead of time.
One fact that deserves emphasizing here is that even with Timeboost, Arbitrum One and Nova block times will continue to be industry leading at 250ms. What will change is that some transactions not in the express lane will be delayed to the next block. Preserving the property of fast block times contributes to the great user experience that Arbitrum chains have and continue to be known for. We believe that the property of fast block times, alongside protection against harmful MEV, will continue to attract and retain both users and the pioneering builders behind next-gen applications, including gaming and prediction markets - especially now with Stylus live on mainnet.
should revenue generated for the DAO come at the expense of the chain’s DEX volume (a key metric for any L2) and LPs? If yes, to which extent will this happen, or should this be accepted? We believe having metrics and estimates to refer to and evaluate the potential consequences should be a hard requirement before voting in favor of any proposal of that type.
The decisions around what strategies to use and how to use them to generate revenue from available MEV on Arbitrum One and Nova are entirely in the hands of the DAO. Whether or not this revenue comes at the expense of DEX volume, and to what extent, remains to be seen. Without real-world data, it is difficult to accurately predict exactly what will happen.
Collection and monitoring of key metrics will be crucial to evaluating Timeboost’s performance and downstream impacts, over time. The insights gained from such analyses can also be used to inform how the 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:
Also mentioned in the AIP is the fact 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 DAO.
The results are in for the Constitutional AIP: Proposal to adopt Timeboost, a new transaction ordering policy off-chain proposal.
See how the community voted and more Arbitrum stats: https://dhive.io/proposal/1371
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 L2 transaction has been finalized on L1, as part of a batch of transactions posted to Ethereum, which can take 2 epochs or roughly 13 minutes in today’s Proof-of-Stake Ethereum. Read more about these two types of finality here: https://docs.arbitrum.io/how-arbitrum-works/tx-lifecycle.
If Timeboost is enabled 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 be 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. For express lane transactions, there will be no impact on transaction finality, meaning that finality will remain at 250ms and ~13minutes for soft finality and Etheruem-equivalent finality, respectively.
Thank you for your feedback. For your first point about a clearer user interface: users can subscribe to the sequencer feed to view, in live time, the final order of transactions. This sequencer feed can be used both today and in a future world where Timeboost is adopted by the DAO (should the vote pass) to understand the logic of how transactions are sorted.
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 is changed so that transactions signed by the express lane controller are sequenced immediately (similar to FCFS) while other types of transactions are sequenced with a 200ms (proposed) delay.
Thank you for your feedback. For your first point about a clearer user interface: users can subscribe to the sequencer feed to view, in live time, the final order of transactions. This sequencer feed can be used both today and in a future world where Timeboost is adopted by the DAO (should the vote pass) to understand the logic of how transactions are sorted.
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 is changed so that transactions signed by the express lane controller are sequenced immediately (similar to FCFS) while other types of transactions are 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 are sorted. Additional documentation and diagrams will be made available to help illustrate this workflow.
To your second point: in this proposal, the ArbitrumDAO can, via governance, change the amount of time that non-express lane transactions are delayed. This parameter, defined as the 'NonExpressDelayMsec', is denominated in miliseconds and is proposed to be 200ms to start.
Hey everyone, here is a compilation of some FAQs that we've gathered from the DAO and relevant stakeholders.
https://arbitrumfoundation.notion.site/Arbitrum-Timeboost-FAQ-bba234acf92e476b8ca5db6855d7da45
Feel free to tag us if there are questions that are not covered in this FAQ document, and we will respond and add on to the list accordingly.
Thank you for your feedback. For your first point about a clearer user interface: users can subscribe to the sequencer feed to view, in live time, the final order of transactions. This sequencer feed can be used both today and in a future world where Timeboost is adopted by the DAO (should the vote pass) to understand the logic of how transactions are sorted.
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 is changed so that transactions signed by the express lane controller are sequenced immediately (similar to FCFS) while other types of transactions are 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 are sorted. Additional documentation and diagrams will be made available to help illustrate this workflow.
To your second point: in this proposal, the ArbitrumDAO can, via governance, change the amount of time that non-express lane transactions are delayed. This parameter, defined as the 'NonExpressDelayMsec', is denominated in miliseconds and is proposed to be 200ms to start.
Hey everyone, here is a compilation of some FAQs that we've gathered from the DAO and relevant stakeholders.
https://arbitrumfoundation.notion.site/Arbitrum-Timeboost-FAQ-bba234acf92e476b8ca5db6855d7da45
Feel free to tag us if there are questions that are not covered in this FAQ document, and we will respond and add on to the list accordingly.
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
--
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
--
Proposed parameters up for the current sequencer operator to change without having to go through a governance vote:
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.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.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, the reservePrice will simply be the minReservePrice.--
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.
Hey everyone, we have made a new section under Timeboost Implementation Adjustments in the original post, which has also been highlighted at the top of the post.
We also want to highlight the change here so that it is maximally visible to the DAO. This will be included in the Snapshot post that will be going live next week.
Hey everyone, we have made a new section under Timeboost Implementation Adjustments in the original post, which has also been highlighted at the top of the post.
We also want to highlight the change here so that it is maximally visible to the DAO. This will be included in the Snapshot post that will be going live next week.
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
NonExpressDelayMsecparameter, 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
maxBidsPerSenderInRoundparameter, 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
reservePriceto respond quickly to opportunities to increase the DAO revenue from Timeboost bid proceeds and/or to mitigate the risks of bidders colluding. To start, thereservePricewill 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 impose a minimum balance/deposit requirement on Timeboost bidders in order to mitigate against active or perceived Denial-of-Service (DoS) attacks. The Arbitrum Foundation and Offchain Labs commits to sharing publicly post-mortems and analyses should this scenario arise.
- 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.
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.
Thank you for your question.
The design outlined in the original Mar 2023 blog post (that features the aforementioned formula for the "time boost") has evolved and is completely different than the one outlined in this AIP. This change in design is an outcome of further research conducted by the Offchain Labs team. We believe the new design (i.e. the current approach) leads to more efficient DeFi markets because it allows faster block times.
Hey everyone, here are the follow up responses to the new questions that have not been previously addressed.
https://forum.arbitrum.foundation/t/constitutional-aip-proposal-to-adopt-timeboost-a-new-transaction-ordering-policy/25167/32?u=dereklee Timeboost is at the beginning of the governance process and must undergo forum discussion here, a Snapshot vote, and an onchain vote (Constitutional AIP) before being adopted on mainnet. Collecting feedback from potential participants and the community is essential throughout the governance process. Changes to the design and/or implementation may be made to address feedback and impact the timelines.
Hey everyone, here are the follow up responses to the new questions that have not been previously addressed.
https://forum.arbitrum.foundation/t/constitutional-aip-proposal-to-adopt-timeboost-a-new-transaction-ordering-policy/25167/32?u=dereklee Timeboost is at the beginning of the governance process and must undergo forum discussion here, a Snapshot vote, and an onchain vote (Constitutional AIP) before being adopted on mainnet. Collecting feedback from potential participants and the community is essential throughout the governance process. Changes to the design and/or implementation may be made to address feedback and impact the timelines.
https://forum.arbitrum.foundation/t/constitutional-aip-proposal-to-adopt-timeboost-a-new-transaction-ordering-policy/25167/27?u=dereklee It is worth clarifying that the participant would have to predict the amount of MEV generated between 15s and 1min 15s in the future - not 1 minute later. This 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). Willing participants are expected to bid continuously for the right to use the express lane in advance so that they (the participants) 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 of time that the participant is in control of the express lane (proposed duration: 1 minute), if the participant wins the auction. If the participant does not win control of the express lane, opportunities that they see in real time can still be exploited, but with a 200ms delay like all other txns (since only the express lane controller has experiences no delay for their txns).
We acknowledge FastLane’s work and the perceived similarity in approach, but we believe the design of Timeboost is fundamentally different from FastLane’s design. We further believe that both designs were aimed at solving different problems. It is our understanding that FastLane sold advantage separately for each AMM market and in txn propagation among peers. Timeboost, on the other hand, sells an advantage in txn inclusion timing and therefore sells the opportunity to profit from MEV altogether.
Additionally, we have edited the first post and included more details under the Specifications section.
Access to the express lane would be auctioned off in one-minute rounds, with the auction happening 15 seconds before the round begins. Bids 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. There are two reserve prices, which determine the minimum bid one can place, that are configurable by the DAO. The first is a “minimum reserve price,” which is set by governance. The second is a “current reserve price.” An address designated by governance can call the auction contract to change the current reserve price to any value greater than or equal to the minimum reserve price. To start, the proposed minimum reserve price is 0.001 ETH or 3 ARB per round (depending on what currency the DAO votes to collect bids in), and there is no address designated to change the current reserve price. The reserve prices are only meant for establishing a minimum bid, and does not represent what the expected value of the express lane will be. There are two main components that facilitate the express lane auction:
Hey everyone, thank you for your questions. Please find the answers to each question in this reply.
What is going to happen if, lets says, every user is deciding to use the fast lane. Who will be the winner then?
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
--
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
--
Proposed parameters up for the current sequencer operator to change without having to go through a governance vote:
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.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.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, the reservePrice will simply be the minReservePrice.--
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.
Hey everyone, we have made a new section under Timeboost Implementation Adjustments in the original post, which has also been highlighted at the top of the post.
We also want to highlight the change here so that it is maximally visible to the DAO. This will be included in the Snapshot post that will be going live next week.
Hey everyone, we have made a new section under Timeboost Implementation Adjustments in the original post, which has also been highlighted at the top of the post.
We also want to highlight the change here so that it is maximally visible to the DAO. This will be included in the Snapshot post that will be going live next week.
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
NonExpressDelayMsecparameter, 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
maxBidsPerSenderInRoundparameter, 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
reservePriceto respond quickly to opportunities to increase the DAO revenue from Timeboost bid proceeds and/or to mitigate the risks of bidders colluding. To start, thereservePricewill 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 impose a minimum balance/deposit requirement on Timeboost bidders in order to mitigate against active or perceived Denial-of-Service (DoS) attacks. The Arbitrum Foundation and Offchain Labs commits to sharing publicly post-mortems and analyses should this scenario arise.
- 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.
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.
Thank you for your question.
The design outlined in the original Mar 2023 blog post (that features the aforementioned formula for the "time boost") has evolved and is completely different than the one outlined in this AIP. This change in design is an outcome of further research conducted by the Offchain Labs team. We believe the new design (i.e. the current approach) leads to more efficient DeFi markets because it allows faster block times.
Hey everyone, here are the follow up responses to the new questions that have not been previously addressed.
https://forum.arbitrum.foundation/t/constitutional-aip-proposal-to-adopt-timeboost-a-new-transaction-ordering-policy/25167/32?u=dereklee Timeboost is at the beginning of the governance process and must undergo forum discussion here, a Snapshot vote, and an onchain vote (Constitutional AIP) before being adopted on mainnet. Collecting feedback from potential participants and the community is essential throughout the governance process. Changes to the design and/or implementation may be made to address feedback and impact the timelines.
Hey everyone, here are the follow up responses to the new questions that have not been previously addressed.
https://forum.arbitrum.foundation/t/constitutional-aip-proposal-to-adopt-timeboost-a-new-transaction-ordering-policy/25167/32?u=dereklee Timeboost is at the beginning of the governance process and must undergo forum discussion here, a Snapshot vote, and an onchain vote (Constitutional AIP) before being adopted on mainnet. Collecting feedback from potential participants and the community is essential throughout the governance process. Changes to the design and/or implementation may be made to address feedback and impact the timelines.
https://forum.arbitrum.foundation/t/constitutional-aip-proposal-to-adopt-timeboost-a-new-transaction-ordering-policy/25167/27?u=dereklee It is worth clarifying that the participant would have to predict the amount of MEV generated between 15s and 1min 15s in the future - not 1 minute later. This 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). Willing participants are expected to bid continuously for the right to use the express lane in advance so that they (the participants) 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 of time that the participant is in control of the express lane (proposed duration: 1 minute), if the participant wins the auction. If the participant does not win control of the express lane, opportunities that they see in real time can still be exploited, but with a 200ms delay like all other txns (since only the express lane controller has experiences no delay for their txns).
We acknowledge FastLane’s work and the perceived similarity in approach, but we believe the design of Timeboost is fundamentally different from FastLane’s design. We further believe that both designs were aimed at solving different problems. It is our understanding that FastLane sold advantage separately for each AMM market and in txn propagation among peers. Timeboost, on the other hand, sells an advantage in txn inclusion timing and therefore sells the opportunity to profit from MEV altogether.
Additionally, we have edited the first post and included more details under the Specifications section.
Access to the express lane would be auctioned off in one-minute rounds, with the auction happening 15 seconds before the round begins. Bids 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. There are two reserve prices, which determine the minimum bid one can place, that are configurable by the DAO. The first is a “minimum reserve price,” which is set by governance. The second is a “current reserve price.” An address designated by governance can call the auction contract to change the current reserve price to any value greater than or equal to the minimum reserve price. To start, the proposed minimum reserve price is 0.001 ETH or 3 ARB per round (depending on what currency the DAO votes to collect bids in), and there is no address designated to change the current reserve price. The reserve prices are only meant for establishing a minimum bid, and does not represent what the expected value of the express lane will be. There are two main components that facilitate the express lane auction:
Hey everyone, thank you for your questions. Please find the answers to each question in this reply.
What is going to happen if, lets says, every user is deciding to use the fast lane. Who will be the winner then?
Hey everyone, thank you for your questions. Please find the answers to each question in this reply.
What is going to happen if, lets says, every user is deciding to use the fast lane. Who will be the winner then?
There is only one winner of the Express Lane auction, with the winner determined by the highest bid during a round.
There are two reserve prices that are configurable by the DAO. The first is a “minimum reserve price,” which is set by governance. The second is a “current reserve price,” which an address designated by governance can call the auction contract to change the current reserve price to any value greater than or equal to the minimum reserve price. To start, the proposed minimum reserve price is 0.001 ETH or 3 ARB per round (depending on what currency the DAO votes to collect bids in), and there is no address designated to change the current reserve price.
Does the starting bid depend on previous time slot bid price helping to capitalise more in periods of high activity or it always starts from the same constant reserve price?
The minimum bid depends on the current reserve price. The minimum bid someone can place has to be at or above the current reserve price.
Prospective bidders can deposit any amount into the auction contract and bid up to the value of their deposit. Bidders benefit by depositing more than their intended bid to conceal their true bid from others. The deposits ensure that funds can always be collected from the winning bidder.
Express lane transactions or bundles aren't associated one-to-one with blocks. A block might have no express lane transactions, or it might include transactions from multiple express lane bundles.
The sequencer never stops and never waits for anything to be submitted.
Normally, when it is time to make the next block, the sequencer takes the express-lane transactions it has received, plus any normal transactions it received at least 200 milliseconds ago, and puts all of them into a block.
If the autonomous auctioneer goes offline or if no bids above the reserve price are received, the sequencer will revert to having no delay imposed on normal transactions.
Is there any existing data on similar implementations on other chains that we could refer to? If not, do we have any projections or models to rely on? Specifically, data on how this change might impact arbitrage behavior – based on the potential increase of transaction costs and block time. How much those increases could impact the current arbitrage opportunities – which in turn might affect traffic? This is a pretty important consideration imho, and having a past study or projections would help assess the potential impact more clearly.
Similar implementations don’t exist on other L2s, however, some chains implement a priority gas auction which can capture a portion of MEV. Estimating how much revenue Timeboost will generate is difficult and based on many factors. There is no reliable way to confidently estimate the amount of arbitrage or backrunning opportunities that will exist on Arbitrum chains in the future. The expectation is the express lane won’t cause an increase in traffic, since the express lane will primarily be used for the same arbitrage and backrunning opportunities that would exist with or without it. Block times will remain 250ms.
The DAO’s recent focus has mostly be on strengthening its treasury and enhancing ARB’s utility, which isn’t a bad thing in itself, but I feel like we’re forgetting there are other options. For instance, could we consider redistributing a portion of the profits (in ARB?) generated to the protocols used by these transactions? This feels like a fair and easy way to incentivize protocols by actually rewarding them for real contributions and activity on the chain.
The DAO is free to distribute Timeboost revenue in any way. However, it may be difficult to attribute the revenue back to the applications that created it.
What type of MEV activity exists today on Arbitrum? What do searchers search for?
Common MEV activities include CEX-DEX arbitrage, cross-DEX, cross-chain MEV, and liquidation backrunning.
Similarly, with this type of timeframe, what kind of transactions would go through the fast lane?
The expectation is that the express lane will be used mostly for arbitrage and backrunning transactions.
We believe this a multi-faceted proposal that represents a significant shift in MEV management and presents a valuable opportunity for Arbitrum.
1. Economic & Technical
We believe this a multi-faceted proposal that represents a significant shift in MEV management and presents a valuable opportunity for Arbitrum.
1. Economic & Technical
The current First-Come First-Serve ordering model is flawed, due to its excessive enablement of MEV Searchers and its failure to capture value. The potential implementation of this proposal would enable the introduction of Timeboost, which allows MEV extraction but in a manner that protects network users and is more efficient at capturing value.
The implementation of this proposal would thus allow Arbitrum to meaningfully innovate on transaction ordering while expanding its set of value-accruing mechanisms.
2. Values, Ethos and Users First Furthermore, Arbitrum's long-term goal and premise is to arguably circumvent and build upon the 'shortcomings and pitfalls' of Ethereum, where maximally extractive activities like sandwich trades and frontrunning profoundly harm and impede user experience.
The implementation of this proposal is aligned with the core values of Arbitrum while solving an important pitfall in the user experience of many crypto users.
3. Value-accrual and Distribution Although exact revenue estimates are challenging, Timeboost is expected to become another revenue-generating source for Arbitrum without compromising user experience. That is undoubtedly another great step forward which enhances Arbitrum's long-term sustainability and viability.
How the newly captured and accrued value is distributed, is a nuanced topic that may require a separate vote, due to the sheer amount of inputs and debates that typically surround value-distributing mechanism proposals (buyback & burn, rev-share to all ARB holders vs. to ARB stakers, distributing ARB vs. ETH, etc.).
Individuals may agree with and be in favour of the implementation and adoption of Timeboost, but may not necessarily agree with and be in favour of any of the proposed value-distributing mechanisms.
In the context of the current options proposed, we find Option 1 (collect ETH) to be the superior option.
At this point in time, the token 'burning' mechanism has been sufficiently time and battle-tested. There have been various implementations of this mechanism across the industry. Yet, according to the existing data (both internal and external) today, it is clear that from a purely economic perspective, none of its implementations tend to fundamentally and efficiently drive value to the underlying token.
From a legal/regulatory perspective, the 'buyback and burn' mechanisms have been deemed a more 'compliant' and viable solution, which is a common reason why many protocols and initiatives still decide to adopt this approach, despite its subpar economic performance.
However, the legal and regulatory landscapes are continuously evolving and changing, while the fundamentals and economics do not. That is why we find Option 1 (collect ETH) to be a superior option.
Additionally, besides the pure assessment of the proposal itself, Express Lane appears to be greatly similar to Fast Lane on Polygon and hence it could be efficient and worthwhile for the two teams to connect and collaborate.
Timeboost is a new transaction ordering policy for Arbitrum chains where participants can bid for the right to get their transactions included slightly faster than anyone else. Importantly, user transactions will still remain private until after they are executed, meaning that no one can frontrun or sandwich users. Timeboost bids are collected by the Arbitrum DAO in either ETH or ARB, depending on DAO approval.
The only difference users should experience is a small delay when submitting their transactions. The default configuration for this delay is 200ms and can be changed by the Arbitrum DAO. This delay is to give the express lane controller an advantage so they are able to include transactions slightly quicker than others. Importantly, user transactions will still remain private until after they are executed, meaning that the express lane controller cannot frontrun or sandwich users.
Timeboost auctions the rights to an 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 this proposal: collecting bids in ETH or collecting bids in ARB.
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.
Depending on which option the Arbitrum DAO chooses, the auction contract can either transfer the proceeds to a designated account or burn them.
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, only parties interested in capturing arbitrage or backrunning opportunities will benefit from winning it. Timeboost works behind the scenes with minimal impact on normal users, generating revenue for the Arbitrum DAO.
Estimating how much revenue Timeboost will generate is difficult and based on many factors. There are no ways to confidently estimate the amount of arbitrage or backrunning opportunities that 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.
Timeboost can be adopted by Orbit chains, and they can also choose different tokens from ETH or ARB to be paid in if they wish. For example, a chain could choose to accept its own token for the auction.
Timeboost will be enabled on internal devnets and Arbitrum Sepolia prior to Arbitrum One and Nova.
Timeboost is at the beginning of the governance process and must undergo forum discussion, a Snapshot vote, and an onchain vote before being adopted on mainnet.
The proposed version of Timeboost is only compatible with a centralized sequencer, however, a future version that works with a decentralized sequencer is under development. This allows us to deliver Timeboost sooner, rather than waiting until the decentralized sequencer is complete.
Hey everyone, thank you for your questions. Please find the answers to each question in this reply.
What is going to happen if, lets says, every user is deciding to use the fast lane. Who will be the winner then?
There is only one winner of the Express Lane auction, with the winner determined by the highest bid during a round.
There are two reserve prices that are configurable by the DAO. The first is a “minimum reserve price,” which is set by governance. The second is a “current reserve price,” which an address designated by governance can call the auction contract to change the current reserve price to any value greater than or equal to the minimum reserve price. To start, the proposed minimum reserve price is 0.001 ETH or 3 ARB per round (depending on what currency the DAO votes to collect bids in), and there is no address designated to change the current reserve price.
Does the starting bid depend on previous time slot bid price helping to capitalise more in periods of high activity or it always starts from the same constant reserve price?
The minimum bid depends on the current reserve price. The minimum bid someone can place has to be at or above the current reserve price.
Prospective bidders can deposit any amount into the auction contract and bid up to the value of their deposit. Bidders benefit by depositing more than their intended bid to conceal their true bid from others. The deposits ensure that funds can always be collected from the winning bidder.
Express lane transactions or bundles aren't associated one-to-one with blocks. A block might have no express lane transactions, or it might include transactions from multiple express lane bundles.
The sequencer never stops and never waits for anything to be submitted.
Normally, when it is time to make the next block, the sequencer takes the express-lane transactions it has received, plus any normal transactions it received at least 200 milliseconds ago, and puts all of them into a block.
If the autonomous auctioneer goes offline or if no bids above the reserve price are received, the sequencer will revert to having no delay imposed on normal transactions.
Is there any existing data on similar implementations on other chains that we could refer to? If not, do we have any projections or models to rely on? Specifically, data on how this change might impact arbitrage behavior – based on the potential increase of transaction costs and block time. How much those increases could impact the current arbitrage opportunities – which in turn might affect traffic? This is a pretty important consideration imho, and having a past study or projections would help assess the potential impact more clearly.
Similar implementations don’t exist on other L2s, however, some chains implement a priority gas auction which can capture a portion of MEV. Estimating how much revenue Timeboost will generate is difficult and based on many factors. There is no reliable way to confidently estimate the amount of arbitrage or backrunning opportunities that will exist on Arbitrum chains in the future. The expectation is the express lane won’t cause an increase in traffic, since the express lane will primarily be used for the same arbitrage and backrunning opportunities that would exist with or without it. Block times will remain 250ms.
The DAO’s recent focus has mostly be on strengthening its treasury and enhancing ARB’s utility, which isn’t a bad thing in itself, but I feel like we’re forgetting there are other options. For instance, could we consider redistributing a portion of the profits (in ARB?) generated to the protocols used by these transactions? This feels like a fair and easy way to incentivize protocols by actually rewarding them for real contributions and activity on the chain.
The DAO is free to distribute Timeboost revenue in any way. However, it may be difficult to attribute the revenue back to the applications that created it.
What type of MEV activity exists today on Arbitrum? What do searchers search for?
Common MEV activities include CEX-DEX arbitrage, cross-DEX, cross-chain MEV, and liquidation backrunning.
Similarly, with this type of timeframe, what kind of transactions would go through the fast lane?
The expectation is that the express lane will be used mostly for arbitrage and backrunning transactions.
We believe this a multi-faceted proposal that represents a significant shift in MEV management and presents a valuable opportunity for Arbitrum.
1. Economic & Technical
We believe this a multi-faceted proposal that represents a significant shift in MEV management and presents a valuable opportunity for Arbitrum.
1. Economic & Technical
The current First-Come First-Serve ordering model is flawed, due to its excessive enablement of MEV Searchers and its failure to capture value. The potential implementation of this proposal would enable the introduction of Timeboost, which allows MEV extraction but in a manner that protects network users and is more efficient at capturing value.
The implementation of this proposal would thus allow Arbitrum to meaningfully innovate on transaction ordering while expanding its set of value-accruing mechanisms.
2. Values, Ethos and Users First Furthermore, Arbitrum's long-term goal and premise is to arguably circumvent and build upon the 'shortcomings and pitfalls' of Ethereum, where maximally extractive activities like sandwich trades and frontrunning profoundly harm and impede user experience.
The implementation of this proposal is aligned with the core values of Arbitrum while solving an important pitfall in the user experience of many crypto users.
3. Value-accrual and Distribution Although exact revenue estimates are challenging, Timeboost is expected to become another revenue-generating source for Arbitrum without compromising user experience. That is undoubtedly another great step forward which enhances Arbitrum's long-term sustainability and viability.
How the newly captured and accrued value is distributed, is a nuanced topic that may require a separate vote, due to the sheer amount of inputs and debates that typically surround value-distributing mechanism proposals (buyback & burn, rev-share to all ARB holders vs. to ARB stakers, distributing ARB vs. ETH, etc.).
Individuals may agree with and be in favour of the implementation and adoption of Timeboost, but may not necessarily agree with and be in favour of any of the proposed value-distributing mechanisms.
In the context of the current options proposed, we find Option 1 (collect ETH) to be the superior option.
At this point in time, the token 'burning' mechanism has been sufficiently time and battle-tested. There have been various implementations of this mechanism across the industry. Yet, according to the existing data (both internal and external) today, it is clear that from a purely economic perspective, none of its implementations tend to fundamentally and efficiently drive value to the underlying token.
From a legal/regulatory perspective, the 'buyback and burn' mechanisms have been deemed a more 'compliant' and viable solution, which is a common reason why many protocols and initiatives still decide to adopt this approach, despite its subpar economic performance.
However, the legal and regulatory landscapes are continuously evolving and changing, while the fundamentals and economics do not. That is why we find Option 1 (collect ETH) to be a superior option.
Additionally, besides the pure assessment of the proposal itself, Express Lane appears to be greatly similar to Fast Lane on Polygon and hence it could be efficient and worthwhile for the two teams to connect and collaborate.
Timeboost is a new transaction ordering policy for Arbitrum chains where participants can bid for the right to get their transactions included slightly faster than anyone else. Importantly, user transactions will still remain private until after they are executed, meaning that no one can frontrun or sandwich users. Timeboost bids are collected by the Arbitrum DAO in either ETH or ARB, depending on DAO approval.
The only difference users should experience is a small delay when submitting their transactions. The default configuration for this delay is 200ms and can be changed by the Arbitrum DAO. This delay is to give the express lane controller an advantage so they are able to include transactions slightly quicker than others. Importantly, user transactions will still remain private until after they are executed, meaning that the express lane controller cannot frontrun or sandwich users.
Timeboost auctions the rights to an 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 this proposal: collecting bids in ETH or collecting bids in ARB.
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.
Depending on which option the Arbitrum DAO chooses, the auction contract can either transfer the proceeds to a designated account or burn them.
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, only parties interested in capturing arbitrage or backrunning opportunities will benefit from winning it. Timeboost works behind the scenes with minimal impact on normal users, generating revenue for the Arbitrum DAO.
Estimating how much revenue Timeboost will generate is difficult and based on many factors. There are no ways to confidently estimate the amount of arbitrage or backrunning opportunities that 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.
Timeboost can be adopted by Orbit chains, and they can also choose different tokens from ETH or ARB to be paid in if they wish. For example, a chain could choose to accept its own token for the auction.
Timeboost will be enabled on internal devnets and Arbitrum Sepolia prior to Arbitrum One and Nova.
Timeboost is at the beginning of the governance process and must undergo forum discussion, a Snapshot vote, and an onchain vote before being adopted on mainnet.
The proposed version of Timeboost is only compatible with a centralized sequencer, however, a future version that works with a decentralized sequencer is under development. This allows us to deliver Timeboost sooner, rather than waiting until the decentralized sequencer is complete.
Citing my comment below:
Citing my comment below:
My stance has not changed, I voted FOR on Snapshot (with collect bids in ETH option) and voted FOR on Tally. Timeboost addresses MEV-related challenges without impacting users and creates another revenue stream for the DAO. The Blockworks estimated, “…additional $19m to $95m increase in annual DAO revenue…” is too compelling to ignore. Lower infrastructure burden in current market conditions is also a plus. After reviewing concerns raised by other delegates, I concluded that the benefits of Timeboost outweigh the drawbacks.
Citing my comment below:
Citing my comment below:
My stance has not changed, I voted FOR on Snapshot (with collect bids in ETH option) and voted FOR on Tally. Timeboost addresses MEV-related challenges without impacting users and creates another revenue stream for the DAO. The Blockworks estimated, “…additional $19m to $95m increase in annual DAO revenue…” is too compelling to ignore. Lower infrastructure burden in current market conditions is also a plus. After reviewing concerns raised by other delegates, I concluded that the benefits of Timeboost outweigh the drawbacks.
As in @web3citizenxyz representation. Voting FOR. Below the rationale:
As in @web3citizenxyz representation. Voting FOR. Below the rationale:
DAOplomats voted FOR this proposal on Tally.
We were in support of the adoption of Timeboost as well as the Nova Fee Sweep proposal when they were initially put up for temp check, and we maintained our support during the onchain vote.
The following reflects the views of L2BEAT’s governance team, composed of @krst and @Sinkas. It’s based on their combined research, fact-checking, and ideation.
We’re voting FOR the proposal.
We’ve previously supported the retroactive sweep of Nova fees into the treasury and the adoption of Timeboost in their respective temp-check votes, as well as the temp-check to execute the combined action.
The following reflects the views of L2BEAT’s governance team, composed of @krst and @Sinkas. It’s based on their combined research, fact-checking, and ideation.
We’re voting FOR the proposal.
We’ve previously supported the retroactive sweep of Nova fees into the treasury and the adoption of Timeboost in their respective temp-check votes, as well as the temp-check to execute the combined action.
After reviewing the proposal’s calldata, we can confirm that the actions that will be carried our are indeed a sweep of the ETH fees from Nova to the DAO’s treasury. However, there’s no onchain action for Timeboost’s adoption, which is understandable given that the ordering policy happens on a sequencer level - something that the DAO doesn’t control.
Voted: Collect bids in ETH to treasury, however based on the discussions from highly technical folks breaking down the potential issues, there is clear reason to deep dive into this more to ensure that we are benefiting the ecosystem more than we are harming it.
We maintain our earlier stance and voted in favour of the adoption of timeboost and Nova fee sweep on tally. https://forum.arbitrum.foundation/t/constitutional-aip-proposal-to-adopt-timeboost-a-new-transaction-ordering-policy/25167/66?u=castlecapital
Vote: Collect bids in ETH to treasury
Type and Proposal Link: Snapshot –> Constitutional AIP: Proposal to adopt Timeboost, a new transaction ordering policy
Voting Rationale Link: https://forum.arbitrum.foundation/t/alex-lumley-savvy-dao-delegate-communication-thread/26147/21
=== COMMENTING ON PROPOSAL: ===
Vote: Collect bids in ETH to treasury
Type and Proposal Link: Snapshot –> Constitutional AIP: Proposal to adopt Timeboost, a new transaction ordering policy
Voting Rationale Link: https://forum.arbitrum.foundation/t/alex-lumley-savvy-dao-delegate-communication-thread/26147/21
=== COMMENTING ON PROPOSAL: ===
We support the adoption of Timeboost as it introduces significant benefits to the Arbitrum ecosystem. Timeboost mitigates front-running attacks, improves transaction fairness by reducing reliance on gas fees, and provides a new revenue stream for the DAO through MEV auctions. Collecting bids in ETH for the treasury ensures future flexibility for the DAO, allowing ETH to be used in multiple ways, including buybacks, burns, or treasury diversification. We appreciate the detailed technical analysis, and while concerns about auction monopolization and user experience persist, these can be mitigated with post-implementation monitoring.
The ITU Blockchain Delegation supports the Constitutional AIP: Proposal to adopt Timeboost with the Collect bids in ETH to treasury option.
Firstly, collecting bids in ETH will reduce the DAO’s dependence on ARB. Secondly, it can provide a stable revenue stream, which can be crucial for funding future initiatives such as staking mechanisms. Finally Timeboost aims to decrease the negative effects of MEV with an auction based express lane. Despite concerns about potential system manipulation and legal risks tied to MEV, we believe the proposal’s benefits, outweigh these risks.
As stated in the Temp Checks - https://forum.arbitrum.foundation/t/constitutional-aip-proposal-to-adopt-timeboost-a-new-transaction-ordering-policy/25167/73?u=bob-rossi & https://forum.arbitrum.foundation/t/aip-timeboost-nova-fee-sweep/28247/39?u=bob-rossi - I agree with the proposal and will be voting "For" on Tally
Having read the proposal, reports, and comments, I voted in favour to this proposal (bids in ETH). Adopting Timeboost does not impact users in regards to value extracted, and it presents another revenue stream for the DAO by capturing some of the available MEV.
ETH can later on be utilized to do any buybacks and burns if needed.
Having read the proposal, reports, and comments, I voted in favour to this proposal (bids in ETH). Adopting Timeboost does not impact users in regards to value extracted, and it presents another revenue stream for the DAO by capturing some of the available MEV.
ETH can later on be utilized to do any buybacks and burns if needed.
Keeping tabs on discussions and points risen by Camelot and leyiang for Tally.
To further the conversation on the impact Timeboost may have on DAO revenue as well as LPs, we want to point everyone in the direction of an ARDC deliverable we just published.
This was not an explicit ask for Blockworks Research to do, but we felt with the recent discourse/concern around Timeboost, it was important for us to put this out there.
To further the conversation on the impact Timeboost may have on DAO revenue as well as LPs, we want to point everyone in the direction of an ARDC deliverable we just published.
This was not an explicit ask for Blockworks Research to do, but we felt with the recent discourse/concern around Timeboost, it was important for us to put this out there.
TL:DR - We estimate that Timeboost could have led to an additional $19m to $95m increase in annual DAO revenue, implying 33-162% growth over the previous twelve months. We believe Timeboost is a net-positive for Arbitrum DAO value capture and that Arbitrum One LPs should still outperform LPs on competing chains. Additionally, we believe the DAO may want to consider a Timeboost Committee to closely monitor Timeboost activity and onchain market conditions, so that it can make informed decisions on adjustments to Timeboost’s parameters in the future.
https://forum.arbitrum.foundation/t/ardc-research-deliverables/23438/13?u=blockworksresearch
Given the discussions around Timeboost, we were asked to address some of the questions highlighted in this thread. We’ll also publish an additional Timeboost analysis in a separate forum post.
Q2: Does increasing block time decrease the number of granular arbitrage opportunities, resulting in less arbitrage activities? (from Camelot, source)
gm, I voted in favor of this proposal, and to collect fees in ETH until the DAO decides how to distribute or that revenue.
Voting "For, Collecting ETH" as this presents a good opportunity to diversify the DAO's treasury.
I definitely value the review from our security experts to understand the depth of these technical proposals.
I’ve decided to vote FOR this proposal, especially regarding collecting bids in ETH for the treasury.
We support this proposal and vote for "Collect bids in ETH to treasury" on Snapshot.
We maintain our stance in the comment posted before and continue to support the progress of the development of Timeboost.
DAOplomats voted in favor of adopting Timeboost, opting to collect bids in ETH.
There are definitely potential benefits to collecting bids in ARB but we opted to go with ETH because of its more wholesome nature. There are several things we could do with the ETH -- one could potentially even be converting to ARB and then burning it. But for now, we say we collect ETH and then decide how we utilize it once it's in the treasury.
Thank you for this clarification. The majority of concerns I have heard have been from the misunderstanding #1 & #3.
DAOplomats voted FOR this proposal on Tally.
We were in support of the adoption of Timeboost as well as the Nova Fee Sweep proposal when they were initially put up for temp check, and we maintained our support during the onchain vote.
The following reflects the views of L2BEAT’s governance team, composed of @krst and @Sinkas. It’s based on their combined research, fact-checking, and ideation.
We’re voting FOR the proposal.
We’ve previously supported the retroactive sweep of Nova fees into the treasury and the adoption of Timeboost in their respective temp-check votes, as well as the temp-check to execute the combined action.
The following reflects the views of L2BEAT’s governance team, composed of @krst and @Sinkas. It’s based on their combined research, fact-checking, and ideation.
We’re voting FOR the proposal.
We’ve previously supported the retroactive sweep of Nova fees into the treasury and the adoption of Timeboost in their respective temp-check votes, as well as the temp-check to execute the combined action.
After reviewing the proposal’s calldata, we can confirm that the actions that will be carried our are indeed a sweep of the ETH fees from Nova to the DAO’s treasury. However, there’s no onchain action for Timeboost’s adoption, which is understandable given that the ordering policy happens on a sequencer level - something that the DAO doesn’t control.
Voted: Collect bids in ETH to treasury, however based on the discussions from highly technical folks breaking down the potential issues, there is clear reason to deep dive into this more to ensure that we are benefiting the ecosystem more than we are harming it.
We maintain our earlier stance and voted in favour of the adoption of timeboost and Nova fee sweep on tally. https://forum.arbitrum.foundation/t/constitutional-aip-proposal-to-adopt-timeboost-a-new-transaction-ordering-policy/25167/66?u=castlecapital
Vote: Collect bids in ETH to treasury
Type and Proposal Link: Snapshot –> Constitutional AIP: Proposal to adopt Timeboost, a new transaction ordering policy
Voting Rationale Link: https://forum.arbitrum.foundation/t/alex-lumley-savvy-dao-delegate-communication-thread/26147/21
=== COMMENTING ON PROPOSAL: ===
Vote: Collect bids in ETH to treasury
Type and Proposal Link: Snapshot –> Constitutional AIP: Proposal to adopt Timeboost, a new transaction ordering policy
Voting Rationale Link: https://forum.arbitrum.foundation/t/alex-lumley-savvy-dao-delegate-communication-thread/26147/21
=== COMMENTING ON PROPOSAL: ===
We support the adoption of Timeboost as it introduces significant benefits to the Arbitrum ecosystem. Timeboost mitigates front-running attacks, improves transaction fairness by reducing reliance on gas fees, and provides a new revenue stream for the DAO through MEV auctions. Collecting bids in ETH for the treasury ensures future flexibility for the DAO, allowing ETH to be used in multiple ways, including buybacks, burns, or treasury diversification. We appreciate the detailed technical analysis, and while concerns about auction monopolization and user experience persist, these can be mitigated with post-implementation monitoring.
The ITU Blockchain Delegation supports the Constitutional AIP: Proposal to adopt Timeboost with the Collect bids in ETH to treasury option.
Firstly, collecting bids in ETH will reduce the DAO’s dependence on ARB. Secondly, it can provide a stable revenue stream, which can be crucial for funding future initiatives such as staking mechanisms. Finally Timeboost aims to decrease the negative effects of MEV with an auction based express lane. Despite concerns about potential system manipulation and legal risks tied to MEV, we believe the proposal’s benefits, outweigh these risks.
As stated in the Temp Checks - https://forum.arbitrum.foundation/t/constitutional-aip-proposal-to-adopt-timeboost-a-new-transaction-ordering-policy/25167/73?u=bob-rossi & https://forum.arbitrum.foundation/t/aip-timeboost-nova-fee-sweep/28247/39?u=bob-rossi - I agree with the proposal and will be voting "For" on Tally
Having read the proposal, reports, and comments, I voted in favour to this proposal (bids in ETH). Adopting Timeboost does not impact users in regards to value extracted, and it presents another revenue stream for the DAO by capturing some of the available MEV.
ETH can later on be utilized to do any buybacks and burns if needed.
Having read the proposal, reports, and comments, I voted in favour to this proposal (bids in ETH). Adopting Timeboost does not impact users in regards to value extracted, and it presents another revenue stream for the DAO by capturing some of the available MEV.
ETH can later on be utilized to do any buybacks and burns if needed.
Keeping tabs on discussions and points risen by Camelot and leyiang for Tally.
To further the conversation on the impact Timeboost may have on DAO revenue as well as LPs, we want to point everyone in the direction of an ARDC deliverable we just published.
This was not an explicit ask for Blockworks Research to do, but we felt with the recent discourse/concern around Timeboost, it was important for us to put this out there.
To further the conversation on the impact Timeboost may have on DAO revenue as well as LPs, we want to point everyone in the direction of an ARDC deliverable we just published.
This was not an explicit ask for Blockworks Research to do, but we felt with the recent discourse/concern around Timeboost, it was important for us to put this out there.
TL:DR - We estimate that Timeboost could have led to an additional $19m to $95m increase in annual DAO revenue, implying 33-162% growth over the previous twelve months. We believe Timeboost is a net-positive for Arbitrum DAO value capture and that Arbitrum One LPs should still outperform LPs on competing chains. Additionally, we believe the DAO may want to consider a Timeboost Committee to closely monitor Timeboost activity and onchain market conditions, so that it can make informed decisions on adjustments to Timeboost’s parameters in the future.
https://forum.arbitrum.foundation/t/ardc-research-deliverables/23438/13?u=blockworksresearch
Given the discussions around Timeboost, we were asked to address some of the questions highlighted in this thread. We’ll also publish an additional Timeboost analysis in a separate forum post.
Q2: Does increasing block time decrease the number of granular arbitrage opportunities, resulting in less arbitrage activities? (from Camelot, source)
gm, I voted in favor of this proposal, and to collect fees in ETH until the DAO decides how to distribute or that revenue.
Voting "For, Collecting ETH" as this presents a good opportunity to diversify the DAO's treasury.
I definitely value the review from our security experts to understand the depth of these technical proposals.
I’ve decided to vote FOR this proposal, especially regarding collecting bids in ETH for the treasury.
We support this proposal and vote for "Collect bids in ETH to treasury" on Snapshot.
We maintain our stance in the comment posted before and continue to support the progress of the development of Timeboost.
DAOplomats voted in favor of adopting Timeboost, opting to collect bids in ETH.
There are definitely potential benefits to collecting bids in ARB but we opted to go with ETH because of its more wholesome nature. There are several things we could do with the ETH -- one could potentially even be converting to ARB and then burning it. But for now, we say we collect ETH and then decide how we utilize it once it's in the treasury.
Thank you for this clarification. The majority of concerns I have heard have been from the misunderstanding #1 & #3.
Given the discussions around Timeboost, we were asked to address some of the questions highlighted in this thread. We’ll also publish an additional Timeboost analysis in a separate forum post.
Q2: Does increasing block time decrease the number of granular arbitrage opportunities, resulting in less arbitrage activities? (from Camelot, source)
[Full Question] Camelot raised concerns that Timeboost could add an additional cost to capturing arbitrage and thus potentially reduce arbitrage activity. They added a side effect of this concern is decreasing "the number of granular arbitrage opportunities." By extension, could we see some arbitrageurs slowing down or simply halting their activities on Arbitrum? If you can’t secure the express lane for yourself, would there still be enough incentives to remain highly reactive to arbitrage opportunities as we have observed thus far?
First, we've noticed some mixed thoughts around the community about this fact, so we'll start off by clarifying: Timeboost does NOT increase Arbitrum's block times. Block times are still 250ms, and the only difference is express lane controllers now have 200ms time advantage. But after those 200ms are finished, traders get included by the sequencer on a FCFS basis for the remaining 50ms. Arbitrum blocks are still extremely short compared to other chains (e.g. Solana and Optimism have 400ms and 2s blocks, respectively).
Pre-Timeboost, capturing arbitrage in a first-come-first-serve (FCFS) setting strictly depends on latency i.e. how quickly you can communicate with the sequencer. This includes both how fast you can reach the sequencer, how quickly you receive messages from the sequencer, and the quality of your signal. We think this suppresses the amount of arbitrage on Arbitrum, relative to other chains with longer block times and mechanisms such as priority fees and PBS, because you have to both invest in the best hardware and physically be as close to Arbitrum’s sequencer (rent an office right above it), which is a high (and more concentrated) capital requirement, to capture arbitrage.
This research studied maximal arbitrage value (MAV) and LVR across Ethereum and select rollups (Arbitrum, Optimism, Base, and Zksync) on Uniswap v3 and finds the average MAV opportunity ($19.68) on Arbitrum lasts for about 6.9 seconds. One might think, how does a $20 arbitrage opportunity exist for that long? While it seems the authors do not elaborate on why this is the case, we think it has to do with the costs and risks of executing that trade in the absence of something like PBS or priority fees–wherein, instead of the determinants of the game being strictly latency, it becomes a game about latency and pricing arbitrage. In other words, in a FCFS environment, the capital requirements and risks associated with capturing that arbitrage opportunity is too high relative to the opportunity, until it reaches a point at which the price discrepancy is large enough given variable market conditions. This period of time (or decay) sometimes spans multiple blocks.
Timeboost explicitly grants a time advantage for transaction inclusion to anyone that is able to buy it, which will alter the costs and risks of capturing arbitrage in such a way that attracts new traders to the ecosystem.
Our expectation is that, by introducing an express lane that has no delay (while other transactions have a 200ms delay), Timeboost should lower the execution risks and costs for capturing arbitrage opportunities, creating market structures and conditions in which arbitrageurs can pay the DAO to adjust price discrepancies potentially over smaller periods of time (decay).
That said, there is valid concern about Timeboost increasing CEX-DEX arbitrage and thus LVR. However, these arbitrage opportunities (as well as other kinds of arbitrage) should still exist in a similar fashion as they do pre-Timeboost. More aptly, if a CEX-DEX arbitrageur owns the express lane and gets a signal for an arbitrage opportunity–there may be some amount of time they can wait before sending the transaction, however, with 250ms block times–they should be sending a transaction to capture that opportunity as fast as possible (before the end of the 200ms express lane slot), because if they don’t someone else competing in FCFS (non-express lane users) will capture it. This doesn't seem materially different from pre-Timeboost conditions i.e. receiving a signal and sending transactions to the sequencer as fast as possible. Put differently, Timeboost shouldn't explicitly reduce the level of entropy in the system--it offers a way in which traders can price it and therefore capture it.
In any case, Timeboost might actually have a neutral effect on LPs and, instead of traders capturing all of the LVR, the DAO will capture some of it. Additionally, it seems Timeboost’s effect on Arbitrum LVR depends on the time delta between CEX-DEX arbitrage signals, or how long a vertically integrated searcher must usually wait in order to exploit LVR. This is an interesting topic for future research.
Thus, while we do not have empirical evidence for what we can expect for a transition to an express lane auction (from FCFS), our base case is Timeboost should not drastically affect the rate of arbitrage, or the amount of LVR, and we lean toward there being slightly more arbitrage by virtue of attracting new traders. It is also worth noting LPs on Arbitrum will still be better off than LPs on other L2s, according to the prevailing AMM and LVR literature (here, here, and here). Other important factors that determine changes to LVR, and arbitrage activity more broadly, include retail participation, volatility, swap fees, and liquidity. Note: this response is only with respect to non-atomic arbitrage (CEX-DEX). There is an entire category of atomic arbitrage that should also benefit from Timeboost.
I definitely value the review from our security experts to understand the depth of these technical proposals.
I’ve decided to vote FOR this proposal, especially regarding collecting bids in ETH for the treasury.
I believe diversification is important and contributes to the sustainability goals we are pursuing as a DAO.
We support this proposal and vote for "Collect bids in ETH to treasury" on Snapshot.
We maintain our stance in the comment posted before and continue to support the progress of the development of Timeboost.
We have also support the adjustments around a few parameters to be adjustable by Offchain Labs to fine-tune the design and achieve the stability, user experience and economics for the Arbitrum DAO. Also, interested in the future improvement partnering with the Espresso team.
One question for @Arbitrum (or Offchain Labs),
How do you make sure of those when modifying the parameters in question? Do you have some kind of A/B test system to try different parameters to evaluate the key metrics?
Thank you for this clarification. The majority of concerns I have heard have been from the misunderstanding #1 & #3.
Arbitrum uses the same model for transaction ordering and block building as Ethereum L1, so L1 MEV issues automatically apply to Arbitrum.
Timeboost gives the auction winner an unfair amount of power around transaction ordering.
I feel that Timeboost is "safe to try" reading this well-articulated reasoning along with the great work by @BlockworksResearch and @chaoslabs to come to an understanding around the rebalancing effect on LPs.
I voted to collect bids in ARB. Blockworks and Chaos Labs reasoning and research provided a strong case for the adoption of this feature.
After consideration, the @SEEDgov delegation has decided to vote “Collect bids in ETH to the treasury” on this proposal at the Snapshot vote.
In the first instance, we welcome the socialisation with the DAO of the gains of those who capture MEV without creating changes to the user experience.
After consideration, the @SEEDgov delegation has decided to vote “Collect bids in ETH to the treasury” on this proposal at the Snapshot vote.
In the first instance, we welcome the socialisation with the DAO of the gains of those who capture MEV without creating changes to the user experience.
However, having read ARDC’s comparison of Timeboost to other transaction ordering policies, and ARDC’s risk analysis of Timeboost, we would like to highlight the importance of post-implementation monitoring. Without reporting, the DAO will lack the necessary tools to be able to follow the outcome and drive changes in the pre-established parameters. Just to give an example, the reservePrice parameter can be modified to avoid collusion at the auction stage, without active monitoring of bids it will be difficult for the DAO to mitigate these risks in a timely manner.
Finally, we agree with @WintermuteGovernance:
If we collect bids in ETH, we can always buy back and burn ARB, but we can’t grow the treasury in a diversified manner if we collect bids in ARB.
This option gives the possibility to decide in the future what to do with the revenue coming from Timeboost and since there are currently active discussions on Treasury Management/Diversification as well as a working group on ARB Staking has been created, we believe it is best to decide the fate of this revenue flow in the context of these two verticals.
I vote in favor of implementing Timeboost to enhance DAO revenue because I believe that every user would appreciate having an express lane for their transactions. Specifically, I support the option to collect bids in ARB and burn the proceeds. Burning ARB reduces its supply, which could raise the value of the remaining tokens
Camelot is voting ABSTAIN on the Timeboost proposal.
This decision is not due to a lack of belief in the idea's value, but rather stems from the absence of thorough analysis, both in the proposal and in the risk reports.
—
Camelot is voting ABSTAIN on the Timeboost proposal.
This decision is not due to a lack of belief in the idea's value, but rather stems from the absence of thorough analysis, both in the proposal and in the risk reports.
—
The first aspect that remains unclear is the exact scope of the Timeboost initiative, from the DAO perspective: is it first intended to address spam transactions stemming from FCFS arbitrage (which inadvertently increases gas fees and adds congestion to the network), or is it designed to generate revenue for the DAO? While the answer could be both, understanding the primary objective is crucial for determining the best mechanisms and parameters to implement. This ties into a fundamental principle we cannot overlook: we must prioritize ensuring the best user experience and the optimal functioning of the chain, for users and protocols, before seeking revenue. Ultimately, it seems that for many of us the proposal appears to be more revenue-focused, and much of the discussion has been shaped by this perspective.
—
We can further analyze the proposal in the context of DEXes and LPers, which will be among the most potentially impacted by it. While setting up a proper MEV infrastructure is critical on a chain, it's also important to remember that arbitrage has been and will always be an essential component of any economic system. Timeboost implementation is highly likely to have an impact on DEX volume – to start with the most obvious point, simply because adding an additional cost to the process will naturally reduce arbitrage. Increasing block time (~doubling it with the current 200ms proposed parameter) will also probably have direct consequences by decreasing the number of granular arbitrage opportunities. Those might not be the only effects and it is very surprising that neither the proposal nor the analysis from ARDC made any significant effort to define or quantify this potential impact – and other consequences regarding general arbitrageur behavior, that could potentially be broader than anticipated.
For instance, could we see some arbitrageurs slowing down or simply halting their activities on Arbitrum? If you can't secure the express lane for yourself, would there still be enough incentives to remain highly reactive to arbitrage opportunities as we have observed thus far? There also wasn't any study as far as we know on the economic consequences, beyond the potential decrease in DEX volume, for LPs. As previously mentioned, adding a 200ms delay would naturally increase LVR and raise the cost of liquidity provisioning – which is something we shouldn't overlook, and should properly measure.
In other words this could be summarized with a very simple question: should revenue generated for the DAO come at the expense of the chain's DEX volume (a key metric for any L2) and LPs? If yes, to which extent will this happen, or should this be accepted? We believe having metrics and estimates to refer to and evaluate the potential consequences should be a hard requirement before voting in favor of any proposal of that type.
—
Last but not least, some considerations regarding the parameters should be addressed. It doesn't seem like any specific rationale has been provided for the proposed initial setup (15 seconds auction, 60 seconds monopoly, and 200ms block time delay). How were these parameters chosen, and what will be their broader impact on the ecosystem?
Chaos Lab and Delphi very rightly pointed out the risk that a 60s monopoly could carry, mentioning the potential creation of secondary markets – and the risk of having entities colluding to control arbitrage on the chain. We already mentioned the potential consequences we can foresee for dexes and their users, but could other critical sectors of our chain, such as lending or gambling apps, be impacted by the introduction of this 200ms delay -- and if yes, how?
Assuming this proposal passes, which seems likely due to its revenue-driven nature, there must be in-depth monitoring and analysis of the consequences and the parameters chosen, that would allow for necessary adjustments and tuning based on the results. To this day, it appears that no specific method or general plan for monitoring and responding to these changes has been outlined.
—
As a final note, we hope that in the future, for proposals of such importance and criticality, risk analysis from Delphi, Chaos Lab, and ADPC are made available well in advance of the vote. This would provide the DAO with sufficient time to discuss and analyze the pros and cons, rather than receiving this information either right before or during the voting period.
—
To be absolutely clear, the goal of this feedback is not to stop the proposal. It is obvious that there is consensus in the DAO, particularly because the proposal is revenue-driven.
That being said, we believe at Camelot that what has been built in Arbitrum so far should not be jeopardized by the promise of future revenue for the DAO without a thorough analysis of what we might also lose in the process. This doesn't mean that our technological foundation and economic model should be monolithic; however, implementing such a significant change without establishing checks and balances to monitor key ecosystem activities, and without a contingency plan to mitigate potential negative outcomes, is not only incomplete but also risky.
We urge the DAO, if the collective decision is to move forward with this initiative, to carefully consider the potential risks and implement strong safeguards to protect the ecosystem.
We are in favor of adopting the Timeboost transaction ordering policy. This implementation will introduce several key benefits to the Arbitrum ecosystem:
We are in favor of adopting the Timeboost transaction ordering policy. This implementation will introduce several key benefits to the Arbitrum ecosystem:
We believe the introduction of Timeboost will be a valuable addition to the Arbitrum protocol, benefiting both the community and the DAO by enhancing the performance and economic incentives of the ecosystem.
We have reviewed the new version of the proposal and the ARDC comment. We are in favor of this proposal and support collecting bids in ETH. While the buyback and burn of ARB could increase its utility, we believe this approach offers greater long-term sustainability.
The following reflects the views of the Lampros Labs DAO governance team, composed of @Blueweb, @Euphoria, and Hirangi Pandya (@Nyx), based on our combined research, analysis, and ideation.
We are voting FOR this proposal with the option to collect bids in ETH to the treasury.
The following reflects the views of the Lampros Labs DAO governance team, composed of @Blueweb, @Euphoria, and Hirangi Pandya (@Nyx), based on our combined research, analysis, and ideation.
We are voting FOR this proposal with the option to collect bids in ETH to the treasury.
We believe this is a well-researched and well-thought-out proposal that can only be properly evaluated through real-world data. Timeboost offers a unique way for ArbitrumDAO to capture value from MEV activity while having a minimal effect on regular users.
We believe that generating revenue should be a key focus for the DAO’s long-term sustainability, and Timeboost provides a good mechanism for this. Collecting bids in ETH keeps future options open, unlike burning ARB tokens. Once we have real-world data, we will be better positioned to decide how to handle the revenue, whether through distribution or token burning.
I have been asked this question by some members which you may want to answer and add it in the FAQ
I agree with this proposal cause the whole new transaction ordering policy can:
On behalf of the UADP, we think adopting the Timeboost as the new transaction ordering policy brings many advantages for the network's long-term health.
Some benefits we were sold on:
On behalf of the UADP, we think adopting the Timeboost as the new transaction ordering policy brings many advantages for the network's long-term health.
Some benefits we were sold on:
We chose ETH as it was the most logical in our opinion, there should be more inflows to the DAO in ETH and we think there's a true case or arguement to make this be the defacto type of inbound token.
We can always buy back and burn ARB if we collect bids in ETH, but we can’t grow the treasury in a diversified manner if we collect bids in ARB.
Completely agree. ETH is the more cautionary approach imo.
I fully support the adoption of Timeboost and voted for the option to collect bids in ETH. This will allow an increased efficency and user experience. Concerning the option, collecting fees in ETH makes more sense to me, even after reading the different perspectives on the forum.
The FranklinDAO/Penn Blockchain Team has voted for the option of collect fees in ETH. We believe that more discussion is needed on where Timeboost fees should be distributed - whether to ARB stakers, applications that created the MEV opportunity, burned, or a mix of these options. Further, 3.7B ARB tokens (or 37% of total supply) have yet to be unlocked, with vesting to Investors/Team & Advisors continuing linearly until March 2027 (link). A later discussion is needed to decide when the right time is for an ARB burn mechanism. In the meantime, we believe growing the DAO's ETH reserves is a good idea.
A couple things we wanted to mention/ask:
I voted to collect bids in ETH and send to treasury on the temp check proposal.
Timeboost is an innovative approach to transaction ordering that creates a more efficient market and internalizes surplus value for the Arbitrum DAO. It's a clear win for the Arbitrum ecosystem as whole relative to the current first-come-first-served system. I'm comfortable with Offchain Lab's development approach from a security perspective.
I voted to collect bids in ETH and send to treasury on the temp check proposal.
Timeboost is an innovative approach to transaction ordering that creates a more efficient market and internalizes surplus value for the Arbitrum DAO. It's a clear win for the Arbitrum ecosystem as whole relative to the current first-come-first-served system. I'm comfortable with Offchain Lab's development approach from a security perspective.
I prefer collecting the fees in ETH because it creates a natural treasury diversification mechanism while preserving decentralization.
Just cast my vote in favor of collecting bids in ETH for the treasury. I see this as a stronger long-term move for the DAO, securing funds for development and ecosystem growth. Don't think it's the right time to tinker with ARB’s inflation/dilution. Definitely interested to see how the testing phase plays out before full implementation.
The following reflects the views of L2BEAT’s governance team, composed of @krst and @Sinkas, and it’s based on the combined research, fact-checking, and ideation of the two.
We’re voting FOR this proposal and opting for bids to be collected in ETH in the treasury.
The following reflects the views of L2BEAT’s governance team, composed of @krst and @Sinkas, and it’s based on the combined research, fact-checking, and ideation of the two.
We’re voting FOR this proposal and opting for bids to be collected in ETH in the treasury.
After reviewing the proposal, reading ARDC’s comparison of Timeboost to other transaction ordering policies, and ARDC’s risk analysis of Timeboost, we are supportive of its adoption on Arbitrum.
Collecting bids in ETH and letting it accumulate in the treasury is a more sensible approach. However, we’re also generally supportive of ARB buybacks and burns in a more general context, and perhaps we could see another proposal in the DAO to do that, utilizing the ETH in the treasury at a later date.
Having ETH enables the DAO to have more options that could bolster ARB’s utilitiy, including that of buying ARB from the market to burn it. If we directly collect bids in ARB and burn them, we limit our options from the start. Apart from burning ARB, mitigating against inflation and token unlocks could also be achieved through other means, such as Tally's recently approved staking proposal.
Lastly, similar to other technical proposals we’ve had in the past, we’ll verify the executable of the proposal once it goes onchain before casting our vote.
Agreed, this proposal is very well planned, lays out a complete plan, steps for implementation, and the community feels it is very reasonable
The Timeboost proposal should it offers a sustainable way for ArbitrumDAO to generate additional revenue without compromising user experience or security. With the implemention of an auction-based system for express transaction lanes, Timeboost will ensure that MEV ops can be captured by the DAO rather than by private searchers alone.
When it comes to the options to collect bids in either ETH or ARB we are in favor of ETH. This diversifies away more dependence of the DAO on ARB and should decrease risks. Overall, Timeboost balances offer a robust, permissionless system that aligns with the ethos of the DAO.
current sequencer operator the below rights to make the following adjustments from time to time for a period of two (2) years
Will these changes be made without community discussion or through on-chain voting?
We voted to collect bids in ETH. Reasoning:
Treasury Diversification Arbitrum DAO's ETH holdings are tiny relative to its ARB holdings. Adding to that in any and all ways possible is just a generally good idea.
We voted to collect bids in ETH. Reasoning:
Treasury Diversification Arbitrum DAO's ETH holdings are tiny relative to its ARB holdings. Adding to that in any and all ways possible is just a generally good idea.
Optionality of MEV share There's a recent movement towards applications collecting MEV, including discussion in this thread. Collecting bids in ETH allows for some MEV "profit-share" with apps if that is decided in the future, whereas buying and burning ARB does not.
Questionable Value Accrual of Buy and Burn MakerDAO tried Buy and Burn but value accrual was questionable and it wasnt a good narrative with the market. Staking is a better mechanism for value accrual which aligns long term holders with the protocol, rather than giving value to every token holder indiscriminantly like burning does, and gives more freedom over the precise way value accrues to the token, and also is just a better narrative as shown by LSD market share.
Given the discussions around Timeboost, we were asked to address some of the questions highlighted in this thread. We’ll also publish an additional Timeboost analysis in a separate forum post.
Q2: Does increasing block time decrease the number of granular arbitrage opportunities, resulting in less arbitrage activities? (from Camelot, source)
[Full Question] Camelot raised concerns that Timeboost could add an additional cost to capturing arbitrage and thus potentially reduce arbitrage activity. They added a side effect of this concern is decreasing "the number of granular arbitrage opportunities." By extension, could we see some arbitrageurs slowing down or simply halting their activities on Arbitrum? If you can’t secure the express lane for yourself, would there still be enough incentives to remain highly reactive to arbitrage opportunities as we have observed thus far?
First, we've noticed some mixed thoughts around the community about this fact, so we'll start off by clarifying: Timeboost does NOT increase Arbitrum's block times. Block times are still 250ms, and the only difference is express lane controllers now have 200ms time advantage. But after those 200ms are finished, traders get included by the sequencer on a FCFS basis for the remaining 50ms. Arbitrum blocks are still extremely short compared to other chains (e.g. Solana and Optimism have 400ms and 2s blocks, respectively).
Pre-Timeboost, capturing arbitrage in a first-come-first-serve (FCFS) setting strictly depends on latency i.e. how quickly you can communicate with the sequencer. This includes both how fast you can reach the sequencer, how quickly you receive messages from the sequencer, and the quality of your signal. We think this suppresses the amount of arbitrage on Arbitrum, relative to other chains with longer block times and mechanisms such as priority fees and PBS, because you have to both invest in the best hardware and physically be as close to Arbitrum’s sequencer (rent an office right above it), which is a high (and more concentrated) capital requirement, to capture arbitrage.
This research studied maximal arbitrage value (MAV) and LVR across Ethereum and select rollups (Arbitrum, Optimism, Base, and Zksync) on Uniswap v3 and finds the average MAV opportunity ($19.68) on Arbitrum lasts for about 6.9 seconds. One might think, how does a $20 arbitrage opportunity exist for that long? While it seems the authors do not elaborate on why this is the case, we think it has to do with the costs and risks of executing that trade in the absence of something like PBS or priority fees–wherein, instead of the determinants of the game being strictly latency, it becomes a game about latency and pricing arbitrage. In other words, in a FCFS environment, the capital requirements and risks associated with capturing that arbitrage opportunity is too high relative to the opportunity, until it reaches a point at which the price discrepancy is large enough given variable market conditions. This period of time (or decay) sometimes spans multiple blocks.
Timeboost explicitly grants a time advantage for transaction inclusion to anyone that is able to buy it, which will alter the costs and risks of capturing arbitrage in such a way that attracts new traders to the ecosystem.
Our expectation is that, by introducing an express lane that has no delay (while other transactions have a 200ms delay), Timeboost should lower the execution risks and costs for capturing arbitrage opportunities, creating market structures and conditions in which arbitrageurs can pay the DAO to adjust price discrepancies potentially over smaller periods of time (decay).
That said, there is valid concern about Timeboost increasing CEX-DEX arbitrage and thus LVR. However, these arbitrage opportunities (as well as other kinds of arbitrage) should still exist in a similar fashion as they do pre-Timeboost. More aptly, if a CEX-DEX arbitrageur owns the express lane and gets a signal for an arbitrage opportunity–there may be some amount of time they can wait before sending the transaction, however, with 250ms block times–they should be sending a transaction to capture that opportunity as fast as possible (before the end of the 200ms express lane slot), because if they don’t someone else competing in FCFS (non-express lane users) will capture it. This doesn't seem materially different from pre-Timeboost conditions i.e. receiving a signal and sending transactions to the sequencer as fast as possible. Put differently, Timeboost shouldn't explicitly reduce the level of entropy in the system--it offers a way in which traders can price it and therefore capture it.
In any case, Timeboost might actually have a neutral effect on LPs and, instead of traders capturing all of the LVR, the DAO will capture some of it. Additionally, it seems Timeboost’s effect on Arbitrum LVR depends on the time delta between CEX-DEX arbitrage signals, or how long a vertically integrated searcher must usually wait in order to exploit LVR. This is an interesting topic for future research.
Thus, while we do not have empirical evidence for what we can expect for a transition to an express lane auction (from FCFS), our base case is Timeboost should not drastically affect the rate of arbitrage, or the amount of LVR, and we lean toward there being slightly more arbitrage by virtue of attracting new traders. It is also worth noting LPs on Arbitrum will still be better off than LPs on other L2s, according to the prevailing AMM and LVR literature (here, here, and here). Other important factors that determine changes to LVR, and arbitrage activity more broadly, include retail participation, volatility, swap fees, and liquidity. Note: this response is only with respect to non-atomic arbitrage (CEX-DEX). There is an entire category of atomic arbitrage that should also benefit from Timeboost.
I definitely value the review from our security experts to understand the depth of these technical proposals.
I’ve decided to vote FOR this proposal, especially regarding collecting bids in ETH for the treasury.
I believe diversification is important and contributes to the sustainability goals we are pursuing as a DAO.
We support this proposal and vote for "Collect bids in ETH to treasury" on Snapshot.
We maintain our stance in the comment posted before and continue to support the progress of the development of Timeboost.
We have also support the adjustments around a few parameters to be adjustable by Offchain Labs to fine-tune the design and achieve the stability, user experience and economics for the Arbitrum DAO. Also, interested in the future improvement partnering with the Espresso team.
One question for @Arbitrum (or Offchain Labs),
How do you make sure of those when modifying the parameters in question? Do you have some kind of A/B test system to try different parameters to evaluate the key metrics?
Thank you for this clarification. The majority of concerns I have heard have been from the misunderstanding #1 & #3.
Arbitrum uses the same model for transaction ordering and block building as Ethereum L1, so L1 MEV issues automatically apply to Arbitrum.
Timeboost gives the auction winner an unfair amount of power around transaction ordering.
I feel that Timeboost is "safe to try" reading this well-articulated reasoning along with the great work by @BlockworksResearch and @chaoslabs to come to an understanding around the rebalancing effect on LPs.
I voted to collect bids in ARB. Blockworks and Chaos Labs reasoning and research provided a strong case for the adoption of this feature.
After consideration, the @SEEDgov delegation has decided to vote “Collect bids in ETH to the treasury” on this proposal at the Snapshot vote.
In the first instance, we welcome the socialisation with the DAO of the gains of those who capture MEV without creating changes to the user experience.
After consideration, the @SEEDgov delegation has decided to vote “Collect bids in ETH to the treasury” on this proposal at the Snapshot vote.
In the first instance, we welcome the socialisation with the DAO of the gains of those who capture MEV without creating changes to the user experience.
However, having read ARDC’s comparison of Timeboost to other transaction ordering policies, and ARDC’s risk analysis of Timeboost, we would like to highlight the importance of post-implementation monitoring. Without reporting, the DAO will lack the necessary tools to be able to follow the outcome and drive changes in the pre-established parameters. Just to give an example, the reservePrice parameter can be modified to avoid collusion at the auction stage, without active monitoring of bids it will be difficult for the DAO to mitigate these risks in a timely manner.
Finally, we agree with @WintermuteGovernance:
If we collect bids in ETH, we can always buy back and burn ARB, but we can’t grow the treasury in a diversified manner if we collect bids in ARB.
This option gives the possibility to decide in the future what to do with the revenue coming from Timeboost and since there are currently active discussions on Treasury Management/Diversification as well as a working group on ARB Staking has been created, we believe it is best to decide the fate of this revenue flow in the context of these two verticals.
I vote in favor of implementing Timeboost to enhance DAO revenue because I believe that every user would appreciate having an express lane for their transactions. Specifically, I support the option to collect bids in ARB and burn the proceeds. Burning ARB reduces its supply, which could raise the value of the remaining tokens
Camelot is voting ABSTAIN on the Timeboost proposal.
This decision is not due to a lack of belief in the idea's value, but rather stems from the absence of thorough analysis, both in the proposal and in the risk reports.
—
Camelot is voting ABSTAIN on the Timeboost proposal.
This decision is not due to a lack of belief in the idea's value, but rather stems from the absence of thorough analysis, both in the proposal and in the risk reports.
—
The first aspect that remains unclear is the exact scope of the Timeboost initiative, from the DAO perspective: is it first intended to address spam transactions stemming from FCFS arbitrage (which inadvertently increases gas fees and adds congestion to the network), or is it designed to generate revenue for the DAO? While the answer could be both, understanding the primary objective is crucial for determining the best mechanisms and parameters to implement. This ties into a fundamental principle we cannot overlook: we must prioritize ensuring the best user experience and the optimal functioning of the chain, for users and protocols, before seeking revenue. Ultimately, it seems that for many of us the proposal appears to be more revenue-focused, and much of the discussion has been shaped by this perspective.
—
We can further analyze the proposal in the context of DEXes and LPers, which will be among the most potentially impacted by it. While setting up a proper MEV infrastructure is critical on a chain, it's also important to remember that arbitrage has been and will always be an essential component of any economic system. Timeboost implementation is highly likely to have an impact on DEX volume – to start with the most obvious point, simply because adding an additional cost to the process will naturally reduce arbitrage. Increasing block time (~doubling it with the current 200ms proposed parameter) will also probably have direct consequences by decreasing the number of granular arbitrage opportunities. Those might not be the only effects and it is very surprising that neither the proposal nor the analysis from ARDC made any significant effort to define or quantify this potential impact – and other consequences regarding general arbitrageur behavior, that could potentially be broader than anticipated.
For instance, could we see some arbitrageurs slowing down or simply halting their activities on Arbitrum? If you can't secure the express lane for yourself, would there still be enough incentives to remain highly reactive to arbitrage opportunities as we have observed thus far? There also wasn't any study as far as we know on the economic consequences, beyond the potential decrease in DEX volume, for LPs. As previously mentioned, adding a 200ms delay would naturally increase LVR and raise the cost of liquidity provisioning – which is something we shouldn't overlook, and should properly measure.
In other words this could be summarized with a very simple question: should revenue generated for the DAO come at the expense of the chain's DEX volume (a key metric for any L2) and LPs? If yes, to which extent will this happen, or should this be accepted? We believe having metrics and estimates to refer to and evaluate the potential consequences should be a hard requirement before voting in favor of any proposal of that type.
—
Last but not least, some considerations regarding the parameters should be addressed. It doesn't seem like any specific rationale has been provided for the proposed initial setup (15 seconds auction, 60 seconds monopoly, and 200ms block time delay). How were these parameters chosen, and what will be their broader impact on the ecosystem?
Chaos Lab and Delphi very rightly pointed out the risk that a 60s monopoly could carry, mentioning the potential creation of secondary markets – and the risk of having entities colluding to control arbitrage on the chain. We already mentioned the potential consequences we can foresee for dexes and their users, but could other critical sectors of our chain, such as lending or gambling apps, be impacted by the introduction of this 200ms delay -- and if yes, how?
Assuming this proposal passes, which seems likely due to its revenue-driven nature, there must be in-depth monitoring and analysis of the consequences and the parameters chosen, that would allow for necessary adjustments and tuning based on the results. To this day, it appears that no specific method or general plan for monitoring and responding to these changes has been outlined.
—
As a final note, we hope that in the future, for proposals of such importance and criticality, risk analysis from Delphi, Chaos Lab, and ADPC are made available well in advance of the vote. This would provide the DAO with sufficient time to discuss and analyze the pros and cons, rather than receiving this information either right before or during the voting period.
—
To be absolutely clear, the goal of this feedback is not to stop the proposal. It is obvious that there is consensus in the DAO, particularly because the proposal is revenue-driven.
That being said, we believe at Camelot that what has been built in Arbitrum so far should not be jeopardized by the promise of future revenue for the DAO without a thorough analysis of what we might also lose in the process. This doesn't mean that our technological foundation and economic model should be monolithic; however, implementing such a significant change without establishing checks and balances to monitor key ecosystem activities, and without a contingency plan to mitigate potential negative outcomes, is not only incomplete but also risky.
We urge the DAO, if the collective decision is to move forward with this initiative, to carefully consider the potential risks and implement strong safeguards to protect the ecosystem.
We are in favor of adopting the Timeboost transaction ordering policy. This implementation will introduce several key benefits to the Arbitrum ecosystem:
We are in favor of adopting the Timeboost transaction ordering policy. This implementation will introduce several key benefits to the Arbitrum ecosystem:
We believe the introduction of Timeboost will be a valuable addition to the Arbitrum protocol, benefiting both the community and the DAO by enhancing the performance and economic incentives of the ecosystem.
We have reviewed the new version of the proposal and the ARDC comment. We are in favor of this proposal and support collecting bids in ETH. While the buyback and burn of ARB could increase its utility, we believe this approach offers greater long-term sustainability.
The following reflects the views of the Lampros Labs DAO governance team, composed of @Blueweb, @Euphoria, and Hirangi Pandya (@Nyx), based on our combined research, analysis, and ideation.
We are voting FOR this proposal with the option to collect bids in ETH to the treasury.
The following reflects the views of the Lampros Labs DAO governance team, composed of @Blueweb, @Euphoria, and Hirangi Pandya (@Nyx), based on our combined research, analysis, and ideation.
We are voting FOR this proposal with the option to collect bids in ETH to the treasury.
We believe this is a well-researched and well-thought-out proposal that can only be properly evaluated through real-world data. Timeboost offers a unique way for ArbitrumDAO to capture value from MEV activity while having a minimal effect on regular users.
We believe that generating revenue should be a key focus for the DAO’s long-term sustainability, and Timeboost provides a good mechanism for this. Collecting bids in ETH keeps future options open, unlike burning ARB tokens. Once we have real-world data, we will be better positioned to decide how to handle the revenue, whether through distribution or token burning.
I have been asked this question by some members which you may want to answer and add it in the FAQ
I agree with this proposal cause the whole new transaction ordering policy can:
On behalf of the UADP, we think adopting the Timeboost as the new transaction ordering policy brings many advantages for the network's long-term health.
Some benefits we were sold on:
On behalf of the UADP, we think adopting the Timeboost as the new transaction ordering policy brings many advantages for the network's long-term health.
Some benefits we were sold on:
We chose ETH as it was the most logical in our opinion, there should be more inflows to the DAO in ETH and we think there's a true case or arguement to make this be the defacto type of inbound token.
We can always buy back and burn ARB if we collect bids in ETH, but we can’t grow the treasury in a diversified manner if we collect bids in ARB.
Completely agree. ETH is the more cautionary approach imo.
I fully support the adoption of Timeboost and voted for the option to collect bids in ETH. This will allow an increased efficency and user experience. Concerning the option, collecting fees in ETH makes more sense to me, even after reading the different perspectives on the forum.
The FranklinDAO/Penn Blockchain Team has voted for the option of collect fees in ETH. We believe that more discussion is needed on where Timeboost fees should be distributed - whether to ARB stakers, applications that created the MEV opportunity, burned, or a mix of these options. Further, 3.7B ARB tokens (or 37% of total supply) have yet to be unlocked, with vesting to Investors/Team & Advisors continuing linearly until March 2027 (link). A later discussion is needed to decide when the right time is for an ARB burn mechanism. In the meantime, we believe growing the DAO's ETH reserves is a good idea.
A couple things we wanted to mention/ask:
I voted to collect bids in ETH and send to treasury on the temp check proposal.
Timeboost is an innovative approach to transaction ordering that creates a more efficient market and internalizes surplus value for the Arbitrum DAO. It's a clear win for the Arbitrum ecosystem as whole relative to the current first-come-first-served system. I'm comfortable with Offchain Lab's development approach from a security perspective.
I voted to collect bids in ETH and send to treasury on the temp check proposal.
Timeboost is an innovative approach to transaction ordering that creates a more efficient market and internalizes surplus value for the Arbitrum DAO. It's a clear win for the Arbitrum ecosystem as whole relative to the current first-come-first-served system. I'm comfortable with Offchain Lab's development approach from a security perspective.
I prefer collecting the fees in ETH because it creates a natural treasury diversification mechanism while preserving decentralization.
Just cast my vote in favor of collecting bids in ETH for the treasury. I see this as a stronger long-term move for the DAO, securing funds for development and ecosystem growth. Don't think it's the right time to tinker with ARB’s inflation/dilution. Definitely interested to see how the testing phase plays out before full implementation.
The following reflects the views of L2BEAT’s governance team, composed of @krst and @Sinkas, and it’s based on the combined research, fact-checking, and ideation of the two.
We’re voting FOR this proposal and opting for bids to be collected in ETH in the treasury.
The following reflects the views of L2BEAT’s governance team, composed of @krst and @Sinkas, and it’s based on the combined research, fact-checking, and ideation of the two.
We’re voting FOR this proposal and opting for bids to be collected in ETH in the treasury.
After reviewing the proposal, reading ARDC’s comparison of Timeboost to other transaction ordering policies, and ARDC’s risk analysis of Timeboost, we are supportive of its adoption on Arbitrum.
Collecting bids in ETH and letting it accumulate in the treasury is a more sensible approach. However, we’re also generally supportive of ARB buybacks and burns in a more general context, and perhaps we could see another proposal in the DAO to do that, utilizing the ETH in the treasury at a later date.
Having ETH enables the DAO to have more options that could bolster ARB’s utilitiy, including that of buying ARB from the market to burn it. If we directly collect bids in ARB and burn them, we limit our options from the start. Apart from burning ARB, mitigating against inflation and token unlocks could also be achieved through other means, such as Tally's recently approved staking proposal.
Lastly, similar to other technical proposals we’ve had in the past, we’ll verify the executable of the proposal once it goes onchain before casting our vote.
Agreed, this proposal is very well planned, lays out a complete plan, steps for implementation, and the community feels it is very reasonable
The Timeboost proposal should it offers a sustainable way for ArbitrumDAO to generate additional revenue without compromising user experience or security. With the implemention of an auction-based system for express transaction lanes, Timeboost will ensure that MEV ops can be captured by the DAO rather than by private searchers alone.
When it comes to the options to collect bids in either ETH or ARB we are in favor of ETH. This diversifies away more dependence of the DAO on ARB and should decrease risks. Overall, Timeboost balances offer a robust, permissionless system that aligns with the ethos of the DAO.
current sequencer operator the below rights to make the following adjustments from time to time for a period of two (2) years
Will these changes be made without community discussion or through on-chain voting?
We voted to collect bids in ETH. Reasoning:
Treasury Diversification Arbitrum DAO's ETH holdings are tiny relative to its ARB holdings. Adding to that in any and all ways possible is just a generally good idea.
We voted to collect bids in ETH. Reasoning:
Treasury Diversification Arbitrum DAO's ETH holdings are tiny relative to its ARB holdings. Adding to that in any and all ways possible is just a generally good idea.
Optionality of MEV share There's a recent movement towards applications collecting MEV, including discussion in this thread. Collecting bids in ETH allows for some MEV "profit-share" with apps if that is decided in the future, whereas buying and burning ARB does not.
Questionable Value Accrual of Buy and Burn MakerDAO tried Buy and Burn but value accrual was questionable and it wasnt a good narrative with the market. Staking is a better mechanism for value accrual which aligns long term holders with the protocol, rather than giving value to every token holder indiscriminantly like burning does, and gives more freedom over the precise way value accrues to the token, and also is just a better narrative as shown by LSD market share.
The FranklinDAO/Penn Blockchain Team has voted for the option of collect fees in ETH. We believe that more discussion is needed on where Timeboost fees should be distributed - whether to ARB stakers, applications that created the MEV opportunity, burned, or a mix of these options. Further, 3.7B ARB tokens (or 37% of total supply) have yet to be unlocked, with vesting to Investors/Team & Advisors continuing linearly until March 2027 (link). A later discussion is needed to decide when the right time is for an ARB burn mechanism. In the meantime, we believe growing the DAO's ETH reserves is a good idea.
A couple things we wanted to mention/ask:
What is the expected revenue Timeboost will bring to the DAO? What is a ballpark number to give delegates a general idea of the revenue opportunity here? @arbitrum A paper quantifying MEV claimed $250k of MEV profit was extracted in the 1.5 year period on Arbitrum (From Arb mainnet launch Aug 2021 to Mar 2023). How much larger is the opportunity now?
Wanted to clarify what winning the Express Lane auction means - Since auctions are every minute, does this mean that the auction winner will have first in block bundle guarantee for an entire 1 minute period - meaning for the next 240 blocks? (1 min * 60 sec * 1000ms per sec / 250ms/block)
Express Lane gives rise to new toxic MEV opportunities at the expense of users/protocols. @chaoslabs explained this in their analysis, citing the example of an Express Lane auction winner identifying a close to liquidation position and sandwiching it to forcibly create a liquidation. It's important to note that these opportunities exist in any transaction order scheme that allows for top of block bundled tx inclusion. We'd like to see more historical analysis on the size and frequency of these user/protocol hurting MEV bundles, and what we can expect to see in Timeboost.
In this case, the owner of the express lane has the opportunity to capture value that is not currently available at the expense of liquidated (or limit order-placing) users and/or protocols. It should be noted that if this is the case then presumably the express lane will become more valuable, increasing DAO revenue.
Voted for collecting bids in ETH to the treasury: Timeboost sounds like a great way to eliminate spam transactions. Also, it will generate revenue for the Arbitrum DAO. The whole proposal sounds like a great innovation in this space. I also like that the tech can be picked up by Orbit chain (Layer 3). Many of them could give their native tokens extra utility with this—another reason for builders to build on Orbit. I did spend some time thinking about whether bids should be done in ETH or ARB. I decided to collect bids in ETH because we have passed the ARB staking proposal, and I’m excited to see how that would work. Also, it’s great that we can change it to collect bids in ARB anytime. It might be interesting to test this out sometime in the future.
I voted Collect bids in ARB and burn because we need to curb ARB inflation.
I don't know much about the underlying technology, but I have always been in favor of technological advances that can improve the fairness and efficiency of the network, and this proposal will greatly improve the user's transaction experience, so I'm all for it! And collecting bids in ARB And burn is a great idea!
We are in favour of adopting Timeboost and will be supporting the option to collect bids in ETH. Our preference for collecting bids in ETH is twofold:
We are in favour of adopting Timeboost and will be supporting the option to collect bids in ETH. Our preference for collecting bids in ETH is twofold:
On point 2, we are strong advocates for efforts that continue to grow Arbitrum’s Treasury in non-native tokens. The DAO has high expenses which consistently lead to large outflows of ARB resulting in large selling pressure. By collecting ETH vs burning ARB the DAO grows its treasury, diversifies its treasury, and most importantly provides optionality for future expenditures, staking programs, yield generation, etc.
We can always buy back and burn ARB if we collect bids in ETH, but we can’t grow the treasury in a diversified manner if we collect bids in ARB.
I am voting in favor of this proposal on Snapshot.
Thank you very much for the proposal and for all the work in developing Time Boost. I believe MEV capture is beneficial as long as it doesn’t affect the user experience or their economic interests, and it provides the DAO with an additional source of revenue beyond the usual fees.
I am voting in favor of this proposal on Snapshot.
Thank you very much for the proposal and for all the work in developing Time Boost. I believe MEV capture is beneficial as long as it doesn’t affect the user experience or their economic interests, and it provides the DAO with an additional source of revenue beyond the usual fees.
That said, MEV capture is still a topic whose legal implications remain somewhat unclear. There is no clear regulatory outlook, nor a solid stance from various jurisdictions on this matter.
This is why I find @chaoslabs analysis of potential risks crucial, particularly the possibility of capturing MEV derived from sandwich attacks on users during the liquidation of their positions.
I would like to know if the Foundation or the OCL team has a reporting roadmap or if they are considering hiring a service provider for this purpose. These reports could be funded with the new revenue generated by Time Boost.
This AIP proposes two main options that the community can vote on if it decides to adopt Timeboost
Regarding this, like many other delegates, I lean toward capturing the gains in ETH. This will strengthen the DAO's treasury with the most important and valuable asset in the Ethereum ecosystem. I'm also not a big fan of burn initiatives, as past experiences have shown they don’t have the short-term impact people expect (i.e., price increases). Market dynamics and asset prices depend on multiple factors, and such measures usually fail to deliver the desired outcome.
Interesting discussion in support of the proposal.Timeboost assigns a fairer priority to transaction execution by combining the time factor with the Gas fee paid by the user, which helps to reduce the manipulation problem in the current transaction ordering and improves the fairness and efficiency of the network.
However, I have some opinions about this place from the user's point of view. 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. How to effectively balance
It does make a difference.
Buyback and burn are mechanism that, economic wise, usually work better in bear markets: it basically creates a constant bid that helps the price. But is not properly perceived by users compared to a direct distribution of incentives. We can see this example in rollbit that, despite having a huge buyback and burn mechanism, is having poor but also kinda stable-ish price action performances.
It does make a difference.
Buyback and burn are mechanism that, economic wise, usually work better in bear markets: it basically creates a constant bid that helps the price. But is not properly perceived by users compared to a direct distribution of incentives. We can see this example in rollbit that, despite having a huge buyback and burn mechanism, is having poor but also kinda stable-ish price action performances.
On the other side, collecting in ETH does indeed need the adding of a second step if we want to accrue this revenue back to holders, either through a staking program, an investment program or others.
As it is now, collecting in eth and later deciding how to utilize it could be the idea that gives us more optionality.
Confirming my previous take, I am voting for collecting the fees in eth.
While the buyback and burn would create some sort of upward pressure, this will be dwarfed by the unlocks; considering we are on track to also approve the arb staking proposal, to me it makes more sense, for now, to just collect everything in eth.
I can also see the dao going back to this decision after a few years to reasses.
In discussing this at EthCC, I realized many didn't understand why I'd suggest this solution.
Collecting ETH fees pays out 1:1 - there is not difference in the speculative ferver us collecting ETH fees will pay and the value collected.
In discussing this at EthCC, I realized many didn't understand why I'd suggest this solution.
Collecting ETH fees pays out 1:1 - there is not difference in the speculative ferver us collecting ETH fees will pay and the value collected.
However, even a small amount of ARB utility is a strong market signal at a smart time saying we are willing to find ARB utility. This could payout 10:1 - or at least more than 1:1. It is a unique opportunity I think we should consider.
Common MEV activities include CEX-DEX arbitrage, cross-DEX, cross-chain MEV, and liquidation backrunning.
Thanks team. To keep clarifying this part, as
Common MEV activities include CEX-DEX arbitrage, cross-DEX, cross-chain MEV, and liquidation backrunning.
Thanks team. To keep clarifying this part, as
"Access to the express lane would be auctioned off in one-minute rounds, with the auction happening 15 seconds before the round begins."
Does it mean we expect searchers to bid continuously in advance, expecting opportunities to happen 1m later, rather than "in real time" opportunities (I see something -> I submit an arbitrage tx with priority)?
Blockworks Research will be voting in favor of the option to COLLECT ETH
We approve of Option 1, especially since the DAO is currently lacking treasury diversification. As we have stated elsewhere, the BoLD validator bootstrapping will take half of the DAO’s current ETH, leaving us in a position to replenish.
It might be worth thinking about collecting bids in ARB?
This will make it necessary for MEV to hold the token ARB and thus it will increase the price of the ARB token.
In any case, it is necessary to carry out some justification for the options. What are the pros and cons of each solution. But I still believe that burning tokens is a thing of the past and it’s no longer worth doing that.
We are definitely excited to see Timeboost will be introduced to mitigate the issues around the L2 MEV landscape and actors while appropriately capturing the revenue opportunity and/or introduction to the burning mechanism for the ARB token.
We are generally in favor of Option 1 in terms of the auction proceeds. We believe the current priority for the DAO is to sustainably manage the DAO treasury as we are currently discussing the Arbitrum gas fee and sequencer revenue. We also like the "split profits" option @DisruptionJoe suggested too, but we consider it the best to keep the ratio of the ETH collection much more than the ARB burning for the short term anyway.
I am in favor of adopting the timeboost proposal and will be voting for the option to collect ETH. Why ETH?
When we talk about burning in general, it means we are sharing value or dividends with all token holders, including speculators and those who don't care about the protocol or the DAO at all. Although this is a great way to avoid regulatory hurdles and create a burning narrative within the community, it will result in leaking value to the speculators. At some point, we can decide to do so, but it requires a rich treasury. Considering the 50% allocation of our ETH treasury to the BOLD validator, helping toward the diversification and strengthening of the treasury would be a more efficient option and will have a more positive impact and flexibility on the DAO.
This is a great proposal that I'm very excited to support. Let's assume for now that the mechanism design finds its sweet spot before implementation. In that case, here are my suggestions.
This is a great proposal that I'm very excited to support. Let's assume for now that the mechanism design finds its sweet spot before implementation. In that case, here are my suggestions.
I think both signals are important for Arbitrum at this time. Showing that we are willing to give ARB utility is why I think this amount should be non-zero. However, diversification is critical and this is a great way to do it.
My suggestion is monthly or quarterly votes to update the ratio such that the community can regularly take part in adjusting to the current environment and needs of the ecosystem.
Timeboost is going to take Arbitrum DAO to the next level. Absolutely stoked for this one! I still need to dig into the technicals, but I am obviously supportive of this initiative.. as I am sure most community members will be.
In reference to the below:
Timeboost is going to take Arbitrum DAO to the next level. Absolutely stoked for this one! I still need to dig into the technicals, but I am obviously supportive of this initiative.. as I am sure most community members will be.
In reference to the below:
I believe it is a no brainer to collect the fees in ETH and send the proceeds to the treasury where they can be leveraged to earn additional yield into perpetuity. I understand people want ARB utility ASAP, but I firmly believe that we can build up a treasury worth 10s of billions of dollars of ETH and Stables over time. Once we reach that point, I will be in favor of protocol revenue share with token holders through some type of mechanism.
I believe it is extremely important for the DAO to have a longterm mindset on these types of issues rather than rushing to share profit or burn ARB tokens during our early stage growth phase. Do we really want to be in a situation where we enter a bear market with a treasury w/ 99% of its assets in ARB with no inherent staking yield, and minimal yield opportunities / liquidity when compared to ETH? Or do we want hundreds of millions (and eventually billions) of dollars of ETH and Stables that can earn at minimum the ETH staking yield and US short term treasury yield?
To me, the answer is obvious. I want Arbitrum to be well capitalized over the coming decades, rather than essentially buying our token at a valuation that has a ton of speculative premium priced in and sending it to an EOA that no one controls or benefits from...
Very interesting proposal, it's a great way to increase revenue while not really disrupting the MEV scene on Arbitrum for average users.
As we are moving closer to ARB staking and some kind of revenue distribution, I believe it makes more sense to collect fees in ETH to also keep some consistency with the rest of fees on the network.
Just curious of a few technical aspects of timeboost:
I share most of this but wanna focus on 3.
For instance, could we consider redistributing a portion of the profits (in ARB?) generated to the protocols used by these transactions?
gm, super interesting proposal - thank you for sharing. Arbitrum developers confirmed to be superstars who always look at new win-win improvements for the ecosystem.
I would like to understand better who would be the target user of this (maybe asking some dumb questions here):
gm, super interesting proposal - thank you for sharing. Arbitrum developers confirmed to be superstars who always look at new win-win improvements for the ecosystem.
I would like to understand better who would be the target user of this (maybe asking some dumb questions here):
user transactions will still remain private until after they are executed, meaning that the express lane controller cannot frontrun or sandwich users
What type of MEV activity exists today on Arbitrum? What do searchers search for?
Access to the express lane would be auctioned off in one-minute rounds, with the auction happening 15 seconds before the round begins.
Similarly, with this type of timeframe, what kind of transactions would go through the fast lane?
On top of the 2 options proposed, I lean towards accumulating ETH in the Treasury, until we agree on the best way to distribute it and/or we have accumulated enough reserves.
In general, I would exclude token burning because it doesn't inherently increase the fundamental value of the token: https://www.placeholder.vc/blog/2020/9/17/stop-burning-tokens-buyback-and-make-instead
I believe the adoption of Timeboost is a beneficial move for Arbitrum, as it not only addresses MEV-related challenges but also creates a sustainable revenue stream for the DAO. I agree with @cp0x suggestion to distribute ARB proceeds to stakers, which fosters community engagement and aligns incentives without reducing the ARB supply through burning.
The FranklinDAO/Penn Blockchain Team has voted for the option of collect fees in ETH. We believe that more discussion is needed on where Timeboost fees should be distributed - whether to ARB stakers, applications that created the MEV opportunity, burned, or a mix of these options. Further, 3.7B ARB tokens (or 37% of total supply) have yet to be unlocked, with vesting to Investors/Team & Advisors continuing linearly until March 2027 (link). A later discussion is needed to decide when the right time is for an ARB burn mechanism. In the meantime, we believe growing the DAO's ETH reserves is a good idea.
A couple things we wanted to mention/ask:
What is the expected revenue Timeboost will bring to the DAO? What is a ballpark number to give delegates a general idea of the revenue opportunity here? @arbitrum A paper quantifying MEV claimed $250k of MEV profit was extracted in the 1.5 year period on Arbitrum (From Arb mainnet launch Aug 2021 to Mar 2023). How much larger is the opportunity now?
Wanted to clarify what winning the Express Lane auction means - Since auctions are every minute, does this mean that the auction winner will have first in block bundle guarantee for an entire 1 minute period - meaning for the next 240 blocks? (1 min * 60 sec * 1000ms per sec / 250ms/block)
Express Lane gives rise to new toxic MEV opportunities at the expense of users/protocols. @chaoslabs explained this in their analysis, citing the example of an Express Lane auction winner identifying a close to liquidation position and sandwiching it to forcibly create a liquidation. It's important to note that these opportunities exist in any transaction order scheme that allows for top of block bundled tx inclusion. We'd like to see more historical analysis on the size and frequency of these user/protocol hurting MEV bundles, and what we can expect to see in Timeboost.
In this case, the owner of the express lane has the opportunity to capture value that is not currently available at the expense of liquidated (or limit order-placing) users and/or protocols. It should be noted that if this is the case then presumably the express lane will become more valuable, increasing DAO revenue.
Voted for collecting bids in ETH to the treasury: Timeboost sounds like a great way to eliminate spam transactions. Also, it will generate revenue for the Arbitrum DAO. The whole proposal sounds like a great innovation in this space. I also like that the tech can be picked up by Orbit chain (Layer 3). Many of them could give their native tokens extra utility with this—another reason for builders to build on Orbit. I did spend some time thinking about whether bids should be done in ETH or ARB. I decided to collect bids in ETH because we have passed the ARB staking proposal, and I’m excited to see how that would work. Also, it’s great that we can change it to collect bids in ARB anytime. It might be interesting to test this out sometime in the future.
I voted Collect bids in ARB and burn because we need to curb ARB inflation.
I don't know much about the underlying technology, but I have always been in favor of technological advances that can improve the fairness and efficiency of the network, and this proposal will greatly improve the user's transaction experience, so I'm all for it! And collecting bids in ARB And burn is a great idea!
We are in favour of adopting Timeboost and will be supporting the option to collect bids in ETH. Our preference for collecting bids in ETH is twofold:
We are in favour of adopting Timeboost and will be supporting the option to collect bids in ETH. Our preference for collecting bids in ETH is twofold:
On point 2, we are strong advocates for efforts that continue to grow Arbitrum’s Treasury in non-native tokens. The DAO has high expenses which consistently lead to large outflows of ARB resulting in large selling pressure. By collecting ETH vs burning ARB the DAO grows its treasury, diversifies its treasury, and most importantly provides optionality for future expenditures, staking programs, yield generation, etc.
We can always buy back and burn ARB if we collect bids in ETH, but we can’t grow the treasury in a diversified manner if we collect bids in ARB.
I am voting in favor of this proposal on Snapshot.
Thank you very much for the proposal and for all the work in developing Time Boost. I believe MEV capture is beneficial as long as it doesn’t affect the user experience or their economic interests, and it provides the DAO with an additional source of revenue beyond the usual fees.
I am voting in favor of this proposal on Snapshot.
Thank you very much for the proposal and for all the work in developing Time Boost. I believe MEV capture is beneficial as long as it doesn’t affect the user experience or their economic interests, and it provides the DAO with an additional source of revenue beyond the usual fees.
That said, MEV capture is still a topic whose legal implications remain somewhat unclear. There is no clear regulatory outlook, nor a solid stance from various jurisdictions on this matter.
This is why I find @chaoslabs analysis of potential risks crucial, particularly the possibility of capturing MEV derived from sandwich attacks on users during the liquidation of their positions.
I would like to know if the Foundation or the OCL team has a reporting roadmap or if they are considering hiring a service provider for this purpose. These reports could be funded with the new revenue generated by Time Boost.
This AIP proposes two main options that the community can vote on if it decides to adopt Timeboost
Regarding this, like many other delegates, I lean toward capturing the gains in ETH. This will strengthen the DAO's treasury with the most important and valuable asset in the Ethereum ecosystem. I'm also not a big fan of burn initiatives, as past experiences have shown they don’t have the short-term impact people expect (i.e., price increases). Market dynamics and asset prices depend on multiple factors, and such measures usually fail to deliver the desired outcome.
Interesting discussion in support of the proposal.Timeboost assigns a fairer priority to transaction execution by combining the time factor with the Gas fee paid by the user, which helps to reduce the manipulation problem in the current transaction ordering and improves the fairness and efficiency of the network.
However, I have some opinions about this place from the user's point of view. 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. How to effectively balance
It does make a difference.
Buyback and burn are mechanism that, economic wise, usually work better in bear markets: it basically creates a constant bid that helps the price. But is not properly perceived by users compared to a direct distribution of incentives. We can see this example in rollbit that, despite having a huge buyback and burn mechanism, is having poor but also kinda stable-ish price action performances.
It does make a difference.
Buyback and burn are mechanism that, economic wise, usually work better in bear markets: it basically creates a constant bid that helps the price. But is not properly perceived by users compared to a direct distribution of incentives. We can see this example in rollbit that, despite having a huge buyback and burn mechanism, is having poor but also kinda stable-ish price action performances.
On the other side, collecting in ETH does indeed need the adding of a second step if we want to accrue this revenue back to holders, either through a staking program, an investment program or others.
As it is now, collecting in eth and later deciding how to utilize it could be the idea that gives us more optionality.
Confirming my previous take, I am voting for collecting the fees in eth.
While the buyback and burn would create some sort of upward pressure, this will be dwarfed by the unlocks; considering we are on track to also approve the arb staking proposal, to me it makes more sense, for now, to just collect everything in eth.
I can also see the dao going back to this decision after a few years to reasses.
In discussing this at EthCC, I realized many didn't understand why I'd suggest this solution.
Collecting ETH fees pays out 1:1 - there is not difference in the speculative ferver us collecting ETH fees will pay and the value collected.
In discussing this at EthCC, I realized many didn't understand why I'd suggest this solution.
Collecting ETH fees pays out 1:1 - there is not difference in the speculative ferver us collecting ETH fees will pay and the value collected.
However, even a small amount of ARB utility is a strong market signal at a smart time saying we are willing to find ARB utility. This could payout 10:1 - or at least more than 1:1. It is a unique opportunity I think we should consider.
Common MEV activities include CEX-DEX arbitrage, cross-DEX, cross-chain MEV, and liquidation backrunning.
Thanks team. To keep clarifying this part, as
Common MEV activities include CEX-DEX arbitrage, cross-DEX, cross-chain MEV, and liquidation backrunning.
Thanks team. To keep clarifying this part, as
"Access to the express lane would be auctioned off in one-minute rounds, with the auction happening 15 seconds before the round begins."
Does it mean we expect searchers to bid continuously in advance, expecting opportunities to happen 1m later, rather than "in real time" opportunities (I see something -> I submit an arbitrage tx with priority)?
Blockworks Research will be voting in favor of the option to COLLECT ETH
We approve of Option 1, especially since the DAO is currently lacking treasury diversification. As we have stated elsewhere, the BoLD validator bootstrapping will take half of the DAO’s current ETH, leaving us in a position to replenish.
It might be worth thinking about collecting bids in ARB?
This will make it necessary for MEV to hold the token ARB and thus it will increase the price of the ARB token.
In any case, it is necessary to carry out some justification for the options. What are the pros and cons of each solution. But I still believe that burning tokens is a thing of the past and it’s no longer worth doing that.
We are definitely excited to see Timeboost will be introduced to mitigate the issues around the L2 MEV landscape and actors while appropriately capturing the revenue opportunity and/or introduction to the burning mechanism for the ARB token.
We are generally in favor of Option 1 in terms of the auction proceeds. We believe the current priority for the DAO is to sustainably manage the DAO treasury as we are currently discussing the Arbitrum gas fee and sequencer revenue. We also like the "split profits" option @DisruptionJoe suggested too, but we consider it the best to keep the ratio of the ETH collection much more than the ARB burning for the short term anyway.
I am in favor of adopting the timeboost proposal and will be voting for the option to collect ETH. Why ETH?
When we talk about burning in general, it means we are sharing value or dividends with all token holders, including speculators and those who don't care about the protocol or the DAO at all. Although this is a great way to avoid regulatory hurdles and create a burning narrative within the community, it will result in leaking value to the speculators. At some point, we can decide to do so, but it requires a rich treasury. Considering the 50% allocation of our ETH treasury to the BOLD validator, helping toward the diversification and strengthening of the treasury would be a more efficient option and will have a more positive impact and flexibility on the DAO.
This is a great proposal that I'm very excited to support. Let's assume for now that the mechanism design finds its sweet spot before implementation. In that case, here are my suggestions.
This is a great proposal that I'm very excited to support. Let's assume for now that the mechanism design finds its sweet spot before implementation. In that case, here are my suggestions.
I think both signals are important for Arbitrum at this time. Showing that we are willing to give ARB utility is why I think this amount should be non-zero. However, diversification is critical and this is a great way to do it.
My suggestion is monthly or quarterly votes to update the ratio such that the community can regularly take part in adjusting to the current environment and needs of the ecosystem.
Timeboost is going to take Arbitrum DAO to the next level. Absolutely stoked for this one! I still need to dig into the technicals, but I am obviously supportive of this initiative.. as I am sure most community members will be.
In reference to the below:
Timeboost is going to take Arbitrum DAO to the next level. Absolutely stoked for this one! I still need to dig into the technicals, but I am obviously supportive of this initiative.. as I am sure most community members will be.
In reference to the below:
I believe it is a no brainer to collect the fees in ETH and send the proceeds to the treasury where they can be leveraged to earn additional yield into perpetuity. I understand people want ARB utility ASAP, but I firmly believe that we can build up a treasury worth 10s of billions of dollars of ETH and Stables over time. Once we reach that point, I will be in favor of protocol revenue share with token holders through some type of mechanism.
I believe it is extremely important for the DAO to have a longterm mindset on these types of issues rather than rushing to share profit or burn ARB tokens during our early stage growth phase. Do we really want to be in a situation where we enter a bear market with a treasury w/ 99% of its assets in ARB with no inherent staking yield, and minimal yield opportunities / liquidity when compared to ETH? Or do we want hundreds of millions (and eventually billions) of dollars of ETH and Stables that can earn at minimum the ETH staking yield and US short term treasury yield?
To me, the answer is obvious. I want Arbitrum to be well capitalized over the coming decades, rather than essentially buying our token at a valuation that has a ton of speculative premium priced in and sending it to an EOA that no one controls or benefits from...
Very interesting proposal, it's a great way to increase revenue while not really disrupting the MEV scene on Arbitrum for average users.
As we are moving closer to ARB staking and some kind of revenue distribution, I believe it makes more sense to collect fees in ETH to also keep some consistency with the rest of fees on the network.
Just curious of a few technical aspects of timeboost:
I share most of this but wanna focus on 3.
For instance, could we consider redistributing a portion of the profits (in ARB?) generated to the protocols used by these transactions?
gm, super interesting proposal - thank you for sharing. Arbitrum developers confirmed to be superstars who always look at new win-win improvements for the ecosystem.
I would like to understand better who would be the target user of this (maybe asking some dumb questions here):
gm, super interesting proposal - thank you for sharing. Arbitrum developers confirmed to be superstars who always look at new win-win improvements for the ecosystem.
I would like to understand better who would be the target user of this (maybe asking some dumb questions here):
user transactions will still remain private until after they are executed, meaning that the express lane controller cannot frontrun or sandwich users
What type of MEV activity exists today on Arbitrum? What do searchers search for?
Access to the express lane would be auctioned off in one-minute rounds, with the auction happening 15 seconds before the round begins.
Similarly, with this type of timeframe, what kind of transactions would go through the fast lane?
On top of the 2 options proposed, I lean towards accumulating ETH in the Treasury, until we agree on the best way to distribute it and/or we have accumulated enough reserves.
In general, I would exclude token burning because it doesn't inherently increase the fundamental value of the token: https://www.placeholder.vc/blog/2020/9/17/stop-burning-tokens-buyback-and-make-instead
I believe the adoption of Timeboost is a beneficial move for Arbitrum, as it not only addresses MEV-related challenges but also creates a sustainable revenue stream for the DAO. I agree with @cp0x suggestion to distribute ARB proceeds to stakers, which fosters community engagement and aligns incentives without reducing the ARB supply through burning.
Blockworks Research will be voting in favor of the option to COLLECT ETH
We approve of Option 1, especially since the DAO is currently lacking treasury diversification. As we have stated elsewhere, the BoLD validator bootstrapping will take half of the DAO’s current ETH, leaving us in a position to replenish.
Understandably, we recognize the potential for driving value to ARB, though, we believe the DAO should prioritize replenishing reserves in ETH, before introducing value accrual mechanisms. That consists of stablecoins and ETH. We can better lay out the path for ARB once we begin to lay out expenses in stablecoins and gain staking yield from ETH. The DAO should be in a stronger position with its treasury before launching other initiatives with ARB. Moreover, the clarification about governance being capable of setting the min bid price is attractive, and should be revisited on a later date.
We are definitely excited to see Timeboost will be introduced to mitigate the issues around the L2 MEV landscape and actors while appropriately capturing the revenue opportunity and/or introduction to the burning mechanism for the ARB token.
We are generally in favor of Option 1 in terms of the auction proceeds. We believe the current priority for the DAO is to sustainably manage the DAO treasury as we are currently discussing the Arbitrum gas fee and sequencer revenue. We also like the "split profits" option @DisruptionJoe suggested too, but we consider it the best to keep the ratio of the ETH collection much more than the ARB burning for the short term anyway.
When it comes to the implementation and integration, we would suggest the team to look into what FastLane has been working on as the idea of introducing an Express Lane is very similar to their approach. (Ref: Alex's post, Disclaimer: Tané's investment arm is an investor of FastLane)
Very interesting proposal, it's a great way to increase revenue while not really disrupting the MEV scene on Arbitrum for average users.
As we are moving closer to ARB staking and some kind of revenue distribution, I believe it makes more sense to collect fees in ETH to also keep some consistency with the rest of fees on the network.
Just curious of a few technical aspects of timeboost:
I share most of this but wanna focus on 3.
For instance, could we consider redistributing a portion of the profits (in ARB?) generated to the protocols used by these transactions?
While i think we should go for eth, because from ballpark numbers arb might not be the best idea, i think the above could be brilliant to spin up the following for builders: when you deploy on arb, if your protocol generates a certain type of traffic, you get a share of the revenue of the whole chain.
And while this could potentially be a compliance and organization nightmare, could also be one of the things that creates a new narrative, not seen at scale, in our industry.
This is an exciting proposal!
Regarding choosing the right option (burn ARB or receive ETH), my belief is that this need to be evaluated having in mind a broader discussion about DAO's spending budget, runway, and treasury management strategy. Having to choose now, I would say that option 1 is better, as is an extra revenue stream to the DAO, that can later decide how to use that to foster growth and perpetuity.
Overall the idea sounds exciting and I'm aligned with most of the positive arguments highlighted in the convo, but I do have a few reservations:
1. Technical implementation As @yusufxzy and @0x_ultra highlighted above, having more information about some mechanisms and technical details would be helpful, in particular re the auctioneer management and potential associated risks.
Overall the idea sounds exciting and I'm aligned with most of the positive arguments highlighted in the convo, but I do have a few reservations:
1. Technical implementation As @yusufxzy and @0x_ultra highlighted above, having more information about some mechanisms and technical details would be helpful, in particular re the auctioneer management and potential associated risks.
2. Data and projections Is there any existing data on similar implementations on other chains that we could refer to? If not, do we have any projections or models to rely on? Specifically, data on how this change might impact arbitrage behavior -- based on the potential increase of transaction costs and block time. How much those increases could impact the current arbitrage opportunities -- which in turn might affect traffic? This is a pretty important consideration imho, and having a past study or projections would help assess the potential impact more clearly.
3. Profits redistribution The DAO's recent focus has mostly be on strengthening its treasury and enhancing ARB's utility, which isn't a bad thing in itself, but I feel like we're forgetting there are other options. For instance, could we consider redistributing a portion of the profits (in ARB?) generated to the protocols used by these transactions? This feels like a fair and easy way to incentivize protocols by actually rewarding them for real contributions and activity on the chain.
I propose a third option for profit distribution. Distribute 100% of the received ARB to ARB stakers (if such staking is accepted) In any case, I believe that there is no point in burning ARB: there are many ways to properly distribute profits.
Hello,
very interesting proposal and idea behind Timeboost. Basically its a "sniper tool" for MEV searcher, NFT sniper and every other situation where one needs to be fast.
What is going to happen if, lets says, every user is deciding to use the fast lane. Who will be the winner then?
Hello,
very interesting proposal and idea behind Timeboost. Basically its a "sniper tool" for MEV searcher, NFT sniper and every other situation where one needs to be fast.
What is going to happen if, lets says, every user is deciding to use the fast lane. Who will be the winner then?
Also I would tend to Option 2, collect in ARB and burn. One could say we need more ETH in the treasury, but I do think the main problem is not that we need more ETH, rather the DAO should focus more on spending and budgets.
Blockworks Research will be voting in favor of the option to COLLECT ETH
We approve of Option 1, especially since the DAO is currently lacking treasury diversification. As we have stated elsewhere, the BoLD validator bootstrapping will take half of the DAO’s current ETH, leaving us in a position to replenish.
Understandably, we recognize the potential for driving value to ARB, though, we believe the DAO should prioritize replenishing reserves in ETH, before introducing value accrual mechanisms. That consists of stablecoins and ETH. We can better lay out the path for ARB once we begin to lay out expenses in stablecoins and gain staking yield from ETH. The DAO should be in a stronger position with its treasury before launching other initiatives with ARB. Moreover, the clarification about governance being capable of setting the min bid price is attractive, and should be revisited on a later date.
We are definitely excited to see Timeboost will be introduced to mitigate the issues around the L2 MEV landscape and actors while appropriately capturing the revenue opportunity and/or introduction to the burning mechanism for the ARB token.
We are generally in favor of Option 1 in terms of the auction proceeds. We believe the current priority for the DAO is to sustainably manage the DAO treasury as we are currently discussing the Arbitrum gas fee and sequencer revenue. We also like the "split profits" option @DisruptionJoe suggested too, but we consider it the best to keep the ratio of the ETH collection much more than the ARB burning for the short term anyway.
When it comes to the implementation and integration, we would suggest the team to look into what FastLane has been working on as the idea of introducing an Express Lane is very similar to their approach. (Ref: Alex's post, Disclaimer: Tané's investment arm is an investor of FastLane)
Very interesting proposal, it's a great way to increase revenue while not really disrupting the MEV scene on Arbitrum for average users.
As we are moving closer to ARB staking and some kind of revenue distribution, I believe it makes more sense to collect fees in ETH to also keep some consistency with the rest of fees on the network.
Just curious of a few technical aspects of timeboost:
I share most of this but wanna focus on 3.
For instance, could we consider redistributing a portion of the profits (in ARB?) generated to the protocols used by these transactions?
While i think we should go for eth, because from ballpark numbers arb might not be the best idea, i think the above could be brilliant to spin up the following for builders: when you deploy on arb, if your protocol generates a certain type of traffic, you get a share of the revenue of the whole chain.
And while this could potentially be a compliance and organization nightmare, could also be one of the things that creates a new narrative, not seen at scale, in our industry.
This is an exciting proposal!
Regarding choosing the right option (burn ARB or receive ETH), my belief is that this need to be evaluated having in mind a broader discussion about DAO's spending budget, runway, and treasury management strategy. Having to choose now, I would say that option 1 is better, as is an extra revenue stream to the DAO, that can later decide how to use that to foster growth and perpetuity.
Overall the idea sounds exciting and I'm aligned with most of the positive arguments highlighted in the convo, but I do have a few reservations:
1. Technical implementation As @yusufxzy and @0x_ultra highlighted above, having more information about some mechanisms and technical details would be helpful, in particular re the auctioneer management and potential associated risks.
Overall the idea sounds exciting and I'm aligned with most of the positive arguments highlighted in the convo, but I do have a few reservations:
1. Technical implementation As @yusufxzy and @0x_ultra highlighted above, having more information about some mechanisms and technical details would be helpful, in particular re the auctioneer management and potential associated risks.
2. Data and projections Is there any existing data on similar implementations on other chains that we could refer to? If not, do we have any projections or models to rely on? Specifically, data on how this change might impact arbitrage behavior -- based on the potential increase of transaction costs and block time. How much those increases could impact the current arbitrage opportunities -- which in turn might affect traffic? This is a pretty important consideration imho, and having a past study or projections would help assess the potential impact more clearly.
3. Profits redistribution The DAO's recent focus has mostly be on strengthening its treasury and enhancing ARB's utility, which isn't a bad thing in itself, but I feel like we're forgetting there are other options. For instance, could we consider redistributing a portion of the profits (in ARB?) generated to the protocols used by these transactions? This feels like a fair and easy way to incentivize protocols by actually rewarding them for real contributions and activity on the chain.
I propose a third option for profit distribution. Distribute 100% of the received ARB to ARB stakers (if such staking is accepted) In any case, I believe that there is no point in burning ARB: there are many ways to properly distribute profits.
Hello,
very interesting proposal and idea behind Timeboost. Basically its a "sniper tool" for MEV searcher, NFT sniper and every other situation where one needs to be fast.
What is going to happen if, lets says, every user is deciding to use the fast lane. Who will be the winner then?
Hello,
very interesting proposal and idea behind Timeboost. Basically its a "sniper tool" for MEV searcher, NFT sniper and every other situation where one needs to be fast.
What is going to happen if, lets says, every user is deciding to use the fast lane. Who will be the winner then?
Also I would tend to Option 2, collect in ARB and burn. One could say we need more ETH in the treasury, but I do think the main problem is not that we need more ETH, rather the DAO should focus more on spending and budgets.