Arbitrum proposal adds an L1 recovery vote with a 25-day timelock

A proposal posted to the Arbitrum Foundation Forum on October 2, 2026 addresses what happens if L2 governance and the Security Council fail at the same time. The proposal would amend Section 2 of the ArbitrumDAO Constitution to add an Ethereum L1 voting route, leaving the existing AIP process on Arbitrum One alone.

As the proposal states: “A simultaneous failure of L2 governance and the Security Council could prevent the DAO from repairing its governance contracts.” The proposed fix, per the same document, “preserves a DAO-controlled recovery path by proving L2 voting state on L1 and allowing governance to proceed without relying on the L2 governor or Security Council.” The proposal is explicit that this wouldn’t displace normal L2 governance, alter the Security Council’s authority, or touch standard AIPs. This is a proposal, not an enacted rule.

Under the mechanism, an ArbitrumDAO action could be created, voted on, queued, and executed from Ethereum L1. Voting power would be drawn from ARB delegations proven against confirmed Arbitrum assertions. Approved actions would then move through a new L1 timelock before reaching the existing upgrade executors. The proposal names six components: L1ArbitrumGovernor, L1ArbitrumTimelock, DelegateMapping, L2StateMirror, ProofHelper, and VotingTokenMirror.

Delegates operating through contract addresses would need to register an L1 voting address via DelegateMapping on Arbitrum One. EOA delegates could do it by submitting an EIP-712 signature through L2StateMirror.claimL1AddressBySig. ARB voting power stays anchored to L2 delegations — the vote runs on L1 only through those registered addresses.

Proposer access requires an Arbitrum One address delegated at least 1 million Votable Tokens, or an Ethereum address registered as the L1 voting address for one. Passing an AIP through this path requires both Threshold 1 and the Constitutional AIP requirements under Threshold 2 to be satisfied.

The arithmetic

The core quorum numerator is 5,000 — meaning 50% — applied to totalDelegated Votable Tokens at a locked snapshot block. The proposal sets a minimum quorum of 150 million ARB and a maximum of 450 million ARB. That’s a 300-million-ARB spread between floor and ceiling, with the floor sitting at one-third the ceiling’s size.

These are voting-power figures, not headcounts. The proposal-block lookback runs up to 300 L1 blocks — roughly one hour. A two-day late-quorum extension also applies.

The minimum timeline is 63 days

Every stage is sized to give delegates time to react and to allow L2 state assertions to confirm. The voting delay is 17 days: three days for delegate reaction, up to 14 for assertion confirmation. The voting period runs 21 days — 14 effective days plus a seven-day censorship budget.

After a passing vote, the action sits in L1VotingTimelock for at least 25 days: a 14-day worst-case assertion-confirmation window plus 11 additional days.

Stack those stages and you get 63 days as the minimum stated sequence from the start of the voting delay to the end of the minimum timelock — 17 plus 21 plus 25. That assumes the stages run as described and excludes whatever time it takes to create or submit a proposal before any of this begins.

The desk’s assessment: the clock trades speed for delegate reaction time and censorship resistance. The path stays available when L2 breaks down, but nothing reaches the upgrade executors until at least 25 days after the vote closes. For users of governed contracts, that means a 25-day minimum queue before any change lands.

The supplied materials contain no prior comparable Arbitrum recovery vote or exploit against which to measure this proposal.