Blockworks Research will be voting FOR this proposal on Tally.
This seems like a clearly needed upgrade for the exit window for Arbitrum. Since the security member review, the timelock delay has been found to be safe and a reasonable upgrade for increasing security.
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 the proposal.
As we pointed out during the temp-check vote, if this 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.
Having reviewed the executable ourselves to confirm that the changes it will bring match the described modifications and also having the security review from the ARDC as a cross-check, we’re comfortable voting in favor of the proposal onchain.
DAOplomats is voting for this proposal on Tally.
We are maintaining our support of the proposal from the temp check
gTrade is in favor of the extended delay! While it might slow down the proposal implementation process, it provides added protection against governance attacks, increases overall security for users, and gives the security council more time to respond in case of any malicious actions.
We vote FOR the proposal on Tally.
We maintain our stance made in the Snapshot phase and continue to support the change after having reviewed the report by the ARDC.
As I mentioned before this is a huge improvement for the ecosystem.
Also in our way to Stage 2 and understanding importance for stage in rollups next year, this is an important step here.
Gm, gm 
The results are in for the Constitutional AIP - Extend Delay on L2Time Lock on-chain proposal.
See how the community voted and more Arbitrum stats:
As a result of this proposal being executed, Arbitrum One is now closer to being a ‘Stage 2 Rollup’
Voted FOR: Extend Delay on L2Time Lock
Voting Rationale: Alex Lumley (Savvy DAO) Delegate Communication Thread - #37 by AlexLumley
As stated in my previous Commenting Rationale (Constitutional - Extend Delay on L2Time Lock - #41 by AlexLumley) , I hoped this proposal would include the points below. While these have not been included I do hope future iterations will include them:
• Consider Emergency Scenarios:
• Define specific emergency situations where a shorter time lock could be justified.
• This ensures flexibility to respond swiftly in rare but urgent cases, balancing speed and security.
• Continuous Evaluation of Delay’s Impact:
• Regularly assess how the delay affects user confidence and operational efficiency.
• Use data-driven insights from these evaluations to inform future adjustments if needed.
• Incorporate Periodic Reviews:
• Schedule periodic reviews to assess the time lock’s relevance and effectiveness.
• Keeps the system responsive and aligned with the evolving needs of the Arbitrum ecosystem, promoting agility and adaptability.