[Constitutional] AIP: Security Council Election Process Improvements

[Arbitrum]

@Griff

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.

@krst

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.

@Saurabh

Candidate key rotation: Concerns raised about unnecessary risk — candidates should demonstrate key control prior to nomination.

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.

[Arbitrum]

The recording of the Security Council Election Process Improvements proposal: Open Discussion #2 can be found here.

[Griff]

@Arbitrum

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

[paulofonseca]

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.

[dzack23]

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

[dzack23]

Also,

@fred

As a member of the March 2025 Security Council cohort I am not keen on extending my mandate.

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