# Arbitrum L2 Time Lock Delay Proposal Security Review **URL:** \ **Category:** ARDC Security Member\ **Created:** [September 18, 2024, 10:11am UTC](https://forum.arbitrum.foundation/t/arbitrum-l2-time-lock-delay-proposal-security-review/26837 "2024-09-18T10:11:54Z")\ **Posts on this page:** 1\ **Showing post:** 1
**Author:** ![openzeppelin](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.arbitrum.foundation/openzeppelin/32/10623_2.png) [@openzeppelin](https://forum.arbitrum.foundation/u/openzeppelin)\ **Post date:** [September 18, 2024, 10:11am UTC](https://forum.arbitrum.foundation/t/arbitrum-l2-time-lock-delay-proposal-security-review/26837/1 "2024-09-18T10:11:54Z")
OpenZeppelin, the Security Member of the ARDC, reviewed the [Arbitrum L2 Time Lock Delay Proposal](https://forum.arbitrum.foundation/t/constitutional-extend-delay-on-l2time-lock/26470) and its specifications. ### Summary If enacted, the proposal will increase the delay of constitutional proposals from 3 days to 8 days. The change only involves a modification of an existing configuration parameter and does not introduce any new functionality. ### Overview The Arbitrum DAO has a governance process whereby the community can vote on proposals fully on-chain. Two distinct kinds of proposals can be passed: those that spend funds from the ArbitrumDAO’s ETH treasury and those that perform upgrades to the contracts governing the system. In either case, there is currently a 3-day delay between the time a proposal has passed and when it is executed. While the same delay applies for both types of proposal, the former is governed by the L2 Treasury Time Lock while the latter is governed by the L2 Core Time Lock. As such, the delays for each proposal type are independent and any changes made to one will not necessarily impact the other. While these delays are in place, the Security Council can always step in to stop malicious proposals. However, the delay gives the Security Council the time to act in the event that a malicious proposal is indeed passed. In addition, it provides users the opportunity to withdraw their assets in the event that they are dissatisfied with the changes that would result from a proposal. The proposal would increase the delay applied to the L2 Core Time Lock from 3 days to 8 days. All proposals regarding spending funds from the ArbitrumDAO ETH treasury would still maintain a delay of 3 days. Only constitutional proposals related to smart contract upgrades would be affected. ### Motivation The primary motivation for this change is to increase the aforementioned security benefits. Namely, an increased delay will give the Security Council more time to review and stop malicious proposals (which is already a technical and lengthy process), while also providing users more time to make an informed decision. Furthermore, the proposal mentions a [framework developed by L2BEAT](https://medium.com/l2beat/introducing-stages-a-framework-to-evaluate-rollups-maturity-d290bb22befe) as part of the motivation behind it. More specifically, it will change the color of [Arbitrum’s ‘Exit Window’ slice](https://l2beat.com/scaling/projects/arbitrum) on [L2BEAT’s Risk Rosette](https://gov.l2beat.com/t/the-risk-rosette-framework/292) from red to yellow. By only increasing the delay on the L2 Core Time Lock, a compromise is achieved between security and speed. Since constitutional proposals are much more complex in nature, the Security Council requires more time to review these proposals than those directed towards the treasury. This timelock delay increase would provide the necessary time to review these potentially complex proposals while the traditional proposals regarding treasury spending adhere to the existing process. The downside of increasing this delay is that constitutional proposals will now take an extra 5 days to execute. No additional costs or security risks are introduced to the system as the proposed changes only modify one configuration parameter. ### Technical Details No new functionality needs to be introduced for this change. The value of the existing `_minDelay` parameter would be changed from 259200 to 691200 in the [L2 Timelock](https://arbiscan.io/address/0x34d45e99f7D8c45ed05B5cA72D54bbD1fb3F98f0#readProxyContract) contract. Note that the units of this parameter are in seconds, so the change is from 3 days to 8 days as explained earlier. The [action contract](https://github.com/ArbitrumFoundation/governance/pull/306) has already been implemented and is pending an audit. It consists of a [contract](https://github.com/ArbitrumFoundation/governance/pull/306/files#diff-aa7423831f93d30e4ebfa2052f0b1e3a90b2d90cd1e76ee2d074d47c6b17a82c) that has a function called `perform` which: 1. Calls the `L2AddressRegistry` contract deployed on Arbitrum at [0x56C4E9Eb6c63aCDD19AeC2b1a00e4f0d7aBda9d3](https://arbiscan.io/address/0x56C4E9Eb6c63aCDD19AeC2b1a00e4f0d7aBda9d3) to get the value of the `coreGovTimelock` state variable. Currently, the value of this variable is the address of the contract deployed at [0x34d45e99f7D8c45ed05B5cA72D54bbD1fb3F98f0](https://arbiscan.io/address/0x34d45e99f7D8c45ed05B5cA72D54bbD1fb3F98f0). 2. Calls the `updateDelay()` function of the stored `coreGovTimelock` contract with the new value of `86400 * 8`. Note that 86400 is 24 hours in seconds, so this would effectively update the delay to 8 days as described. This function, in turn, sets the `_arbMinDelay` to this new value and emits an event. No other changes occur. - Using the same `coreGovTimelock` contract, the `getMinDelay()` function is called to ensure that the new value of `_arbMinDelay` reflects the proposed change. 3. Calls the `L2Registry` contract once again, this time retrieving the value of the `arbitrumDAOConstitution` state variable. Currently, the value of this variable is the address of the contract deployed at [0x1D62fFeB72e4c360CcBbacf7c965153b00260417](https://arbiscan.io/address/0x1D62fFeB72e4c360CcBbacf7c965153b00260417). 4. Calls the `setConstitutionHash` function with the new value of `0x28faf2acba9b3ff80ec484e3d5646931eeef40568b1b7c38dbe52b890bfd7938`. This reflects the changes made to the constitution text which are discussed further below. This function, in turn, sets the `constitutionHash` state variable and emits an event. No other changes occur. - Using the same `arbitrumDAOConstitution` contract, the `constitutionHash()` getter for this state variable is called to ensure that the new value of `constitutionHash` reflects this change. The `CoreGovTimelockUpdateDelayEightDayAction` contract already seems to have been deployed on the Arbitrum network at [0x5B947D8bF197467be7ef381b7cAfEE0A7B35737A](https://arbiscan.io/address/0x5B947D8bF197467be7ef381b7cAfEE0A7B35737A#code). The [current constitution](https://docs.arbitrum.foundation/dao-constitution) of the Arbitrum DAO has been modified with the following changes: ```diff - 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 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 3 day waiting period in Phase 4 has passed, an L2-to-L1 message is sent indicating that the AIP was passed. + 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. ``` A `keccak256` hash of the full constitution text was used to generate the value mentioned above. Based on independent review from the ARDC, these changes have been verified to produce the same hash as mentioned by the team. This can be verified by following the same [instructions for generating the hash](https://docs.arbitrum.foundation/dao-constitution#constitution-hash) as outlined by the team, with the new changes to the constitution reflected. Note that the `CoreGovTimelockUpdateDelayEightDayAction` contract has not been directly audited and any calls are not guaranteed to succeed. However, the functionality would only execute if the changes are successfully performed. In addition, no other changes are proposed beyond those explicitly mentioned in the proposal. ### Conclusion We found the timelock delay increase proposal to be a reasonable compromise between increased security and maintaining the existing benefits of speedy treasury proposals. This will enable Arbitrum to transition into a more mature rollup that operates independently of any centralized actors, as outlined by the L2BEAT framework. Moreover, the proposal provides added security to reduce the possibility of malicious contract upgrades being executed, while also increasing the amount of time a user has to act on a proposal. The changes described in the proposal have been verified and exactly match those that are currently pending execution on-chain. --- _[View the full topic](https://forum.arbitrum.foundation/t/arbitrum-l2-time-lock-delay-proposal-security-review/26837)._