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