This proposal was co-authored by the L2BEAT governance and research teams.
This AIP seeks to propose changes to the structure of the security council so Arbitrum can maintain the “Stage 1” designation as per L2BEAT and not fall back to “Stage 0” designation.
On December 7, L2BEAT published an update to the security council requirements for the Stages Framework. The requirements were updated after a lot of research and feedback to make Stages more formal and precise.
Upgrading the security council as per the Stage 1 requirements set by L2BEAT, will help ensure Arbitrum remains decentralized, but properly secured. See ‘Specifications’ for more details.
Stages: A framework, inspired by Vitalik’s proposed milestones, that categorises rollups into three distinct stages based on their reliance on these training wheels. You can learn more about the Stages framework here.
Security Council: A group of 12 individuals who are responsible for addressing risks to the Arbitrum ecosystem through the selective application of emergency actions and non-emergency actions. Learn more in the ArbitrumDAO Docs.
Timelock: Smart contracts which implement a delay between an upgrade confirmation and execution.
Exit Window: The actual time users have to exit the system in case of an unwanted upgrade.
Arbitrum currently has two multisigs and they both contain the same set of members:
a) A 9/12 multisig with instant upgrade power
b) A 7/12 multisig that can upgrade with a 3+7+3 days delay
While the higher threshold multisig can be classified as a Security Council, the lower one is below the minimum threshold and it’s considered a simple multisig according to the Stages framework introduced above.
For normal multisigs, L2BEAT requires at least a 7 days exit window for users. The current exit window for Arbitrum is 2 days (see this thread for a quick explanation).
Moreover, the higher threshold multisig is supposed to stop malicious upgrades attempted by the lower threshold multisig. However, since the member set is the same, if the lower threshold agrees on something there are not enough members in the higher threshold to stop them, which means that the actual security of the upgradeability mechanism boils down to the 7/12 threshold.
For the above reason, technically, with the updated requirements for Stages, Arbitrum falls back to the Stage 0 designation. Since we know that it takes time to upgrade Arbitrum, we decided to leave the Stage 1 designation with the promise of addressing the above issues in a timely manner. This proposal is about addressing the issues and moving them to be voted on by the DAO.
Proposed Solutions
The second solution would be to leave the lower threshold multisig as it is, but to increase the exit window to 7 days. In practice, this involves increasing the L2 timelock delay from 3 days to 8 days, since there is a 1 day max delay to force transactions on Arbitrum via L1 using the ‘DelayedInbox’. Increasing the L1 Timelock would not be very beneficial due to delay attacks on the fraud proof systems, since, even with BoLD, the challenge period would end up being up to 16 days.
The third solution, which is not strictly required by the Stages Framework for the Stage 1 designation, is to both remove the lower threshold multisig entirely and increase the L2 Timelock delay so users have more time to exit in case of unwanted upgrades, increasing the security of the system even more.
Following a week of discussion of this RFC, the proposal will go for a vote on Snapshot with the following 4 options (as they are or slightly adjusted), and/or any additional ones, should they arise from the discussion during the RFC phase:
Following the temp-check, if any of the aforementioned options apart from No.4 is the most popular, the proposal will move to on-chain vote to execute the proposal.
There’s no overhead to the DAO for the implementation of this proposal.
RFC - January 11th to January 18th
Snapshot - January 18th to January 25th
On-Chain Vote: January 30th to February 13th
Execution Delay:
Please note the aforementioned timeline is tentative and the actual timeline might be slightly different.
This proposal was co-authored by the L2BEAT governance and research teams.
This AIP seeks to propose changes to the structure of the security council so Arbitrum can maintain the “Stage 1” designation as per L2BEAT and not fall back to “Stage 0” designation.
On December 7, L2BEAT published an update to the security council requirements for the Stages Framework. The requirements were updated after a lot of research and feedback to make Stages more formal and precise.
Upgrading the security council as per the Stage 1 requirements set by L2BEAT, will help ensure Arbitrum remains decentralized, but properly secured. See ‘Specifications’ for more details.
Stages: A framework, inspired by Vitalik’s proposed milestones, that categorises rollups into three distinct stages based on their reliance on these training wheels. You can learn more about the Stages framework here.
Security Council: A group of 12 individuals who are responsible for addressing risks to the Arbitrum ecosystem through the selective application of emergency actions and non-emergency actions. Learn more in the ArbitrumDAO Docs.
Timelock: Smart contracts which implement a delay between an upgrade confirmation and execution.
Exit Window: The actual time users have to exit the system in case of an unwanted upgrade.
Arbitrum currently has two multisigs and they both contain the same set of members:
a) A 9/12 multisig with instant upgrade power
b) A 7/12 multisig that can upgrade with a 3+7+3 days delay
While the higher threshold multisig can be classified as a Security Council, the lower one is below the minimum threshold and it’s considered a simple multisig according to the Stages framework introduced above.
For normal multisigs, L2BEAT requires at least a 7 days exit window for users. The current exit window for Arbitrum is 2 days (see this thread for a quick explanation).
Moreover, the higher threshold multisig is supposed to stop malicious upgrades attempted by the lower threshold multisig. However, since the member set is the same, if the lower threshold agrees on something there are not enough members in the higher threshold to stop them, which means that the actual security of the upgradeability mechanism boils down to the 7/12 threshold.
For the above reason, technically, with the updated requirements for Stages, Arbitrum falls back to the Stage 0 designation. Since we know that it takes time to upgrade Arbitrum, we decided to leave the Stage 1 designation with the promise of addressing the above issues in a timely manner. This proposal is about addressing the issues and moving them to be voted on by the DAO.
Proposed Solutions
The second solution would be to leave the lower threshold multisig as it is, but to increase the exit window to 7 days. In practice, this involves increasing the L2 timelock delay from 3 days to 8 days, since there is a 1 day max delay to force transactions on Arbitrum via L1 using the ‘DelayedInbox’. Increasing the L1 Timelock would not be very beneficial due to delay attacks on the fraud proof systems, since, even with BoLD, the challenge period would end up being up to 16 days.
The third solution, which is not strictly required by the Stages Framework for the Stage 1 designation, is to both remove the lower threshold multisig entirely and increase the L2 Timelock delay so users have more time to exit in case of unwanted upgrades, increasing the security of the system even more.
Following a week of discussion of this RFC, the proposal will go for a vote on Snapshot with the following 4 options (as they are or slightly adjusted), and/or any additional ones, should they arise from the discussion during the RFC phase:
Following the temp-check, if any of the aforementioned options apart from No.4 is the most popular, the proposal will move to on-chain vote to execute the proposal.
There’s no overhead to the DAO for the implementation of this proposal.
RFC - January 11th to January 18th
Snapshot - January 18th to January 25th
On-Chain Vote: January 30th to February 13th
Execution Delay:
Please note the aforementioned timeline is tentative and the actual timeline might be slightly different.
we are in support of increasing the threshold to 9/12
https://forum.arbitrum.foundation/t/constitutional-aip-security-council-improvement-proposal/20541/33?u=mcfly
we are in support of increasing the threshold to 9/12
https://forum.arbitrum.foundation/t/constitutional-aip-security-council-improvement-proposal/20541/33?u=mcfly
https://forum.arbitrum.foundation/t/constitutional-aip-security-council-improvement-proposal/20541/31?u=princetonblockchain
https://forum.arbitrum.foundation/t/constitutional-aip-security-council-improvement-proposal/20541/30?u=0x_ultra
https://forum.arbitrum.foundation/t/constitutional-aip-security-council-improvement-proposal/20541/29?u=ocandocrypto
Fully support changing the number of required signers to maintain stage 1 status
Thank you to L2Beat for creating these standards, it is heroes work! We absolutely should make these small changes to comply with them.
https://forum.arbitrum.foundation/t/jojo-delegate-communication-thread/24429/3?u=jojo
https://forum.arbitrum.foundation/t/constitutional-aip-security-council-improvement-proposal/20541/6
The proposal aims to create an Incentivized Governance Rewards Pool for Arbitrum. By distributing rewards to users participating in governance activities, it seeks to enhance community engagement and activity. The proposal outlines the source of funds, distribution mechanism, and specific forms of rewards, ensuring fairness and transparency. This initiative will significantly boost the enthusiasm and participation in community governance.
This increases user safety. Thank you to L2Beat for pushing for more rigorous standards in rollups. Optimism recently made changes to their Security council multisig for similar reasons.
https://forum.arbitrum.foundation/t/constitutional-aip-security-council-improvement-proposal/20541/23?u=blockworksresearch
Speaking with L2 beat i have come to be convinced that the security council does need an improvement to the design. Originally I didn't quite understand the need by I've been convinced.
FOR: https://forum.arbitrum.foundation/t/savvy-dao-delegate-communication-thread/21266/42?u=savvydao
This security upgrade makes sense, and decreases the amount of risk through a higher threshold of signers without too much overhead.
https://forum.arbitrum.foundation/t/constitutional-aip-security-council-improvement-proposal/20541/22
Check our governance forum profile for rationale
https://forum.arbitrum.foundation/t/constitutional-aip-security-council-improvement-proposal/20541/10?u=olimpio
https://forum.arbitrum.foundation/t/constitutional-aip-security-council-improvement-proposal/20541/9?u=krst
https://forum.arbitrum.foundation/t/constitutional-aip-security-council-improvement-proposal/20541/4?u=cattin
https://forum.arbitrum.foundation/t/constitutional-aip-security-council-improvement-proposal/20541/31?u=princetonblockchain
https://forum.arbitrum.foundation/t/constitutional-aip-security-council-improvement-proposal/20541/30?u=0x_ultra
https://forum.arbitrum.foundation/t/constitutional-aip-security-council-improvement-proposal/20541/29?u=ocandocrypto
Fully support changing the number of required signers to maintain stage 1 status
Thank you to L2Beat for creating these standards, it is heroes work! We absolutely should make these small changes to comply with them.
https://forum.arbitrum.foundation/t/jojo-delegate-communication-thread/24429/3?u=jojo
https://forum.arbitrum.foundation/t/constitutional-aip-security-council-improvement-proposal/20541/6
The proposal aims to create an Incentivized Governance Rewards Pool for Arbitrum. By distributing rewards to users participating in governance activities, it seeks to enhance community engagement and activity. The proposal outlines the source of funds, distribution mechanism, and specific forms of rewards, ensuring fairness and transparency. This initiative will significantly boost the enthusiasm and participation in community governance.
This increases user safety. Thank you to L2Beat for pushing for more rigorous standards in rollups. Optimism recently made changes to their Security council multisig for similar reasons.
https://forum.arbitrum.foundation/t/constitutional-aip-security-council-improvement-proposal/20541/23?u=blockworksresearch
Speaking with L2 beat i have come to be convinced that the security council does need an improvement to the design. Originally I didn't quite understand the need by I've been convinced.
FOR: https://forum.arbitrum.foundation/t/savvy-dao-delegate-communication-thread/21266/42?u=savvydao
This security upgrade makes sense, and decreases the amount of risk through a higher threshold of signers without too much overhead.
https://forum.arbitrum.foundation/t/constitutional-aip-security-council-improvement-proposal/20541/22
Check our governance forum profile for rationale
https://forum.arbitrum.foundation/t/constitutional-aip-security-council-improvement-proposal/20541/10?u=olimpio
https://forum.arbitrum.foundation/t/constitutional-aip-security-council-improvement-proposal/20541/9?u=krst
https://forum.arbitrum.foundation/t/constitutional-aip-security-council-improvement-proposal/20541/4?u=cattin
OpenZeppelin, as Security Member of the ARDC, was asked to review a live Arbitrum DAO proposal (id: 108365…9297) which would modify the Arbitrum Security Council from a seven-of-twelve to a nine-of-twelve signing threshold for non-emergency actions.
Overall, we found the proposal to be well-formed, to follow established methodologies set forth by the Arbitrum Constitution, and to pose no other risks to the protocol even if only part of the call chain succeeds. You can review our full analysis in the report linked below.
OpenZeppelin, as Security Member of the ARDC, was asked to review a live Arbitrum DAO proposal (id: 108365…9297) which would modify the Arbitrum Security Council from a seven-of-twelve to a nine-of-twelve signing threshold for non-emergency actions.
Overall, we found the proposal to be well-formed, to follow established methodologies set forth by the Arbitrum Constitution, and to pose no other risks to the protocol even if only part of the call chain succeeds. You can review our full analysis in the report linked below.
OpenZeppelin, as Security Member of the ARDC, was asked to review a live Arbitrum DAO proposal (id: 108365…9297) which would modify the Arbitrum Security Council from a seven-of-twelve to a nine-of-twelve signing threshold for non-emergency actions.
Overall, we found the proposal to be well-formed, to follow established methodologies set forth by the Arbitrum Constitution, and to pose no other risks to the protocol even if only part of the call chain succeeds. You can review our full analysis in the report linked below.
OpenZeppelin, as Security Member of the ARDC, was asked to review a live Arbitrum DAO proposal (id: 108365…9297) which would modify the Arbitrum Security Council from a seven-of-twelve to a nine-of-twelve signing threshold for non-emergency actions.
Overall, we found the proposal to be well-formed, to follow established methodologies set forth by the Arbitrum Constitution, and to pose no other risks to the protocol even if only part of the call chain succeeds. You can review our full analysis in the report linked below.
Proposed language for new constitution and respective hash are available in https://github.com/ArbitrumFoundation/docs/pull/762
Proposed language for new constitution and respective hash are available in https://github.com/ArbitrumFoundation/docs/pull/762
Worth flagging that this proposal should not only update the onchain system to reflect the proposed Security Council thresholds, but should also update the constitution text to reflect the new behavior. More specifically, Section 3 where the Security Council is described.
Worth flagging that this proposal should not only update the onchain system to reflect the proposed Security Council thresholds, but should also update the constitution text to reflect the new behavior. More specifically, Section 3 where the Security Council is described.
The code has been audited and public report by Chain security is available ChainSecurity_Arbitrum_Foundation_Security_Council_AIP_audit.pdf|attachment (437.0 KB)
The code has been audited and public report by Chain security is available ChainSecurity_Arbitrum_Foundation_Security_Council_AIP_audit.pdf|attachment (437.0 KB)
We vote FOR the proposal on Tally.
We maintained the vote from Snapshot as we believe increasing the threshold to 9/12 is the vital first step to improve the system to achieve the revised Stage1 designation.
We agree with the Princeton Blockchain Club and recommend voting FOR increasing the Arbitrum Security Council's non-emergency action threshold from 7/12 to 9/12.
Key reasons to support this proposal:
We agree with the Princeton Blockchain Club and recommend voting FOR increasing the Arbitrum Security Council's non-emergency action threshold from 7/12 to 9/12.
Key reasons to support this proposal:
This pragmatic change improves security while minimizing risks. We encourage all delegates to vote FOR this proposal on-chain.
Overall, we found the proposal to be well-formed, to follow established methodologies set forth by the Arbitrum Constitution, and to pose no other risks to the protocol even if only part of the call chain succeeds. You can review our full analysis in the report linked below.
Overall, we found the proposal to be well-formed, to follow established methodologies set forth by the Arbitrum Constitution, and to pose no other risks to the protocol even if only part of the call chain succeeds. You can review our full analysis in the report linked below.
Thanks for the feedback guys. Arbitrum should always lead in terms of security - voted FOR.
I voted FOR this proposal on Tally. It's essential that Arbitrum maintain its status as a stage 1 rollup. Increasing the non-emergency threshold to 9/12 is a reasonable and safe way to do it.
These reports are definitely a significant step in analyzing technical proposals, as they summarize and help us understand their implications.
Of course, I decided to vote FOR this proposal.
These reports are definitely a significant step in analyzing technical proposals, as they summarize and help us understand their implications.
Of course, I decided to vote FOR this proposal.
Maintaining Arbitrum’s status as a stage 1 rollup is essential. Increasing the non-emergency threshold to 9/12 is a reasonable and safe approach. This change ensures that necessary actions can be executed promptly in emergencies, with an appropriate number of signatures, preventing delays if someone cannot access quickly. It strikes a good balance.
Voting "FOR" Increasing the threshold to 9/12 will enhance Arbitrum's security.
Voted "For" By increasing the threshold of the non-emergency Security Council to 9/12, the proposal effectively addresses the identified risks associated with the current multisig setup. This change will enhance the security and reliability of Arbitrum’s upgradeability mechanism, providing a robust safeguard against potential malicious upgrades. This proposal not only fortifies Arbitrum’s security infrastructure but also reaffirms its dedication to upholding high standards of decentralization and user protection.
Savvy DAO votes FOR this proposal.
See delegate thread: https://forum.arbitrum.foundation/t/savvy-dao-delegate-communication-thread/21266/42?u=savvydao
The below response 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.
The proposal has now gone to Tally for an on-chain vote!
Important update to the security council framework, I'm personally more in favor of 9/12 as I believe the security council role is a very important post that shouldn't suffer from the classic "we need two more signers" desperate telegram messages. 9/12 people should be reachable and ready to act in 24 hours in all cases, otherwise that's where the problem lies IMO.
DAOplomats voted in favor on Tally.
We maintained our vote from Snapshot as we support the increase in the number of seats to 9/12.
Blockworks Research will be voting FOR this proposal on Tally.
Increasing the lower threshold multisig to 9/12 appears to be the most straightforward way to maintain the Stage 1 classification. This change does not seem to intrinsically alter anything compared to the previous configuration, except for enhancing security without compromising agility, as 9 signers will always be required to perform an action.
Blockworks Research will be voting FOR this proposal on Tally.
Increasing the lower threshold multisig to 9/12 appears to be the most straightforward way to maintain the Stage 1 classification. This change does not seem to intrinsically alter anything compared to the previous configuration, except for enhancing security without compromising agility, as 9 signers will always be required to perform an action.
We would like to thank @krst and @Sinkas for taking the initiative on this important topic and for working on creating a document that covers how putting together a proposal like this should be approached in the future.
The below response 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.
As we are the ones that made the proposal, we are obviously supporting it and we voted in its favor.
The Princeton Blockchain Club is voting FOR increasing the non-emergency action threshold for the Security Council to 9/12 onchain. This lets us keep Arbitrum One looking nice on L2Beat, but more importantly, increasing the 7/12 multisig threshold is overall good for Arbitrum's security.
Following the audit by ChainSecurity and review by OpenZeppelin, we're confident in voting for the change on Tally.
The Princeton Blockchain Club is voting FOR increasing the non-emergency action threshold for the Security Council to 9/12 onchain. This lets us keep Arbitrum One looking nice on L2Beat, but more importantly, increasing the 7/12 multisig threshold is overall good for Arbitrum's security.
Following the audit by ChainSecurity and review by OpenZeppelin, we're confident in voting for the change on Tally.
Delegates: if you haven't voted yet, please do soon! We still need ~12m votes to reach quorum, as Constitutional AIPs have higher quorum thresholds.
I voted for this proposal, as it enhances the operational and security standards of the Security Coouncil.
We vote FOR the proposal on Tally.
We maintained the vote from Snapshot as we believe increasing the threshold to 9/12 is the vital first step to improve the system to achieve the revised Stage1 designation.
We agree with the Princeton Blockchain Club and recommend voting FOR increasing the Arbitrum Security Council's non-emergency action threshold from 7/12 to 9/12.
Key reasons to support this proposal:
We agree with the Princeton Blockchain Club and recommend voting FOR increasing the Arbitrum Security Council's non-emergency action threshold from 7/12 to 9/12.
Key reasons to support this proposal:
This pragmatic change improves security while minimizing risks. We encourage all delegates to vote FOR this proposal on-chain.
Overall, we found the proposal to be well-formed, to follow established methodologies set forth by the Arbitrum Constitution, and to pose no other risks to the protocol even if only part of the call chain succeeds. You can review our full analysis in the report linked below.
Overall, we found the proposal to be well-formed, to follow established methodologies set forth by the Arbitrum Constitution, and to pose no other risks to the protocol even if only part of the call chain succeeds. You can review our full analysis in the report linked below.
Thanks for the feedback guys. Arbitrum should always lead in terms of security - voted FOR.
I voted FOR this proposal on Tally. It's essential that Arbitrum maintain its status as a stage 1 rollup. Increasing the non-emergency threshold to 9/12 is a reasonable and safe way to do it.
These reports are definitely a significant step in analyzing technical proposals, as they summarize and help us understand their implications.
Of course, I decided to vote FOR this proposal.
These reports are definitely a significant step in analyzing technical proposals, as they summarize and help us understand their implications.
Of course, I decided to vote FOR this proposal.
Maintaining Arbitrum’s status as a stage 1 rollup is essential. Increasing the non-emergency threshold to 9/12 is a reasonable and safe approach. This change ensures that necessary actions can be executed promptly in emergencies, with an appropriate number of signatures, preventing delays if someone cannot access quickly. It strikes a good balance.
Voting "FOR" Increasing the threshold to 9/12 will enhance Arbitrum's security.
Voted "For" By increasing the threshold of the non-emergency Security Council to 9/12, the proposal effectively addresses the identified risks associated with the current multisig setup. This change will enhance the security and reliability of Arbitrum’s upgradeability mechanism, providing a robust safeguard against potential malicious upgrades. This proposal not only fortifies Arbitrum’s security infrastructure but also reaffirms its dedication to upholding high standards of decentralization and user protection.
Savvy DAO votes FOR this proposal.
See delegate thread: https://forum.arbitrum.foundation/t/savvy-dao-delegate-communication-thread/21266/42?u=savvydao
The below response 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.
The proposal has now gone to Tally for an on-chain vote!
Important update to the security council framework, I'm personally more in favor of 9/12 as I believe the security council role is a very important post that shouldn't suffer from the classic "we need two more signers" desperate telegram messages. 9/12 people should be reachable and ready to act in 24 hours in all cases, otherwise that's where the problem lies IMO.
DAOplomats voted in favor on Tally.
We maintained our vote from Snapshot as we support the increase in the number of seats to 9/12.
Blockworks Research will be voting FOR this proposal on Tally.
Increasing the lower threshold multisig to 9/12 appears to be the most straightforward way to maintain the Stage 1 classification. This change does not seem to intrinsically alter anything compared to the previous configuration, except for enhancing security without compromising agility, as 9 signers will always be required to perform an action.
Blockworks Research will be voting FOR this proposal on Tally.
Increasing the lower threshold multisig to 9/12 appears to be the most straightforward way to maintain the Stage 1 classification. This change does not seem to intrinsically alter anything compared to the previous configuration, except for enhancing security without compromising agility, as 9 signers will always be required to perform an action.
We would like to thank @krst and @Sinkas for taking the initiative on this important topic and for working on creating a document that covers how putting together a proposal like this should be approached in the future.
The below response 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.
As we are the ones that made the proposal, we are obviously supporting it and we voted in its favor.
The Princeton Blockchain Club is voting FOR increasing the non-emergency action threshold for the Security Council to 9/12 onchain. This lets us keep Arbitrum One looking nice on L2Beat, but more importantly, increasing the 7/12 multisig threshold is overall good for Arbitrum's security.
Following the audit by ChainSecurity and review by OpenZeppelin, we're confident in voting for the change on Tally.
The Princeton Blockchain Club is voting FOR increasing the non-emergency action threshold for the Security Council to 9/12 onchain. This lets us keep Arbitrum One looking nice on L2Beat, but more importantly, increasing the 7/12 multisig threshold is overall good for Arbitrum's security.
Following the audit by ChainSecurity and review by OpenZeppelin, we're confident in voting for the change on Tally.
Delegates: if you haven't voted yet, please do soon! We still need ~12m votes to reach quorum, as Constitutional AIPs have higher quorum thresholds.
I voted for this proposal, as it enhances the operational and security standards of the Security Coouncil.
The below response 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.
The proposal has now gone to Tally for an on-chain vote!
Please note, that while we tried to keep the description of the proposal in Tally as close as possible to the content of the proposal in Snapshot, the proposal being voted on is to implement the one specific solution that was voted on in Snapshot (which is mentioned in the description, but we realized after the vote was posted that it might be overlooked by the reader).
Following the successful temp-check, and given that the security audit by ChainSecurity did not reveal any issues with the proposed changes, we’ve moved the proposal to an on-chain vote on Tally. Should the proposal succeed, the associated executable will increase the threshold of the small security council from 7/12 to 9/12, as per the consensus in the temp-check. The text of the constitution will be amended accordingly, as mentioned in one of the comments above.
Going through the process of submitting this proposal, we’ve run into unforeseen delays, which, combined with our increased workload resulted in a significant deviation from our original timeline.
Putting together such a proposal is not an easy task. We have made many observations along the way about how such a proposal should be approached, especially when it comes to the code, the audit, and the executable. We will shortly follow up with a short guide based on what we learned by going through the process ourselves.
The cp0x team voted in favor of this proposal. We support more secure multisig 9/12
implementation of latest changes (consistent with result of snapshot) are WIP here: https://github.com/ArbitrumFoundation/governance/pull/253
Update on the proposal and the timeline: The temp-check was successful and the most voted option was to increase the small security council threshold from 7/12 to 9/12. We're working with the Foundation to create the necessary executable code in order to move to an on-chain vote. We will update this thread once the vote has been posted on Tally.
The below response 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.
First off, we want to thank the DAO for supporting the proposal during the temp-check.
The below response 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.
First off, we want to thank the DAO for supporting the proposal during the temp-check.
Our initial timeline was based on the time it takes to move a proposal through the governance process, but that didn’t include any external delays. Since the changes outlined in the proposal have to do with the Security Council and its structure, we believe it’s best to approach the implementation with caution. To that end, we’ve been in touch with the Arbitrum Foundation which will help see the execution through by producing the necessary code and having it audited by a security firm. This process is expected to take up to 2 months.
While the code to implement the proposed changes is relatively simple, we want to ensure there are no unwanted implications that could put the security of Arbitrum at risk. We think sacrificing 1 or 2 weeks to have complete peace of mind is worth it.
Having said that, the updated expected timeline is:
While the updated timeline is far off from the one included in the original proposal, there’s no material benefit to expediting the process at the expense of security.
We would like to thank the @dzack23 and the Arbitrum Foundation for their support and willingness to work with us on this proposal, and after the entire process is complete, we will publish our lessons learned and the guideline for the DAO on how to proceed with such proposals.
Thanks to L2B for putting this forward. Upon consideration, I just voted to increase the threshold from 7/12 to 9/12, since it would be quicker to implement than both at the same time, a good way to start.
The below response 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.
Even though this is our own proposal, we don't see any conflict of interest in voting on it, so we'll vote as well.
The below response 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.
Even though this is our own proposal, we don't see any conflict of interest in voting on it, so we'll vote as well.
We vote for both options - increasing the threshold and increasing the delay. We find both solutions valuable in terms of increasing the security of the chain. While we understand the concerns regarding increasing the delay, as it will delay all votes by an additional 5 days, we believe that increasing the exit window for user funds is a significant and meaningful value-add in the event of an emergency.
@juanbug and I have posted our perspective below on behalf of the Uniswap DAO’s Arbitrum governance team.
Vote: Increase the threshold to 9/12 Type: Snapshot
@juanbug and I have posted our perspective below on behalf of the Uniswap DAO’s Arbitrum governance team.
Vote: Increase the threshold to 9/12 Type: Snapshot
We respect the L2Beat team’s continual efforts to bring awareness towards the risks surrounding L2s as they continually mature. Our vote went towards increasing the threshold from 7/12 to 9/12 since this approach is the simplest way to null the second multisig. It also allows for more flexibility in the future than entirely removing the second multisig. Increasing the delay has its merits, but we feel that it’s a topic that the DAO should discuss in further detail before executing. To us, this proposal is meant to be a quick response to a potential security concern as opposed to implementing a more sticky alteration like the delay increase.
After consideration Treasure’s Arbitrum Representative Council (ARC) would like to share the following feedback on the proposal.
We want to thank L2Beat for taking the initiative to address this important topic of security. After discussion we open to support the proposal to increase the threshold to 9/12.
After consideration Treasure’s Arbitrum Representative Council (ARC) would like to share the following feedback on the proposal.
We want to thank L2Beat for taking the initiative to address this important topic of security. After discussion we open to support the proposal to increase the threshold to 9/12.
We feel that this option provides the cleanest and clearest "win-win" security benefit for Arbitrum which does not also impact the timeline of an already long governance process.
Edit: Due to operational issues we were not able to submit our vote on Snapshot. We will make an intentional commitment to support this proposal on Tally.
As the Curia team, after reviewing the Security Council Improvement Proposal and @dzack23 's comment on the Arbitrum forum, we have decided to support the increase of the non-emergency Security Council threshold from 7/12 to 9/12. This decision is driven by our commitment to enhancing network security, aligning with community preferences, and maintaining some degree of decentralization.
I will be voting to increase the multisig to 9/12. This looks to be the quickest and least intrusive way to achieve the goal, so feels like a no brainer given the context.
Editing comment to save space: I will maintain my "For" vote on Tally. Thank you to L2Beat for their work on this, as well as taking all the extra steps to roll this out as safely and thoughtfully as possible. With ChainSecurity's audit I feel comfortable moving forward with the multisig update.
Thanks L2Beat!
Technical Considerations
Here are governance action contracts for the 3 potential changes discussed in the post (note that as of posting this, contracts are not yet audited; including here for demonstration purposes):
Savvy DAO is voting to Increase the threshold to 9/12.
We thank @Sinkas and @krst for all their work developing this proposal.
After carefully reviewing the proposal and considering the comments from @dzack23, we believe that option 1 is the most appropriate.
We consider this approach essential, as the Security Council is a crucial component for Arbitrum. Therefore, we would like to propose the inclusion of some sort of Emergency Response Drills for the Security Council. This idea aims to allow the DAO to empirically assess the Council's response times in various emergency scenarios. These drills should be carried out 2 to 4 times a year, at random times during this period.
Thanks @dzack23 for your explanation! It's good to hear that both all three changes discussed in the post are trivial!
We've moved to Snapshot vote according to the plan. We hope to get some delegates attention and feedback on this proposal.
The below response 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.
The proposal has now gone to Tally for an on-chain vote!
Please note, that while we tried to keep the description of the proposal in Tally as close as possible to the content of the proposal in Snapshot, the proposal being voted on is to implement the one specific solution that was voted on in Snapshot (which is mentioned in the description, but we realized after the vote was posted that it might be overlooked by the reader).
Following the successful temp-check, and given that the security audit by ChainSecurity did not reveal any issues with the proposed changes, we’ve moved the proposal to an on-chain vote on Tally. Should the proposal succeed, the associated executable will increase the threshold of the small security council from 7/12 to 9/12, as per the consensus in the temp-check. The text of the constitution will be amended accordingly, as mentioned in one of the comments above.
Going through the process of submitting this proposal, we’ve run into unforeseen delays, which, combined with our increased workload resulted in a significant deviation from our original timeline.
Putting together such a proposal is not an easy task. We have made many observations along the way about how such a proposal should be approached, especially when it comes to the code, the audit, and the executable. We will shortly follow up with a short guide based on what we learned by going through the process ourselves.
The cp0x team voted in favor of this proposal. We support more secure multisig 9/12
implementation of latest changes (consistent with result of snapshot) are WIP here: https://github.com/ArbitrumFoundation/governance/pull/253
Update on the proposal and the timeline: The temp-check was successful and the most voted option was to increase the small security council threshold from 7/12 to 9/12. We're working with the Foundation to create the necessary executable code in order to move to an on-chain vote. We will update this thread once the vote has been posted on Tally.
The below response 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.
First off, we want to thank the DAO for supporting the proposal during the temp-check.
The below response 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.
First off, we want to thank the DAO for supporting the proposal during the temp-check.
Our initial timeline was based on the time it takes to move a proposal through the governance process, but that didn’t include any external delays. Since the changes outlined in the proposal have to do with the Security Council and its structure, we believe it’s best to approach the implementation with caution. To that end, we’ve been in touch with the Arbitrum Foundation which will help see the execution through by producing the necessary code and having it audited by a security firm. This process is expected to take up to 2 months.
While the code to implement the proposed changes is relatively simple, we want to ensure there are no unwanted implications that could put the security of Arbitrum at risk. We think sacrificing 1 or 2 weeks to have complete peace of mind is worth it.
Having said that, the updated expected timeline is:
While the updated timeline is far off from the one included in the original proposal, there’s no material benefit to expediting the process at the expense of security.
We would like to thank the @dzack23 and the Arbitrum Foundation for their support and willingness to work with us on this proposal, and after the entire process is complete, we will publish our lessons learned and the guideline for the DAO on how to proceed with such proposals.
Thanks to L2B for putting this forward. Upon consideration, I just voted to increase the threshold from 7/12 to 9/12, since it would be quicker to implement than both at the same time, a good way to start.
The below response 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.
Even though this is our own proposal, we don't see any conflict of interest in voting on it, so we'll vote as well.
The below response 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.
Even though this is our own proposal, we don't see any conflict of interest in voting on it, so we'll vote as well.
We vote for both options - increasing the threshold and increasing the delay. We find both solutions valuable in terms of increasing the security of the chain. While we understand the concerns regarding increasing the delay, as it will delay all votes by an additional 5 days, we believe that increasing the exit window for user funds is a significant and meaningful value-add in the event of an emergency.
@juanbug and I have posted our perspective below on behalf of the Uniswap DAO’s Arbitrum governance team.
Vote: Increase the threshold to 9/12 Type: Snapshot
@juanbug and I have posted our perspective below on behalf of the Uniswap DAO’s Arbitrum governance team.
Vote: Increase the threshold to 9/12 Type: Snapshot
We respect the L2Beat team’s continual efforts to bring awareness towards the risks surrounding L2s as they continually mature. Our vote went towards increasing the threshold from 7/12 to 9/12 since this approach is the simplest way to null the second multisig. It also allows for more flexibility in the future than entirely removing the second multisig. Increasing the delay has its merits, but we feel that it’s a topic that the DAO should discuss in further detail before executing. To us, this proposal is meant to be a quick response to a potential security concern as opposed to implementing a more sticky alteration like the delay increase.
After consideration Treasure’s Arbitrum Representative Council (ARC) would like to share the following feedback on the proposal.
We want to thank L2Beat for taking the initiative to address this important topic of security. After discussion we open to support the proposal to increase the threshold to 9/12.
After consideration Treasure’s Arbitrum Representative Council (ARC) would like to share the following feedback on the proposal.
We want to thank L2Beat for taking the initiative to address this important topic of security. After discussion we open to support the proposal to increase the threshold to 9/12.
We feel that this option provides the cleanest and clearest "win-win" security benefit for Arbitrum which does not also impact the timeline of an already long governance process.
Edit: Due to operational issues we were not able to submit our vote on Snapshot. We will make an intentional commitment to support this proposal on Tally.
As the Curia team, after reviewing the Security Council Improvement Proposal and @dzack23 's comment on the Arbitrum forum, we have decided to support the increase of the non-emergency Security Council threshold from 7/12 to 9/12. This decision is driven by our commitment to enhancing network security, aligning with community preferences, and maintaining some degree of decentralization.
I will be voting to increase the multisig to 9/12. This looks to be the quickest and least intrusive way to achieve the goal, so feels like a no brainer given the context.
Editing comment to save space: I will maintain my "For" vote on Tally. Thank you to L2Beat for their work on this, as well as taking all the extra steps to roll this out as safely and thoughtfully as possible. With ChainSecurity's audit I feel comfortable moving forward with the multisig update.
Thanks L2Beat!
Technical Considerations
Here are governance action contracts for the 3 potential changes discussed in the post (note that as of posting this, contracts are not yet audited; including here for demonstration purposes):
Savvy DAO is voting to Increase the threshold to 9/12.
We thank @Sinkas and @krst for all their work developing this proposal.
After carefully reviewing the proposal and considering the comments from @dzack23, we believe that option 1 is the most appropriate.
We consider this approach essential, as the Security Council is a crucial component for Arbitrum. Therefore, we would like to propose the inclusion of some sort of Emergency Response Drills for the Security Council. This idea aims to allow the DAO to empirically assess the Council's response times in various emergency scenarios. These drills should be carried out 2 to 4 times a year, at random times during this period.
Thanks @dzack23 for your explanation! It's good to hear that both all three changes discussed in the post are trivial!
We've moved to Snapshot vote according to the plan. We hope to get some delegates attention and feedback on this proposal.
Thanks L2Beat!
Technical Considerations
Here are governance action contracts for the 3 potential changes discussed in the post (note that as of posting this, contracts are not yet audited; including here for demonstration purposes):
1a: Increase non-emergency SC threshold
1b: Disable the on-emergency SC
We believe the implementations of all three changes are equally trivial from a technical perspective, and thus the relative technical complexity of the upgrades shouldn’t be an important factor when considering the options.
Additionally, re 1a, the proposal reads:
Increasing the threshold gives us the flexibility to restore a lower threshold in the future should the need arise, and it’s also a very quick and easy fix since it doesn’t require an on-chain upgrade.
As the implementation linked above demonstrates, changing the non-emergency security council’s threshold can be carried out entirely via DAO vote, and does not require a security council action (in this way, this is no different than any other governance action).
General Thoughts
We at Offchain Labs see little downside to increasing the non-emergency Security Council’s threshold; this increases the barrier to submitting non-emergency proposals, but we see this as a positive.
Since this is the most modest protocol change of the ones suggested (1b removes the ability for the council to put forth non-emergency upgrades at all, and 2 adds five additional days to the time it takes proposals to finalize), we lean toward option one. Curious to see what others think!
After carefully reviewing the proposal and considering the comments from @dzack23, we believe that option 1 is the most appropriate.
We consider this approach essential, as the Security Council is a crucial component for Arbitrum. Therefore, we would like to propose the inclusion of some sort of Emergency Response Drills for the Security Council. This idea aims to allow the DAO to empirically assess the Council's response times in various emergency scenarios. These drills should be carried out 2 to 4 times a year, at random times during this period.
Broadly speaking, the idea is to define certain response parameters that the DAO expects to be satisfactorily met by the Security Council, including response time, number of signatories, among other aspects.
It is likely that the members of the Security Council maintain a private group with the Arbitrum Foundation and OffchainLabs. However, from the DAO's perspective, we do not have, nor should have, visibility of this. The role of governance should be to ensure that the Council fulfills its role through these drills, especially considering that the DAO’s governance selects the security council members. This approach is not intended to add bureaucracy but rather to enhance security in the rollup with the highest TVL and activity in the ecosystem.
What are your thoughts?
Thanks L2Beat!
Technical Considerations
Here are governance action contracts for the 3 potential changes discussed in the post (note that as of posting this, contracts are not yet audited; including here for demonstration purposes):
1a: Increase non-emergency SC threshold
1b: Disable the on-emergency SC
We believe the implementations of all three changes are equally trivial from a technical perspective, and thus the relative technical complexity of the upgrades shouldn’t be an important factor when considering the options.
Additionally, re 1a, the proposal reads:
Increasing the threshold gives us the flexibility to restore a lower threshold in the future should the need arise, and it’s also a very quick and easy fix since it doesn’t require an on-chain upgrade.
As the implementation linked above demonstrates, changing the non-emergency security council’s threshold can be carried out entirely via DAO vote, and does not require a security council action (in this way, this is no different than any other governance action).
General Thoughts
We at Offchain Labs see little downside to increasing the non-emergency Security Council’s threshold; this increases the barrier to submitting non-emergency proposals, but we see this as a positive.
Since this is the most modest protocol change of the ones suggested (1b removes the ability for the council to put forth non-emergency upgrades at all, and 2 adds five additional days to the time it takes proposals to finalize), we lean toward option one. Curious to see what others think!
After carefully reviewing the proposal and considering the comments from @dzack23, we believe that option 1 is the most appropriate.
We consider this approach essential, as the Security Council is a crucial component for Arbitrum. Therefore, we would like to propose the inclusion of some sort of Emergency Response Drills for the Security Council. This idea aims to allow the DAO to empirically assess the Council's response times in various emergency scenarios. These drills should be carried out 2 to 4 times a year, at random times during this period.
Broadly speaking, the idea is to define certain response parameters that the DAO expects to be satisfactorily met by the Security Council, including response time, number of signatories, among other aspects.
It is likely that the members of the Security Council maintain a private group with the Arbitrum Foundation and OffchainLabs. However, from the DAO's perspective, we do not have, nor should have, visibility of this. The role of governance should be to ensure that the Council fulfills its role through these drills, especially considering that the DAO’s governance selects the security council members. This approach is not intended to add bureaucracy but rather to enhance security in the rollup with the highest TVL and activity in the ecosystem.
What are your thoughts?
