[Constitutional] AIP: Security Council Election Process Improvements

Proposals
1

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:

  • Longer 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.

  • Adjust qualification thresholds. In the Nominee Selection phase, change the qualifying threshold from 0.2% to 0.1% of circulating 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.

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

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 circulating 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 Security Council Key

  • 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 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 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 changes to the Security Council elections implementations.

Update Frequency of Elections

  • Old Text:

The date chosen for the first electionwill formthe basis for all future elections. Every election should begin6 monthsafter the previous election has started and it will replace its respective cohort of 6 members.

  • New Text:

The date chosen for the first electionformedthe basis for all future elections. Every election should begin12 monthsafter 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 least0.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 least0.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 least0.1%of all Votable Tokens. If any current Security Council members in the cohort being replaced declare their candidacy for the incoming cohort, they will automatically progress to being a candidate in the Member Election phase (assuming they pass the compliance process).

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

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.

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 electionis scheduled to beginon the 15th September 2023or the earliest possible date. The election can only begin upon theavailability of an on-chain election process thatisapproved 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 electioncommenced on the15th September 2023,following theavailability of an on-chain election process thatwasapproved and installed by the Arbitrum DAO. This first election replaced the 'First Cohort'. The next election replaced the 'Second Cohort' and so forth.

Unrelated Change to ArbitrumDAO Constitution

While we are updating the ArbitrumDAO Constitution, it is a good time to better reflect the DAO’s process of submitting a temperature check using Snapshot in Section 2 to reflect current practices.

  • Old Text:

Phase 1: Temperature Check (1 week) (Optional but Recommended): The AIP is suggested on the public forum and discussed/debated for 1 week. The AIP should be accompanied by aSnapshotpoll or other method as determined pursuant to the governance process, which can only be submitted by an address that can vote at least0.01% of the Votable Tokens.

  • New Text:

Phase 1:Forum Post (1 week)(Optional but Recommended): The AIP is suggested on the public forumand discussed/debated for 1 week.

Phase 2: Temperature Check (1 week) (Optional but Recommended): The AIP should be accompanied by aSnapshotpoll or other method as determined pursuant to the governance process, which can only be submitted by an address that can vote at least500,000of the Votable Tokens.

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 these 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 apply from the 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 → AIP forum post outlining the proposed changes to Security Council election process.

  • August 20, 2025 - September 4, 2025 → Full audit of proposed changes.

  • September 4, 2025 → Temperature check held on Snapshot.

  • November 2025 → Onchain Tally vote will commence following the September 2025 Security Council election.

The Foundation will also be hosting governance calls to discuss this proposal. Stay tuned!

5 Likes
2

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.

3 Likes
3

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.

4

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

  • dropping amount of votes needed to do X
  • increasing time in the role.

In particular

  1. the reduction from 0.2% to 0.1% seems to address the barrier of rising quorum. In favour
  2. term of 1y vs 6 months, allows for less operational burden in the DAO. In favour.
  3. auto pass of previous security council members: in general if they were elected they are likely still good enough for the council. In favour.

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.

1 Like
5

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.

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.

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.

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

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.

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.

6

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.

7

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

8

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.

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.

9

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.

10

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:

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

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

2 Likes
11

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:

  • Technical expertise
  • Strong integrity
  • Ability to respond quickly when needed

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.

12

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:

Election Process

  1. What do we consider the ‘right candidate’?

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?

  1. What do we expect from candidates in the election process?

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?

  1. Should we proactively search for fitting SC members?

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?

Security Council Operations

Aside from the election process itself, we could also take the opportunity to address some of the aspects of the SC’s operations.

  1. How do we handle SC’s funding going forward?

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

  1. Should the SC rely on the Arbitrum Foundation for operations?

As an extension to the above, should the SC continue to rely on AF for operations, or should it potentially handle that independently?

  1. What is the relationship between the SC and the DAO?

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?

  1. Should there be an internal structure?

Instead of having 12 members with a horizontal structure, does it make sense to introduce a hierarchy and perhaps have a Security Council lead?

  1. Do we still need the ‘small Security Council’?

IIrc, we have only used it once, and right now there doesn’t seem to be any clear use case for it.

  1. Should we change the language of the Constitution around SC’s scope?

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?

  1. Should we introduce some kind of a transparency report / retrospective for the Security Council to better understand its past actions and the performance of particular members?

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.

4 Likes
13

Would like to emphasize this point.

As of today, the DAO is “passive” in every aspect.

  • we don’t source protocols to participate to grant and incentive programs (as far as I know, I might be wrong with the recent example of the DRIP but is just too new to evaluate and there are not too many info around it)
  • we don’t source people/member
  • we wait for someone to show up, maybe after single initiatives of members of AF/OCL or personal efforts.

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.

1 Like
14

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

15

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: Arbitrum Security Council Recommendations

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

16

The recording of ‘Security Council Election Process Improvements proposal: Open Discussion’ can be accessed here: https://drive.google.com/file/d/1iTxtCSHP2n0zZ8D-4wZyu6uL1Fn8mdF9/view

2 Likes
17

We agree with some changes to the Security Council suggested:

  • Change the SC elections from 6 months to 1 year. This avoids delegate fatigue and keeps those elected in office for longer, preventing frequent changes in membership.

However, we have concerns about other suggested changes:

  • The proposal mention changing the threshold to 0.1% of the circulating supply of $ARB, but mentions “Votable tokens” in the Constitution amendment. And the correct thing to do is to use 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.

18

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.