TLDR
The report evaluates potential improvements to the Arbitrum Security Council, which safeguards over $14B in assets. Key recommendations include: defining governance attacks in the Constitution, limiting pseudonymous members to three, implementing technical proficiency demonstrations during compliance screening, allowing organizations as members with 1-of-N multi-signature wallet configurations (N≤3), maintaining the council’s emergency action powers rather than restricting to veto-only, and preserving the current 12-month staggered terms. The council requires members who are impartial, trustworthy, and technically competent, capable of independently assessing threats and validating remedial actions.
Introduction
The Arbitrum Security Council consists of individuals tasked with evaluating and addressing risks to the Arbitrum ecosystem through both emergency and non-emergency actions. The Arbitrum DAO elects the 12 Security Council members, who can be removed by either the DAO or fellow Council members if removal criteria are met. Members serve in two separate groups of six for twelve-month terms, with elections for each group staggered by six months.
Disclosure: OpenZeppelin currently serves as a member of the Arbitrum Security Council
This report examines potential improvements to the Arbitrum Security Council, specifically investigating:
- Ideal qualities and capabilities for Security Council members
- Possible modifications to the Security Council election process
- Potential expansion of the Security Council’s responsibilities
- Risk assessment of implementing a veto-only Security Council
- Organizational use of multi-signature wallets for Security Council participation
Current Election Process
The elective process for appointing Security Council members is enshrined in the DAO constitution:
The following timeline governs an election that starts at time T:
Contender submission (T until T+7 days): Any DAO member may declare their candidacy for the Security Council, provided that a current Security Council member in one cohort may not be a candidate for a seat in the other cohort.
Nominee selection (T+7 until T+14 days): Each DAO member or delegate may vote for their declared contender. Each token may be cast for one contender. To the extent that there are more than six contenders, each eligible contender must be supported by pledged votes representing at least 0.2% of all Votable Tokens.
Compliance process (T+14 until T+28 days): All candidates will cooperate with the Arbitrum Foundation and complete the compliance process. The Arbitrum Foundation is responsible for removing any candidates that fail the compliance process. In the event that fewer than six candidates are supported by pledged votes representing at least 0.2% of all Votable Tokens, the current Security Council members whose seats are up for election may become candidates (as randomly selected out of their Cohort) until there are 6 candidates.
Member election (T+28 until T+49 days): Each DAO member or delegate may vote for any declared candidate. Each token may be cast for one candidate. Votes cast before T+35 days will have 100% weight. Votes cast between T+35 days and T+49 days will have weight based on the time of casting, decreasing linearly with time, with 100% weight at T+35 days, decreasing linearly to 0% weight at T+49 days.
At T+49 days: The process for replacing the cohort of security council members with the 6 candidates who received the most votes will be activated. The installation process must be executed via the on-chain governance smart contracts and it may take several days until the new security council members are installed.
The recommendations explored within this report are to be considered within the context of the above elective process.
The High Stakes of Arbitrum Security
The Arbitrum Security Council functions as the ultimate protective barrier for the Arbitrum ecosystem. While an ideal decentralized system would operate without such concentrated authority, the council currently exists to counter governance attacks, problematic upgrades, and severe exploits. The stakes are exceptionally high—the council safeguards over $14 billion in bridge assets alone, making it a compelling target for sophisticated attackers.
Recent incidents illustrate the extreme measures criminals will take to access substantial crypto assets. The council faces numerous potential attack vectors, including physical coercion of members, election infiltration through fabricated personas, vote manipulation to remove members, bribery of members or voters, technical compromise via malware, or various combinations of these approaches.
The council’s authority makes it particularly vulnerable—with approval from 9 of 12 members, it can implement immediate protocol upgrades or schedule proposals with a three-day delay. This 9-signature requirement represents the critical safeguard protecting billions in assets. Even if an attacker spent $1 billion to compromise each council member, the potential reward would still make such an expensive attack financially worthwhile.
Bridge assets require particular attention because, unlike previous crypto incidents such as the DAO attack where Ethereum could implement a hard fork to reverse the damage, stolen bridge funds would be irretrievably lost. Such an attack would not only drain billions in assets but would permanently damage Arbitrum’s reputation as a secure network.
Qualities of an Ideal Security Council Member
The duties and principles of an ideal Security Council member have been explored by the Arbitrum Foundation. Based on the Arbitrum Constitution and the expectation of Security Council members, we believe that these qualities are the most important:
Impartial
A security council member must be prepared to address both technical issues and governance attacks. We define issues as exploits or bugs in protocol code/contracts requiring straightforward remedies or upgrades. Attacks, specifically governance attacks, present more nuanced challenges - what one participant views as legitimate proposal ratification, another might consider a hostile takeover. For us, the qualifying characteristic of a governance attack is exploitation. If a proposal or action irrevocably exhausts a DAO resource (e.g. funds, goodwill, reputation) to the benefit of a select few and does so in bad faith (i.e. isn’t just incompetence), we would classify it as a governance attack. We furthermore would say that a governance attack fits the description of a “security emergency” as outlined in the Security Council’s responsibilities of the Arbitrum Constitution. Of course, this is a subjective ruling and always will be. But exploitation we consider to be the measuring stick council members can judge against. To evaluate well, council members should exercise judgment while remaining detached from routine DAO governance politics. Thus, impartiality emerges as a crucial characteristic, though political disengagement alone does not guarantee unbiased decision-making.
Recommendation:
Governance attacks are not explicitly defined in the Arbitrum Constitution. We believe they should be added to the language describing the responsibilities of the Security Council.
Trustworthy
The Security Council is not a perfect solution. An ideal decentralized system would have no trusted parties at all. But because the security council has been set up as a trusted group, its members must be trustworthy. While the current KYC process verifies member identities, it cannot ensure members are truly autonomous actors. Even with thorough identity verification, council members could still be proxies for other entities or operating under external control. Therefore, KYC serves primarily as regulatory compliance, not as vetting of outside interests. The measure of a candidate’s trustworthiness should be based on a member’s demonstrated capabilities, commitment to the ecosystem, and track record rather than their identity verification or community status. Voters should keep this in mind when voting for pseudonymous security council candidates. Pseudonymity can be seen as a proxy for being trustworthy, impartial, and accountable, but it makes it hard to have assurance of their autonomy.
Recommendation:
The Security Council should not have more than three pseudonymous council members. This should be stated in the constitution.
Competent
Council member competence spans multiple dimensions. While executing fixes may only require transaction construction and verification skills, the full scope of council responsibilities demands broader expertise. Members must assess threats, collect and validate evidence, evaluate potential solutions, and ensure correctness of their actions. This requires a combination of:
- Technical security knowledge to understand vulnerabilities
- Deep ecosystem familiarity to grasp implications
- Sound judgment to evaluate complex situations
- Collaborative skills to work effectively with other council members
The ideal candidate demonstrates these capabilities while maintaining impartiality and establishing trust with the community, whether operating publicly or pseudonymously.
Security Council Member Capabilities
Technical Competency
Arbitrum’s security is fundamentally the DAO’s responsibility. The council should not necessarily be the first to identify threats, nor should they be the only ones capable of crafting remedial transactions. However, each council member must be capable of independently assessing threats and proposed remedies on their own. This requires several key capabilities that each council member must be able to do on their own:
-
Arbitrum is an EVM-based network. Council members should have a solid understanding of how the EVM works, how functions are encoded and called, how to query an RPC, how blocks become finalized in Arbitrum and on Ethereum mainnet, and common pitfalls when coding in these environments. Candidates who want to learn the foundational concepts could read the somewhat-out-of-date, but still instructive Mastering Ethereum. Solidity by Example is also a great place to get to know patterns and anti-patterns in Solidity, the primary language of the EVM.
-
Best practices and baseline cryptography skills. Council members should understand how private and public keys are used, how to keep them safe, they should have hard wallets, know how to rotate keys, and have a good sense of danger. They should be able to construct call data, hashes, transactions, and signatures locally and independently (i.e. with no assistance from other council members, community members, attackers, or from online tools). The council uses a Safe multi-signature wallet. Each council member should read their guide on how to check the data they are signing. OpenZeppelin also has a tool to use to confirm Safe transaction hashes. But ultimately and again, each council member should be able to do this locally.
-
Understanding of key DAO contracts and their functions. Candidates should have an intimate knowledge of the interfaces of the council multi-signature wallets, Upgrade Executors, Governors, and Timelock contracts. They should understand what contracts can call what functions on each other. They should understand how these interact and depend on the node software’s precompiles. All of this allows a council member to understand the context of any remedy they will transact and its ramifications. Candidates who want to learn these skills can read the governance docs on Github and confirm if the docs are accurate by reading the on-chain contracts’ code listed here (this author prefers using deth.net for on-chain viewing of code).
-
Be able to build, decode, and simulate their transactions and proposals. Council members should not just sign and transact. Each member should be able to decode transaction data, construct their own, and simulate and assess a transaction on their own. Tools like Hardhat or Foundry allow for local simulation of transactions but manual decoding and tracing through the transaction data should be possible. Indeed this may be necessary as Arbitrum’s precompiles do not integrate tightly with the automated tooling mentioned above. We would encourage the community to consider prioritizing building simulation tools to allow rapid understanding of proposal implications. Solidity is also not the only language that council members need to be able to read and reason about. Arbitrum contains a considerable amount of Go and Rust as well.
-
Excellent on-chain data verification skills. Docs can go stale, forum posts can be out-of-date, but the code is law. Each council member should be able to verify on-chain data, query multiple different RPC nodes, gather historical data through logs, and do this locally (not just using block explorers like Etherscan). Ethers v6 (not v5, as it can leak private keys) is a popular Javascript library for interacting with RPC nodes, but there are many great ones.
A real-world example that highlights the need for technical competency is the recent Bybit incident, which is a prime example of the types of threats that the Security Council will face. A full post-mortem from Bybit is still forthcoming, but the incident is believed to be centered around the compromise of a Safe{Wallet} developer’s machine by a sophisticated threat actor. The key take-away from this incident has been that signers must always be able to independently evaluate and understand what they are signing without relying on tools hosted by a third party.
Standardized Assessments
Standardized technical assessments through multiple choice questions, coding exercises, or time-limited challenges present several challenges. Such tests can be undermined by answer sharing and test design inevitably introduces biases in what skills are measured. Instead of rigid testing, technical demonstrations should serve as meaningful signals rather than absolute measures.
For practical demonstration, candidates could engage with purposefully designed on-chain contracts. For example:
- Submit signed nested transactions on testnets to demonstrate multi-signature wallet operation
- Trace crafted transaction paths to specific verification contracts
- Prove ability to verify data on chain
Substantive Signals
While these basic demonstrations establish baseline competency, more substantive signals might include:
- Publishing threat analyses
- Documenting potential DAO attack vectors
- Proposing governance improvements
- Contributing to security documentation and processes
These and other similar activities demonstrate both technical capability and commitment to protocol security better than standalone tests.
Recommendation
During the compliance phase of the elective process it is recommended that candidates demonstrate their technical proficiency to the Arbitrum Foundation through the following:
- Submitting a signed nested transaction for a testnet multi-signature wallet operation
- Demonstrating how to verify transaction data on-chain
- Evaluating a proposal transaction payload and explaining which actions will be performed
- Tracing a constitutional proposal execution call and describing the paths and state changes
It would be beneficial to council members if they familiarized themselves with the materials outlined in the [Technical Competency] section which should equip them with the necessary skills to successfully complete the aforementioned tasks.
Organizations as Security Council Members
Enhanced Response Capabilities
The primary benefit of organizational members lies in their enhanced response capabilities. Through a 1-of-N multi-signature wallet configuration, organizations can be more responsive to the DAO’s needs and possibly even provide 24/7 coverage through multiple qualified experts. They bring broader technical expertise to threat assessment and solution development, backed by greater resource depth for handling complex incidents. Indeed, organizations can maintain internal processes for collaboration and expertise-sharing without requiring formal role designation in the multi-signature wallet structure. This preserves both quick response capability and depth of resources. Signers can collaborate when time permits but act independently when speed is critical.
But there are numerous other benefits as well. Organizations offer robustness through built-in succession planning. They are more likely to have strong key management policies and practices. Their involvement carries the weight of reputation as an incentive and legal liability as a deterrent. When threats arise, organizations typically have the resources to protect threatened team members or are made aware of and can respond to these threats more readily.
Attack Surface Considerations
Of course, not all organizations have all of these qualities and indeed can be more risky than an individual in certain scenarios. With a 1-of-N configuration, any single signer being compromised is sufficient for control, and organizations that are known make their members public targets for social engineering. There’s also the risk of organizational restructuring (e.g. a target company’s management board being fired), which asks whether the new organization is to be trusted as it was. Furthermore, mitigating these risks with higher thresholds of the company multi-signature wallet would negate the response time benefits.
Recommendation
- Allow organizations as council members
- Permit 1-of-N multi-signature wallet configurations (with N ≤ 3) to optimize for responsiveness and attack surface
- Organizations should be subject to the same scrutiny as individuals
- Each signer should have equal authority to act on behalf of the organization
- Keys should not be shared between individuals
- Signers should be capable of utilizing hardware wallets
The benefits of enhanced response capabilities and institutional robustness outweigh the increased attack surface risks, especially in view of the eventual curtailing of the security council’s arbitrary power. Organizations should complement, not replace, pseudonymous individual members, as each type provides different security properties that strengthen the council’s overall resilience.
Scope of Security Council Member Responsibilities
The core function of security council members is to execute privileged transactions when needed to protect the protocol. As stated above, this does not include incident response or threat detection. However, Security council members typically possess deep technical expertise and protocol knowledge. This expertise could benefit the DAO through additional contributions like security assessments, threat analysis, process improvements, and governance recommendations. Their unique perspective from their council seat could inform valuable insights for protocol development and security enhancement.
Expanding Responsibilities
However, expanding responsibilities creates practical concerns. Additional duties could distract from or conflict with the core security mandate. If a council member is deeply engaged in a technical analysis or improvement project when an emergency response is needed, competing priorities could impact response time or decision quality. The selection criteria for council members focuses on their ability to assess and respond to threats, not necessarily their capacity for broader contributions. Furthermore, council members with DAO responsibilities outside the council are by definition engaged in the political process and are subject to political forces. Political goals must not be pursued with so much vigor so as to taint a council members’ appearance of impartiality.
Recommendation
Any broader contributions from council members should remain strictly voluntary and not be an election qualification. The DAO should maintain clear separation between the council’s core security duties and any additional activities. While council members’ expertise is valuable, protecting the protocol through reliable execution of their primary role must take precedence. Members can contribute to the ecosystem in other capacities, but not as an explicit extension of their security council duties. This recommendation preserves focus on the essential security function while allowing members to voluntarily leverage their expertise for the DAO’s benefit when doing so doesn’t compromise their primary responsibility.
Veto-Only Power for the Security Council
Reducing Attack Surface
A veto-only model offers several key benefits for protocol decentralization. By restricting the council’s power to blocking proposals, it significantly reduces the attack surface since a compromised council could only prevent actions rather than execute malicious ones. This aligns with decentralization principles by removing the council’s ability to unilaterally make protocol changes. The council’s role becomes purely defensive rather than maintaining broad executive powers, creating clearer scope and accountability.
Operational Risks
However, this restricted authority introduces substantial operational risks. Response to exploits would face critical delays as the council could not quickly patch vulnerabilities or stop active exploits. Instead, they would need to wait for the normal governance process to implement fixes, potentially giving attackers more time to drain funds or cause damage. Crisis management capabilities would be severely limited without the ability to take emergency protective actions, freeze vulnerable contracts, or pause operations. The council would be forced to rely on proposal scheduling even in critical situations.
New Vulnerabilities
The model also creates new governance vulnerabilities. Attackers could attempt to overwhelm the council by submitting multiple proposals simultaneously, making it harder to analyze and veto all dangerous ones in time. A delayed response could allow malicious proposals to succeed before being vetoed. Additionally, a potential stalemate could emerge if compromised council members coordinated to block all proposals, effectively freezing protocol development and upgrades.
Recommendation
Given the high value of assets at risk ($14B+ in the bridge) and the ongoing development of key facets of the protocol, maintaining the council’s ability to take swift protective action currently outweighs the benefits of limiting their power to vetoes only. However, this recommendation could shift as the protocol matures and develops more robust decentralized security mechanisms. Key milestones that might enable a transition to veto-only power include:
- Development of automated threat detection and response systems
- Implementation of protocol-level circuit breakers and safety checks
- Establishment of rapid community response mechanisms
- Significant reduction in total value locked in bridges or critical infrastructure
- Proven track record of successful decentralized governance responses to security incidents
The path to maximizing decentralization should be gradual, with security council powers reduced as these alternative protective mechanisms demonstrate effectiveness.
Security Council Member Elections
Short Terms
Term length involves critical trade-offs that impact council effectiveness and governance overhead. Shorter terms of 6 months or less allow for more frequent community input and representation adjustments, and enable faster removal of under-performing members. However, they create higher operational costs through frequent onboarding and transitions, risk collective knowledge loss and relationship disruption, contribute to voter fatigue among DAO members, and may incentivize short-term thinking over long-term security focus.
Long Terms
In contrast, longer terms of 12+ months provide stability and consistency in security operations, allow members to maintain established working relationships, reduce governance overhead and election fatigue, and enable long-term process optimizations. The potential drawbacks include being less responsive to changing community preferences, risks to council members not staying updated with the ecosystem’s developments, and possibly entrenching power if removal mechanisms are not robust.
Recommendation
We recommend maintaining the current practice of terms of 12 months to prioritize operational continuity. With staggered elections where half the council is elected at a time, a reasonable schedule of two elections per year is achieved while maintaining consistency. The security-critical nature of the council benefits from the stability and efficiency that longer terms facilitate, even among already-qualified professionals, while staggered elections provide regular opportunities for community input.
Conclusion
The Arbitrum Security Council serves as the last line of defense for billions in assets, requiring careful balance between security, decentralization, and operational effectiveness. The key design decisions around composition, authority, term length, and scope must prioritize the council’s ability to respond effectively to threats while establishing a path toward greater decentralization. Success depends on maintaining robust security capabilities in the near term while developing the mechanisms and processes that will enable reduced centralization over time.
The Security Council Election process is crucial to ensuring qualified candidates are elected to the Arbitrum Security Council. In particular, methods to surface candidate technical proficiency during the contender submission phase and assessment tasks to evaluate relevant technical skills during the compliance phase are recommended. In addition, this report makes recommendations for areas of improvement in the current elective process. The report has highlighted materials and tools with which Security Council members should be familiar as a baseline level of technical proficiency. Recommendations are also made regarding the topic of allowing organizations on the Security Council to use multi-signature wallets as signers and guidelines for the configuration of these multi-signature wallets have been provided.