We support this proposal as it balances allowing time for opponents to respond and take action, providing the Security Council with an opportunity to review actions in detail, and delaying the implementation of proposed changes.
We appreciate the inclusion of emergency situations but suggest clarifying the criteria for defining them. We understand this may be difficult and will be decided by the Security Council but this criteria would be a nice to have.
In the future, we recommend giving the Security Council flexibility to adjust the delay from 3 to 10 days based on the quantity of proposals or specific needs, if technically possible.
An additional 5 days is based on the recommendation from L2 Beatâs website to turn the red slice into a yellow slice.
The motivation for it can be found here:
Specifically:
Do users have at least 7 days to exit in case of unwanted upgrades (Security Council and governance excluded)?
This requirement is designed to protect users in the event of significant changes to the system, such as upgrades or modifications that they do not agree with. A minimum exit period of 7 days provides users with sufficient time to withdraw their assets and exit the system if they choose. At this stage, a Security Council and a governance system are permitted to act more swiftly. Note that a 7-day upgrade delay alone might not be sufficient: if any delay to withdraw is present (for example, a delay to force transactions in case of censoring operators), it is subtracted from the exit window.
The proposal only needs to update a configuration as well, so it is a fairly straight forward proposal.
Overall, there is very minimal downside for extending this timeframe to ensure proper diligence. @Argonaut brings up a good point regarding making sure we can define some of the terminology here, and although some on the moment adaptation is needed, we think having some definitions would be nice.
Adding in the delay such that there is sufficient time to bridge out natively if needed makes sense and maybe even an extra day or two from this could do well in the future.
On behalf of the UADP, the 8 day lock that is being instituted is crucial for people to get out if they want to using the 7 day native bridge. We think this additional time is only a positive and with very little negatives, and plus, we can always change again in the future.
The following reflects the views of the Lampros Labs DAO governance team, composed of @Blueweb, @Euphoria, and @Nyx, based on our combined research and analysis.
We vote in favour of this proposal.
The proposed increase in the timelock delay for core upgrades is a positive step, aligning with the direction L2s are moving towards. This change follows L2Beatâs recommendations, and the shift from red to yellow status is a good signal for Arbitrum.
We went through the L2Beat website and noticed that zkSync Lite already has a yellow slice, so joining them in this status would be beneficial.
We also believe itâs important to define emergency situations clearly and as much as possible with current knowledge. This will help the Security Council make more informed and deterministic decisions when needed.
We voted in favor of this proposal on Snapshot. We believe that constitutional votes and changes could benefit from having an extra delay to ensure smart contract upgrades will have the intended effects. This will not affect most on-chain proposals and hence will not slow down the process for treasury and operational related proposals. We see this as a positive for Arbitrumâs security with little downside.
However, the idea that someone would want to withdraw money from Arbitrum within 8 days is not entirely realistic.
In order for users to know that Arbitrum has accepted some new conditions, a more widespread notification is needed.
There is almost no information about voting on Twitter right now.
Those who follow the situation may know about changes months in advance, can follow the development of the proposal on the forum, then on Snapshot, and only then implementation through Tally.
I voted FOR this proposal at the temp check stage. I think itâs reasonable to give users and the security council more time to exit after a constitutional proposal is passed. Most DAO proposals are non-constitutional, so it wonât affect the timeline in most cases.
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 are voting FOR this proposal.
The proposed extension of the L2 timelock delay will help make Arbitrum even more secure by increasing the time window in which the Security Council can act in case a malicious proposal is passed or in which users can withdraw their assets from Arbitrum (One and Nova) if they are worried or not satisfied with a proposal.
If the proposal is successful, Arbitrumâs âExit Windowâ slice on L2BEATâs Risk Rosette will be turned yellow. Additionally, Arbitrum will be one step closer to the 30d exit window required for Stage 2 classification as outlined in L2BEATâs stages framework.
As L2BEAT, weâll ensure that weâve done our due diligence on the proposed executable before casting our vote onchain when the proposal goes to Tally.
As the DAO Advocate for the ARDC, we have assigned OpenZeppelin, the âSecurityâ member, to review the proposed implementation so delegates can make an informed decision when the proposal moves to an onchain vote. We will publish the review as soon as itâs complete and link it here for visibility.
After consideration, the @SEEDgov delegation has decided to vote âFORâ on this proposal at the Snapshot vote.
Rationale
We value the framework developed by L2BEAT as a guide for this initiative and recognize the necessity of this update for two key reasons:
Extending the window for users to exit the network in the event of an unwanted update is ethically sound and enhances the confidence of those looking to invest their capital in Arbitrum.
Providing the Security Council with additional time to address potentially malicious proposals is, without question, a prudent measure. We believe this approach reinforces the principle that security is always the top priority.
We believe the benefits of extending the L2 Core Time Lock delay should outweigh the downside described in the proposal and itâs reasonable as this change wouldnât affect proposals that merely transfer funds from the treasury. We would review the planned check by the ARDC Security member before its onchain vote.
The extended delay makes sense, and I would argue that it should be even longer than 8 days. This is because 7 days are required to bridge the funds back to the mainnet, leaving only 1 day to communicate with the community about any potential changes they may not agree with, which could lead them to decide to exit the network. Anyway, I voted for the proposal, as it will give the Security Council members more time to double-check for any potential threats related to the approved proposal and exited for the Arbitrum network moving another Step to higher Security Stages of Rollups.
DAOplomats is voting in favor of this proposal on Snapshot.
Security is imperative and implementations to ensure this is kept on a high level are always welcome. Extending delay on the L2Time lock gives that extra time to the Security Council and would certainly be vital if malicious proposals make it past voting stage.
Regarding the downside, itâs a small tradeoff compared to this proposalâs overall gain, so we are happy to support this.
Voting âForâ as it will increase security at no cost to the DAO.
Edit: In order to save forum space, I am editing this comment to indicate my opinion has not changed sinced the snapshot vote - I will be voting âforâ on tally.
=== COMMENTING ON PROPOSAL: ===
As this proposal moves forward, it would be valuable to consider defining emergency scenarios in which a shorter time lock might still be necessary. This could help ensure that, in rare but urgent cases, the system remains flexible enough to act quickly while maintaining security. Additionally, continuous evaluation of the delayâs impact on both user confidence and operational efficiency could provide data-driven insights for future adjustments. Incorporating periodic reviews would keep the system agile and aligned with the evolving needs of the Arbitrum ecosystem.