[Constitutional] AIP: Security Council Election Process Improvements

We agree with @euphoria that any future changes to the election cadence should take place well in advance of the following election. This is why the changes from this proposal will only take effect after the September 2025 election and several months before the following Security Council election (which would take place in September 2026, assuming this proposal passes on Tally).

Regarding the suggestion to share candidate declarations: all members of the March 2025 cohort were required to agree to potential term changes via their declarations in order to apply. As illustrated in this guide, it is mandatory for candidates to agree to declarations when applying. The same requirement will apply to the incoming September 2025 cohort.

Regarding the suggestion to publish an election calendar, we have added clarification to the proposal text that, if this proposal passes, all future Security Council elections will take place every September.

Thank you to @Euphoria for the suggestion to publish a public feed of rotations as they happen. Considering the sensitive nature of any actions the Security Council may take, we do not believe actions in the process of being executed should be publicized via a live feed. However, we agree that a candidate or member requesting a key rotation should announce this on the forum once they have submitted the rotation on-chain. Since attempted key rotations will be actively monitored by the AF and Security Council, either of these stakeholders will be able to verify on the forum whether such key rotations are expected, have followed standard procedures, and whether or not they should be approved or vetoed. It is also worth noting that all Security Council actions are already broadcast via Tally and the forum once executed.

Regarding Euphoria’s suggestion to share an emergency playbook: the Security Council already follows a robust set of best practices, which are not publicized due to their sensitive nature. Accordingly, we do not believe it is wise to publicly share an emergency playbook.

Thank you to @tane for the suggestion to conduct periodic liveness checks on Security Council members’ keys to ensure that members remain capable of fulfilling their responsibilities. It is worth noting that Arbitrum Security Council members already participate in routine, off-chain fire drills that account for this risk.

2 Likes

Thank you to @paulofonseca for questioning whether allowing candidates and members to self-rotate their keys would create new attack vectors. It is worth noting that key rotations are common, and this change would actually minimize the risks posed by key rotations (especially during elections), as it reduces the time that a Security Council member possesses a suboptimal key setup. Furthermore, just as the Security Council and AF currently need to actively approve key rotations, if this proposal passes, the Security Council and AF will still be able to veto key rotations if they do not follow standard procedures (e.g., the signer must notify the Security Council and AF in advance, pass compliance checks, etc.) or if the proposed key rotation results from a Security Council member being compromised, during the 18-day governance timelock.

Thank you to @seedgov for questioning whether the Nominee Selection phase’s qualification threshold needs to be reduced from 0.2% to 0.1%. We believe it is important to reduce this threshold because, if Security Council elections become less frequent, the existing 0.2% threshold will quickly become difficult to meet over time as ARB continues to unlock. According to our estimates, a 0.2% threshold would equate to 11.7M ARB in September 2026 and 14.7M ARB in September 2027. Furthermore, the aim of the Nominee Selection phase is to weed out subpar candidates, not to prevent strong candidates from progressing due to a lack of votes. As Seedgov correctly noted, delegates do not need to cast their full voting power, can selectively cast votes for candidates they consider strong, and should not be encouraged to utilize their full voting power for its own sake.

Regarding @Euphoria’s point about the amount of ARB required to raise a proposal to Snapshot: this proposal aims to correct the constitution. The threshold is fixed at 500,000 ARB, as it is not possible to set this threshold as a percentage in the current Snapshot configuration.

Thank you to @seedgov and @krst for highlighting the need to discuss how to enhance the candidate pool for future elections, improve the Security Council’s operations, and strengthen other off-chain aspects of the Security Council election process, as well as other topics identified in OpenZeppelin’s Arbitrum Security Council Recommendations. We agree it is important to address these broader topics and that now is a good time to do so. However, we consider most of these topics to be outside the scope of this proposal, as they would not impact the constitution nor the Security Council election smart contracts and therefore would not need to be voted on. Accordingly, we have created a separate thread on the forum to discuss these higher-level topics separately, but in parallel with this proposal.

Speaking as someone currently serving on the Security Council since the March 2025 election and having served as OpenZeppelin’s Council representative prior, I want to share my perspective on this AIP.

Longer Cohorts

I’m strongly in favor of moving to two-year cohorts. The six-month cycle can be exhausting for candidates, delegates, and members alike. Too much energy goes into campaigning and turnover prep that changes the makeup of the Council. Longer terms would provide continuity and reduce election fatigue. In my experience on other Security Councils, longer-serving members work more effectively with one another.

Key Rotation

I also strongly support adding key rotation mechanisms. There are often perfectly reasonably reasons for a Council member to rotate keys for security measures or because of personnel changes for organizations. A clear process with timelocks and monitoring ensures this does not become a significant irsk

The risk of abuse is already low — every rotation is subject to the 18-day timelock with Foundation oversight. Still, this could be improved by requiring other Council members (e.g., 7 of 12) to co-sign a rotation after checking that the new key is controlled by the same person or entity.

Thresholds & Incumbents

On the lower threshold and incumbent auto-progression, I’m neutral. Lowering the bar could help some candidates, but the real challenge is quality. Likewise, skipping the nomination phase eases delegate work, but competition is also healthy. I’m comfortable following delegate consensus here.

Candidate Qualifications

Where I do agree with many comments is on candidate qualifications and vetting. It’s one thing to have the numbers, but the DAO also needs confidence that members have the technical skills and integrity the role requires. The OpenZeppelin report laid out good recommendations, and I’d like to see those explored. That said, I don’t think this AIP needs to be blocked on that front. Improving qualifications will inevitably depend on the Foundation to design and enforce stronger checks during compliance, and I hope that conversation continues in parallel.

In summary

  • I am strongly in favor of the longer cohort duration and key rotation changes.

  • I support key rotation and believe its security could be further strengthened by requiring a threshold of the current Security Council members (e.g., 7 of 12) to co-sign a rotation, validating that the new key is controlled by the member without creating the friction of involving governance.

  • I am neutral on lowering nomination thresholds and incumbent progression.

  • I agree that technical qualification standards is lacking in this proposal and deserves attention, although not necessarily a blocker to the AIP if the AF could commit to making improvements on this front.

This proposal addresses several real pain points we’ve felt inside the Council, and I believe it’s a step in the right direction.

As a current member elected in the March 2025 cohort, I would personally be comfortable with — and supportive of — an extension of my term under these changes.

4 Likes

Thank you very much for your reply. Just out of curiosity, why do you think that addressing those other issues would not impact the constitution nor the Security Council election smart contracts, while we haven’t discussed those topics yet? For example, the part where we point out that the scope of responsibilities of the security council does not match the reality might very much impact the constitution.

OpenZeppelin recommendations were published in March, and it seems that there has been ample time to discuss the outcomes. I haven’t seen any attempts by the Arbitrum Foundation to initiate a discussion on the topic with the community in that time. Furthermore, the implementation of these changes is scheduled for the March elections next year, providing more than enough time for a thorough discussion.

I don’t see any good reason to vote to support these particular changes before having a proper discussion first. In my view, if this was proposed by anyone else than the AF this would not even be considered as ready for a vote.

1 Like

Thanks to the @Arbitrum foundation for drafting this. Security Council elections have been one of the more demanding processes in the DAO, and this proposal tries to smooth out the biggest pain points: short terms creating constant campaigns, thresholds creeping too high, and unclear rules around key rotation.

Overall, the direction feels right. The changes make the process less exhausting, easier to participate in, and more secure. We’ll be voting FOR.

Item v1 v2 Why it matters
Cohort Duration 6-month elections (1-year term) Annual elections (2-year term) Cuts down fatigue and frees space for proper evaluation.
Qualification Threshold 0.2% of Votable Tokens 0.1% of Votable Tokens Keeps pace with ARB supply growth, lowers the barrier so candidates can actually qualify.
Incumbent Progression Must re-qualify Auto-pass into Member Election Adds continuity but risks reducing competitiveness if incumbency = endorsement.
Key Rotation Only ad hoc, non-emergency Formal functions for nominees & members to rotate keys Clearer process, stronger security, no more patchwork fixes.
Snapshot Threshold 0.01% of Votable Tokens Fixed 500k ARB Fixed numbers drift over time. Proportional thresholds stay fairer.

Lowering the nomination threshold from 0.2% to 0.1% is a sensible adjustment given quorum creep, but this alone won’t solve the deeper issue: the candidate pool has been shrinking. To keep the role attractive and bring in higher-quality applicants, the DAO could consider modest stipends or expense coverage, as seen in other ecosystems, to signal that Council service is valued.

At the moment, Arbitrum SC members earn a $5,000/month stipend in ARB (≈$60k/year), fixed in USD terms. This makes costs predictable for the DAO, but compared to peers it’s a fairly minimal setup. Optimism pays ~8,955 OP/month (≈$72k/year), reviews the budget each season, and even reimburses basics like hardware wallets and signer tools. zkSync takes a tiered approach, paying $8k/month for organizations and $5k/month for individuals, plus around $100k/year in operational funding to cover security tooling and legal support.

For Arbitrum, it might be worth considering something similar, a small ops budget for hardware wallets or signer tools, and periodic stipend reviews to stay aligned with responsibilities and market conditions. These wouldn’t be major changes, but they’d make the role easier to take on, signal that the DAO values Council members’ security needs, and help keep the position attractive for high-quality candidates in future elections.

Proactive outreach from the Foundation and delegates to technically competent community members or aligned organizations would also help broaden the pipeline, provided that clear conflict-of-interest disclosures are required. We can also borrow lessons from Optimism’s model, which sets baseline expectations around technical competency, independence, and geographic diversity.

Building on this, we find @openzeppelin ’s recommendations highly relevant. First, explicitly defining “governance attacks” within the Constitution would give the Council a clearer mandate to act against exploitation leveraging governance mechanisms. We also support limiting pseudonymous members to three; while pseudonyms can build strong reputations, their anonymity complicates assurances of their autonomy. To raise the baseline competency, we agree that candidates should demonstrate technical proficiency during compliance, for instance, by signing and verifying transactions. We also endorse allowing organizational members with small 1-of-N multisig setups (N ≤ 3) to provide resilience and institutional accountability while containing risk.

We agree with @Tane that periodic liveness checks are an important safeguard, and we appreciate the Foundation’s note that current off-chain fire drills already help cover this risk. Still, adding an onchain element could provide extra assurance and transparency for the community. To complement this, we’d also suggest introducing a mandatory security workshop for all signers at the start of each term. Having an external specialist walk through best practices in key custody, incident response, and rotation procedures would ensure everyone is aligned and set a consistent baseline for future cohorts. Together, liveness checks and structured training would make the Council’s key management practices more resilient while also raising confidence across the DAO.

Really appreciate the proposal from AF. A few thoughts on where I see risks, and some ideas for how we might handle them:

Cadence & Engagement
Longer terms do reduce overhead, but the flip side is less frequent elections can make voters tune out.

Like what @krst pointed out here that even the official guidebook guiding how delegates should evaluate candidates have not been updated in two years. I’m afraid that longer terms will only make it harder for delegates to keep track of the updates from Security Council and will naturally become out of touch.

While we’re not so sure about the longer terms, one way to maintain the same election frequency while still keeping delegates interested and engaged might be to line up Security Council elections with other big governance events (like the annual budget or constitutional reviews). It’s very common on many countries where several important and routine votes are bundled together every year to increase voting turnouts and reduce voters’ fatigue. That way, we create a kind of “governance season” where attention and participation are naturally higher.

Nomination Thresholds
Lowering the bar makes it easier for new candidates to step in, which is good, but as @SEEDGov flagged it also raises information costs for voters. A fix could be asking nominees to show an ongoing commitment — for example, at least 90 days of active participation in security-related discussions or working groups before elections. That way, candidates aren’t just names on a ballot but have already demonstrated engagement with Arbitrum’s security process.

To be fair, most of the delegates are probably not security experts, so it’s difficult for us to evaluate and vote just from the candidates’ personal statements in their applications. An ongoing commitment requirement, similar to the one for DIP, can provide delegates a chance to interact with and evaluate each of the candidates better. This filters for candidates who are already engaged, and makes the nomination phase about proven contribution rather than one-off mobilization.

Institutionalization
Finally, the bigger picture is that the Security Council is no longer just an “election event” — it is becoming a standing institution in Arbitrum governance. To reflect that, the DAO could consider instituting a periodic review process (for example, every quarter) where the Council reports on its activities, mandate, and security posture. This would keep legitimacy and accountability fresh between elections, not just when terms expire.

Thank you for your reply.

Please see Discussion: Improving the Arbitrum Security Council, where we further address these points.

After reviewing the proposal and comments, we find ourselves much aligned with @michael-oz.

We support key rotation, technical qualification standards, and an extension to a two-year term.

As per the thresholds, we found that many quality candidates applied, and it’s unclear what benefits more candidates actually provide. We won’t block this change, but it does not seem as necessary as the others. It does not appear as though we have a candidate problem currently.

Another consideration could be supporting stakeholders (such as other Orbit Chains, core contributors, etc.) rather than anyone applying. But we do not have as strong opinions on this matter.

1 Like

After discussing internally, Entropy Advisors is generally supportive of the changes to the Security Council brought forward by the Arbitrum Foundation.

The only matter outlined in this proposal that gave us pause for further consideration was the automatic progression of previous Security Council members to the Member Election Phase. As highlighted by @SeedGov, when combined with the lowering of thresholds and taking into account the current number of applicants, the required amount of VP to approve all applicants to the next phase is quite low (<100m ARB). While the Arbitrum Foundation can monitor for subpar candidates, our team fears that both changes may lower the bar too much.

Our team has also been following the conversation around higher-level meta changes to the Security Council. After reviewing the response of the Arbitrum Foundation to the numerous questions raised, we believe there is little reason to delay the Snapshot vote for the changes in this particular proposal. While it is obviously presumptuous to consider any of the changes final at the temperature check stage, we see value in providing prospective candidates for the September 2025 election a certain level of clarity on the DAO’s stance regarding term duration and key rotation. Additionally, given the proposed timeline for the follow up onchain vote, there is an opportunity to raise another Snapshot vote that incorporates any further changes based on discussions.

2 Likes

The temperature check for this proposal is live.

As stated, since all the proposed changes to the Security Council election process are independent of one another (apart from the corresponding text changes to the constitution), this temperature check will use ‘approval voting’ to better understand sentiment regarding each individual change before deciding how to proceed with the vote.

With approval voting, you may select any number of choices, and each selected choice will receive your full voting power. Accordingly, if you do not support any of the proposed changes, please remember to select only ‘None’ to ensure the reliability of results.

The voting options are as follows:

  1. Increase cohort duration
  2. Reduce qualification threshold
  3. Allow members to bypass Nominee Selection
  4. Allow candidates to rotate keys
  5. Allow members to rotate keys
  6. None

Separately, as mentioned here, if discussions suggest that further technical and/or constitutional text changes are required, these can be raised through another temperature check and bundled into the on-chain Security Council Election Process Improvements proposal (intended to take place at the end of the year, assuming the relevant temperature check(s) pass).

I think that overall the changes are positive, so I vote FOR almost all the points

I would like to draw attention to the point “Allow members to bypass Nominee” - as was said earlier - this is a very positive point, since it increases competition in fact due to the fact that many votes are freed up that members would have collected
Look at the previous votes - we nominate almost the same people, and so there will be a chance for good candidates to get in and increase competition, which always has a positive effect on the system

Regarding the replacement of the point “Allow candidates to rotate keys” - I do not understand the need: if a candidate passes, he can change the key as a committee member, and if not, then next time he will apply with a different key

Thanks @arbitrum for putting together such a well-founded proposal.

We are generally onboard with the direction - less frequent elections, more focus on the execution; Adjust the qualification threshold accordingly; key rotation for security check.

Also we are happy to see from the replies of arbitrum that they are taking more actions on the check of the key security, which is one of our main concerns while reading the proposal.

One question - If the incumbent can bypass the nomination phase, do we have a evaluation method to decide the performance of the incumbent? If the incumbent is well performed, we for sure should give a bypass. But if not, we don’t think it makes sense to do so. So our point is that the bypass should be based on general performance.

We are align with some of the @krst suggestions on enhancing candidate pool and operation sied of improvement, will follow up on the separate threads.

Regarding the replacement of the point “Allow candidates to rotate keys” - I do not understand the need: if a candidate passes, he can change the key as a committee member, and if not, then next time he will apply with a different key

Currently key, rotation requires that the Security Council itself take an action; in the new proposal, an individual member can self-rotate without any involvement from the other Security Council members.

We are in alignment with @michael-oz and @gauntlet. Longer terms and key rotation make sense. The benefits of automatic incumbent progression and lower nomination thresholds do not address the root problem of a weak candidate pipeline.

1 Like

How will the extended Security Council term impact voter engagement and continuity in decision-making