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.