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
Chosen solution: In the temperature check vote Arbitrum DAO decided to increase the threshold of the non-emergency Security Council to 9/12.
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.