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.
We are in favor of adopting the Timeboost transaction ordering policy. This implementation will introduce several key benefits to the Arbitrum ecosystem:
- Efficient Arbitrage: Timeboost will enable more efficient arbitrage opportunities within the network, helping to tighten price spreads and provide better trading experiences across decentralized exchanges (DEXs) and other protocols.
- Lower Infrastructure Burden: By optimizing the way transactions are ordered and processed, Timeboost will reduce the infrastructure burden on validators, ensuring more efficient resource usage and faster transaction throughput.
- New Revenue Stream for the DAO: A key benefit of Timeboost is its ability to collect bids in ETH for transaction ordering. This can generate a new and sustainable revenue stream for the Arbitrum DAO, strengthening the DAO’s long-term financial health while maintaining fair and efficient transaction processing.
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.
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.
1 Like
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: Overview: The Lifecycle of an Arbitrum Transaction | Arbitrum Docs.
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.
1 Like
After consideration, the @SEEDgov delegation has decided to vote “Collect bids in ETH to the treasury” on this proposal at the Snapshot vote.
Rationale
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:
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 agree with this proposal cause the whole new transaction ordering policy can:
- provides a new revenue stream for Arbitrum DAO. Proceeds from auctions, collected in ETH or ARB, can be directed to the treasury or used for ARB token burns, creating value for token holders.
- helps reduce the infrastructure strain caused by MEV searchers, lessening the load on the chain.
- retains front running protections and allows the DAO to capture some of the MEV value, which would otherwise be monopolized by searchers, redistributing benefits back to the community.
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?
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.
Voting “For, Collecting ETH” as this presents a good opportunity to diversify the DAO’s treasury.
gm, I voted in favor of this proposal, and to collect fees in ETH until the DAO decides how to distribute or that revenue.
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.
5 Likes
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:
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
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).
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.
Thanks,
MevAintFree
2 Likes
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.
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.
1 Like
Timeboost is essentially a auction for ‘god trader’, who can then do as they please. Wintermute loves it. Good luck, guys!
2 Likes
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.
1 Like
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.
2 Likes