The Security Council Elections within the Arbitrum DAO — A Comprehensive Guide

The Security Council Elections within the Arbitrum DAO are not just vital; they’re the cornerstone of Arbitrum’s democratic ethos. Your participation in the ongoing Code4rena contest helps shape who will vigilantly maintain the security and integrity of the state-of-the-art Arbitrum DAO.

What is the Security Council, and what does it do?

The Security Council is a group of 12 members who are responsible for making urgent changes to the protocol in case of emergencies. They have the power to, for example, instantly upgrade the system if needed to maintain security and integrity. However, they are meant to act only in rare emergencies.

What’s its purpose? Why is it important to have it?

The Arbitrum DAO doesn’t just govern; it protects both Arbitrum One/Nova chains. The Security Council is our answer to unforeseen threats, ensuring that the system remains not just secure but versatile and ready for whatever comes next.

How does Arbitrum’s governance work?

For any sort of affordance, such as changing the protocol, updating contracts, or making changes to the core system, the governance is responsible for making all of these updates. Two parties can propose updates:

1. The Arbitrum DAO, which follows the typical collective path through the standard governance process.
2. The Security Council, which is there for emergencies.

What Qualifies as an Emergency within the Arbitrum DAO?

The Arbitrum’s Constitution clearly defines what constitutes an emergency, outlining the specific circumstances under which the Security Council should exercise its power.

For example, an emergency, as defined, refers to situations where users’ funds may be at risk or other critical issues that require immediate attention.

Emergency Actions:

Addressing urgent situations like this mandates swift Emergency Actions. The Security Council requires a consensus, with at least 9 of the 12 members concurring, to execute such actions.

Routine Operations: Non-Emergency Actions

Beyond emergencies, the Security Council also oversees routine software upgrades, maintenance, and parameter adjustments. These “Non-Emergency Actions” are standard operational procedures. A consensus of 7 out of the 12 council members suffices for these actions.

Who is part of the Security Council?

The initial 12 members of the Security Council were selected when governance was first introduced at the launch of the Arbitrum DAO. You can find the list here.

What are the Security Council Elections?

The Security Council Elections are meant to democratically determine the members of the Security Council on a semi-annual basis. This helps ensure that the members remain accountable to the DAO over time rather than becoming entrenched. It also allows fresh members with new skills and perspectives to join the Security Council.

What does the election process look like?

1. The election starts every 6 months.
2. For the first week, contenders can register to become nominees. They need 0.2% of votes.
3. There is then a 2 week compliance period for the foundation to vet nominees.
4. There is then a 3 week election period where delegates vote for nominees. The first week has full voting weight, and the next 2 weeks have linearly decreasing weight.
5. The top 6 nominees with the most votes become the new Security Council members.
6. The results go through a 3-day time lock on L2, a 1-week withdrawal delay, and a 3-day time lock on L1.
7. The new members are then distributed to the Security Council multi-sig wallets on each chain via the Upgrade Executor contracts.

Aside from biannual elections, the Arbitrum DAO can also submit a proposal at any time to remove a single member if needed.

How are membership changes managed?

The Security Council Manager Contract contains the authoritative list of Security Council members. It is responsible for propagating membership changes to the Security Council multisig wallets on all relevant chains, including Arbitrum One, Ethereum and Arbitrum Nova.

It does this by leveraging the Arbitrum cross-chain messaging system. It initiates a message that propagates across all chains through the same time locks as a core governance proposal. This ensures users have time to withdraw their funds if they disagree with the changes.

The Security Council Manager Contract interacts with the upgrade executor contract on each chain to actually update the multisig wallet members. The upgrade executor has the ability to carry out actions approved by the DAO.

The unsung hero: The Upgrade Executor

The Upgrade Executor contract is a core part of the governance system. It is the contract that is called to enact any changes or upgrades to the system that are approved by the DAO.

The Security Council Election contracts execute their actions via the Upgrade Executor. This gives them the ability to update the Security Council multisig wallets.

However, the election contracts are extremely locked down and can only call a single hardcoded action within the Upgrade Executor — updating the Security Council members. They cannot make any other changes to the system.

This means that while the election contracts have access to the powerful Upgrade Executor, their permissions are very constrained and limited only to the specific action of changing Security Council members.

Why does the upgrade executor have to be extremely locked down?

The Upgrade Executor has to be extremely locked down because it is a very powerful contract that has the ability to enact any changes to the system.

If arbitrary or unconstrained access was given to the Upgrade Executor, it could potentially be used to make malicious changes that compromise the system.

Therefore, when giving access to the Upgrade Executor — like in the case of the election contracts — it is crucial to constrain that access extremely tightly.

In this case, the election contracts are only allowed to call a single hardcoded action within the Upgrade Executor — updating the Security Council members. They cannot do anything else.

This extremely constrained and locked-down access ensures that while the election contracts can use the Upgrade Executor to change Security Council members, they cannot make any other unintended changes that could compromise the system.

Adopting a “Security by design” approach

• Constrained access: Only a single function within the Upgrade Executor can be called, strictly limiting what the election contracts can do. This constrained access model is baked into the protocol architecture from the start.
• Reuse of existing architecture: The system leverages the existing secure Upgrade Executor and cross-chain messaging, rather than introducing new contracts that would need to be secured. This reuse of existing secure infrastructure is another example of “security by design” at the protocol level.
• Adherence to specifications: The implementation strictly follows the Constitution, ensuring it meets the intended security properties outlined there.

Where to Look for Bugs

Access Control and Permissions: Begin by examining the access control and permissions for any contracts that interact with vital components of the system, such as the Upgrade Executor. It’s essential to ensure that access is tightly constrained and locked down to prevent unauthorized or malicious activities. This step is foundational to the system’s security.

Logic and Flow Analysis: Once you’ve confirmed that the access controls are robust, shift your focus to the logic and flow of the system. Analyze the underlying algorithms and processes to ensure they function as intended and align with the system’s objectives. Any inconsistencies or flaws in the logic could lead to unexpected behavior or vulnerabilities.

Race Conditions and Edge Cases: Pay meticulous attention to potential race conditions or edge cases that might lead to unexpected interactions between upgrades, actions, or other components. These scenarios can be subtle but may have significant consequences. For example:

• A governance proposal and a Security Council action could both try to upgrade the system at the same time, conflicting with each other.
• An election result could come in while a governance proposal to remove a Security Council member is in progress.
• Upgrades coming from different chains could arrive out of order and conflict.

Full Lifecycle Analysis: Finally, conduct a comprehensive trace through the entire lifecycle of the election process, from initiation to conclusion. This in-depth analysis will help you identify any hidden or overlooked issues that might not be apparent in isolated examinations of individual components.

In summary, focus first on access controls and permissions, then logic and intended behavior, then race conditions and edge cases, and finally trace through the full process to identify any other issues.

Thank you to an incredible contributor from the Code4rena community, Bytes032, for writing this guest post.

• Bytes’ Twitter: https://twitter.com/bytes032
• Bytes’ Website: https://bytes032.xyz/
• Bytes’ Code4rena Profile: https://code4rena.com/@bytes032

For more information on Code4rena:

• Website: https://code4rena.com/
• Twitter: https://twitter.com/code4rena
• Discord: https://discord.gg/code4rena

For more information on Arbitrum:

• Website: https://arbitrum.foundation/
• Twitter: https://twitter.com/arbitrum
• Discord: https://discord.gg/arbitrum