AIP: Timeboost + Nova Fee Sweep

Proposals
62

Voted For on Tally proposal for the same reasons as explained in my Snapshot comment.

1 Like
63

Voted in the same way in Tally than in the snapshot vote..here is my rationale.

1 Like
64

We have voted in favor on Tally, as this is a straightforward proposal and we have nothing further to add.

1 Like
65

Voted FOR.

Excited for Timeboost to go live, and looking forward to seeing data on how the market responds to this new policy, how builders can create innovation on top of it, and what revenue the DAO generates.

In support of the Nova Fee sweep and to bring the ETH into our Treasury.

Onwards!

1 Like
66

Voted in favor of this proposal (Tally ) the same reason I voted on Snapshot “it introduces an innovative mechanism that not only optimizes the distribution of funds collected through Nova fees but also incentivizes active community participation by rewarding users who contribute to the ecosystem”.

1 Like
67

I voted FOR this proposal on Tally

1 Like
68

Hey everyone, quick update - the auction contracts for Timeboost are actually already deployed on Arbitrum One and Arbitrum Nova, which can be used for Timeboost. Should this vote be passed, within 5 business days, the sequencer operator will provision and enable the autonomous auctioneer to begin receiving bids and upgrade the sequencer to begin honoring the time-advantage to a given round’s express lane controller (whenever there is one). If this vote does not pass, the deployed auction contracts will simply lie dormant and remain unused.

The reason why the auction contracts are deployed is because it is better to do it sooner rather than later when things are more time sensitive, and acts as a practice run so we have time to check through everything a few times. We can always deploy it again if we find an error or misconfiguration - the contracts don’t have to be used if the vote doesn’t pass.

Here are the contracts that are already deployed:

4 Likes
69

The proposal is already live on Tally. You can see it here.

2 Likes
70

I voted FOR on Tally. Timeboost is a great development for Arbitrum, and I am excited to see how it unfolds.

1 Like
71

Previously, both Solana and Arbitrum employed the FIFS (First-In-First-Served) model, but now they’ve chosen completely different paths. Solana, without negatively impacting regular users, grants higher priority to those paying higher priority fees. In contrast, Arbitrum deliberately worsens the experience for all other users by adding a 200ms delay, effectively clearing the way for a single dominant player. Solana has successfully encouraged broader competition, while Arbitrum, frankly speaking, seems to encourage Wintermute’s monopoly.

1 Like
72

I’m voting FOR this proposal on tally. I dont have anything new to add, lets do it!

73

Camelot will ABSTAIN from this vote.
While Camelot wants to support innovation, we’re also extremely worried about the lack of evaluation regarding the consequences of these fundamental changes we are introducing to the chain. We would like to highlight several points that we expect to see as follow-ups to this proposal.

Tail risks and lack of success/failure scenarios

We believe that crypto is an inherently experimental industry built on trial and error, but we don’t think these experiments should come at the potential expense of the entire chain and ecosystem. While we are fully confident in the ability of OCL, we should not minimize or downplay a scenario that carries tail risks, especially because we have had nowhere near enough precautionary analysis or guardrails in place.

To name one: the sequencer operator will have the ability for two years to adjust parameters, pause/disable the system, and, in general, have control over it to “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.” We understand and agree with the general approach and the need for flexibility, but at the same time, we have no clear definition of what success or failure would look like. This is one of the questions we, as a DAO, should get an answer to.

Potential impact on protocols

We also have concerns regarding Timeboost’s potential impact on protocols. As we mentioned from the very beginning, the priority seems to be increasing revenue for the DAO without either:

  • a clear plan for how this revenue will be used
  • any mention of redistribution back to the protocols enabling this revenue in the first place

This approach is worsened by the fact that transitioning from an FCFS model to an express lane purchasable via auction is very close to what we could call value extraction. This creates an environment where Arbitrum non-express lane users will potentially be disadvantaged when providing liquidity, executing swaps, and trading derivatives. To put it more bluntly, the captured value will directly come from current users in Arbitrum and will most impact DeFi protocols like DEXs and perps.

To recap, so far, the setup of Timeboost:

  • introduces new, unstudied risks to our chains
  • lacks any specific success/failure scenario to help us correct what might go wrong
  • increases the DAO’s revenue at the expense of users and protocols
  • does not provide returns to protocols and builders

Metrics to monitor

We also want to list some metrics we believe are worth monitoring for Timeboost at 30, 90, and 180 days post-activation to allow for better evaluation. We think these metrics and any findings should be reported to the DAO for public discussion to assess whether Timeboost has not only delivered the expected revenue benefits but also has not disrupted protocols operating on the chain:

  • overall on-chain volume
  • arbitrage frequency and price stale duration
  • average and median transaction amounts per user
  • protocols’ arbitrage dynamics

These metrics are only suggestions and, of course, not exhaustive, and we think the proposer should put forward their own metrics . It comes down, as mentioned, to defining what success and failure look like, and data measurement is key to this. Recognizing the complexity of this task and the potential challenges in data availability, we suggest that OCL and ARDC collaborate on the analysis.



Timeboost represents one of the most significant fundamental changes in Arbitrum to date, and despite our criticism, we believe it could be a major shift for the ecosystem. Knowing that the proposal will likely pass regardless of our vote, our goal is to highlight the potential risks and what should be effectively monitored moving forward, as well as to push for coordination between OCL and ARDC on this task. Above all, we would like to hear from the proposer what success and failure look like so that we will know when it is time for the DAO to act and in what way.

1 Like
74

Voted FOR on Tally: this proposal is a good step for ArbitrumDAO. I think it helps collect more money and improve the system.

75

Although it won’t affect the outcome of the vote I have to express my concerns, to recap from orginal timeboost thread.
Pros:

  1. Increases DAO revenue.
  2. Reduces spam.

Cons:

  1. Increased slippage and decreasing trading volume, as the auction winner gains greater advatange of liquid providers, so they have to increase the slippage to compensate。
  2. 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.
  3. 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.
76

As a newly active delegate, I’ll preface this response by saying much of my response and questioning is for my own education, rather than critique:

  1. I support added revenue for the DAO, but is there any notion of the expected amount of revenue to be generated? EDIT: @ananth shared the following doc detailing revenue projections noted in a different forum thread last year: Timeboost Revenue and LP Impact Analysis - Google Docs

  2. Does this system, theoretically and if used substantially, run the risk of taking precedence over all non-express transactions thereby forcing all txs to be handled within the express lane and creating a bidding war for processing / high effective tx fee?

  3. I echo some of the other delegates in advocating for the separation of completely disparate proposal actions in the future. Nova fee sweep seems far more simple and generally agreeable. To package a fairly straightforward, non-experimental, and broadly agreed upon action with an experimental, complex, chain-level alternation seems to only muddy things.

  4. Contrary to some general delegate commentary, I do generally support the delay of non-express lane transactions. While it doubles tx time, I don’t believe 200ms is a sum of time appreciable to the average retail user. And, it is certainly not a driving factor in a retail user’s choice of chain. Personally, I believe transaction speed between chains being a marketable advantage is converging on zero as all chains approach speeds seemingly instantaneous to the average user. At a certain point, being milliseconds faster than the next chain simply doesn’t matter.

This being said, I will vote FOR this proposal in support of OCL, added revenue for the DAO, and lack of strong concern to justify not experimenting with this solution.

77

The following reflects the views of the Lampros DAO governance team, composed of Chain_L (@Blueweb), @Euphoria, and Hirangi Pandya (@Nyx), based on our combined research, analysis, and ideation.

We are voting FOR this proposal in Tally voting.

As mentioned in our Snapshot rationale, this is a clear and straightforward proposal that supports both the Nova Fee Sweep and the Timeboost AIP, making execution more efficient.

The update from the @Arbitrum team about the early deployment of auction contracts on both Arbitrum One and Nova shows good foresight and readiness for the smooth implementation once the vote passes.

We’re also eager to see how builders engage with Timeboost and the kind of revenue it can bring to the DAO over time.

78

We vote FOR the proposal on Tally.

We confirmed that the onchain action is related to the Nova fee sweep as instructed and the deployment of the proxy contract and ExpressLaneAuction implementation and continue to support the experimental initiative.

79

I would like to remind everyone that due to the fact that this Adopt Timeboost + Nova Fee Sweep is a Constitutional AIP, which means the quorum is 5% - about 210 million, which is a lot even taking into account the extra week of voting.
We only had 3 proposals that exceeded 210 million votes, so don’t forget to vote!

In turn, I also voted FOR. I will simply summarize the theses that I consider important:

  1. TimeBoost is possibly the only way to get additional profit for Arbitrum for stable budget support. Future initiatives will be formed from this budget, because the current treasury with such large expenses will not last long.
  2. TimeBoost is a competitive advantage even in relation to Ethereum, where such an opportunity is not possible due to the peculiarities of chain construction. Perhaps this will attract more liquidity to Arbitrum.
  3. Nova Fee Sweep is a necessity, because money should not lie as a dead weight, but should work for the benefit of the community.
80

Voting FOR

The DD on this has been done properly and it’s worthwhile to test

81

I’m voting FOR this proposal on tally, maintaining my previous votes for Timeboost and Nova Fee Sweep proposals

I expect continuous monitoring of the implementation of Time Boost and its impact on the chain and protocol performance.

In particular, I want to echo the concerns raised by @Camelot. If there is a risk that the MEV captured by this new transaction auction model could impact users (and even harm them), there could be implications for performance, network trust, and legal considerations.

Understanding that the MEV being captured will come from arbitrage opportunities, it is still very important to maintain monitoring to analyze any unforeseen consequences.

That’s why I’m also tagging the ARDC (cc @tamara @Atomist @Frisson @Juanrah) and kindly asking them :slight_smile: to coordinate with OCL and the Foundation to assess whether it makes sense to assign the available providers to conduct thorough monitoring and reporting on the impact of Time Boost during the first few months (at least for the duration of the current ARDC mandate)