This constitutional proposal focuses on updating the Security Council election process alongside the necessary changes to the ArbitrumDAO constitution.
We propose the following changes:
Increase cohort durations. Extend the Security Council cohort duration from 1 year to 2 years, therefore reducing election frequency from twice a year to once a year.
Reduce qualification thresholds. In the Nominee Selection phase, change the qualifying threshold from 0.2% to 0.1% of votable ARB.
Progress Security Council members. Allow any existing Security Council members who have re-applied to bypass the Nominee Selection phase and into the Member Election phase.
Security Council key rotation. Enable Security Council candidates to rotate their keys during the Compliance phase of the election and enable Security Council members to rotate their keys at any time during their term.
Update Constitution Text. All changes should be reflected in the ArbitrumDAO Constitution to ensure the implementation adheres to the text.
As these changes are independent of one another (apart from the corresponding text changes to the constitution), this temperature check will use ‘approval voting’ to enable delegates to express support for each individual change (with their full voting power going towards each choice they select).
This AIP aims to improve the effectiveness, efficiency, and practicality of the Security Council election process (for both candidates and delegates); while addressing the following pain points identified in recent cycles:
Frequent election cycles. Both voter and candidate fatigue from participating in the election every six months as a single election requires significant effort from all parties from advertising the election, getting candidates to nominate themselves, evaluating their candidacy, and ultimately picking them.
Qualification threshold increasing. A rising qualification threshold has reduced the number of candidates who can progress to the Member Election phase simply due to the unavailability of active voting power.
Non-Emergency Actions to Rotate Keys. Candidates, and existing Security Council members, cannot rotate their keys after they have registered for the election. This has led to the Security Council performing non-emergency actions to update their keys after the election has concluded. Not only is there increased risk due to suboptimal setups, but the additional burden on the Security Council is unnecessary.
Renominating Security Council members. It requires active voting power to progress an existing Security Council member to the Member Election phase. As they were already elected previously and vetted by the community, we can alleviate voting power pressure by automatically progressing any existing Security Council members who register for the new election.
We have implemented several new functions in the smart contract suite to facilitate the changes.
This new function allows for the cadence of elections to be updated in the future by simply calling a setter function. It will be implemented within the Nominee Election Governor contract. We plan to initialise it with the value of ‘12’ to represent 1 year and a future vote by the DAO can change its value. This would extend the March 2025 Security Council’s cohort duration from 1 year to 1.5 years and extend all future Security Council cohort durations (including the September 2025 Security Council cohort) from 1 year to 2 years. This would also result in all future elections being held each September.
This function already exists in the Nominee Election Governor contract. We plan to set a new value of ‘10’ to represent 0.1% of votable ARB and thus adjusting it from 0.2% to 0.1%.
This function will be modified to check if the address that is applying for the election is already an existing Security Council member from the cohort that is due to conclude. If the address is found, then this address will automatically be added as a candidate for the Member Election and go straight to the Compliance phase. The addContender function is implemented within the Nominee Election Governor contract.
This new function allows candidates to rotate their key prior to the completion of the compliance stage and before the Member Election phase. It will be implemented within the Nominee Election Governor contract. Additionally, there is a special condition, such that they can only rotate their keys at least 3 days before the Compliance Process ends. The Arbitrum Foundation will monitor for key rotations.
This new function allows a Security Council member to self-rotate their keys during their term. It will be implemented within the Security Council Manager contract. The new rotateMember function will replace the existing rotateMember function (which is redundant as it has the same functionality as the existing replaceMember function). The execution of a rotation will be subject to the full governance time lock of 18 days before they are registered into the Security Council multisigs on Arbitrum One, Ethereum, and Arbitrum Nova. The Arbitrum Foundation will monitor for key rotations.
Note, this code change has already been written, tested, and partially audited in March 2025, with an additional full audit in process.
We have put together proposed changes to the ArbitrumDAO Constitution in Section 3 and Section 4 to reflect these changes to the Security Council election process; as well as a minor correction in Section 2 to reflect current governance practices. All these proposed text changes can be found in the Changes to the ArbitrumDAO Constitution section of the proposal’s forum post.
Considering that the next Security Council election (for the September 2025 cohort), will commence in mid-September, this proposal would only go to an onchain vote after the respective election is complete. However, the Foundation wants to make the DAO, current Security Council members, and future Security Council candidates aware of the potential changes that might soon take place (if approved by the DAO), and will therefore aim to raise this to Snapshot before the September 2025 cohort’s election process starts.
If this proposal were to pass, it would retroactively apply to both the March 2025 and September 2025 cohorts, as well as to any future cohorts. This would also mean that the election following the September 2025 election would be held in September 2026, to replace the current March 2025 cohort. Those who applied for the recently elected March 2025 Security Council cohort, agreed to this hypothetical term extension in their declarations, while those who will apply to the forthcoming September 2025 Security Council cohort will need to agree to this hypothetical term extension in their declarations.
The following timeline outlines proposed milestones from initial discussions to full implementation. Adjustments may be made based on community feedback and DAO governance requirements.
August 20, 2025 (complete)→ AIP forum post outlining the proposed changes to the Security Council election process.
August 20, 2025 - September 2025 (ongoing)→ Full audit of proposed changes. Any further changes will be re-audited ahead of a potential Tally vote.
September 4, 2025 → Temperature check held on Snapshot.
November 2025 → Onchain Tally vote will commence following the September 2025 Security Council election.
As 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, each delegate may select any number of choices, and each selected choice will receive the delegate’s full voting power. As a reminder, if a delegate does not support any of the proposed changes, they should only select ‘None’ to ensure reliability of results.
This constitutional proposal focuses on updating the Security Council election process alongside the necessary changes to the ArbitrumDAO constitution.
We propose the following changes:
Increase cohort durations. Extend the Security Council cohort duration from 1 year to 2 years, therefore reducing election frequency from twice a year to once a year.
Reduce qualification thresholds. In the Nominee Selection phase, change the qualifying threshold from 0.2% to 0.1% of votable ARB.
Progress Security Council members. Allow any existing Security Council members who have re-applied to bypass the Nominee Selection phase and into the Member Election phase.
Security Council key rotation. Enable Security Council candidates to rotate their keys during the Compliance phase of the election and enable Security Council members to rotate their keys at any time during their term.
Update Constitution Text. All changes should be reflected in the ArbitrumDAO Constitution to ensure the implementation adheres to the text.
As these changes are independent of one another (apart from the corresponding text changes to the constitution), this temperature check will use ‘approval voting’ to enable delegates to express support for each individual change (with their full voting power going towards each choice they select).
This AIP aims to improve the effectiveness, efficiency, and practicality of the Security Council election process (for both candidates and delegates); while addressing the following pain points identified in recent cycles:
Frequent election cycles. Both voter and candidate fatigue from participating in the election every six months as a single election requires significant effort from all parties from advertising the election, getting candidates to nominate themselves, evaluating their candidacy, and ultimately picking them.
Qualification threshold increasing. A rising qualification threshold has reduced the number of candidates who can progress to the Member Election phase simply due to the unavailability of active voting power.
Non-Emergency Actions to Rotate Keys. Candidates, and existing Security Council members, cannot rotate their keys after they have registered for the election. This has led to the Security Council performing non-emergency actions to update their keys after the election has concluded. Not only is there increased risk due to suboptimal setups, but the additional burden on the Security Council is unnecessary.
Renominating Security Council members. It requires active voting power to progress an existing Security Council member to the Member Election phase. As they were already elected previously and vetted by the community, we can alleviate voting power pressure by automatically progressing any existing Security Council members who register for the new election.
We have implemented several new functions in the smart contract suite to facilitate the changes.
This new function allows for the cadence of elections to be updated in the future by simply calling a setter function. It will be implemented within the Nominee Election Governor contract. We plan to initialise it with the value of ‘12’ to represent 1 year and a future vote by the DAO can change its value. This would extend the March 2025 Security Council’s cohort duration from 1 year to 1.5 years and extend all future Security Council cohort durations (including the September 2025 Security Council cohort) from 1 year to 2 years. This would also result in all future elections being held each September.
This function already exists in the Nominee Election Governor contract. We plan to set a new value of ‘10’ to represent 0.1% of votable ARB and thus adjusting it from 0.2% to 0.1%.
This function will be modified to check if the address that is applying for the election is already an existing Security Council member from the cohort that is due to conclude. If the address is found, then this address will automatically be added as a candidate for the Member Election and go straight to the Compliance phase. The addContender function is implemented within the Nominee Election Governor contract.
This new function allows candidates to rotate their key prior to the completion of the compliance stage and before the Member Election phase. It will be implemented within the Nominee Election Governor contract. Additionally, there is a special condition, such that they can only rotate their keys at least 3 days before the Compliance Process ends. The Arbitrum Foundation will monitor for key rotations.
This new function allows a Security Council member to self-rotate their keys during their term. It will be implemented within the Security Council Manager contract. The new rotateMember function will replace the existing rotateMember function (which is redundant as it has the same functionality as the existing replaceMember function). The execution of a rotation will be subject to the full governance time lock of 18 days before they are registered into the Security Council multisigs on Arbitrum One, Ethereum, and Arbitrum Nova. The Arbitrum Foundation will monitor for key rotations.
Note, this code change has already been written, tested, and partially audited in March 2025, with an additional full audit in process.
We have put together proposed changes to the ArbitrumDAO Constitution in Section 3 and Section 4 to reflect these changes to the Security Council election process; as well as a minor correction in Section 2 to reflect current governance practices. All these proposed text changes can be found in the Changes to the ArbitrumDAO Constitution section of the proposal’s forum post.
Considering that the next Security Council election (for the September 2025 cohort), will commence in mid-September, this proposal would only go to an onchain vote after the respective election is complete. However, the Foundation wants to make the DAO, current Security Council members, and future Security Council candidates aware of the potential changes that might soon take place (if approved by the DAO), and will therefore aim to raise this to Snapshot before the September 2025 cohort’s election process starts.
If this proposal were to pass, it would retroactively apply to both the March 2025 and September 2025 cohorts, as well as to any future cohorts. This would also mean that the election following the September 2025 election would be held in September 2026, to replace the current March 2025 cohort. Those who applied for the recently elected March 2025 Security Council cohort, agreed to this hypothetical term extension in their declarations, while those who will apply to the forthcoming September 2025 Security Council cohort will need to agree to this hypothetical term extension in their declarations.
The following timeline outlines proposed milestones from initial discussions to full implementation. Adjustments may be made based on community feedback and DAO governance requirements.
August 20, 2025 (complete)→ AIP forum post outlining the proposed changes to the Security Council election process.
August 20, 2025 - September 2025 (ongoing)→ Full audit of proposed changes. Any further changes will be re-audited ahead of a potential Tally vote.
September 4, 2025 → Temperature check held on Snapshot.
November 2025 → Onchain Tally vote will commence following the September 2025 Security Council election.
As 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, each delegate may select any number of choices, and each selected choice will receive the delegate’s full voting power. As a reminder, if a delegate does not support any of the proposed changes, they should only select ‘None’ to ensure reliability of results.
https://forum.arbitrum.foundation/t/constitutional-aip-security-council-election-process-improvements/29848/52?u=bob-rossi
https://forum.arbitrum.foundation/t/constitutional-aip-security-council-election-process-improvements/29848/50
don't agree with any measure that makes it easy to become a Security Council member or entrenches their power for longer, and I think candidates should apply with a safe enough key from the get go.
https://forum.arbitrum.foundation/t/constitutional-aip-security-council-election-process-improvements/29848/49
https://forum.arbitrum.foundation/t/constitutional-aip-security-council-election-process-improvements/29848/48?u=blockworksresearch
https://forum.arbitrum.foundation/t/constitutional-aip-security-council-election-process-improvements/29848/47
https://forum.arbitrum.foundation/t/tekr0x-eth-delegate-communication-thread/24804/22?u=tekr0x.eth
https://forum.arbitrum.foundation/t/constitutional-aip-security-council-election-process-improvements/29848/43?u=euphoria
Reasoning here: https://forum.arbitrum.foundation/t/constitutional-aip-security-council-election-process-improvements/29848/39?u=pennblockchain
https://forum.arbitrum.foundation/t/constitutional-aip-security-council-election-process-improvements/29848/52?u=bob-rossi
https://forum.arbitrum.foundation/t/constitutional-aip-security-council-election-process-improvements/29848/50
don't agree with any measure that makes it easy to become a Security Council member or entrenches their power for longer, and I think candidates should apply with a safe enough key from the get go.
https://forum.arbitrum.foundation/t/constitutional-aip-security-council-election-process-improvements/29848/49
https://forum.arbitrum.foundation/t/constitutional-aip-security-council-election-process-improvements/29848/48?u=blockworksresearch
https://forum.arbitrum.foundation/t/constitutional-aip-security-council-election-process-improvements/29848/47
https://forum.arbitrum.foundation/t/tekr0x-eth-delegate-communication-thread/24804/22?u=tekr0x.eth
https://forum.arbitrum.foundation/t/constitutional-aip-security-council-election-process-improvements/29848/43?u=euphoria
Reasoning here: https://forum.arbitrum.foundation/t/constitutional-aip-security-council-election-process-improvements/29848/39?u=pennblockchain
If this proposal passes after the March 2026 election and before the September 2026 election, the results would retroactively apply to the September 2025 and March 2026 cohorts, and future elections would be held every March (i.e. the March 2027 election would replace the September 2025 cohort and the March 2028 election would replace the March 2026 cohort).
We will be postponing the on-chain vote for this proposal till after the currently scheduled March 2026 Security Council election.
If this proposal passes after the March 2026 election and before the September 2026 election, the results would retroactively apply to the September 2025 and March 2026 cohorts, and future elections would be held every March (i.e. the March 2027 election would replace the September 2025 cohort and the March 2028 election would replace the March 2026 cohort).
We will be postponing the on-chain vote for this proposal till after the currently scheduled March 2026 Security Council election.
Given our experience in governance, our relationship with Arbitrum, and our previous application to the Security Council, we see these changes as a good step to reduce operational overhead by introducing longer terms, encourage participation, and strengthen security (Key Rotation just for members).
On one hand, we don’t see a major issue with having only a few candidates, since most bring strong alignment with Arbitrum and the skills needed for the role. Furthermore, the clarifications shared here should help drive broader participation.
Given our experience in governance, our relationship with Arbitrum, and our previous application to the Security Council, we see these changes as a good step to reduce operational overhead by introducing longer terms, encourage participation, and strengthen security (Key Rotation just for members).
On one hand, we don’t see a major issue with having only a few candidates, since most bring strong alignment with Arbitrum and the skills needed for the role. Furthermore, the clarifications shared here should help drive broader participation.
On the other hand, based on our experience, we see two main factors that discourage candidates from stepping forward:
Thanks for bringing this discussion forward and for the dedication on all sides to reach the best possible solution.
How does extending the Security Council cohort duration from 1 year to 2 years impact voter engagement and accountability
How will the extended Security Council term impact voter engagement and continuity in decision-making
Given our experience in governance, our relationship with Arbitrum, and our previous application to the Security Council, we see these changes as a good step to reduce operational overhead by introducing longer terms, encourage participation, and strengthen security (Key Rotation just for members).
On one hand, we don’t see a major issue with having only a few candidates, since most bring strong alignment with Arbitrum and the skills needed for the role. Furthermore, the clarifications shared here should help drive broader participation.
Given our experience in governance, our relationship with Arbitrum, and our previous application to the Security Council, we see these changes as a good step to reduce operational overhead by introducing longer terms, encourage participation, and strengthen security (Key Rotation just for members).
On one hand, we don’t see a major issue with having only a few candidates, since most bring strong alignment with Arbitrum and the skills needed for the role. Furthermore, the clarifications shared here should help drive broader participation.
On the other hand, based on our experience, we see two main factors that discourage candidates from stepping forward:
Thanks for bringing this discussion forward and for the dedication on all sides to reach the best possible solution.
How does extending the Security Council cohort duration from 1 year to 2 years impact voter engagement and accountability
How will the extended Security Council term impact voter engagement and continuity in decision-making
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Key rotation is obviously critical for members of a 9/12 multisig. People can lose access to their keys in a multitude of ways so having an easy way to fix this issue is a no brainer… but allowing candidates to rotate extra keys feels like unnecessary overhead. Just let members rotate their own keys, nothing more. It is a 9 of 12 multisig, one wrong key for a day doesn’t break it. Adding complexity for the small period where a candidate needs to change their key seems like needless scope that adds needless risks of bugs or exploits. I would suggest to keep it simple, only members can rotate out of their keys, the function for candidates is needless overhead as we can use the fact that members can rotate to address the issue.
Key rotation is obviously critical for members of a 9/12 multisig. People can lose access to their keys in a multitude of ways so having an easy way to fix this issue is a no brainer… but allowing candidates to rotate extra keys feels like unnecessary overhead. Just let members rotate their own keys, nothing more. It is a 9 of 12 multisig, one wrong key for a day doesn’t break it. Adding complexity for the small period where a candidate needs to change their key seems like needless scope that adds needless risks of bugs or exploits. I would suggest to keep it simple, only members can rotate out of their keys, the function for candidates is needless overhead as we can use the fact that members can rotate to address the issue.
Security Council key rotation - we agree to this change overall, but as explained during the call, we believe this requires some offchain procedure that would ensure (and inform the community) that those key rotations are indeed planned. Right now, the proposal only states that the Foundation will monitor those changes, but does not require public announcements of those changes.
In the current election process, once a candidate applies, the Foundation verifies that the address used to apply is a fresh one (i.e., an address that has not interacted with other smart contracts, and generated using a new or reset hardware wallet).
If the proposed upgrade allowing candidates to rotate their keys during the election cycle is approved, the Foundation would notify candidates in cases where a sub-optimal setup is identified. The candidate could then submit a key rotation at least three days before the Compliance Process ends. This would give the Foundation time to veto the rotation if the new keys fail to meet compliance requirements. In practice, this change would only introduce a minor additional responsibility for the Foundation, which we are comfortable with.
@Griff and @Saurabh — could you elaborate on the risks you foresee at this stage? From our perspective, enabling candidates to rotate their keys before potentially becoming members actually mitigates risk, as it helps ensure that no elected member operates, even temporarily, with a sub-optimal setup.
Regarding GMX’s suggestion that candidates should demonstrate ownership of their keys — this requirement already exists. During the Contender Submission phase, candidates must sign a message using the same keys they use to apply. However, proving ownership alone does not guarantee that the keys are suitable for Security Council use. For instance, there have been multiple cases where candidates applied using hot wallets (e.g., MetaMask-generated addresses), which is not suitable for this role.
Finally, on L2Beat’s suggestion that the DAO should be informed of planned key rotations — we fully agree. As noted previously, any candidate or member requesting a key rotation should announce it on the forum once the rotation has been submitted on-chain. Since all key rotation attempts will be actively monitored by both the AF and the Security Council, either party will be able to confirm on the forum whether such rotations were expected, conducted according to standard procedures, and whether they should be approved or vetoed.
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.
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.
In the current system, a rotation takes effect only if 9 of the 12 Security Council members co-sign it. Under the proposed change, any single Security Council member could initiate a rotation independently. However, the Security Council would retain the authority to veto the rotation within the 18-day timelock if it fails to comply with standard procedures (e.g., prior notification to the Security Council and AF, successful completion of compliance checks, etc.).
As mentioned, we will be hosting the Security Council Election Process Improvements proposal: Open Discussion #2 on Friday, October 10th at 13:00 UTC.
The call will be used to further discuss the proposed changes, before deciding how to proceed with the Tally proposal.
Key rotation is obviously critical for members of a 9/12 multisig. People can lose access to their keys in a multitude of ways so having an easy way to fix this issue is a no brainer… but allowing candidates to rotate extra keys feels like unnecessary overhead. Just let members rotate their own keys, nothing more. It is a 9 of 12 multisig, one wrong key for a day doesn’t break it. Adding complexity for the small period where a candidate needs to change their key seems like needless scope that adds needless risks of bugs or exploits. I would suggest to keep it simple, only members can rotate out of their keys, the function for candidates is needless overhead as we can use the fact that members can rotate to address the issue.
Key rotation is obviously critical for members of a 9/12 multisig. People can lose access to their keys in a multitude of ways so having an easy way to fix this issue is a no brainer… but allowing candidates to rotate extra keys feels like unnecessary overhead. Just let members rotate their own keys, nothing more. It is a 9 of 12 multisig, one wrong key for a day doesn’t break it. Adding complexity for the small period where a candidate needs to change their key seems like needless scope that adds needless risks of bugs or exploits. I would suggest to keep it simple, only members can rotate out of their keys, the function for candidates is needless overhead as we can use the fact that members can rotate to address the issue.
Security Council key rotation - we agree to this change overall, but as explained during the call, we believe this requires some offchain procedure that would ensure (and inform the community) that those key rotations are indeed planned. Right now, the proposal only states that the Foundation will monitor those changes, but does not require public announcements of those changes.
In the current election process, once a candidate applies, the Foundation verifies that the address used to apply is a fresh one (i.e., an address that has not interacted with other smart contracts, and generated using a new or reset hardware wallet).
If the proposed upgrade allowing candidates to rotate their keys during the election cycle is approved, the Foundation would notify candidates in cases where a sub-optimal setup is identified. The candidate could then submit a key rotation at least three days before the Compliance Process ends. This would give the Foundation time to veto the rotation if the new keys fail to meet compliance requirements. In practice, this change would only introduce a minor additional responsibility for the Foundation, which we are comfortable with.
@Griff and @Saurabh — could you elaborate on the risks you foresee at this stage? From our perspective, enabling candidates to rotate their keys before potentially becoming members actually mitigates risk, as it helps ensure that no elected member operates, even temporarily, with a sub-optimal setup.
Regarding GMX’s suggestion that candidates should demonstrate ownership of their keys — this requirement already exists. During the Contender Submission phase, candidates must sign a message using the same keys they use to apply. However, proving ownership alone does not guarantee that the keys are suitable for Security Council use. For instance, there have been multiple cases where candidates applied using hot wallets (e.g., MetaMask-generated addresses), which is not suitable for this role.
Finally, on L2Beat’s suggestion that the DAO should be informed of planned key rotations — we fully agree. As noted previously, any candidate or member requesting a key rotation should announce it on the forum once the rotation has been submitted on-chain. Since all key rotation attempts will be actively monitored by both the AF and the Security Council, either party will be able to confirm on the forum whether such rotations were expected, conducted according to standard procedures, and whether they should be approved or vetoed.
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.
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.
In the current system, a rotation takes effect only if 9 of the 12 Security Council members co-sign it. Under the proposed change, any single Security Council member could initiate a rotation independently. However, the Security Council would retain the authority to veto the rotation within the 18-day timelock if it fails to comply with standard procedures (e.g., prior notification to the Security Council and AF, successful completion of compliance checks, etc.).
As mentioned, we will be hosting the Security Council Election Process Improvements proposal: Open Discussion #2 on Friday, October 10th at 13:00 UTC.
The call will be used to further discuss the proposed changes, before deciding how to proceed with the Tally proposal.
As a member of the March 2025 Security Council cohort I am not keen on extending my mandate.
The change can be designed to trigger so that elected members have 2 year mandates after the March 2025 cohort finishes their term.
The temperature check for this proposal has concluded. Thank you to those who voted.
The results illustrate that there is strong support for:
The results reflect less support for:
The temperature check for this proposal has concluded. Thank you to those who voted.
The results illustrate that there is strong support for:
The results reflect less support for:
We will soon be hosting additional governance calls to further discuss these (latter) changes, before deciding how to proceed with the Tally proposal.
As a member of the March 2025 Security Council cohort I am not keen on extending my mandate.
The change can be designed to trigger so that elected members have 2 year mandates after the March 2025 cohort finishes their term.
The temperature check for this proposal has concluded. Thank you to those who voted.
The results illustrate that there is strong support for:
The results reflect less support for:
The temperature check for this proposal has concluded. Thank you to those who voted.
The results illustrate that there is strong support for:
The results reflect less support for:
We will soon be hosting additional governance calls to further discuss these (latter) changes, before deciding how to proceed with the Tally proposal.
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.
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:
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).
Thank you for your reply.
Please see https://forum.arbitrum.foundation/t/discussion-improving-the-arbitrum-security-council/29907, where we further address these points.
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.
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:
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).
Thank you for your reply.
Please see https://forum.arbitrum.foundation/t/discussion-improving-the-arbitrum-security-council/29907, where we further address these points.
Such a debate began after the OpenZeppelin’s ARDC report on Arbitrum Security Council Recommendations, but hasn’t been picked up by the Foundation or any other AAEs. The report outlined many recommendations for improving the election process. We don’t see this work referenced anywhere in this proposal. During both open and private discussions following the report, many other ideas were surfaced that deserve at least thoughtful consideration.
Such a debate began after the OpenZeppelin’s ARDC report on Arbitrum Security Council Recommendations, but hasn’t been picked up by the Foundation or any other AAEs. The report outlined many recommendations for improving the election process. We don’t see this work referenced anywhere in this proposal. During both open and private discussions following the report, many other ideas were surfaced that deserve at least thoughtful consideration.
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.
Of course, that’s their perspective — and that’s fine — but it shows that more candidates could have qualified, and didn’t, for reasons unrelated to either the threshold or the amount of active VP available.
On key management, we appreciate that the proposal introduces clearer provisions for key rotation and even emergency actions. This is a meaningful step forward in strengthening operational security. We would suggest adding one more safeguard: a periodic liveness check for Security Council keys. In Optimism, Council members are required to perform an on-chain action roughly every three months to demonstrate they still control their keys, and failure to do so may result in removal.
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.
setCadence: any change takes effect only for the next cohort with at least 90 days of notice, and never extends a cohort already in its final 90 days.
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).
Such a debate began after the OpenZeppelin’s ARDC report on Arbitrum Security Council Recommendations, but hasn’t been picked up by the Foundation or any other AAEs. The report outlined many recommendations for improving the election process. We don’t see this work referenced anywhere in this proposal. During both open and private discussions following the report, many other ideas were surfaced that deserve at least thoughtful consideration.
Such a debate began after the OpenZeppelin’s ARDC report on Arbitrum Security Council Recommendations, but hasn’t been picked up by the Foundation or any other AAEs. The report outlined many recommendations for improving the election process. We don’t see this work referenced anywhere in this proposal. During both open and private discussions following the report, many other ideas were surfaced that deserve at least thoughtful consideration.
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.
Of course, that’s their perspective — and that’s fine — but it shows that more candidates could have qualified, and didn’t, for reasons unrelated to either the threshold or the amount of active VP available.
On key management, we appreciate that the proposal introduces clearer provisions for key rotation and even emergency actions. This is a meaningful step forward in strengthening operational security. We would suggest adding one more safeguard: a periodic liveness check for Security Council keys. In Optimism, Council members are required to perform an on-chain action roughly every three months to demonstrate they still control their keys, and failure to do so may result in removal.
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.
setCadence: any change takes effect only for the next cohort with at least 90 days of notice, and never extends a cohort already in its final 90 days.
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).
Of course, that’s their perspective — and that’s fine — but it shows that more candidates could have qualified, and didn’t, for reasons unrelated to either the threshold or the amount of active VP available.
Looking at past elections:
We went from 44 to 22 candidates in a single year. In 2025, the average VP used in Constitutional proposals was 234M ARB, and 201M in non-constitutional ones. In the last Member Election Phase (March 2025), turnout reached 63.47% of delegated votes — meaning 231,118,431 ARB participated.
Theoretically, if the same level of participation applied to the Nomination Phase with a threshold of around 9.1M ARB (0.2%), up to 25 candidates could have qualified. If the threshold is reduced to 0.1%, this number doubles to 50.
This figure is even higher than the number of applicants in the last process. So, while we understand the motivation (increased votable supply makes it harder for some candidates to qualify), we believe the root problem goes beyond that technicality.
Therefore, it might be worth exploring how to improve both the quantity and the quality of candidates.
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.
setCadence: any change takes effect only for the next cohort with at least 90 days of notice, and never extends a cohort already in its final 90 days.
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).
If we go that route, it would help to either link the candidate declarations where applicants agreed to a potential extension, or collect an explicit confirmation from seated members before enactment. Publishing a three year election calendar alongside this AIP would make planning easier for candidates and delegates.
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.
It’s a small detail, but aligning on one term would avoid confusion down the line and make it easier for everyone to understand exactly which metric applies.
We agree with the point made by @0xDonPepe / @Euphoria / @paulofonseca about clarifying the terminology between “Circulating” and “Votable” ARB. We have modified the proposal text accordingly.
I believe they should go through the Nomination Phase as all the other candidates.
I believe they should go through the Nomination Phase as all the other candidates.
Thank you to @jameskbh / @0xDonPepe / @JoJo / @euphoria / @tane / @seedgov for the comments on allowing existing Security Council members who have re-applied to bypass the Nominee Selection phase and move directly into the Member Election phase.
We understand the rationale that incumbency alone should not substitute for fresh endorsement from the DAO. However, as suggested by Jojo and Seedgov, the AF would not be able to veto re-applying candidates at the compliance stage solely on the basis of their historical performance, as performance is unrelated to compliance. Furthermore, 0xDonPepe and Euphoria’s suggestions to implement an even lower threshold for re-applying Security Council members to progress from the Nominee Selection phase would add too much complexity to the existing Security Council election process. Therefore, considering that this proposal also suggests reducing the election cadence and lowering the qualification threshold to progress from the Nominee Selection phase, we are open to omitting this change from the proposal so that re-applying Security Council members would still need to go through the Nominee Selection phase alongside all other candidates.
In light of this feedback, we will add two separate “FOR” voting options in this proposal’s temperature check to determine whether or not to include this change.
The recording of ‘Security Council Election Process Improvements proposal: Open Discussion’ can be accessed here: https://drive.google.com/file/d/1iTxtCSHP2n0zZ8D-4wZyu6uL1Fn8mdF9/view
Thank you for the feedback so far. We will be hosting a governance call to discuss this proposal on Wednesday, August 27th at 15:00 UTC. See details below:
Security Council Election Process Improvements proposal: Open Discussion Wednesday, August 27 · 3:00 – 4:00pm Time zone: UTC Google Meet joining info Video call link: https://meet.google.com/fnu-dvdw-rai
Of course, that’s their perspective — and that’s fine — but it shows that more candidates could have qualified, and didn’t, for reasons unrelated to either the threshold or the amount of active VP available.
Looking at past elections:
We went from 44 to 22 candidates in a single year. In 2025, the average VP used in Constitutional proposals was 234M ARB, and 201M in non-constitutional ones. In the last Member Election Phase (March 2025), turnout reached 63.47% of delegated votes — meaning 231,118,431 ARB participated.
Theoretically, if the same level of participation applied to the Nomination Phase with a threshold of around 9.1M ARB (0.2%), up to 25 candidates could have qualified. If the threshold is reduced to 0.1%, this number doubles to 50.
This figure is even higher than the number of applicants in the last process. So, while we understand the motivation (increased votable supply makes it harder for some candidates to qualify), we believe the root problem goes beyond that technicality.
Therefore, it might be worth exploring how to improve both the quantity and the quality of candidates.
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.
setCadence: any change takes effect only for the next cohort with at least 90 days of notice, and never extends a cohort already in its final 90 days.
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).
If we go that route, it would help to either link the candidate declarations where applicants agreed to a potential extension, or collect an explicit confirmation from seated members before enactment. Publishing a three year election calendar alongside this AIP would make planning easier for candidates and delegates.
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.
It’s a small detail, but aligning on one term would avoid confusion down the line and make it easier for everyone to understand exactly which metric applies.
We agree with the point made by @0xDonPepe / @Euphoria / @paulofonseca about clarifying the terminology between “Circulating” and “Votable” ARB. We have modified the proposal text accordingly.
I believe they should go through the Nomination Phase as all the other candidates.
I believe they should go through the Nomination Phase as all the other candidates.
Thank you to @jameskbh / @0xDonPepe / @JoJo / @euphoria / @tane / @seedgov for the comments on allowing existing Security Council members who have re-applied to bypass the Nominee Selection phase and move directly into the Member Election phase.
We understand the rationale that incumbency alone should not substitute for fresh endorsement from the DAO. However, as suggested by Jojo and Seedgov, the AF would not be able to veto re-applying candidates at the compliance stage solely on the basis of their historical performance, as performance is unrelated to compliance. Furthermore, 0xDonPepe and Euphoria’s suggestions to implement an even lower threshold for re-applying Security Council members to progress from the Nominee Selection phase would add too much complexity to the existing Security Council election process. Therefore, considering that this proposal also suggests reducing the election cadence and lowering the qualification threshold to progress from the Nominee Selection phase, we are open to omitting this change from the proposal so that re-applying Security Council members would still need to go through the Nominee Selection phase alongside all other candidates.
In light of this feedback, we will add two separate “FOR” voting options in this proposal’s temperature check to determine whether or not to include this change.
The recording of ‘Security Council Election Process Improvements proposal: Open Discussion’ can be accessed here: https://drive.google.com/file/d/1iTxtCSHP2n0zZ8D-4wZyu6uL1Fn8mdF9/view
Thank you for the feedback so far. We will be hosting a governance call to discuss this proposal on Wednesday, August 27th at 15:00 UTC. See details below:
Security Council Election Process Improvements proposal: Open Discussion Wednesday, August 27 · 3:00 – 4:00pm Time zone: UTC Google Meet joining info Video call link: https://meet.google.com/fnu-dvdw-rai
What will the updated timeline be? I.e., after the proposal passes (assuming it does) will future annual elections be held in March or September? Also, which cohorts will the results retroactively apply to (September 2025, March 2026, etc)?
Also,
Also,
^ has this been resolved / are there other members of the March 2025 cohort that don’t want to extend their term? If so, since having to add new members in March will require DAO participation anyway, an alternative would be to hold an election in March for a 1.5 year term and then continue with elections in September / two year terms after that (fwiw I believe this can be implemented without tech debt).
(Snapshot took place prior to my being a delegate; not sure if more progress has been made since the discussion here fizzled / where things stand at the moment, but will post my views now regardless):
I support all of the proposed changes.
Rationales:
(Snapshot took place prior to my being a delegate; not sure if more progress has been made since the discussion here fizzled / where things stand at the moment, but will post my views now regardless):
I support all of the proposed changes.
Rationales:
** Increase cohort durations:** Elections are too frequent; campaigns for the next one starting just months just after the last one effectuates feels weird, most seem to agree on this.
Reduce qualification thresholds: I’m fairly neutral on this one as there doesn’t seem to be a shortage of candidates (let alone strong candidates), but would vote in favor.
Progress Current Security Council members to Bypass Nominee Selection Phase:
Strongly in favor. In my view, the purpose of a Nominee selection phase is to provide a filter for the next phase so that votes are only cast for candidates with a reasonably-proven chance of winning. I.e., without this phase, there would be a wide (if not infinite) pool of candidates in the Member Selection phase, about whose viability voters may have no information; early voters could be effectively wasting their votes.
When a candidate is already a member of the Security Council, they have already demonstrated that they pass this filter (and then some). Requiring them to meet the Nominee Selection threshold again only siphons votes away from other potential candidates. If, for whatever reason, the candidate has significantly less support than in the last election, bypassing nomineee selection in no way guarantees them a win or even really helps them, since making it into the top 6 during Member Selection requires far more than the .2% required for Nominee Selection. (And, no be sure, if the candidate has, in their time in the Security Council, committed some serious infraction, then they should be removed before the election regardless). Thus, this is in my opinion a strict improvement.
Security Council candidate key rotation: Support, as it reduces operational overhead of key rotations without changing the security model. If anything, potentially reducing the time that a compromised key is active is a security improvement.
Security Council member key rotation: Support for a more sensible candidate registration process, providing that the foundation require proof of ownership of the new key (as they’ve said they would).
voting None on this offchain vote because I don't agree with any measure that makes it easy to become a Security Council member or entrenches their power for longer, and I think candidates should apply with a safe enough key from the get go.
What will the updated timeline be? I.e., after the proposal passes (assuming it does) will future annual elections be held in March or September? Also, which cohorts will the results retroactively apply to (September 2025, March 2026, etc)?
Also,
Also,
^ has this been resolved / are there other members of the March 2025 cohort that don’t want to extend their term? If so, since having to add new members in March will require DAO participation anyway, an alternative would be to hold an election in March for a 1.5 year term and then continue with elections in September / two year terms after that (fwiw I believe this can be implemented without tech debt).
(Snapshot took place prior to my being a delegate; not sure if more progress has been made since the discussion here fizzled / where things stand at the moment, but will post my views now regardless):
I support all of the proposed changes.
Rationales:
(Snapshot took place prior to my being a delegate; not sure if more progress has been made since the discussion here fizzled / where things stand at the moment, but will post my views now regardless):
I support all of the proposed changes.
Rationales:
** Increase cohort durations:** Elections are too frequent; campaigns for the next one starting just months just after the last one effectuates feels weird, most seem to agree on this.
Reduce qualification thresholds: I’m fairly neutral on this one as there doesn’t seem to be a shortage of candidates (let alone strong candidates), but would vote in favor.
Progress Current Security Council members to Bypass Nominee Selection Phase:
Strongly in favor. In my view, the purpose of a Nominee selection phase is to provide a filter for the next phase so that votes are only cast for candidates with a reasonably-proven chance of winning. I.e., without this phase, there would be a wide (if not infinite) pool of candidates in the Member Selection phase, about whose viability voters may have no information; early voters could be effectively wasting their votes.
When a candidate is already a member of the Security Council, they have already demonstrated that they pass this filter (and then some). Requiring them to meet the Nominee Selection threshold again only siphons votes away from other potential candidates. If, for whatever reason, the candidate has significantly less support than in the last election, bypassing nomineee selection in no way guarantees them a win or even really helps them, since making it into the top 6 during Member Selection requires far more than the .2% required for Nominee Selection. (And, no be sure, if the candidate has, in their time in the Security Council, committed some serious infraction, then they should be removed before the election regardless). Thus, this is in my opinion a strict improvement.
Security Council candidate key rotation: Support, as it reduces operational overhead of key rotations without changing the security model. If anything, potentially reducing the time that a compromised key is active is a security improvement.
Security Council member key rotation: Support for a more sensible candidate registration process, providing that the foundation require proof of ownership of the new key (as they’ve said they would).
voting None on this offchain vote because I don't agree with any measure that makes it easy to become a Security Council member or entrenches their power for longer, and I think candidates should apply with a safe enough key from the get go.
@Griff and @Saurabh — could you elaborate on the risks you foresee at this stage? From our perspective, enabling candidates to rotate their keys before potentially becoming members actually mitigates risk, as it helps ensure that no elected member operates, even temporarily, with a sub-optimal setup.
@Griff and @Saurabh — could you elaborate on the risks you foresee at this stage? From our perspective, enabling candidates to rotate their keys before potentially becoming members actually mitigates risk, as it helps ensure that no elected member operates, even temporarily, with a sub-optimal setup.
It's debatable which is a bigger security risk, adding extra code to the most critical smart contracts we have, or having someone control 9 out of 12 multisig with a hot wallet for a few days.
They can always rotate their keys the day after their term starts if needed. Accounting for the timelock and 3 week delay for key rotation, the math changes a little bit from my initial argument, but that was my concern. To me, it feels like unnecessary code changes.
The following reflects the views of GMX’s Governance Committee, and is based on the combined research, evaluation, consensus, and ideation of various committee members.
Committee discussion:
The following reflects the views of GMX’s Governance Committee, and is based on the combined research, evaluation, consensus, and ideation of various committee members.
Committee discussion:
Cadence: Clarified that with two staggered cohorts, elections currently occur twice per year. Extending terms to 2 years consolidates to one annual election. The committee supports this change for efficiency and reduced voter fatigue.
Threshold: Support lowering to 0.1% to broaden the candidate pool and reduce whale-gating.
Member key rotation: Strong support as it improves operational resilience.
Candidate key rotation: Concerns raised about unnecessary risk — candidates should demonstrate key control prior to nomination.
Incumbent bypass: Opposition due to risk of inflating the ballot and weakening accountability. The new 2-year cadence already reduces burden without needing auto-progression.
Final position (GMX response):
✅ Support: Annual cadence, lower threshold, member key rotation.
❌ Oppose: Candidate key rotation, incumbent bypass.
Rationale (for Snapshot comment):
GMX Governance Committee supports the reforms that strengthen the Security Council process, namely moving to annual elections, lowering the nomination threshold to 0.1%, and enabling mid-term key rotation for members.
We oppose candidate key rotation (as it introduces unnecessary risk) and incumbent auto-bypass (which weakens accountability and inflates ballots). On balance, these targeted changes improve efficiency and resilience while preserving healthy competition in election
Regarding the point "Allow members to bypass Nominee" there is the following question:
If someone thinks that if we make two stages, it will filter out spam, but in fact this just adds work to the delegates, who could also choose the winners at the first stage
I voted for all other options, except this one.
I want to reinforce the question I asked in the GRC regarding the support each option had, with the concrete example from the vote:
Bypass Nomination Phase (the least voted option) had fewer than half of the votes of Increase cohort durations, clearly showing a lack of support.
I voted for all other options, except this one.
I want to reinforce the question I asked in the GRC regarding the support each option had, with the concrete example from the vote:
Bypass Nomination Phase (the least voted option) had fewer than half of the votes of Increase cohort durations, clearly showing a lack of support.
What will be the method AF will use to apply this feedback? This was not clear in the vote.
I have voted as follows:
gm, I voted and supported most of the options.
The part I’m not on board with is skipping the Nominee phase for existing members. With the threshold already lowered, I believe the process is already simple enough. Letting everyone start from the Nominee phase keeps things clearer and puts everyone on the same field.
gm, I voted and supported most of the options.
The part I’m not on board with is skipping the Nominee phase for existing members. With the threshold already lowered, I believe the process is already simple enough. Letting everyone start from the Nominee phase keeps things clearer and puts everyone on the same field.
That said, I agree with L2 that a broader review of the Security Council mechanisms will be necessary in the long run.
Thanks
Thanks for the proposal.
The only thing I cannot understand is why and how the reduction of the threshold will help. For now, I will not vote for it, although I will continue to observe the discussion and pay close attention.
@Griff and @Saurabh — could you elaborate on the risks you foresee at this stage? From our perspective, enabling candidates to rotate their keys before potentially becoming members actually mitigates risk, as it helps ensure that no elected member operates, even temporarily, with a sub-optimal setup.
@Griff and @Saurabh — could you elaborate on the risks you foresee at this stage? From our perspective, enabling candidates to rotate their keys before potentially becoming members actually mitigates risk, as it helps ensure that no elected member operates, even temporarily, with a sub-optimal setup.
It's debatable which is a bigger security risk, adding extra code to the most critical smart contracts we have, or having someone control 9 out of 12 multisig with a hot wallet for a few days.
They can always rotate their keys the day after their term starts if needed. Accounting for the timelock and 3 week delay for key rotation, the math changes a little bit from my initial argument, but that was my concern. To me, it feels like unnecessary code changes.
The following reflects the views of GMX’s Governance Committee, and is based on the combined research, evaluation, consensus, and ideation of various committee members.
Committee discussion:
The following reflects the views of GMX’s Governance Committee, and is based on the combined research, evaluation, consensus, and ideation of various committee members.
Committee discussion:
Cadence: Clarified that with two staggered cohorts, elections currently occur twice per year. Extending terms to 2 years consolidates to one annual election. The committee supports this change for efficiency and reduced voter fatigue.
Threshold: Support lowering to 0.1% to broaden the candidate pool and reduce whale-gating.
Member key rotation: Strong support as it improves operational resilience.
Candidate key rotation: Concerns raised about unnecessary risk — candidates should demonstrate key control prior to nomination.
Incumbent bypass: Opposition due to risk of inflating the ballot and weakening accountability. The new 2-year cadence already reduces burden without needing auto-progression.
Final position (GMX response):
✅ Support: Annual cadence, lower threshold, member key rotation.
❌ Oppose: Candidate key rotation, incumbent bypass.
Rationale (for Snapshot comment):
GMX Governance Committee supports the reforms that strengthen the Security Council process, namely moving to annual elections, lowering the nomination threshold to 0.1%, and enabling mid-term key rotation for members.
We oppose candidate key rotation (as it introduces unnecessary risk) and incumbent auto-bypass (which weakens accountability and inflates ballots). On balance, these targeted changes improve efficiency and resilience while preserving healthy competition in election
Regarding the point "Allow members to bypass Nominee" there is the following question:
If someone thinks that if we make two stages, it will filter out spam, but in fact this just adds work to the delegates, who could also choose the winners at the first stage
I voted for all other options, except this one.
I want to reinforce the question I asked in the GRC regarding the support each option had, with the concrete example from the vote:
Bypass Nomination Phase (the least voted option) had fewer than half of the votes of Increase cohort durations, clearly showing a lack of support.
I voted for all other options, except this one.
I want to reinforce the question I asked in the GRC regarding the support each option had, with the concrete example from the vote:
Bypass Nomination Phase (the least voted option) had fewer than half of the votes of Increase cohort durations, clearly showing a lack of support.
What will be the method AF will use to apply this feedback? This was not clear in the vote.
I have voted as follows:
gm, I voted and supported most of the options.
The part I’m not on board with is skipping the Nominee phase for existing members. With the threshold already lowered, I believe the process is already simple enough. Letting everyone start from the Nominee phase keeps things clearer and puts everyone on the same field.
gm, I voted and supported most of the options.
The part I’m not on board with is skipping the Nominee phase for existing members. With the threshold already lowered, I believe the process is already simple enough. Letting everyone start from the Nominee phase keeps things clearer and puts everyone on the same field.
That said, I agree with L2 that a broader review of the Security Council mechanisms will be necessary in the long run.
Thanks
Thanks for the proposal.
The only thing I cannot understand is why and how the reduction of the threshold will help. For now, I will not vote for it, although I will continue to observe the discussion and pay close attention.
well... it depends on how we define "strong support"
for example, I don't agree that 120.5M ARB casted on the Reduce qualification threshold option should be considered "strong support" because at the time of this offchain vote, the 3% quorum was 139,253,514 ARB and this option didn't reach that, so I wouldn't consider it to have had "strong support" on this vote.
it's cleaner to consider that the options that should move forward are the ones that had more than 3% quorum of support, aka:
Regarding the point "Allow members to bypass Nominee" there is the following question:
If someone thinks that if we make two stages, it will filter out spam, but in fact this just adds work to the delegates, who could also choose the winners at the first stage
In this regard, it is unclear why this parameter scored less than 50%, because this stage is not needed at all
We have voted "none".
As we mentioned above and as I also explained during the dedicated call, we believe this proposal is not well prepared, and we should go back to the drawing board and discuss it further. Below are our thoughts and comments on individual issues raised in the Snapshot:
We have voted "none".
As we mentioned above and as I also explained during the dedicated call, we believe this proposal is not well prepared, and we should go back to the drawing board and discuss it further. Below are our thoughts and comments on individual issues raised in the Snapshot:
We will soon join the discussion in the other thread.
Blockworks Advisory supports this proposal on Snapshot.
Cohort duration increases, lowering the qualifying threshold, the addition of the security council bypass, etc, all seem to bring a very tangible benefit to the election process.
We supported nearly the full set of proposed changes in this snapshot, with the exception of “Allow members to bypass Nominee.”
Extending cohort terms and lowering entry thresholds both feel like sensible steps to keep governance stable while also opening the door to a wider pool of candidates. Likewise, adding rotation mechanisms strengthens accountability and reduces key-person risk, an important safeguard as the Council matures.
We supported nearly the full set of proposed changes in this snapshot, with the exception of “Allow members to bypass Nominee.”
Extending cohort terms and lowering entry thresholds both feel like sensible steps to keep governance stable while also opening the door to a wider pool of candidates. Likewise, adding rotation mechanisms strengthens accountability and reduces key-person risk, an important safeguard as the Council matures.
Where we differ is on skipping the Nominee stage for sitting members. Even experienced members benefit from re-establishing their mandate with the DAO, and the suggested shortcut doesn’t strike us as necessary.
As a current member of the security council and an active delegate that I haven’t experienced fatigue with yearly votes. That said, I don’t see any issue with moving to a 2 year term as long as people can resign. I also don’t mind a 1 year term, it really doesn’t matter, but I mildly support 2 year terms as it reduces operational overhead.
As a current member of the security council and an active delegate that I haven’t experienced fatigue with yearly votes. That said, I don’t see any issue with moving to a 2 year term as long as people can resign. I also don’t mind a 1 year term, it really doesn’t matter, but I mildly support 2 year terms as it reduces operational overhead.
I don’t support reducing qualifications. I don’t see why we would make th upfront filter weaker. Requiring 0.2% of the votable ARB supply, (around 8 to 9 million ARB), feels right. If someone can’t reach that in the nomination phase, they won’t make it as a member anyway. With 6 seats and around ~200 million ARB on average participating, it should be fine...
Presented another way, looking at the current top delegates:
With a 0.2% voting threshold, Entropy can make almost 3 full nominations, L2beat and LobbyFi can make almost 2 and Gauntlet can make 1.5 nominations
If we halve the requirement, then Entropy can make almost 6 full nominations, L2beat and LobbyFi can make almost 4 and Gauntlet can make 3 nominations...
Which sounds better? To me it's an obvious choice, so i don't support this change.
As a current member I am naturally biased, but allowing sitting members to bypass the nomination phase makes sense to me. If you’re already in, and you want to do it again, you’ll almost certainly clear nominations anyway, so forcing it just wastes time. I’m confident no current member would have trouble passing the filter, so why make them jump through the hoops?
Key rotation is obviously critical for members of a 9/12 multisig. People can lose access to their keys in a multitude of ways so having an easy way to fix this issue is a no brainer... but allowing candidates to rotate extra keys feels like unnecessary overhead. Just let members rotate their own keys, nothing more. It is a 9 of 12 multisig, one wrong key for a day doesn’t break it. Adding complexity for the small period where a candidate needs to change their key seems like needless scope that adds needless risks of bugs or exploits. I would suggest to keep it simple, only members can rotate out of their keys, the function for candidates is needless overhead as we can use the fact that members can rotate to address the issue.
We voted for the proposals within this snapshot, except for "Allow members to bypass Nominee".
In our view, extending cohort duration and lowering thresholds will both strengthen governance continuity and allow more diverse candidates to participate. The introduction of key rotation mechanisms is another critical step forward, as it reduces operational risks and ensures Council members remain responsive.
We voted for the proposals within this snapshot, except for "Allow members to bypass Nominee".
In our view, extending cohort duration and lowering thresholds will both strengthen governance continuity and allow more diverse candidates to participate. The introduction of key rotation mechanisms is another critical step forward, as it reduces operational risks and ensures Council members remain responsive.
However, we remain unconvinced by the bypass of the Nominee phase for current members. It is better to seek renewed legitimacy from the DAO even for existing members, and the proposed change didn't seem necessary.
Overall, the package of changes represents meaningful progress, and we are glad to support it in nearly all respects.
The following reflects the views of the Lampros DAO governance team, composed of Chain_L (@Blueweb) and @Euphoria, based on our combined research, analysis, and ideation.
Thank you, @Arbitrum, for the clarifications on the questions.
The following reflects the views of the Lampros DAO governance team, composed of Chain_L (@Blueweb) and @Euphoria, based on our combined research, analysis, and ideation.
Thank you, @Arbitrum, for the clarifications on the questions.
We are voting FOR the following options in the Snapshot voting: Increase cohort duration, Reduce qualification threshold, Allow candidates to rotate keys, and Allow members to rotate keys.
One election per year with two-year terms reduces fatigue and gives more time for real review. Lowering the nominee threshold to 0.1% of Votable Tokens should widen the pool while keeping standards in the final round. Letting candidates rotate keys during the compliance stage fixes a practical risk before voting starts. Letting members rotate keys during their term, with the 18-day governance path, replaces ad-hoc non-emergency actions with a clean and visible process. Forum notes on submitted rotations and short follow-ups after execution provide enough visibility without exposing sensitive procedures.
We are not voting in favour of: Allow members to bypass Nominee Selection. We appreciate the intent to reduce overhead for incumbents. Our preference is to keep a small, fresh signal of community support each cycle, so we are not supporting the full bypass as we mentioned before. A light continuity check and a short-term summary from incumbents would keep accountability in place while preserving most of the simplicity you’re aiming for. If the final on-chain version reflects that balance, we are comfortable moving to support.
I’m supportive of all the proposed changes outlined in this AIP. These improvements strike the right balance between reducing operational burden and increasing inclusivity, while keeping the process secure and aligned with the DAO’s needs.
I’ll be voting in favor of all the changes.
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.
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.
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
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
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.
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.
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.
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.
well... it depends on how we define "strong support"
for example, I don't agree that 120.5M ARB casted on the Reduce qualification threshold option should be considered "strong support" because at the time of this offchain vote, the 3% quorum was 139,253,514 ARB and this option didn't reach that, so I wouldn't consider it to have had "strong support" on this vote.
it's cleaner to consider that the options that should move forward are the ones that had more than 3% quorum of support, aka:
Regarding the point "Allow members to bypass Nominee" there is the following question:
If someone thinks that if we make two stages, it will filter out spam, but in fact this just adds work to the delegates, who could also choose the winners at the first stage
In this regard, it is unclear why this parameter scored less than 50%, because this stage is not needed at all
We have voted "none".
As we mentioned above and as I also explained during the dedicated call, we believe this proposal is not well prepared, and we should go back to the drawing board and discuss it further. Below are our thoughts and comments on individual issues raised in the Snapshot:
We have voted "none".
As we mentioned above and as I also explained during the dedicated call, we believe this proposal is not well prepared, and we should go back to the drawing board and discuss it further. Below are our thoughts and comments on individual issues raised in the Snapshot:
We will soon join the discussion in the other thread.
Blockworks Advisory supports this proposal on Snapshot.
Cohort duration increases, lowering the qualifying threshold, the addition of the security council bypass, etc, all seem to bring a very tangible benefit to the election process.
We supported nearly the full set of proposed changes in this snapshot, with the exception of “Allow members to bypass Nominee.”
Extending cohort terms and lowering entry thresholds both feel like sensible steps to keep governance stable while also opening the door to a wider pool of candidates. Likewise, adding rotation mechanisms strengthens accountability and reduces key-person risk, an important safeguard as the Council matures.
We supported nearly the full set of proposed changes in this snapshot, with the exception of “Allow members to bypass Nominee.”
Extending cohort terms and lowering entry thresholds both feel like sensible steps to keep governance stable while also opening the door to a wider pool of candidates. Likewise, adding rotation mechanisms strengthens accountability and reduces key-person risk, an important safeguard as the Council matures.
Where we differ is on skipping the Nominee stage for sitting members. Even experienced members benefit from re-establishing their mandate with the DAO, and the suggested shortcut doesn’t strike us as necessary.
As a current member of the security council and an active delegate that I haven’t experienced fatigue with yearly votes. That said, I don’t see any issue with moving to a 2 year term as long as people can resign. I also don’t mind a 1 year term, it really doesn’t matter, but I mildly support 2 year terms as it reduces operational overhead.
As a current member of the security council and an active delegate that I haven’t experienced fatigue with yearly votes. That said, I don’t see any issue with moving to a 2 year term as long as people can resign. I also don’t mind a 1 year term, it really doesn’t matter, but I mildly support 2 year terms as it reduces operational overhead.
I don’t support reducing qualifications. I don’t see why we would make th upfront filter weaker. Requiring 0.2% of the votable ARB supply, (around 8 to 9 million ARB), feels right. If someone can’t reach that in the nomination phase, they won’t make it as a member anyway. With 6 seats and around ~200 million ARB on average participating, it should be fine...
Presented another way, looking at the current top delegates:
With a 0.2% voting threshold, Entropy can make almost 3 full nominations, L2beat and LobbyFi can make almost 2 and Gauntlet can make 1.5 nominations
If we halve the requirement, then Entropy can make almost 6 full nominations, L2beat and LobbyFi can make almost 4 and Gauntlet can make 3 nominations...
Which sounds better? To me it's an obvious choice, so i don't support this change.
As a current member I am naturally biased, but allowing sitting members to bypass the nomination phase makes sense to me. If you’re already in, and you want to do it again, you’ll almost certainly clear nominations anyway, so forcing it just wastes time. I’m confident no current member would have trouble passing the filter, so why make them jump through the hoops?
Key rotation is obviously critical for members of a 9/12 multisig. People can lose access to their keys in a multitude of ways so having an easy way to fix this issue is a no brainer... but allowing candidates to rotate extra keys feels like unnecessary overhead. Just let members rotate their own keys, nothing more. It is a 9 of 12 multisig, one wrong key for a day doesn’t break it. Adding complexity for the small period where a candidate needs to change their key seems like needless scope that adds needless risks of bugs or exploits. I would suggest to keep it simple, only members can rotate out of their keys, the function for candidates is needless overhead as we can use the fact that members can rotate to address the issue.
We voted for the proposals within this snapshot, except for "Allow members to bypass Nominee".
In our view, extending cohort duration and lowering thresholds will both strengthen governance continuity and allow more diverse candidates to participate. The introduction of key rotation mechanisms is another critical step forward, as it reduces operational risks and ensures Council members remain responsive.
We voted for the proposals within this snapshot, except for "Allow members to bypass Nominee".
In our view, extending cohort duration and lowering thresholds will both strengthen governance continuity and allow more diverse candidates to participate. The introduction of key rotation mechanisms is another critical step forward, as it reduces operational risks and ensures Council members remain responsive.
However, we remain unconvinced by the bypass of the Nominee phase for current members. It is better to seek renewed legitimacy from the DAO even for existing members, and the proposed change didn't seem necessary.
Overall, the package of changes represents meaningful progress, and we are glad to support it in nearly all respects.
The following reflects the views of the Lampros DAO governance team, composed of Chain_L (@Blueweb) and @Euphoria, based on our combined research, analysis, and ideation.
Thank you, @Arbitrum, for the clarifications on the questions.
The following reflects the views of the Lampros DAO governance team, composed of Chain_L (@Blueweb) and @Euphoria, based on our combined research, analysis, and ideation.
Thank you, @Arbitrum, for the clarifications on the questions.
We are voting FOR the following options in the Snapshot voting: Increase cohort duration, Reduce qualification threshold, Allow candidates to rotate keys, and Allow members to rotate keys.
One election per year with two-year terms reduces fatigue and gives more time for real review. Lowering the nominee threshold to 0.1% of Votable Tokens should widen the pool while keeping standards in the final round. Letting candidates rotate keys during the compliance stage fixes a practical risk before voting starts. Letting members rotate keys during their term, with the 18-day governance path, replaces ad-hoc non-emergency actions with a clean and visible process. Forum notes on submitted rotations and short follow-ups after execution provide enough visibility without exposing sensitive procedures.
We are not voting in favour of: Allow members to bypass Nominee Selection. We appreciate the intent to reduce overhead for incumbents. Our preference is to keep a small, fresh signal of community support each cycle, so we are not supporting the full bypass as we mentioned before. A light continuity check and a short-term summary from incumbents would keep accountability in place while preserving most of the simplicity you’re aiming for. If the final on-chain version reflects that balance, we are comfortable moving to support.
I’m supportive of all the proposed changes outlined in this AIP. These improvements strike the right balance between reducing operational burden and increasing inclusivity, while keeping the process secure and aligned with the DAO’s needs.
I’ll be voting in favor of all the changes.
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.
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.
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
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
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.
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.
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.
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.
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.
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.
The Arbitrum Foundation created a forum post explaining their view on the attributes of good Security Council candidates. However, this document has not been updated in two years. Some questions that could be answered include whether we prefer entities or individuals, what kind of entities we prefer (if we do), and how they should be represented. There are also technical questions like should we allow for multisigs, or do we require EOAs, and why?
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.
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.
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.
as they would not impact the constitution nor the Security Council election smart contracts and therefore would not need to be voted on.
as they would not impact the constitution nor the Security Council election smart contracts and therefore would not need to be voted on.
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.
Thanks for putting this proposal forward and to everyone who joined the recent call. We felt the most constructive way to contribute here is by reflecting on the meta-level themes raised in discussion.
These themes include candidate sourcing and outreach, vetting, member compensation, and the recommendations from OpenZeppelin’s report on the Security Council as part of their ARDC research.
Thanks for putting this proposal forward and to everyone who joined the recent call. We felt the most constructive way to contribute here is by reflecting on the meta-level themes raised in discussion.
These themes include candidate sourcing and outreach, vetting, member compensation, and the recommendations from OpenZeppelin’s report on the Security Council as part of their ARDC research.
From the call, it was clear that these issues are top of mind for delegates and are driving much of the feedback. This is where a rift seems to emerge: the Foundation’s intent with this proposal is to make technical updates to the Nominee Election Governor and Security Council Manager smart contracts, while delegates are raising broader governance concerns that go beyond the scope of this AIP. The @Arbitrum Foundation has clarified that these meta-level questions warrant a separate discussion.
While we generally agree with the proposed changes to the security council elections, our view is that this proposal should not move forward to a vote until those broader questions are addressed. Smart contracts are ultimately just codified expressions of social agreements, and without alignment on the underlying social layer, it’s difficult to see technical changes gaining full legitimacy.
As a constructive next step, we support starting a new forum thread for the meta-level discussion, allowing these broader questions to be addressed before advancing any technical changes.
We agree with some changes to the Security Council suggested:
However, we have concerns about other suggested changes:
We agree with some changes to the Security Council suggested:
However, we have concerns about other suggested changes:
To the extent that there are more than six contenders, each eligible contender must be supported by pledged votes representing at least 0.1% of all Votable Tokens.
Removing the requirement for members who have already served on the council to participate again—without going through the Nominee Selection process—gives others more opportunity to be elected in the next phase, but makes it easier for former members to be elected. In our opinion, they should go through the same election process as the others.
We understand the change in the rotation of Security Council keys to reduce operational friction in its management. However, while key management is simplified, additional security mechanisms must be put in place to maintain the same level of protection. Facilitating the change of keys after the election of SC members could become a vector of attack on a Council that is so sensitive to Arbitrum.
as I said in the call today, I would like to remind that we did pay @openzeppelin to conduct research into our security council, and to come up with a few recommendations. They’ve provided an output report that can be seen here: https://forum.arbitrum.foundation/t/arbitrum-security-council-recommendations/28850
Specifically, they’ve looked into the duration of the Security Council term and their conclusion was:
But: passing that phase means, here, to get that 0.1% of total votable supply, that potentially can’t go to other candidates
I had the same thought in my head - I completely agree with this argument and vote to give other candidates a better chance to get on the list of candidates
Do we solely expect promising candidates to apply on their own initiative, or should the DAO perform some sort of outreach to potentially promising candidates and facilitate their application? How should this be handled?
The following reflects the views of L2BEAT’s governance team, composed of @krst, @Sinkas, and @Manugotsuka, and it’s based on their combined research, fact-checking, and ideation.
We’d like to thank the Arbitrum Foundation for starting the conversation, as the Security Council is of critical importance to Arbitrum, and any changes that will materially improve its election process should be brought forward.
gm, in support of the 3 proposed changes that aim to alleviate some operational frictions both for the DAO and the council.
Hi @Arbitrum. Thank you for this proposal.
We won’t go into detail on every change, as we agree with most of them.
Regarding the ongoing discussion on the following item:
Hi @Arbitrum. Thank you for this proposal.
We won’t go into detail on every change, as we agree with most of them.
Regarding the ongoing discussion on the following item:
We agree with the perspective provided by JoJo — allowing current Security Council members to skip the nomination phase actually opens up space for other strong candidates to receive votes:
In any case, if a member is not performing as expected — or if the DAO simply no longer wants them on the Security Council — it can just choose not to vote for that candidate in the Member Election Phase. It’s also important to remember that there is a compliance review stage in which the Foundation can remove candidates due to conflicts of interest. We suggest that this continue to be enforced in cases where a Security Council member is being advanced directly into the Member Election Phase.
Now, we’d like to elaborate further on the proposal to reduce the threshold from 0.2% to 0.1%.
The rationale behind the growing ARB supply justifying a lower threshold makes sense at first glance. However, it’s worth noting that L2BEAT did not use their voting power during the last Nomination Phase because, from their perspective, “all the candidates they wanted to see qualify for the elections phase had already done so.” So they chose not to vote for the remaining nine candidates.
Of course, that’s their perspective — and that’s fine — but it shows that more candidates could have qualified, and didn’t, for reasons unrelated to either the threshold or the amount of active VP available.
Looking at past elections:
Sept 2023: 24 qualified out of 41 candidates (4.7M threshold)
March 2024: 22 qualified out of 44 candidates (5.4M threshold)
Sept 2024: 13 qualified out of 39 candidates (8.6M threshold)
March 2025: 13 qualified out of 22 candidates (8.5M threshold)
We went from 44 to 22 candidates in a single year. In 2025, the average VP used in Constitutional proposals was 234M ARB, and 201M in non-constitutional ones. In the last Member Election Phase (March 2025), turnout reached 63.47% of delegated votes — meaning 231,118,431 ARB participated.
Theoretically, if the same level of participation applied to the Nomination Phase with a threshold of around 9.1M ARB (0.2%), up to 25 candidates could have qualified. If the threshold is reduced to 0.1%, this number doubles to 50.
This figure is even higher than the number of applicants in the last process. So, while we understand the motivation (increased votable supply makes it harder for some candidates to qualify), we believe the root problem goes beyond that technicality.
Therefore, it might be worth exploring how to improve both the quantity and the quality of candidates.
Some questions we’re asking ourselves:
How can we attract more high-quality candidates?
Should the DAO or AF take a more proactive approach to sourcing them?
Why has the number of candidates dropped by 50%?
Is the position attractive enough (financially or otherwise) to draw the kind of candidates we want?
We believe that before approving any threshold change (again — we’re not opposed to it, we just think there’s a deeper issue), we need to address these questions. Otherwise, we may be lowering the bar for candidates who lack the quality or reputation to serve on the Security Council.
As mentioned earlier, during the last Nomination Phase, the DAO had enough VP to allow all 22 candidates to qualify — but delegates chose not to use it. This is empirical evidence that there wasn’t enough trust in the qualifications of the remaining nine candidates.
Let’s imagine a scenario where we again have 22 candidates, 6 of whom are already members of the Security Council and automatically advance. That leaves 16 candidates for the Nomination Phase. At a 0.1% threshold (4.55M ARB approximately), it would take only ~73M ARB for all of them to qualify.
Now consider two possibilities:
Delegates use their VP (up to 73M ARB), and everyone qualifies — regardless of merit. (Note: any remaining delegates would not be able to vote afterward.)
Delegates don’t use their VP or fall short of the 73M threshold, which limits the final pool to the 6 incumbents + a few who passed nomination. (This is a likely outcome — in fact, it already happened. This was one of the reasons why voting in the Nomination Phase was not made mandatory to qualify for the DIP.)
Neither outcome seems to improve the process. From our perspective, the problem is not the amount of VP available but rather the shrinking number of viable options for delegates to choose from.
For this reason, we encourage the DAO to initiate a discussion on how to enhance the candidate pool for future elections — regardless of whether this specific initiative proceeds.
We are in favour of this proposal.
The Security Council has proven itself to be an important element of the DAO, helping to improve both the security and efficiency of critical operations. Now that we have seen the Council functioning effectively in practice for some time, we support the Arbitrum Foundation’s initiative to streamline the election process and strengthen its overall structure.
We are in favour of this proposal.
The Security Council has proven itself to be an important element of the DAO, helping to improve both the security and efficiency of critical operations. Now that we have seen the Council functioning effectively in practice for some time, we support the Arbitrum Foundation’s initiative to streamline the election process and strengthen its overall structure.
We believe the proposed changes are valuable and well-considered, and we support their implementation without modification.
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.
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.
The Arbitrum Foundation created a forum post explaining their view on the attributes of good Security Council candidates. However, this document has not been updated in two years. Some questions that could be answered include whether we prefer entities or individuals, what kind of entities we prefer (if we do), and how they should be represented. There are also technical questions like should we allow for multisigs, or do we require EOAs, and why?
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.
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.
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.
as they would not impact the constitution nor the Security Council election smart contracts and therefore would not need to be voted on.
as they would not impact the constitution nor the Security Council election smart contracts and therefore would not need to be voted on.
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.
Thanks for putting this proposal forward and to everyone who joined the recent call. We felt the most constructive way to contribute here is by reflecting on the meta-level themes raised in discussion.
These themes include candidate sourcing and outreach, vetting, member compensation, and the recommendations from OpenZeppelin’s report on the Security Council as part of their ARDC research.
Thanks for putting this proposal forward and to everyone who joined the recent call. We felt the most constructive way to contribute here is by reflecting on the meta-level themes raised in discussion.
These themes include candidate sourcing and outreach, vetting, member compensation, and the recommendations from OpenZeppelin’s report on the Security Council as part of their ARDC research.
From the call, it was clear that these issues are top of mind for delegates and are driving much of the feedback. This is where a rift seems to emerge: the Foundation’s intent with this proposal is to make technical updates to the Nominee Election Governor and Security Council Manager smart contracts, while delegates are raising broader governance concerns that go beyond the scope of this AIP. The @Arbitrum Foundation has clarified that these meta-level questions warrant a separate discussion.
While we generally agree with the proposed changes to the security council elections, our view is that this proposal should not move forward to a vote until those broader questions are addressed. Smart contracts are ultimately just codified expressions of social agreements, and without alignment on the underlying social layer, it’s difficult to see technical changes gaining full legitimacy.
As a constructive next step, we support starting a new forum thread for the meta-level discussion, allowing these broader questions to be addressed before advancing any technical changes.
We agree with some changes to the Security Council suggested:
However, we have concerns about other suggested changes:
We agree with some changes to the Security Council suggested:
However, we have concerns about other suggested changes:
To the extent that there are more than six contenders, each eligible contender must be supported by pledged votes representing at least 0.1% of all Votable Tokens.
Removing the requirement for members who have already served on the council to participate again—without going through the Nominee Selection process—gives others more opportunity to be elected in the next phase, but makes it easier for former members to be elected. In our opinion, they should go through the same election process as the others.
We understand the change in the rotation of Security Council keys to reduce operational friction in its management. However, while key management is simplified, additional security mechanisms must be put in place to maintain the same level of protection. Facilitating the change of keys after the election of SC members could become a vector of attack on a Council that is so sensitive to Arbitrum.
as I said in the call today, I would like to remind that we did pay @openzeppelin to conduct research into our security council, and to come up with a few recommendations. They’ve provided an output report that can be seen here: https://forum.arbitrum.foundation/t/arbitrum-security-council-recommendations/28850
Specifically, they’ve looked into the duration of the Security Council term and their conclusion was:
But: passing that phase means, here, to get that 0.1% of total votable supply, that potentially can’t go to other candidates
I had the same thought in my head - I completely agree with this argument and vote to give other candidates a better chance to get on the list of candidates
Do we solely expect promising candidates to apply on their own initiative, or should the DAO perform some sort of outreach to potentially promising candidates and facilitate their application? How should this be handled?
The following reflects the views of L2BEAT’s governance team, composed of @krst, @Sinkas, and @Manugotsuka, and it’s based on their combined research, fact-checking, and ideation.
We’d like to thank the Arbitrum Foundation for starting the conversation, as the Security Council is of critical importance to Arbitrum, and any changes that will materially improve its election process should be brought forward.
gm, in support of the 3 proposed changes that aim to alleviate some operational frictions both for the DAO and the council.
Hi @Arbitrum. Thank you for this proposal.
We won’t go into detail on every change, as we agree with most of them.
Regarding the ongoing discussion on the following item:
Hi @Arbitrum. Thank you for this proposal.
We won’t go into detail on every change, as we agree with most of them.
Regarding the ongoing discussion on the following item:
We agree with the perspective provided by JoJo — allowing current Security Council members to skip the nomination phase actually opens up space for other strong candidates to receive votes:
In any case, if a member is not performing as expected — or if the DAO simply no longer wants them on the Security Council — it can just choose not to vote for that candidate in the Member Election Phase. It’s also important to remember that there is a compliance review stage in which the Foundation can remove candidates due to conflicts of interest. We suggest that this continue to be enforced in cases where a Security Council member is being advanced directly into the Member Election Phase.
Now, we’d like to elaborate further on the proposal to reduce the threshold from 0.2% to 0.1%.
The rationale behind the growing ARB supply justifying a lower threshold makes sense at first glance. However, it’s worth noting that L2BEAT did not use their voting power during the last Nomination Phase because, from their perspective, “all the candidates they wanted to see qualify for the elections phase had already done so.” So they chose not to vote for the remaining nine candidates.
Of course, that’s their perspective — and that’s fine — but it shows that more candidates could have qualified, and didn’t, for reasons unrelated to either the threshold or the amount of active VP available.
Looking at past elections:
Sept 2023: 24 qualified out of 41 candidates (4.7M threshold)
March 2024: 22 qualified out of 44 candidates (5.4M threshold)
Sept 2024: 13 qualified out of 39 candidates (8.6M threshold)
March 2025: 13 qualified out of 22 candidates (8.5M threshold)
We went from 44 to 22 candidates in a single year. In 2025, the average VP used in Constitutional proposals was 234M ARB, and 201M in non-constitutional ones. In the last Member Election Phase (March 2025), turnout reached 63.47% of delegated votes — meaning 231,118,431 ARB participated.
Theoretically, if the same level of participation applied to the Nomination Phase with a threshold of around 9.1M ARB (0.2%), up to 25 candidates could have qualified. If the threshold is reduced to 0.1%, this number doubles to 50.
This figure is even higher than the number of applicants in the last process. So, while we understand the motivation (increased votable supply makes it harder for some candidates to qualify), we believe the root problem goes beyond that technicality.
Therefore, it might be worth exploring how to improve both the quantity and the quality of candidates.
Some questions we’re asking ourselves:
How can we attract more high-quality candidates?
Should the DAO or AF take a more proactive approach to sourcing them?
Why has the number of candidates dropped by 50%?
Is the position attractive enough (financially or otherwise) to draw the kind of candidates we want?
We believe that before approving any threshold change (again — we’re not opposed to it, we just think there’s a deeper issue), we need to address these questions. Otherwise, we may be lowering the bar for candidates who lack the quality or reputation to serve on the Security Council.
As mentioned earlier, during the last Nomination Phase, the DAO had enough VP to allow all 22 candidates to qualify — but delegates chose not to use it. This is empirical evidence that there wasn’t enough trust in the qualifications of the remaining nine candidates.
Let’s imagine a scenario where we again have 22 candidates, 6 of whom are already members of the Security Council and automatically advance. That leaves 16 candidates for the Nomination Phase. At a 0.1% threshold (4.55M ARB approximately), it would take only ~73M ARB for all of them to qualify.
Now consider two possibilities:
Delegates use their VP (up to 73M ARB), and everyone qualifies — regardless of merit. (Note: any remaining delegates would not be able to vote afterward.)
Delegates don’t use their VP or fall short of the 73M threshold, which limits the final pool to the 6 incumbents + a few who passed nomination. (This is a likely outcome — in fact, it already happened. This was one of the reasons why voting in the Nomination Phase was not made mandatory to qualify for the DIP.)
Neither outcome seems to improve the process. From our perspective, the problem is not the amount of VP available but rather the shrinking number of viable options for delegates to choose from.
For this reason, we encourage the DAO to initiate a discussion on how to enhance the candidate pool for future elections — regardless of whether this specific initiative proceeds.
We are in favour of this proposal.
The Security Council has proven itself to be an important element of the DAO, helping to improve both the security and efficiency of critical operations. Now that we have seen the Council functioning effectively in practice for some time, we support the Arbitrum Foundation’s initiative to streamline the election process and strengthen its overall structure.
We are in favour of this proposal.
The Security Council has proven itself to be an important element of the DAO, helping to improve both the security and efficiency of critical operations. Now that we have seen the Council functioning effectively in practice for some time, we support the Arbitrum Foundation’s initiative to streamline the election process and strengthen its overall structure.
We believe the proposed changes are valuable and well-considered, and we support their implementation without modification.
as I said in the call today, I would like to remind that we did pay @openzeppelin to conduct research into our security council, and to come up with a few recommendations. They’ve provided an output report that can be seen here: https://forum.arbitrum.foundation/t/arbitrum-security-council-recommendations/28850
Specifically, they’ve looked into the duration of the Security Council term and their conclusion was:
Therefore, I don’t agree with longer cohort durations.
I also want to highlight that the primary recommendation on Open Zeppelin’s report was:
Therefore, and since this proposal doesn’t include anything of the sorts, I don’t agree with “adjusting the qualification thresholds” and neither with “progress security council members”.
Also, regarding the “security council key rotation”, as I also said in the call, I think it opens a new attack vector and also delegitimizes the results of the nomination and election phases since delegates would be voting on security council members with specific keys and then those keys could change way more easily. And since we’ve had issues with past security council members keys, in exactly this issue, as can be seen here, I also don’t agree with “security council key rotation”.
Do we solely expect promising candidates to apply on their own initiative, or should the DAO perform some sort of outreach to potentially promising candidates and facilitate their application? How should this be handled?
Would like to emphasize this point.
As of today, the DAO is "passive" in every aspect.
This is one of the big things that we need to change, in general. Not only in the security council. Otherwise we risk to slip into irrelevance.
The following reflects the views of L2BEAT’s governance team, composed of @krst, @Sinkas, and @Manugotsuka, and it’s based on their combined research, fact-checking, and ideation.
We’d like to thank the Arbitrum Foundation for starting the conversation, as the Security Council is of critical importance to Arbitrum, and any changes that will materially improve its election process should be brought forward.
While the proposed changes are welcome, and we are generally supportive of them, we believe that there is much more room for improvement. This proposal is a great opportunity to discuss other aspects of the election process and of the Security Council itself, and hopefully introduce some additional changes. If we are to go through a constitutional vote, it seems prudent to have a proper retrospective and debate in the DAO so as not to have to go through the process again for additional things in the future — things that could have been included already.
Such a debate began after the OpenZeppelin’s ARDC report on Arbitrum Security Council Recommendations, but hasn’t been picked up by the Foundation or any other AAEs. The report outlined many recommendations for improving the election process. We don’t see this work referenced anywhere in this proposal. During both open and private discussions following the report, many other ideas were surfaced that deserve at least thoughtful consideration.
For example, some of the things that are, in our opinion, unaddressed are:
The Arbitrum Foundation created a forum post explaining their view on the attributes of good Security Council candidates. However, this document has not been updated in two years. Some questions that could be answered include whether we prefer entities or individuals, what kind of entities we prefer (if we do), and how they should be represented. There are also technical questions like should we allow for multisigs, or do we require EOAs, and why?
How much effort should candidates put into their application to the Security Council? What kind of info should they share with the DAO? How can we make them more visible to delegates, enabling them to assess and decide more effectively? Should we rely on their pitching skills or should we provide some kind of independent assessment of the applications?
Do we solely expect promising candidates to apply on their own initiative, or should the DAO perform some sort of outreach to potentially promising candidates and facilitate their application? How should this be handled?
Aside from the election process itself, we could also take the opportunity to address some of the aspects of the SC’s operations.
Right now, the Security Council is being funded through the Arbitrum Foundation. Do we want to continue in this way, or should we consider alternatives? Should there be a budget for things besides compensation for the SC to use if needed (for example, to be able to fund additional tooling needed for Security Council)?
As an extension to the above, should the SC continue to rely on AF for operations, or should it potentially handle that independently?
Apart from the elections themselves, should the Security Council have a more active role in the DAO? If yes, what should that role be, and how would it work?
Instead of having 12 members with a horizontal structure, does it make sense to introduce a hierarchy and perhaps have a Security Council lead?
IIrc, we have only used it once, and right now there doesn’t seem to be any clear use case for it.
For example, the Constitution states:
The Security Council may also approve and implement routine software upgrades, routine maintenance and other parameter adjustments in a non-emergency setting…
But in practice, even routine and non-controversial upgrades go through the full governance process. Should we change the scope of the Security Council, or should the SC start executing on that mandate more?
Right now, there is no feedback loop between the DAO and Security Council, we have no tools to assess whether the past member was a good choice or not.
Overall, we think it’s pretty clear that there are many things to discuss and decide on relevant to the Security Council that extend beyond the changes proposed by the Arbitrum Foundation in the proposal above.
We believe that before the proposal moves to a vote, a Constitutional one nonetheless, we should have a proper open discussion on all of the above and more, especially if we are to have a Constitutional vote. We already have good precedent for such debates, as seen in the ones facilitated by us - the debate on incentive programs, consolidation of treasury management initiatives, and the SOSs.
We will not be supportive of the proposal in its current form if it moves to a vote without such a proper discussion.
gm, in support of the 3 proposed changes that aim to alleviate some operational frictions both for the DAO and the council.
This is a well paid position with minimal time commitments.
The most important qualities are:
The Ethereum ecosystem already has many individuals who fit this profile.
However, the lack of clarity around expected time commitments, both during the election phase (what a campaign should look like) and the operational phase, is discouraging people from applying.
With a focused awareness campaign and a clear outline of the operational responsibilities and time expectations, attracting strong candidates should be straightforward.
Thanks @Arbitrum for putting this proposal together. The motivation and rationale are well-founded, and we broadly agree with the direction, especially the term extension and the reduction of the qualification threshold. These changes should help reduce fatigue and expand participation.
One area we are less convinced by is the automatic bypass for incumbent Security Council members. While we understand the reasoning, we share some of the concerns already raised in this thread that incumbency alone should not substitute for fresh endorsement from the DAO.
Thanks @Arbitrum for putting this proposal together. The motivation and rationale are well-founded, and we broadly agree with the direction, especially the term extension and the reduction of the qualification threshold. These changes should help reduce fatigue and expand participation.
One area we are less convinced by is the automatic bypass for incumbent Security Council members. While we understand the reasoning, we share some of the concerns already raised in this thread that incumbency alone should not substitute for fresh endorsement from the DAO.
On key management, we appreciate that the proposal introduces clearer provisions for key rotation and even emergency actions. This is a meaningful step forward in strengthening operational security. We would suggest adding one more safeguard: a periodic liveness check for Security Council keys. In Optimism, Council members are required to perform an on-chain action roughly every three months to demonstrate they still control their keys, and failure to do so may result in removal.
Optimism Collective’s Governance Forum
Given the longer terms and the ability to rotate keys, introducing a similar mechanism in Arbitrum would ensure that Council members remain capable of acting when needed and prevent unnoticed key loss over time.
This kind of check would help maintain confidence that the Security Council is always ready to fulfill its responsibilities, especially as terms extend and operational continuity becomes more important.
Yeah, agree with this.
And Votable Tokens is the correct term in Arbitrum’s case, because it is calculated as: ~10B ARB that will ever exist minus the ~5.7B ARB that are currently delegated to the exclusion address.
So around 4.3B ARB of Votable Tokens.
So it’s not circulating ARB, it’s votable ARB, as in, tokens that are unlocked and not delegated to the exclusion address.
The following reflects the views of the Lampros DAO governance team, composed of Chain_L (@Blueweb) and @Euphoria, based on our combined research, analysis, and ideation.
Thanks for putting this together.
Extend the Security Council cohort duration from 1 year to 2 years
The following reflects the views of the Lampros DAO governance team, composed of Chain_L (@Blueweb) and @Euphoria, based on our combined research, analysis, and ideation.
Thanks for putting this together.
Extend the Security Council cohort duration from 1 year to 2 years
We support moving to one election per year because it should reduce fatigue and help delegates spend more time on actual evaluation. To protect predictability, could we add a simple rule to setCadence: any change takes effect only for the next cohort with at least 90 days of notice, and never extends a cohort already in its final 90 days.
would retroactively apply to both the March 2025 and September 2025 cohorts
Allow any existing Security Council members who have re-applied to bypass the Nominee Selection phase
As mentioned by @jameskbh, @0xDonPepe & @JoJo as well, we think competition should stay live each cycle. In the last election, 22 candidates registered and 13 reached the bar at 0.2% of Votable Tokens to advance, so the pipeline already looks healthy. And in the final round, voting power decayed over time to encourage early participation, which is a useful protection on its own. Instead of an auto-pass, a lighter continuity test could work: a small micro-threshold plus a minimum number of unique endorsers, and a short “term report” in the forum post covering attendance and incidents handled, so delegates can judge recent service. Also, the proposal mentions “0.1% of circulating ARB” while the Constitution uses Votable Tokens for thresholds and defines the vote-decay schedule. It would be clearer if the proposal, the code, and the docs all use the same term (Votable Tokens).
Enable Security Council candidates to rotate their keys during the Compliance phase
This new function allows a Security Council member to self-rotate their keys during their term.
This direction makes sense; we’ve had non-emergency rotations before, and a clearer path will reduce friction. Two asks to make this safer in practice. First, please publish a public feed of rotations as they happen, not just Foundation monitoring, and link it from the elections page. Second, add a simple emergency playbook: if a key is suspected of being compromised, place it in a “containment” state with no upgrade actions until the standard rotation completes, and publish a short incident note within 48 hours. It would also help if the compliance checklist required hardware-backed or threshold wallets and included an attestation template.
which can only be submitted by an address that can vote at least 500,000 of the Votable Tokens.
Lastly, the Constitution today says a Snapshot temperature check “can only be submitted by an address that can vote at least 0.01% of the Votable Tokens,” and the AIP proposes a fixed 500,000 ARB threshold. A fixed number can drift as supply and delegation change. If possible, please consider keeping it proportional with a floor and a cap, or document how and when the threshold will be reviewed so the bar stays fair over time.
Net, we’re supportive if these guardrails are added. They keep the spirit of your changes while tightening accountability and transparency for the DAO.
Thanks for the proposal. I think the changes are generally consistent with the changes we are seeing broadly in the DAO and DAO related councils, initiatives etc, specifically
In particular
Thanks for the proposal. I think the changes are generally consistent with the changes we are seeing broadly in the DAO and DAO related councils, initiatives etc, specifically
In particular
Would like to expand on last point, especially for answering @0xDonPepe and @jameskbh above. While I do see a scenario in which you want to put checks and balances, it is quite likely that any incumbent going again for nominee would pass that phase. But: passing that phase means, here, to get that 0.1% of total votable supply, that potentially can't go to other candidates. To say in other terms, if we have a low turnaround of voting in security elections (or a rising quorum which gets us to the same result), allowing incumbent already vetted to not have to go through that again means increasing the chance to have fresh names for the actual election.
I do see, tho, a situation in which an old incumbent could not be deemed suitable anymore due to new reasons. But I guess there is still the ability, from the Arbitrum Foundation, to cut a name from the final phase of election like it happened a few elections ago for the vp of security / security officer (can't remember the title sorry) of polygon, right? This should preserve us from the scenario in which an old incumbent has a free pass but is not suitable anymore for whatever reason written in the constitution.
Thanks for your proposal! It introduces several welcomed enhancements to the election process.
That being said, I have an issue with the following point
Progress Security Council members. Allow any existing Security Council members who have re-applied to bypass the Nominee Selection phase and into the Member Election phase.
Thanks for your proposal! It introduces several welcomed enhancements to the election process.
That being said, I have an issue with the following point
Progress Security Council members. Allow any existing Security Council members who have re-applied to bypass the Nominee Selection phase and into the Member Election phase.
The simple fact of a current member wanting to reapply shouldn't be equalized to a nomination from the DAO. Given that we are changing the election cadence, the support/reasoning to support given to them in the previous election may have change, and we can't assume it remains the same.
I believe they should go through the Nomination Phase as all the other candidates.
Overall, I’m supportive of this proposal, but with a few important tweaks.
My main concern (echoing the point raised by @jameskbh) is the auto-progress for incumbents. Simply re-applying shouldn’t be treated as equivalent to a fresh endorsement from the DAO. I suggest that incumbents only bypass the full 0.1% threshold if they either:
Overall, I’m supportive of this proposal, but with a few important tweaks.
My main concern (echoing the point raised by @jameskbh) is the auto-progress for incumbents. Simply re-applying shouldn’t be treated as equivalent to a fresh endorsement from the DAO. I suggest that incumbents only bypass the full 0.1% threshold if they either:
(a) meet a lighter micro-threshold (e.g., 0.05% + ≥3 unique endorsers with ≥50k ARB each), or
(b) there’s a shortage of candidates (e.g., fewer than 12 reach the 0.1% threshold).
This approach would preserve continuity while still ensuring competitiveness.
To further reduce whale-gating, I’d also recommend a simple pluralism guard: cap any single endorser’s contribution to ≤70**%** of a candidate’s qualifying total.
Finally, I’d suggest cleaning up the terminology between “circulating ARB” and “Votable Tokens.” Right now the Constitution uses Votable Tokens as the basis for thresholds, but the abstract of this proposal referenced circulating ARB:
Constitution: “During the Nominee Selection phase, a contender must be supported by pledged votes representing at least 0.2% of all Votable Tokens.”
Proposal: “…change the qualifying threshold from 0.2% to 0.1% of circulating ARB.”
It’s a small detail, but aligning on one term would avoid confusion down the line and make it easier for everyone to understand exactly which metric applies.
as I said in the call today, I would like to remind that we did pay @openzeppelin to conduct research into our security council, and to come up with a few recommendations. They’ve provided an output report that can be seen here: https://forum.arbitrum.foundation/t/arbitrum-security-council-recommendations/28850
Specifically, they’ve looked into the duration of the Security Council term and their conclusion was:
Therefore, I don’t agree with longer cohort durations.
I also want to highlight that the primary recommendation on Open Zeppelin’s report was:
Therefore, and since this proposal doesn’t include anything of the sorts, I don’t agree with “adjusting the qualification thresholds” and neither with “progress security council members”.
Also, regarding the “security council key rotation”, as I also said in the call, I think it opens a new attack vector and also delegitimizes the results of the nomination and election phases since delegates would be voting on security council members with specific keys and then those keys could change way more easily. And since we’ve had issues with past security council members keys, in exactly this issue, as can be seen here, I also don’t agree with “security council key rotation”.
Do we solely expect promising candidates to apply on their own initiative, or should the DAO perform some sort of outreach to potentially promising candidates and facilitate their application? How should this be handled?
Would like to emphasize this point.
As of today, the DAO is "passive" in every aspect.
This is one of the big things that we need to change, in general. Not only in the security council. Otherwise we risk to slip into irrelevance.
The following reflects the views of L2BEAT’s governance team, composed of @krst, @Sinkas, and @Manugotsuka, and it’s based on their combined research, fact-checking, and ideation.
We’d like to thank the Arbitrum Foundation for starting the conversation, as the Security Council is of critical importance to Arbitrum, and any changes that will materially improve its election process should be brought forward.
While the proposed changes are welcome, and we are generally supportive of them, we believe that there is much more room for improvement. This proposal is a great opportunity to discuss other aspects of the election process and of the Security Council itself, and hopefully introduce some additional changes. If we are to go through a constitutional vote, it seems prudent to have a proper retrospective and debate in the DAO so as not to have to go through the process again for additional things in the future — things that could have been included already.
Such a debate began after the OpenZeppelin’s ARDC report on Arbitrum Security Council Recommendations, but hasn’t been picked up by the Foundation or any other AAEs. The report outlined many recommendations for improving the election process. We don’t see this work referenced anywhere in this proposal. During both open and private discussions following the report, many other ideas were surfaced that deserve at least thoughtful consideration.
For example, some of the things that are, in our opinion, unaddressed are:
The Arbitrum Foundation created a forum post explaining their view on the attributes of good Security Council candidates. However, this document has not been updated in two years. Some questions that could be answered include whether we prefer entities or individuals, what kind of entities we prefer (if we do), and how they should be represented. There are also technical questions like should we allow for multisigs, or do we require EOAs, and why?
How much effort should candidates put into their application to the Security Council? What kind of info should they share with the DAO? How can we make them more visible to delegates, enabling them to assess and decide more effectively? Should we rely on their pitching skills or should we provide some kind of independent assessment of the applications?
Do we solely expect promising candidates to apply on their own initiative, or should the DAO perform some sort of outreach to potentially promising candidates and facilitate their application? How should this be handled?
Aside from the election process itself, we could also take the opportunity to address some of the aspects of the SC’s operations.
Right now, the Security Council is being funded through the Arbitrum Foundation. Do we want to continue in this way, or should we consider alternatives? Should there be a budget for things besides compensation for the SC to use if needed (for example, to be able to fund additional tooling needed for Security Council)?
As an extension to the above, should the SC continue to rely on AF for operations, or should it potentially handle that independently?
Apart from the elections themselves, should the Security Council have a more active role in the DAO? If yes, what should that role be, and how would it work?
Instead of having 12 members with a horizontal structure, does it make sense to introduce a hierarchy and perhaps have a Security Council lead?
IIrc, we have only used it once, and right now there doesn’t seem to be any clear use case for it.
For example, the Constitution states:
The Security Council may also approve and implement routine software upgrades, routine maintenance and other parameter adjustments in a non-emergency setting…
But in practice, even routine and non-controversial upgrades go through the full governance process. Should we change the scope of the Security Council, or should the SC start executing on that mandate more?
Right now, there is no feedback loop between the DAO and Security Council, we have no tools to assess whether the past member was a good choice or not.
Overall, we think it’s pretty clear that there are many things to discuss and decide on relevant to the Security Council that extend beyond the changes proposed by the Arbitrum Foundation in the proposal above.
We believe that before the proposal moves to a vote, a Constitutional one nonetheless, we should have a proper open discussion on all of the above and more, especially if we are to have a Constitutional vote. We already have good precedent for such debates, as seen in the ones facilitated by us - the debate on incentive programs, consolidation of treasury management initiatives, and the SOSs.
We will not be supportive of the proposal in its current form if it moves to a vote without such a proper discussion.
gm, in support of the 3 proposed changes that aim to alleviate some operational frictions both for the DAO and the council.
This is a well paid position with minimal time commitments.
The most important qualities are:
The Ethereum ecosystem already has many individuals who fit this profile.
However, the lack of clarity around expected time commitments, both during the election phase (what a campaign should look like) and the operational phase, is discouraging people from applying.
With a focused awareness campaign and a clear outline of the operational responsibilities and time expectations, attracting strong candidates should be straightforward.
Thanks @Arbitrum for putting this proposal together. The motivation and rationale are well-founded, and we broadly agree with the direction, especially the term extension and the reduction of the qualification threshold. These changes should help reduce fatigue and expand participation.
One area we are less convinced by is the automatic bypass for incumbent Security Council members. While we understand the reasoning, we share some of the concerns already raised in this thread that incumbency alone should not substitute for fresh endorsement from the DAO.
Thanks @Arbitrum for putting this proposal together. The motivation and rationale are well-founded, and we broadly agree with the direction, especially the term extension and the reduction of the qualification threshold. These changes should help reduce fatigue and expand participation.
One area we are less convinced by is the automatic bypass for incumbent Security Council members. While we understand the reasoning, we share some of the concerns already raised in this thread that incumbency alone should not substitute for fresh endorsement from the DAO.
On key management, we appreciate that the proposal introduces clearer provisions for key rotation and even emergency actions. This is a meaningful step forward in strengthening operational security. We would suggest adding one more safeguard: a periodic liveness check for Security Council keys. In Optimism, Council members are required to perform an on-chain action roughly every three months to demonstrate they still control their keys, and failure to do so may result in removal.
Optimism Collective’s Governance Forum
Given the longer terms and the ability to rotate keys, introducing a similar mechanism in Arbitrum would ensure that Council members remain capable of acting when needed and prevent unnoticed key loss over time.
This kind of check would help maintain confidence that the Security Council is always ready to fulfill its responsibilities, especially as terms extend and operational continuity becomes more important.
Yeah, agree with this.
And Votable Tokens is the correct term in Arbitrum’s case, because it is calculated as: ~10B ARB that will ever exist minus the ~5.7B ARB that are currently delegated to the exclusion address.
So around 4.3B ARB of Votable Tokens.
So it’s not circulating ARB, it’s votable ARB, as in, tokens that are unlocked and not delegated to the exclusion address.
The following reflects the views of the Lampros DAO governance team, composed of Chain_L (@Blueweb) and @Euphoria, based on our combined research, analysis, and ideation.
Thanks for putting this together.
Extend the Security Council cohort duration from 1 year to 2 years
The following reflects the views of the Lampros DAO governance team, composed of Chain_L (@Blueweb) and @Euphoria, based on our combined research, analysis, and ideation.
Thanks for putting this together.
Extend the Security Council cohort duration from 1 year to 2 years
We support moving to one election per year because it should reduce fatigue and help delegates spend more time on actual evaluation. To protect predictability, could we add a simple rule to setCadence: any change takes effect only for the next cohort with at least 90 days of notice, and never extends a cohort already in its final 90 days.
would retroactively apply to both the March 2025 and September 2025 cohorts
Allow any existing Security Council members who have re-applied to bypass the Nominee Selection phase
As mentioned by @jameskbh, @0xDonPepe & @JoJo as well, we think competition should stay live each cycle. In the last election, 22 candidates registered and 13 reached the bar at 0.2% of Votable Tokens to advance, so the pipeline already looks healthy. And in the final round, voting power decayed over time to encourage early participation, which is a useful protection on its own. Instead of an auto-pass, a lighter continuity test could work: a small micro-threshold plus a minimum number of unique endorsers, and a short “term report” in the forum post covering attendance and incidents handled, so delegates can judge recent service. Also, the proposal mentions “0.1% of circulating ARB” while the Constitution uses Votable Tokens for thresholds and defines the vote-decay schedule. It would be clearer if the proposal, the code, and the docs all use the same term (Votable Tokens).
Enable Security Council candidates to rotate their keys during the Compliance phase
This new function allows a Security Council member to self-rotate their keys during their term.
This direction makes sense; we’ve had non-emergency rotations before, and a clearer path will reduce friction. Two asks to make this safer in practice. First, please publish a public feed of rotations as they happen, not just Foundation monitoring, and link it from the elections page. Second, add a simple emergency playbook: if a key is suspected of being compromised, place it in a “containment” state with no upgrade actions until the standard rotation completes, and publish a short incident note within 48 hours. It would also help if the compliance checklist required hardware-backed or threshold wallets and included an attestation template.
which can only be submitted by an address that can vote at least 500,000 of the Votable Tokens.
Lastly, the Constitution today says a Snapshot temperature check “can only be submitted by an address that can vote at least 0.01% of the Votable Tokens,” and the AIP proposes a fixed 500,000 ARB threshold. A fixed number can drift as supply and delegation change. If possible, please consider keeping it proportional with a floor and a cap, or document how and when the threshold will be reviewed so the bar stays fair over time.
Net, we’re supportive if these guardrails are added. They keep the spirit of your changes while tightening accountability and transparency for the DAO.
Thanks for the proposal. I think the changes are generally consistent with the changes we are seeing broadly in the DAO and DAO related councils, initiatives etc, specifically
In particular
Thanks for the proposal. I think the changes are generally consistent with the changes we are seeing broadly in the DAO and DAO related councils, initiatives etc, specifically
In particular
Would like to expand on last point, especially for answering @0xDonPepe and @jameskbh above. While I do see a scenario in which you want to put checks and balances, it is quite likely that any incumbent going again for nominee would pass that phase. But: passing that phase means, here, to get that 0.1% of total votable supply, that potentially can't go to other candidates. To say in other terms, if we have a low turnaround of voting in security elections (or a rising quorum which gets us to the same result), allowing incumbent already vetted to not have to go through that again means increasing the chance to have fresh names for the actual election.
I do see, tho, a situation in which an old incumbent could not be deemed suitable anymore due to new reasons. But I guess there is still the ability, from the Arbitrum Foundation, to cut a name from the final phase of election like it happened a few elections ago for the vp of security / security officer (can't remember the title sorry) of polygon, right? This should preserve us from the scenario in which an old incumbent has a free pass but is not suitable anymore for whatever reason written in the constitution.
Thanks for your proposal! It introduces several welcomed enhancements to the election process.
That being said, I have an issue with the following point
Progress Security Council members. Allow any existing Security Council members who have re-applied to bypass the Nominee Selection phase and into the Member Election phase.
Thanks for your proposal! It introduces several welcomed enhancements to the election process.
That being said, I have an issue with the following point
Progress Security Council members. Allow any existing Security Council members who have re-applied to bypass the Nominee Selection phase and into the Member Election phase.
The simple fact of a current member wanting to reapply shouldn't be equalized to a nomination from the DAO. Given that we are changing the election cadence, the support/reasoning to support given to them in the previous election may have change, and we can't assume it remains the same.
I believe they should go through the Nomination Phase as all the other candidates.
Overall, I’m supportive of this proposal, but with a few important tweaks.
My main concern (echoing the point raised by @jameskbh) is the auto-progress for incumbents. Simply re-applying shouldn’t be treated as equivalent to a fresh endorsement from the DAO. I suggest that incumbents only bypass the full 0.1% threshold if they either:
Overall, I’m supportive of this proposal, but with a few important tweaks.
My main concern (echoing the point raised by @jameskbh) is the auto-progress for incumbents. Simply re-applying shouldn’t be treated as equivalent to a fresh endorsement from the DAO. I suggest that incumbents only bypass the full 0.1% threshold if they either:
(a) meet a lighter micro-threshold (e.g., 0.05% + ≥3 unique endorsers with ≥50k ARB each), or
(b) there’s a shortage of candidates (e.g., fewer than 12 reach the 0.1% threshold).
This approach would preserve continuity while still ensuring competitiveness.
To further reduce whale-gating, I’d also recommend a simple pluralism guard: cap any single endorser’s contribution to ≤70**%** of a candidate’s qualifying total.
Finally, I’d suggest cleaning up the terminology between “circulating ARB” and “Votable Tokens.” Right now the Constitution uses Votable Tokens as the basis for thresholds, but the abstract of this proposal referenced circulating ARB:
Constitution: “During the Nominee Selection phase, a contender must be supported by pledged votes representing at least 0.2% of all Votable Tokens.”
Proposal: “…change the qualifying threshold from 0.2% to 0.1% of circulating ARB.”
It’s a small detail, but aligning on one term would avoid confusion down the line and make it easier for everyone to understand exactly which metric applies.