Constitutional - Extend Delay on L2Time Lock

Proposals
1

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

1600×809 143 KB

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:

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.

9 Likes
2

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.

1 Like
3

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.

1 Like
4

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

5

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!

6

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.

8

A balance of security + optionality supports the proposal.

9

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.

1 Like
10

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

2 Likes
11

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

12

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

13

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.

15

Not all proposals, just constitutional ones.

1 Like
16

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.

17

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.

18

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.

19

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.

20

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.

21

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.

22

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.

1 Like