Class: A, assumption-bounded Target: Arbitrum DAO governance path. Security Council multisigs on Ethereum, Arbitrum One, Arbitrum Nova Method: Reacher EE v2.4.2-rc2-R0 (Core v2.4.2-rc), R/A/U state classification Data: public only. On-chain records, L1 Timelock scheduled transactions, Arbitrum Foundation docs, forum council-action threads, L2BEAT permissions data Status: revised draft

Revised 21 September 2026 after review on the Arbitrum forum. Section 7 is rewritten and two counts are corrected. What changed and who raised it is listed in §10. Final version follows once review closes.

The Arbitrum DAO treasury holds roughly $1.33B in ARB plus about 14,200 ETH, across two contracts. Neither contract has a private key. Against an adversary that derives private keys from public keys, the treasury itself is U: there is nothing to derive.

Scope first, because the first draft didn't make it clear enough. A public key is meant to be public. Against every adversary anyone knows how to build, exposure of a public key doesn't matter. This report looks at one adversary class only: one that can go from a secp256k1 public key to the private key. That adversary has not been demonstrated. Class R is empty.

Under that one assumption, the reachable path is the Security Council. Nine signatures out of twelve, no delay, upgrade authority over every system contract on three chains.

Two things about that path, both checkable from public data:

• The same twelve addresses sit on four separate multisigs across three chains. Each member holds one key, not four.

• Against this adversary class the threshold buys time, not independent compromises.

The first draft proposed key rotation as the mitigation. Review showed it doesn't hold up (§7). If this adversary ever appears, the answer is a change in how the council safes verify signatures, not key hygiene.

The present-day risk for these keys is something else: how they were generated. That is outside this report and noted in §8.

Arbitrum's own risk docs state the condition: if nine Security Council members are compromised or act maliciously, the system and user funds could be compromised.

Embedded in that is the assumption that nine compromises are nine separate problems. The assumption is load-bearing. The emergency path has no timelock and no exit window, and the DAO can't cancel it while the council is active.

This report checks whether that cost description holds for one specific adversary class, and only that one.

Treasury. 0xF3FC178157fb3c87548bAA86F9d24BA38E649B58, DAO Treasury, ~2.65B ARB. 0xbFc1FECa8B09A5c5D3EFfE7429eBE24b9c09EF58, L2 Treasury Timelock, ~14,211 ETH. Both upgradeable proxies, neither controlled by a private key.

Two control paths.

Normal: forum temp-check, on-chain vote (14d), L2 Timelock (8d), L2→L1 outbox (~6.4d), L1 Timelock (3d), execute. About 41 days wall-clock for constitutional proposals, ~17.4d of it enforced on-chain. Exit window exists.

Emergency: 9/12 Security Council. Instant. No timelock, no exit window, direct access to admin and upgrade functions on all three chains.

The council also holds Canceller on both timelocks, so an active council can't be routed around by normal governance inside the execution window.

Four multisigs.

Membership and threshold are synced by SecurityCouncilManager (0xD509E5f5aEe2A205F554f36E8a7d56094494eDFC) through cross-chain messages.

The SecurityCouncilMemberSyncAction transactions in the L1 Timelock carry the member list pushed to each council. Nonce 18, scheduled 6 August 2026, pushes the same twelve addresses to all four:

Identity isn't inferred here. The Foundation publishes the members with addresses: individuals and orgs, including Immunefi, Certora and OpenZeppelin.

So a member doesn't hold four keys for four councils. One key covers the seat on Ethereum, both seats on Arbitrum One, and the seat on Nova.

Synced membership is a deliberate choice and it buys real things: no divergence between chains, one election, simpler ops. The side effect is that exposure doesn't decompose by chain. MconnectDAO put it as blast radius in review, which is a fair way to say it.

An address is a hash of a public key. Holding a seat exposes nothing. Signing does, and it doesn't matter what gets signed: a transaction or a plain message.

Two routes, for the current twelve:

Onboarding. New members prove they control their key by signing a message, and the signature is published on the forum. The July 2026 rotation thread shows this for both incoming members (0xeeffd9... and 0xeeb8886c..., both in the list above). The public key is recoverable from that signature. So these two seats were exposed on the day the members joined, before either signed anything as council.

Council actions. Safe signatures ride in the calldata of execTransaction, and the public key comes back out of each signature. The July rotation was installed through three emergency actions, one per safe, each needing nine signatures from the council as it stood before the change. At most two of those nine could have been the outgoing members. So at least seven of the ten continuing members signed.

Seven continuing plus two new gives at least nine of the current twelve seats with public keys already recoverable. This is a lower bound from structure. I haven't checked signature by signature which member signed which action, and the real number is probably higher given earlier actions (October 2025, April 2026, May 2026).

Against an ordinary attacker, 9/12 is strong for reasons that aren't arithmetic. The ninth signer is a different person on different hardware under different law with different habits. Getting to nine isn't nine times the first, it's nine different problems. Three seats are organisations, which adds internal controls on top.

Against an adversary that derives keys from exposed public keys, those differences stop mattering. Nine keys are one problem run nine times. The cost is time, and time is cheap if the capability exists at all.

Put another way: adding a required signature raises difficulty steeply against every adversary the scheme was designed for, and raises only duration against this one. The multisig isn't weakened. The threshold just prices a different thing than people read into it.

Together with §3, nine derivations hand over four councils on three chains.

A moves to R on a public demonstration of ECDLP-256 at scale, or any other route from secp256k1 public key to private key.

A moves to U only if the council safes stop depending on secp256k1 signatures. Key hygiene alone doesn't get there, see §7.

The first draft of this section said the fix had already shipped. That was wrong in two ways, and review caught both.

Rotation isn't new. Non-emergency rotation actions go back to at least June 2024, and the Constitution already lets members rotate signing keys (MconnectDAO pointed this out). What the 31 August 2026 AIP added is members rotating their own keys, with a 44-day floor.

The draft's idea was to rotate into a key that never signs, so its public key never appears. Onboarding breaks that. If the new key has to sign a published ownership message, it's exposed on day one. I don't know yet whether the August self-rotation flow still requires that message. If it doesn't, self-rotation avoids this step and elections and replacements don't.

Use breaks it too. Any council action exposes the keys that sign it. And the emergency path is used more often than the first draft counted: the July rotation alone was three emergency actions, one per safe.

Then there's the cost. Rotating after every use is a lot of key management overhead for a threat nobody has demonstrated. stonecoldpat made this point in review and I think it's right.

The 44-day floor also works against a rotate-after-use policy, and for good reasons. Arb_Junior explained part of its purpose in review: it gives a window to catch a coerced or compromised member swapping in an attacker's key. And emergencies come in clusters. KelpDAO on 21 April and the DoS fix on 24 May were 33 days apart, inside the floor. A mandatory rotation after each emergency can't work under it, and forcing one in the middle of incident response adds its own risk.

On the question the first draft asked, whether anyone treats fresh council keys as cold: the answer from review (Arb_Junior) is no, and under current EVM primitives it isn't practical. A key exists to sign, and signing exposes it.

So rotation doesn't move this path from A to U in practice. If the adversary ever appears, the realistic answer is changing how the council safes verify signatures: moving verification off raw ecrecover, through account abstraction, toward a post-quantum scheme at the contract layer once one is standardised and affordable on the EVM. That's a protocol-level migration, and the June forum thread on PQC patterns in Arbitrum contracts covers the routes in general terms.

Public data only. Nothing here asserts wrongdoing or a vulnerability in any contract. Every structural fact described is a documented design decision, and some of them, synced membership and an emergency path with no delay, buy things this report doesn't weigh against the cost.

What this report doesn't cover, and what matters more today: whether each council key was generated with enough real randomness. Weak entropy at generation is a present-day path to a private key, no special machine needed. Using hardware from different vendors across the council hedges against one vendor's generator being broken. stonecoldpat raised this in review, and it's a better thing to check on the council now than anything in this report.

A note on the 2030 date, which comes up in this context: it originates in the EU post-quantum cryptography roadmap published by the NIS Cooperation Group on 23 June 2025. Member States begin transition by end of 2026, critical infrastructure migrated no later than end of 2030. It's sometimes attributed to DORA Article 50, which covers administrative penalties rather than cryptography. The deadline is real; the source is the roadmap.

Other systems run cross-chain synced councils on the same pattern. This report looks at one of them.

An audit asks whether the multisig executes correctly. It does.

The question here is what the threshold parameter actually costs an attacker, and whether that cost holds across the adversary classes the system will meet over the lifetime of what it guards.

For most adversaries 9/12 costs nine separate compromises. For one class it costs nine runs of the same capability, and it pays out four councils across three chains. The parameter wasn't chosen with that class in mind, and nothing in the current setup changes the answer for it.

21 September 2026, after review in the forum thread Security Council key exposure across three chains, draft for review.

• Scope. Summary and §1 now state up front that public key exposure only matters under one adversary class. Raised by stonecoldpat: public keys are meant to be public.

• §4. Exposure count re-derived. The July 2026 rotation replaced two members; their keys are exposed through published onboarding signatures. Lower bound of nine current seats now derived from the July emergency actions plus onboarding, not from earlier actions whose signers may since have rotated out.

• §7. Rewritten. Rotation is not new (since June 2024; Constitution already permits it, raised by MconnectDAO). Rotation into an unused key is defeated by the onboarding signature and by any later use. Overhead point raised by stonecoldpat. Mitigation now stated as a signature-scheme change.

• Emergency count. First draft said emergency powers were used twice in five months. The July rotation alone used three emergency actions.

• §8. Added entropy at key generation and vendor diversity as the present-day risk this report doesn't cover. Raised by stonecoldpat.

• §7, second pass. Added the purpose of the 44-day floor (a window to catch a coerced key swap), the clustering of emergencies (21 April and 24 May, 33 days apart), the answer that council keys can't practically be kept cold, and account abstraction as the route off raw ecrecover. Raised by Arb_Junior.

• Open question carried from review, not yet answered: does the August self-rotation flow require a published ownership signature from the new key?

Reacher. Reachable failure paths in systems where verification claims are load-bearing. Reacher EE v2.4.2-rc2-R0. Independent solo-founder operation. Operating async, Ukraine.