Security Council key exposure across three chains — draft for review

Technical Discussion
1

Edit 21 Sep: report revised after the replies below, same link. §7 is rewritten since rotation doesn’t hold up as the mitigation, and the emergency count is fixed. Changes and credits are in §10.

I’ve been looking at the Security Council path from a key-exposure angle and ended up with something I’d rather have checked before I publish it as final. Draft is up here: Reacher Report #002

If parts of it are wrong or already handled, I’d like to know before rather than after.

Short version of what I found.

The treasury contracts themselves have no private key, so a key-derivation adversary can’t touch them directly. The path runs through the council. Three things there:

The twelve member addresses are the same across four multisigs on three chains — Ethereum emergency, Arbitrum One emergency, Arbitrum One proposer, Nova. That’s visible in the SecurityCouncilMemberSyncAction transactions in the L1 Timelock, nonce 18 from 6 August. One key per member, four seats.

Public keys for at least nine of those seats are recoverable from chain data already. Safe signatures ride in execTransaction calldata, and the key comes back out of the signature. Three emergency actions have executed — KelpDAO recovery in April, the L2→L1 DoS patch in May, Stylus in October 2025 — nine signatures each.

Against an ordinary attacker, 9/12 is nine different problems: different people, hardware, jurisdictions, habits, plus three org seats with their own internal controls. Against an adversary that derives keys from exposed public keys, it’s one problem run nine times. The threshold buys duration there, not independence. And because of the first point, nine derivations reach four councils, not one seat.

This is class A in our terms, not R — conditional on a machine that doesn’t exist in demonstrated form. Nothing is reachable by this path today.

The part I found more interesting than the finding: the fix already shipped. The 31 August AIP added member self-rotation to SecurityCouncilManager with a 44-day floor. Reading the change notes it looks like an ops improvement, but it’s also the mitigation here — with one condition that isn’t stated anywhere I could find. A rotated key only helps while it stays unused. Sign anything with it, on any chain, and the seat is exposed again. So the protective bit isn’t the rotation, it’s not signing afterwards.

Which raises two questions I can’t answer from outside:

Is rotation-after-emergency-action something the council would consider as practice? Emergency powers were used twice in five months, and the 44-day floor means a council can’t get back to a clean state between two uses inside that window.

And is anyone already treating fresh council keys as cold in this sense, or are they normal working keys?

Public data only, no assertion of a vulnerability in any contract, and I’m not claiming any of the structural choices here are mistakes — synced membership and a no-delay emergency path buy real things I don’t try to weigh. Corrections welcome, I’ll fold them in and credit them.

Related: the June thread on PQC patterns in Arbitrum contracts raised the general question. This is one specific path rather than a survey.

1 Like
2

Thoughtful and well scoped analysis. The cross chain reuse of Security Council keys can increase the potential blast radius under a future key derivation threat model, even though there is no demonstrated practical threat today.

It is also important to note that ArbitrumDAO already has a governance framework for Security Council resilience. The Constitution allows individual members to rotate signing keys and allows the DAO to change the Security Council’s powers or structure through a Constitutional AIP.

The next useful step may be to document a clear post emergency key rotation policy, key separation across chains, and a long term post quantum migration roadmap. This would turn a future risk discussion into a practical and accountable preparedness plan. @Reacher

1 Like
3

Hi Reacher,

Exposure of public keys is not a risk in itself. In fact, cryptography is designed, so the keys can be public (i.e., “public key”).

The main risk is whether the corresponding private key was generated randomly and in a way that is not predictable. The recent hacks we saw with the Coldcard hardware wallet was simply due to the entropy used to generate the private key was not actually random or sufficient.

Most HW wallets should rely on cryptographic random number generators. There can be an advantage for the SC to use different HW manufacturers (like Ledger, Trezor, etc) to hedge against a single provider being compromised or poorly implemented. But that is primarily the risk and defense against it.

Rotating keys after use is not necessarily an ideal solution. Not only does it become a bit of a key management hurdle (hassle), but the rotation function only rotates 1 key at a time, so you will end up just revealing the public keys anyway.

2 Likes
4

Thanks, and yes on the Constitution. I made the 31 August change sound like rotation was new, which it isn’t. There’ve been rotation actions since at least June 2024. What August added is that members can do it themselves, 44-day floor. Will fix that in the report.

Went through the July 2026 rotation thread after reading your reply and found two more things I got wrong.

I said emergency powers were used twice in five months. The July rotation alone was three emergency actions, one per safe, to get the new members in straight away. So it’s used more than I counted.

The bigger one is about onboarding. New members prove they own the key by signing a message, and the signature gets posted, like in that thread. You can recover the public key from that signature. Which means a fresh key is already exposed the day the member joins, before it ever signs anything as council. So my suggestion in §7 (rotate to a key that never signs) doesn’t really work with how onboarding is done today.

One thing I don’t know: does the new self-rotation flow from August still need that published message, or can a member rotate without it? If it doesn’t, the fix works for self-rotations and just not for elections or replacements.

Agree with you on writing the policy down. I’d start with how ownership gets proven, since the rest depends on it. Separate keys per chain I’ll leave to the council, that’s a real trade-off against keeping membership in sync.

1 Like
5

Fair point, and you’re right that a public key being public is the whole design. Against anything we know how to build today, exposure doesn’t matter, which is why the report puts this in class A with R empty. The only case where it matters is an adversary that can go from public key to private key, and that’s the one case the report looks at. I should make that scope clearer up top, it reads broader than it is.

Entropy is a much better point on present-day risk and the report doesn’t cover it at all. Agree on mixing hardware vendors too. If anything that’s a stronger thing to check on the council today than what I wrote about.

On rotation, I think you’re right, and together with the onboarding signature it mostly kills §7 as a mitigation. Using a key exposes it again, and rotating after every use is a lot of overhead for a threat that doesn’t exist yet. I’ll rewrite that section. If this adversary ever shows up, the real answer probably means changing the signature scheme on the Safe side rather than rotating keys.

One thing I didn’t follow: what do you mean by the rotation function doing one key at a time and revealing the keys anyway? Is that the other members having to sign to approve it, or something else?

6

Hi @Reacher,

Thank you for putting this together and sharing it before final publication. The distinction between classical operational independence ($9/12$ distinct operational enclaves, jurisdictions, and human workflows) versus the mathematical collapse under parallelized discrete-log recovery from revealed public keys is cleanly framed.

Below is some additional context on the 44-day governance mechanics, operational constraints, and the broader architectural trade-offs to help inform your final report.

1. The Threat Model: Class A Framing

Your classification of this attack surface as Class A (theoretical, conditional on Shor’s algorithm running on fault-tolerant quantum hardware or an unprecedented algorithmic break in secp256k1) is the essential premise.

Under current cryptographic assumptions, an exposed $xy$-coordinate pair in Safe execTransaction calldata carries zero marginal extraction risk. The $9/12$ threshold remains an active, robust Byzantine fault-tolerant barrier. The value of your report is therefore in long-term resilience modeling rather than signaling an immediate patch requirement.

2. Mechanics & Rationale of the 44-Day Floor

The August 31 AIP introducing member self-rotation via SecurityCouncilManager operates under tight governance constraints. The 44-day floor is not an arbitrary administrative buffer; it is structurally bound to Arbitrum’s dual-layer governance architecture:

  • Anti-Coercion and Hijack Mitigation: If a council member’s operational environment or hardware key is targeted, compromised, or coerced, an unconstrained self-rotation mechanism could allow an attacker (or a compromised signer) to immediately swap out the legitimate key for an adversarial address without oversight. The 44-day floor enforces an immutable window where anomalous rotation attempts can be detected, challenged, and remediated by the DAO or fellow council members.
  • Timelock & Challenge Latency Constraints: Non-emergency member changes must clear the L2 Timelock, traverse the canonical L1 inbox pipeline, and allow sufficient duration for the fraud-proof challenge window and governance veto mechanisms. Compressing this timeline to permit rapid sequential rotations would erode the fundamental security guarantees of the L1 $\leftrightarrow$ L2 messaging topology.
  • The Clustering Problem: As your data highlights, emergency interventions often occur in clusters (e.g., KelpDAO in April followed by the L2 $\to$ L1 DoS mitigation in May). Because these actions fell within a ~30-day window, a mandatory rotate-after-emergency policy is mathematically and operationally impossible under the 44-day floor. Forcing a council through an expedited rotation path would introduce substantial operational fragility and key-handling errors during an already high-stress incident response cycle.

3. Unified Signer Topology vs. Attack Surface Separation

Mirroring the 12 addresses across Ethereum L1, Arbitrum One, Nova, and the proposer role via SecurityCouncilMemberSyncAction is an explicit prioritization of containment speed over perimeter isolation:

  • In an active zero-day bridge exploit or L2 consensus stall, the council’s mandate is immediate, deterministic containment.
  • Fragmenting membership across distinct keys per chain would fragment operational bandwidth, significantly increase coordination latency, and multiply key-management failure modes across 12 distributed signers during critical emergencies.

4. Cold Signing Limits & The Durable Path Forward

To answer your second question directly: council keys cannot practically be treated as “cold” or single-use under current EVM primitives.

Every signature published to execute a transaction exposes the signer’s unhashed public key. Therefore, key rotation only preserves secrecy until the key is called upon to perform the exact function it exists for. Rotating a key simply to obtain an unexposed public key creates a “single-use key” operational overhead that is impractical without native protocol support.

The long-term mitigation for the key-derivation vector will not come from manual operational rotations, but from protocol-level structural upgrades:

  1. Account Abstraction (ERC-4337 / Native AA): Transitioning signer verification logic away from raw ecrecover dependencies.

  2. Post-Quantum Signature Schemes: Transitioning to stateful hash-based (e.g., XMSS/LMS) or lattice-based signature algorithms at the contract layer once standardized and gas-optimized for the EVM.

    Looking forward to the publication of the final report. This is a high-value contribution toward keeping the DAO’s long-term risk roadmap ahead of future cryptographic shifts.

1 Like
7

Didn’t know the anti-coercion reason for the 44 days, that helps. I’d only thought of the floor as a limit on how often you can rotate.

Your conclusion matches where §7 ended up after the earlier replies, so I’ve mostly just added your clustering point (April and May, 33 days apart) and credited you in §10. Same link as before.

Do you know if the August self-rotation still has the new member post a signed ownership message like onboarding does? If yes, the fresh key is out from day one anyway.

1 Like
8

Glad the clustering timeline and governance delay context were useful, and thanks for folding them into §7 and §10.

To your question regarding the August self-rotation flow: yes, your intuition is spot on.

The self-rotation mechanism implemented in SecurityCouncilManager requires positive proof-of-control from the incoming key before the rotation can finalize. To prevent a member from fat-fingering an address or rotating into an unmanaged contract, the protocol enforces an acceptance handshake:

  1. The incoming address must execute an explicit claim transaction, or
  2. A signed authorization payload (EIP-712/EIP-191 proof of ownership) signed by the new key must be submitted in the rotation execution calldata.

Because an EOA transaction or an on-chain signature verification passes the raw signature data through calldata, the unhashed public key ($xy$-coordinate pair) of the new address is revealed the moment the rotation is executed on-chain.

Even before the newly onboarded key ever participates in an emergency execTransaction call, its public key is already permanently queryable in the transaction history. This further closes the loop on your thesis: keeping keys mathematically “cold” isn’t just broken by emergency usage—the registration process itself leaks the public key on day zero.

1 Like
9

That closes it, appreciated. I’ll fold it into §7 and mark the open question as answered.

For the citation, is there a link to the rotation code or an executed self-rotation tx? I can see a ROTATE_MEMBER type hash on the deployed manager, which fits what you describe, but I’d rather point readers at the actual function than at my reading of a hash.

10

Here are the exact code pointers and references for §7:

Contract & Function:

The Exposure Mechanism:
The ROTATE_MEMBER_TYPEHASH defines the EIP-712 struct that the incoming key must sign. When rotateMember is executed, signature ($r, s, v$) is passed in raw calldata to recover newMemberAddress. Anyone parsing the transaction can immediately derive the new key’s full uncompressed public key coordinates ($x, y$) via standard EC recovery—meaning the key is publicly exposed on day zero, prior to signing any multisig action.

Governance Spec:

  • [Constitutional] AIP: Ratification of Security Council Election Process Improvements (under section Rotate Member’s Security Council Key during term).
1 Like
11

Got it, thanks. Added with the AIP reference.

Small thing though. The copy of SecurityCouncilManager on main in ArbitrumFoundation/governance still has rotateMember(address,address), no signature argument, so I couldn’t check your version against published source. The deployed manager does have ROTATE_MEMBER_TYPE_HASH and the domain hash on it, so that’s what I cited. Is the current source somewhere I can link to?

12

Publish / update the source
The highest-value action is to push the exact source that matches the deployed SecurityCouncilManager (including ROTATE_MEMBER_TYPEHASH, domain separator, and the full rotateMember signature) to the public ArbitrumFoundation/governance repo (or a clear commit/tag) and verify it on the explorer.

1 Like
13

My mistake on that last bit. The implementation behind the manager proxy, 0x01B370d9b1ed1591C64C9a4b0FAFF193AF5Fa928, is verified on the explorer and does have rotateMember(address, address, bytes). So the source is public, it’s the repo that’s behind. Fixing that line in the report now.

A repo copy or a tagged commit would still help though, that’s where people look first.

14

Thanks for checking and correcting that.

Agreed: the implementation behind the manager proxy is verified on the explorer, and it includes rotateMember(address,address,bytes). So the source is public; the gap is that the repository copy hasn’t caught up.

For the report, citing the verified implementation and proxy address is the right way to document the deployed behavior. A matching repo copy or tagged commit would make it easier for reviewers to find and compare the source. Ideally, that release would include the typehash and domain-separator logic, then document the bytecode match against the implementation on the explorer.

1 Like
15

That’s the thread closed for me then. The report has the implementation address and the explorer note in it now.

Unless something else comes up I’ll drop the draft label in a day or two and leave it as final, with the three of you credited in §10. Thanks for the time, it ended up better than what I posted.

1 Like