Constitutional AIP

Abstract

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).

Motivation/Rationale

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.

Proposed Smart Contract Changes

We have implemented several new functions in the smart contract suite 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 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.

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 and thus adjusting it from 0.2% to 0.1%.

Bypass Nomination Phase

• addContender(proposalId, signature)

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.

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. The Arbitrum Foundation will monitor 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 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.

Changes to the ArbitrumDAO Constitution

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.

Timeline

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 a

... please visit link below to view full proposal

https://snapshot.org/#/arbitrumfoundation.eth/proposal/0xb41324ddcc115d08149b192e0b8ae4cfad0ef39cecb5663ea63d8a460d2cb3cc