Abstract

The ArbitrumDAO has on-chain governance via a suite of smart contracts. It allows the ArbitrumDAO to spend funds from its treasury alongside upgrading any smart contract that governs Arbitrum One or Arbitrum Nova. The on-chain smart contract suite includes a voting protocol alongside a series of contracts that will forward the proposal’s intended action to the correct destination before executing it.

The proposal focuses on extending the time delay between when the voting protocol has concluded and the time it takes for the successful proposal to be passed along by the system until it is in the right destination to be executed. The focus is on the L2 Core Time Lock contract that lives on Arbitrum One and proposes changing the delay from 3 days to 8 days which effectively increases the delay by an additional 5 days.

There are two benefits to increasing the delay:

Security Council. The Security Council will have more time to act if a malicious proposal is passed by the ArbitrumDAO for whatever reason.
Exit window. Users will have more time to withdraw their assets from Arbitrum One or Arbitrum Nova if they are worried or not satisfied about how a proposal intends to change the smart contracts that govern Arbitrum One or Arbitrum Nova.

Additionally, by increasing the exit window, it will also update the status of Arbitrum by L2Beat and replace a red slice with a yellow slice. This will help Arbitrum move one step closer towards a Stage-2 rollup.

The downside of increasing the delay is that all constitutional proposals, primarily for upgrading the smart contracts, will be delayed by an additional 5 days. It does not impact or add an additional delay to any spending from the ArbitrumDAO’s treasury including ARB and ETH.

Time Lock Extension

|624x316 Image: Overview of the Current Time Locks

All proposals voted on and passed by the ArbitrumDAO must pass through an L2 Time Lock before it can move onto the next stage.

There are currently two L2 Time Locks that are implemented via the on-chain governance smart contracts.

L2 Treasury TimeLock. Delays all spends from the ArbitrumDAO’s ETH Treasury.
L2 Core TimeLock. Delays any actions related to on-chain upgrades.

The proposal focuses on the Core L2 TimeLock. It is responsible for passing messages that contain executable code and it has the authority to upgrade any smart contract in the system including on-chain governance and the bridges (holding user assets) on Arbitrum One/Nova.

If you want to learn more about the governance of smart contracts, please check out this diagram and the docs.

Steps to Implement & Timeline

The proposal is to change the value of _minDelay from 259200 (seconds) to 691200 (seconds) in the L2 Timelock contract. This will change the time delay from 3 days to 8 days, an additional 5 days.

The action contract is implemented and still pending an audit:

https://github.com/ArbitrumFoundation/governance/pull/306

Additionally, we will need to update the ArbitrumDAO Constitution:

Phase 4: L2 Waiting Period (3 days): After an AIP has passed Phase 3, a 3 day waiting period occurs. This gives users who object to the AIP time to initiate withdrawal of their funds or take other action on L2.

Phase 5: Initiate and Finalize an L2-to-L1 Message (at least 1 challenge period of the rollup protocol): After the 3 day waiting period in Phase 4 has passed, an L2-to-L1 message is sent indicating that the AIP was passed.

The Constitution Text will be updated to the following:

Phase 4: L2 Waiting Period (3 or 8 days): After an AIP has passed Phase 3, there is a 3 day waiting period for actions related to the DAO Treasury and an 8 day waiting period for an L2-to-L1 Message. This gives users who object to the AIP time to initiate withdrawal of their funds or take other action on L2.

Phase 5: Initiate and Finalize an L2-to-L1 Message (at least 1 challenge period of the rollup protocol): After the waiting period for Phase 4 has passed, an L2-to-L1 message is sent indicating that the AIP was passed.

The new constitution hash: 0x28faf2acba9b3ff80ec484e3d5646931eeef40568b1b7c38dbe52b890bfd7938

Timeline

Feedback Period: 23/8/24 to 29/8/24
Temperature Check: 29/8/24 to 5/9/24
ARDC Review: 5/9/24 to 16/9/24
On-chain vote: 16/9/24

There is no cost to the ArbitrumDAO for the implementation of this proposal and an audit will be publicly available prior to the on-chain vote.

Abstract

There are two benefits to increasing the delay:

Security Council. The Security Council will have more time to act if a malicious proposal is passed by the ArbitrumDAO for whatever reason.
Exit window. Users will have more time to withdraw their assets from Arbitrum One or Arbitrum Nova if they are worried or not satisfied about how a proposal intends to change the smart contracts that govern Arbitrum One or Arbitrum Nova.

Time Lock Extension

|624x316 Image: Overview of the Current Time Locks

All proposals voted on and passed by the ArbitrumDAO must pass through an L2 Time Lock before it can move onto the next stage.

There are currently two L2 Time Locks that are implemented via the on-chain governance smart contracts.

L2 Treasury TimeLock. Delays all spends from the ArbitrumDAO’s ETH Treasury.
L2 Core TimeLock. Delays any actions related to on-chain upgrades.

If you want to learn more about the governance of smart contracts, please check out this diagram and the docs.

Steps to Implement & Timeline

The proposal is to change the value of _minDelay from 259200 (seconds) to 691200 (seconds) in the L2 Timelock contract. This will change the time delay from 3 days to 8 days, an additional 5 days.

The action contract is implemented and still pending an audit:

https://github.com/ArbitrumFoundation/governance/pull/306

Additionally, we will need to update the ArbitrumDAO Constitution:

Phase 4: L2 Waiting Period (3 days): After an AIP has passed Phase 3, a 3 day waiting period occurs. This gives users who object to the AIP time to initiate withdrawal of their funds or take other action on L2.

Phase 5: Initiate and Finalize an L2-to-L1 Message (at least 1 challenge period of the rollup protocol): After the 3 day waiting period in Phase 4 has passed, an L2-to-L1 message is sent indicating that the AIP was passed.

The Constitution Text will be updated to the following:

Phase 4: L2 Waiting Period (3 or 8 days): After an AIP has passed Phase 3, there is a 3 day waiting period for actions related to the DAO Treasury and an 8 day waiting period for an L2-to-L1 Message. This gives users who object to the AIP time to initiate withdrawal of their funds or take other action on L2.

Phase 5: Initiate and Finalize an L2-to-L1 Message (at least 1 challenge period of the rollup protocol): After the waiting period for Phase 4 has passed, an L2-to-L1 message is sent indicating that the AIP was passed.

The new constitution hash: 0x28faf2acba9b3ff80ec484e3d5646931eeef40568b1b7c38dbe52b890bfd7938

Timeline

Feedback Period: 23/8/24 to 29/8/24
Temperature Check: 29/8/24 to 5/9/24
ARDC Review: 5/9/24 to 16/9/24
On-chain vote: 16/9/24

There is no cost to the ArbitrumDAO for the implementation of this proposal and an audit will be publicly available prior to the on-chain vote.

Abstract

There are two benefits to increasing the delay:

Security Council. The Security Council will have more time to act if a malicious proposal is passed by the ArbitrumDAO for whatever reason.
Exit window. Users will have more time to withdraw their assets from Arbitrum One or Arbitrum Nova if they are worried or not satisfied about how a proposal intends to change the smart contracts that govern Arbitrum One or Arbitrum Nova.

Time Lock Extension

|624x316 Image: Overview of the Current Time Locks

All proposals voted on and passed by the ArbitrumDAO must pass through an L2 Time Lock before it can move onto the next stage.

There are currently two L2 Time Locks that are implemented via the on-chain governance smart contracts.

L2 Treasury TimeLock. Delays all spends from the ArbitrumDAO’s ETH Treasury.
L2 Core TimeLock. Delays any actions related to on-chain upgrades.

If you want to learn more about the governance of smart contracts, please check out this diagram and the docs.

Steps to Implement & Timeline

The proposal is to change the value of _minDelay from 259200 (seconds) to 691200 (seconds) in the L2 Timelock contract. This will change the time delay from 3 days to 8 days, an additional 5 days.

The action contract is implemented and still pending an audit:

https://github.com/ArbitrumFoundation/governance/pull/306

Additionally, we will need to update the ArbitrumDAO Constitution:

Phase 4: L2 Waiting Period (3 days): After an AIP has passed Phase 3, a 3 day waiting period occurs. This gives users who object to the AIP time to initiate withdrawal of their funds or take other action on L2.

Phase 5: Initiate and Finalize an L2-to-L1 Message (at least 1 challenge period of the rollup protocol): After the 3 day waiting period in Phase 4 has passed, an L2-to-L1 message is sent indicating that the AIP was passed.

The Constitution Text will be updated to the following:

Phase 4: L2 Waiting Period (3 or 8 days): After an AIP has passed Phase 3, there is a 3 day waiting period for actions related to the DAO Treasury and an 8 day waiting period for an L2-to-L1 Message. This gives users who object to the AIP time to initiate withdrawal of their funds or take other action on L2.

Phase 5: Initiate and Finalize an L2-to-L1 Message (at least 1 challenge period of the rollup protocol): After the waiting period for Phase 4 has passed, an L2-to-L1 message is sent indicating that the AIP was passed.

The new constitution hash: 0x28faf2acba9b3ff80ec484e3d5646931eeef40568b1b7c38dbe52b890bfd7938

Timeline

Feedback Period: 23/8/24 to 29/8/24
Temperature Check: 29/8/24 to 5/9/24
ARDC Review: 5/9/24 to 16/9/24
On-chain vote: 16/9/24

There is no cost to the ArbitrumDAO for the implementation of this proposal and an audit will be publicly available prior to the on-chain vote.

Abstract

There are two benefits to increasing the delay:

Security Council. The Security Council will have more time to act if a malicious proposal is passed by the ArbitrumDAO for whatever reason.
Exit window. Users will have more time to withdraw their assets from Arbitrum One or Arbitrum Nova if they are worried or not satisfied about how a proposal intends to change the smart contracts that govern Arbitrum One or Arbitrum Nova.

Time Lock Extension

|624x316 Image: Overview of the Current Time Locks

All proposals voted on and passed by the ArbitrumDAO must pass through an L2 Time Lock before it can move onto the next stage.

There are currently two L2 Time Locks that are implemented via the on-chain governance smart contracts.

L2 Treasury TimeLock. Delays all spends from the ArbitrumDAO’s ETH Treasury.
L2 Core TimeLock. Delays any actions related to on-chain upgrades.

If you want to learn more about the governance of smart contracts, please check out this diagram and the docs.

Steps to Implement & Timeline

The proposal is to change the value of _minDelay from 259200 (seconds) to 691200 (seconds) in the L2 Timelock contract. This will change the time delay from 3 days to 8 days, an additional 5 days.

The action contract is implemented and still pending an audit:

https://github.com/ArbitrumFoundation/governance/pull/306

Additionally, we will need to update the ArbitrumDAO Constitution:

Phase 4: L2 Waiting Period (3 days): After an AIP has passed Phase 3, a 3 day waiting period occurs. This gives users who object to the AIP time to initiate withdrawal of their funds or take other action on L2.

Phase 5: Initiate and Finalize an L2-to-L1 Message (at least 1 challenge period of the rollup protocol): After the 3 day waiting period in Phase 4 has passed, an L2-to-L1 message is sent indicating that the AIP was passed.

The Constitution Text will be updated to the following:

Phase 4: L2 Waiting Period (3 or 8 days): After an AIP has passed Phase 3, there is a 3 day waiting period for actions related to the DAO Treasury and an 8 day waiting period for an L2-to-L1 Message. This gives users who object to the AIP time to initiate withdrawal of their funds or take other action on L2.

Phase 5: Initiate and Finalize an L2-to-L1 Message (at least 1 challenge period of the rollup protocol): After the waiting period for Phase 4 has passed, an L2-to-L1 message is sent indicating that the AIP was passed.

The new constitution hash: 0x28faf2acba9b3ff80ec484e3d5646931eeef40568b1b7c38dbe52b890bfd7938

Timeline

Feedback Period: 23/8/24 to 29/8/24
Temperature Check: 29/8/24 to 5/9/24
ARDC Review: 5/9/24 to 16/9/24
On-chain vote: 16/9/24

There is no cost to the ArbitrumDAO for the implementation of this proposal and an audit will be publicly available prior to the on-chain vote.

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.

OpenZeppelin, the Security Member of the ARDC, reviewed this proposal for security risks. You may find our review at

https://forum.arbitrum.foundation/t/arbitrum-l2-time-lock-delay-proposal-security-review/26837

Treasure ARC has voted in favor of this proposal. The increase in security and flexibility for the Security Council and for users is beneficial and moving the needle on the Stage 2 Rollup metrics is aligned with Arbitrum's longer term goals.

OpenZeppelin, the Security Member of the ARDC, reviewed this proposal for security risks. You may find our review at

https://forum.arbitrum.foundation/t/arbitrum-l2-time-lock-delay-proposal-security-review/26837

We support this proposal. Although it will introduce delays in certain circumstances, we believe the increased security is a worthwhile tradeoff.

In favour as it increases security for users without any significant sacrifices.

https://x.com/arbitrumdao_gov/status/1849806623637897322

As a result of this proposal being executed, Arbitrum One is now closer to being a 'Stage 2 Rollup'

Gm, gm :sparkles:

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: https://dhive.io/proposal/1385

https://x.com/arbitrumdao_gov/status/1849806623637897322

As a result of this proposal being executed, Arbitrum One is now closer to being a 'Stage 2 Rollup'

Gm, gm :sparkles:

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: https://dhive.io/proposal/1385

Gm, gm! :sparkles:

The results are in for the [Constitutional] Extend Delay on L2Time Lock off-chain proposal.

See how the community voted and more Arbitrum stats: https://dhive.io/proposal/1126

Gm, gm! :sparkles:

The results are in for the [Constitutional] Extend Delay on L2Time Lock off-chain proposal.

See how the community voted and more Arbitrum stats: https://dhive.io/proposal/1126

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: https://medium.com/l2beat/introducing-stages-a-framework-to-evaluate-rollups-maturity-d290bb22befe

Specifically:

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: https://medium.com/l2beat/introducing-stages-a-framework-to-evaluate-rollups-maturity-d290bb22befe

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.

In the case of an emergency, the security council can always step in to upgrade the software immediately and fix the bug.

Not all proposals, just constitutional ones.

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: https://medium.com/l2beat/introducing-stages-a-framework-to-evaluate-rollups-maturity-d290bb22befe

Specifically:

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: https://medium.com/l2beat/introducing-stages-a-framework-to-evaluate-rollups-maturity-d290bb22befe

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.

In the case of an emergency, the security council can always step in to upgrade the software immediately and fix the bug.

Not all proposals, just constitutional ones.

Voted FOR: Extend Delay on L2Time Lock https://www.tally.xyz/gov/arbitrum/proposal/27888300053486667232765715922683646778055572080881341292116987136155397805421?govId=eip155:42161:0xf07DeD9dC292157749B6Fd268E37DF6EA38395B9

Voting Rationale: https://forum.arbitrum.foundation/t/alex-lumley-savvy-dao-delegate-communication-thread/26147/37

As stated in my previous Commenting Rationale (https://forum.arbitrum.foundation/t/constitutional-extend-delay-on-l2time-lock/26470/41?u=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.

As I mentioned before this is a huge improvement for the ecosystem.

https://forum.arbitrum.foundation/t/constitutional-extend-delay-on-l2time-lock/26470/36?u=ocandocrypto

Also in our way to Stage 2 and understanding importance for stage in rollups next year, this is an important step here.

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.

DAOplomats is voting for this proposal on Tally.

We are maintaining our support of the proposal from the temp check

Voting Rationale: https://forum.arbitrum.foundation/t/alex-lumley-savvy-dao-delegate-communication-thread/26147/37

• 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.

As I mentioned before this is a huge improvement for the ecosystem.

https://forum.arbitrum.foundation/t/constitutional-extend-delay-on-l2time-lock/26470/36?u=ocandocrypto

Also in our way to Stage 2 and understanding importance for stage in rollups next year, this is an important step here.

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.

DAOplomats is voting for this proposal on Tally.

We are maintaining our support of the proposal from the temp check

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.

I voted FOR this proposal on Tally for the reasons outlined below. Normally, I would want to see a published audit before voting for this proposal. Due to the simple nature of the change and the fact that it was created by the Offchain Labs team, I'm comfortable voting FOR.

Quoted from Frisson

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.

Quoted from Frisson

jump to post →

Voted For: The proposal seems very straightforward. I voted For this proposal because this will increase security and bring Arbitrum chains closer to stage 2 rollups.

I voted in favor for the same reasons that I mentioned for the Snapshot vote. You can find my voting rationale here: https://forum.arbitrum.foundation/t/constitutional-extend-delay-on-l2time-lock/26470/17?u=duokongcrypto

voting For the current onchain proposal because this makes Arbitrum closer to become a Stage 2 Ethereum L2 network.

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.

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.

Voted FOR on Tally

It’s a smart step towards enhancing Arbitrum's security and governance.

I voted FOR on Tally for the same reasons.

Vote For. extending the time lock will grant users a better timeline to analize changes and opt in or out if they decide in either way. This for me is an enhacement for the L2.

Regarding the Tally on-chain vote: Voted in favour for the reasons stated above.

Voted FOR this proposal on Tally following the previous rationale and the recommendations from the ARDC.

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

We are voting FOR this proposal in Tally Voting.

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

We are voting FOR this proposal in Tally Voting.

Increasing the timelock delay for core upgrades is a positive advancement that reflects the current path L2s are taking. Rest our overall thoughts remain the same as expressed in our rationale during the Snapshot voting.

Quoted from Euphoria

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.

jump to post →

We voted FOR for this upgrade

Rationale:

We voted FOR for this upgrade

Rationale:

The extended time lock will apply exclusively to upgrades involving critical contracts. Given Arbitrum's current maturity and stable growth, there should be no urgent need for such critical proposals to be passed quickly
This proposal to increase the time lock delay strikes a reasonable balance between enhancing security and preserving the advantages of swift treasury proposals
ADRC review is also in favor of the proposal
The upgrade will help Arbitrum to have yellow rating on L2Beat from red in terms of the exit window:

We support this proposal. It benefits users by providing more time to mitigate risks and plan exits, enhancing Arbitrum's security perception. It marks progress towards a safer stage 2 rollup environment.

Safety is always the first priority

I voted FOR this proposal as the benefits surpass the additional time it introduces.

I voted in favor of extending the L2 time lock as it provides necessary flexibility to respond to critical situations.

Blockworks Research will be voting FOR this proposal on Tally.

Quoted from Frisson

jump to post →

Voted For: The proposal seems very straightforward. I voted For this proposal because this will increase security and bring Arbitrum chains closer to stage 2 rollups.

voting For the current onchain proposal because this makes Arbitrum closer to become a Stage 2 Ethereum L2 network.

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.

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.

Voted FOR on Tally

It’s a smart step towards enhancing Arbitrum's security and governance.

I voted FOR on Tally for the same reasons.

Vote For. extending the time lock will grant users a better timeline to analize changes and opt in or out if they decide in either way. This for me is an enhacement for the L2.

Regarding the Tally on-chain vote: Voted in favour for the reasons stated above.

Voted FOR this proposal on Tally following the previous rationale and the recommendations from the ARDC.

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

We are voting FOR this proposal in Tally Voting.

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

We are voting FOR this proposal in Tally Voting.

Quoted from Euphoria

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.

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.

jump to post →

We voted FOR for this upgrade

Rationale:

We voted FOR for this upgrade

Rationale:

The extended time lock will apply exclusively to upgrades involving critical contracts. Given Arbitrum's current maturity and stable growth, there should be no urgent need for such critical proposals to be passed quickly
This proposal to increase the time lock delay strikes a reasonable balance between enhancing security and preserving the advantages of swift treasury proposals
ADRC review is also in favor of the proposal
The upgrade will help Arbitrum to have yellow rating on L2Beat from red in terms of the exit window:

Safety is always the first priority

I voted FOR this proposal as the benefits surpass the additional time it introduces.

I voted in favor of extending the L2 time lock as it provides necessary flexibility to respond to critical situations.

Voting FOR Extend Delay on L2Time Lock

Adding more information.

Vote: FOR Type: Snapshot Proposal link: [Constitutional] Extend Delay on L2Time Lock

Voting Rationale Link: https://forum.arbitrum.foundation/t/alex-lumley-savvy-dao-delegate-communication-thread/26147/13

Voting FOR Extend Delay on L2Time Lock

Adding more information.

Vote: FOR Type: Snapshot Proposal link: [Constitutional] Extend Delay on L2Time Lock

Voting Rationale Link: https://forum.arbitrum.foundation/t/alex-lumley-savvy-dao-delegate-communication-thread/26147/13

=== 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.

We support this proposal. While the proposal has little impact on the Security Council, we believe it is a positive step for users. The extension will give users extra time to protect themselves from potential risks and plan their exit strategies more easily. This is a good step that will make Arbitrum users feel more secure. Additionally, the potential to change the red circle on L2beat to yellow is an important step for Arbitrum to move into a safer rollup phase.

gm, in support of this proposal.

The request to give enough time for the Security Council to act on malicious proposals is reasonable for those upgrades.

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.

DAOplomats is voting in favor of this proposal on Snapshot.

Regarding the downside, it's a small tradeoff compared to this proposal's overall gain, so we are happy to support this.

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.

I voted FOR this proposal:

It’s a no-brainer for me to provide users and the security council with more time to exit after a constitutional proposal is passed.

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.

We vote For the proposal at its Snapshot phase.

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.

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:

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.

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 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.

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.

Castle supports the proposal to extend the L2 Core TimeLock delay from 3 days to 8 days.

We believe that this change brings significant benefits to the Arbitrum ecosystem in terms of both security and user confidence.

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 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.

Fully supports the proposal as it contributes to the security of the Arbitrum network

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.

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.

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.

cp0x votes for this proposal.

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.

cp0x votes for this proposal.

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.

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.

In general, I support this proposal. However, @Arbitrum, I have not seen anywhere the justification for 5 days. Why exactly 5, and what happened that such a proposal appeared?

These questions are about the fact that such proposals can be launched endlessly if we do not have an understanding of how many days are good, and how many are not enough, or maybe too many.

Voting FOR Extend Delay on L2Time Lock

Adding more information.

Vote: FOR Type: Snapshot Proposal link: [Constitutional] Extend Delay on L2Time Lock

Voting Rationale Link: https://forum.arbitrum.foundation/t/alex-lumley-savvy-dao-delegate-communication-thread/26147/13

Voting FOR Extend Delay on L2Time Lock

Adding more information.

Vote: FOR Type: Snapshot Proposal link: [Constitutional] Extend Delay on L2Time Lock

Voting Rationale Link: https://forum.arbitrum.foundation/t/alex-lumley-savvy-dao-delegate-communication-thread/26147/13

gm, in support of this proposal.

The request to give enough time for the Security Council to act on malicious proposals is reasonable for those upgrades.

DAOplomats is voting in favor of this proposal on Snapshot.

Regarding the downside, it's a small tradeoff compared to this proposal's overall gain, so we are happy to support this.

I voted FOR this proposal:

It’s a no-brainer for me to provide users and the security council with more time to exit after a constitutional proposal is passed.

We vote For the proposal at its Snapshot phase.

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:

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.

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 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.

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.

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.

Castle supports the proposal to extend the L2 Core TimeLock delay from 3 days to 8 days.

We believe that this change brings significant benefits to the Arbitrum ecosystem in terms of both security and user confidence.

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 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.

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.

Fully supports the proposal as it contributes to the security of the Arbitrum network

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.

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.

cp0x votes for this proposal.

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.

In general, I support this proposal. However, @Arbitrum, I have not seen anywhere the justification for 5 days. Why exactly 5, and what happened that such a proposal appeared?

These questions are about the fact that such proposals can be launched endlessly if we do not have an understanding of how many days are good, and how many are not enough, or maybe too many.

The timeline is good, the upgrade is good, and no costs, this proposal deserves a green light.

Voted FOR - this gives the security council time to act in response to any issues malicious or not.

If this turns out to be too long of a timelock, we can always adjust.

yellow is a good color. Voting for. The 8D lock for constitutional proposal is definitely not a lot for the proposals itself (that, usually, needs to be vetted by several actors and discussed by the dao). At the same time we need to implement mechanism for users to be able to get the fuck out if the want in time, especially considering that arbitrum as of now is the biggest L2 in term of tvl. We have a responsibility, ensuring that users are safe in their ability to manage their capital, and this vote works toward this first principle.

I support extending the L2 Core Time Lock to 8 days, as it increases security and gives users more time to withdraw assets if needed. The increased protection is well worth the slight delay in executing the proposals, especially since we are talking about constitutional ones.

We support extending the L2 time lock. It gives the community more time to review decisions, making the process safer and more thoughtful. The slight delay is worth it for better security. The trade-off of slightly slower processes is justified by the increased protection against rushed or poorly considered actions.

I totally support the proposal because it's beneficial to improve the security of Arbitrum network.

A balance of security + optionality supports the proposal.

If this is accepted, does it mean that all future proposals will have this extra 5 days of delay?

If so, I think it's fine. But we have to keep in mind that DAO decisions already take a lot of time and processes are just getting longer and longer. This doesn't result in the lean and fast-adjusted organization we would all want to have. But in terms of security issues, I would still support this proposal. Maybe we can look at where else can we skim back those 5 days in other parts of the processes.

Supporting this because of improved security (if needed) and better ranking on L2Beat

my educated guess is that native arbi bridge takes 7 days to let you out. Having an 8 days delay means you can act through it and be safe. But maybe i am just imagining things here.

The timeline is good, the upgrade is good, and no costs, this proposal deserves a green light.

Voted FOR - this gives the security council time to act in response to any issues malicious or not.

If this turns out to be too long of a timelock, we can always adjust.

I totally support the proposal because it's beneficial to improve the security of Arbitrum network.

A balance of security + optionality supports the proposal.

If this is accepted, does it mean that all future proposals will have this extra 5 days of delay?

Supporting this because of improved security (if needed) and better ranking on L2Beat

my educated guess is that native arbi bridge takes 7 days to let you out. Having an 8 days delay means you can act through it and be safe. But maybe i am just imagining things here.

Extending the delay by an additional 5 days seems reasonable, giving users and the Security Council with more time to react if issues arise. However, wouldn't this increment also slow down the implementation of urgent/beneficial updates? Is there a contingency plan if a critical upgrade is needed urgently, considering the extended delay period?

Edit: Just voted 'FOR' this proposal on Snapshot for the reasons outlined above. My question got answered perfectly: the security council can always step in to upgrade the software immediately in case of emergencies.

Edit: Just voted 'FOR' this proposal on Tally for the reasons outlined above.

Bring on the yellow slice.

In favour of this change, makes the process slightly longer, but for the sake of security, it is worth it. and for the yellow slice.

I think that this proposal makes sense. A constitutional proposal has a much higher threshold from a quorum perspective and it should also be accompanied with a more rigorous (somewhat prolonged) process for one to effectively be fully executed.

The main value-add here imo is the additional time granted to the Security Council to review more complex Constitutional proposal that affect the tech-stack itself.

Decision - In Favour - but will also read through the ARDC review for a more informed opinion!

We're in favor of this proposal, in general its just good to have additional safety rails in case of a possible emergency, governance attacks or otherwise. While the proposal adds a delay to constitutional proposals, these proposals are meant to be fundamental to the DAO anyways, and as such their frequency should dwindle as Arbitrum moves forward.

I voted FOR: Giving the process 5 extra days seems a small price to pay for how much extra safety we gain in response to bad actors. It is also great that the delay is only for constitutional votes, and not all future proposals.

Quoted from Arbitrum

I want the yellow slice, and I want it now!

Jokes aside, I am strongly in favor of this proposal. It increases security/optionality for users, and also reduces the odds of a sucessful governance attack. Security is always the number one priority, even if it comes at the cost of longer constitional proposal implementation.

Edit: Just voted 'FOR' this proposal on Tally for the reasons outlined above.

Bring on the yellow slice.

In favour of this change, makes the process slightly longer, but for the sake of security, it is worth it. and for the yellow slice.

The main value-add here imo is the additional time granted to the Security Council to review more complex Constitutional proposal that affect the tech-stack itself.

Decision - In Favour - but will also read through the ARDC review for a more informed opinion!

Quoted from Arbitrum

I want the yellow slice, and I want it now!