In September 2025, the ArbitrumDAO showed varying degrees of support for five Security Council Election process improvements via a temperature check. This updated temperature check aims to ratify the DAO’s support for the inclusion of four and omission of one of the originally proposed improvements, ahead of an on-chain vote.
The following improvements will be included:
Increase the Security Council cohort duration from 1 year to 2 years, therefore reducing election frequency from twice a year to once a year.
Reduce the qualification threshold in the Nominee Selection phase, from 0.2% to 0.1% of votable ARB.
Enable Security Council candidates to rotate their keys during the Compliance phase of the election.
Enable Security Council members to rotate their keys at any time during their term.
The following improvement will be omitted:
The proposal’s original intention was for the on-chain vote for this proposal to take place before the recently concluded March 2026 Security Council election. However, as a result of the on-chain vote being postponed, and assuming the on-chain vote is approved in accordance with the specified timeline, the next election would take place in March 2027 (see Timeline section).
The improvement to allow existing Security Council members who re-apply to the Security Council to bypass the Nominee Selection phase, has been omitted (see Rationale section).
Further procedural details regarding the key rotation procedures have been added (see Specification section).
Since the original temperature check, a full audit of all the proposed changes was completed.
The originally proposed changes to the constitution have been updated (see Specification section).
This updated temperature check 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 can reduce the number of candidates who can progress to the Member Election phase 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.
Considering that this proposal also suggests reducing the election cadence and lowering the qualification threshold to progress from the Nominee Selection phase, there was significant delegate sentiment that allowing existing Security Council members who have re-applied to bypass the Nominee Selection phase, would make it too easy for candidates to progress to the Member Election phase. Moreover, many delegates believed that incumbency alone should not substitute for fresh endorsement from the DAO. Considering the above, the change to allow existing Security Council members who have re-applied to bypass the Nominee Selection phase, has been omitted from this proposal.
As outlined in the prior temperature check, several new functions in the smart contract suite have been prepared 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 September 2025 Security Council’s cohort duration from 1 year to 1.5 years and extend all future Security Council cohort durations (including the March 2026 Security Council cohort) from 1 year to 2 years. This would also result in all future elections being held each March.
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, thus adjusting it from 0.2% to 0.1%.
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. This will give the Arbitrum Foundation enough time to veto any proposed key rotations that do not follow correct procedure nor pass compliance checks. It is expected that a candidate requesting a rotation will inform the DAO on the forum once the rotation has been submitted on-chain, which will then be confirmed by the Arbitrum Foundation who actively monitors 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 timelock of 18 days before they are registered into the Security Council multisigs on Arbitrum One, Ethereum, and Arbitrum Nova. The Security Council will be able to veto any proposed key rotations that do not follow correct procedure nor pass compliance checks. It is expected that a member requesting a rotation will inform the DAO on the forum once the rotation has been submitted on-chain, which will then be confirmed by the Arbitrum Foundation who actively monitors for key rotations.
Note, these code changes have already been written, tested, and audited in September 2025.
We have put together proposed changes to the ArbitrumDAO Constitution in Section 3 and Section 4 to reflect changes to the Security Council election process; as well as minor corrections 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.
We aim to raise the on-chain vote to integrate these improvements ahead of the next scheduled election cycle, which is currently scheduled to take place in September 2026. Accordingly, if this updated temperature check and the following on-chain vote were to pass, it would retroactively apply to both the September 2025 and March 2026 cohorts, as well as to any future cohorts. This would also mean that the next election would take place in March 2027, to replace the September 2025 cohort. The current members of the September 2025 and March 2026 Security Council cohorts have already agreed to this potential term extension in their declarations. This would also result in all future elections being held each March.
Adjustments to the following timeline may be made based on community feedback and DAO governance requirements:
August 20, 2025 (complete)→ Forum post outlining the proposed changes to the Security Council election process.
August 20, 2025 - September 2025 (complete)→ Full audit of proposed changes.
September 4, 2025 (complete)→ Approval voting temperature check to understand support for all proposed Security Council Election Process Improvements.
July 9, 2026 (complete)→ Updated forum post to ratify that the ArbitrumDAO supports the inclusion of four of the originally proposed improvements.
July 16, 2026→ Updated temperature check (FOR, AGAINST, ABSTAIN) to ratify the improvements ahead of an on-chain vote.
July 30, 2025→ If this updated temperature check passes, a constitutional on-chain vote will be put forward.