Abstract
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:
- Allow existing Security Council members who re-apply to the Security Council to bypass the Nominee Selection phase and progress directly into the Member Election phase.
Changes Since the Original Temperature Check
-
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).
Rationale
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.
Specification
As outlined in the prior temperature check, several new functions in the smart contract suite have been prepared to facilitate the changes.
Set Cadence for Elections
- setCadence(numberOfMonths)
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.
Reduce qualification threshold
- updateQuorumNumerator(newQuorumNumerator)
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%.
Rotate Candidate’s Security Council Key during election
- rotateNominee(proposalId, newNomineeAddress, signature)
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.
Rotate Member’s Security Council Key during term
- rotateMember(newMemberAddress, memberElectionGovernor, signature)
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.
Changes to the ArbitrumDAO Constitution
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.
Update: Frequency of Elections
- Old Text:
The date chosen for the first election will form the basis for all future elections. Every election should begin 6 months after the previous election has started and it will replace its respective cohort of 6 members.
- New Text:
The date chosen for the first election formed the basis for all future elections. Every election should begin 12 months after the previous election has started and it will replace its respective cohort of 6 members.
Update: Qualification Threshold And Key Rotation During Election
- Old Text:
Nominee selection (T+7 until T+14 days): Each DAO member or delegate may vote for their declared contender. Each token may be cast for one contender. To the extent that there are more than six contenders, each eligible contender must be supported by pledged votes representing at least 0.2% of all Votable Tokens.
Compliance process (T+14 until T+28 days): All candidates will cooperate with the Arbitrum Foundation and complete the compliance process. The Arbitrum Foundation is responsible for removing any candidates that fail the compliance process. In the event that fewer than six candidates are supported by pledged votes representing at least 0.2% of all Votable Tokens, the current Security Council members whose seats are up for election may become candidates (as randomly selected out of their Cohort) until there are 6 candidates.
- New Text:
Nominee selection (T+7 until T+14 days): Each DAO member or delegate may vote for their declared contender. Each token may be cast for one contender. To the extent that there are more than six contenders, each eligible contender must be supported by pledged votes representing at least 0.1% of all Votable Tokens.
Compliance process (T+14 until T+28 days): All candidates will cooperate with the Arbitrum Foundation and complete the compliance process. If candidates need to rotate their signer addresses during a Security Council election, they must do so before day T+25 (during the compliance process).The Arbitrum Foundation is responsible for removing any candidates who fail the compliance process. In the event that fewer than six candidates are supported by pledged votes representing at least 0.1% of all Votable Tokens, the current Security Council members whose seats are up for election may become candidates (as randomly selected out of their Cohort) until there are 6 candidates.
Update: Security Council Can Rotate Keys During Term
- Old Text:
Equivalent "copies" of the Security Council multi-sig contracts exist, one on Ethereum and another on each ArbitrumDAO-governed chain.
- New Text:
Equivalent "copies" of the Security Council multi-sig contracts exist, one on Ethereum and another on each ArbitrumDAO-governed chain. A Security Council Member can independently rotate their signing key in the multi-sigs, but the rotation must go through Phases 4 to 7 of the AIP process. In Phase 4, it adheres to the waiting time for an L2 to L1 message.
Update: Election Smart Contracts Already Installed
A small edit to acknowledge that the election smart contract software is already installed and the elections can begin.
- Old Text:
The first Security Council election is scheduled to begin on the 15th September 2023 or the earliest possible date. The election can only begin upon the availability of an on-chain election process that is approved and installed by the Arbitrum DAO. This first election replaces the 'First Cohort'. The next election replaces the 'Second Cohort' and so forth.
- New Text:
The first Security Council election commenced on 15th September 2023, following the availability of an on-chain election process that was approved and installed by the ArbitrumDAO. This first election replaced the 'First Cohort'. The next election replaced the 'Second Cohort' and so forth.
Update: Procedural Change to ArbitrumDAO Constitution #1
While we are updating the ArbitrumDAO Constitution, it is a good time to better reflect the DAO’s current practices in Section 2, including the latest governance process and UIs.
- Old Text:
Phase 1: Temperature Check (1 week) (Optional but Recommended): The AIP is suggested on the public forumand discussed/debated for 1 week. The AIP should be accompanied by aSnapshot poll or other method as determined pursuant to the governance process, which can only be submitted by an address that can vote at least 0.01% of the Votable Tokens. The Snapshot poll also runs for 1 week, and is decided by a simple majority with no required participation threshold. An AIP that fails the temperature check should not be submitted for a vote. If an AIP fails the temperature check, or has not undergone a temperature check, as a matter of good governance practice, it is recommended that voters strongly consider voting to reject it.
Phase 2: Formal AIP and call for voting (3 days): The AIP is submitted via governance contracts on Arbitrum One, with a user interface available on Tally. The AIP proposer is required to have an address that is delegated at least 1,000,000 Votable Tokens.
- New Text:
Phase 1: Forum Post (1 week) (Optional but Recommended): The AIP is suggested on the public forum and discussed/debated for 1 week.
Phase 2: Temperature Check (1 week) (Optional but Recommended): The AIP should be accompanied by an off-chain temperature check poll or other method as determined pursuant to the governance process, which can only be submitted by an address that can vote at least 500,000 of the Votable Tokens. The off-chain temperature check runs for 1 week, and is decided by a simple majority with no required participation threshold. An AIP that fails the temperature check should not be submitted for a vote. If an AIP fails the temperature check, or has not undergone a temperature check, as a matter of good governance practice, it is recommended that voters strongly consider voting to reject it.
Phase 3: Formal AIP and call for voting (3 days): The AIP is submitted via governance contracts on Arbitrum One, with a user interface available on https://alt.gov.arbitrum.foundation/. The AIP proposer is required to have an address that is delegated at least 1,000,000 Votable Tokens.
Update: Procedural Change to ArbitrumDAO Constitution #2
- Old Text:
This AIP process as specified will typically require 37 days from the beginning of the temperature check in Phase 1 until an AIP is finally executed in Phase 7 for a Constitutional AIP, or 27 days for a Non-Constitutional AIP. An AIP may optionally specify further delay before its implementation.
- New Text:
This AIP process as specified will typically require at least 42 days from the beginning of the temperature check in Phase 1 until an AIP is finally executed in Phase 7 for a Constitutional AIP, or at least 27 days for a Non-Constitutional AIP. An AIP may optionally specify further delay before its implementation.
Timeline
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→ 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.