[CONSTITUTIONAL]: Establish an L1 Voting Recovery System

Proposals
1

[Constitutional] AIP: Establish an L1 Voting Recovery System

Abstract

This AIP proposes a L1 voting system that allows ArbitrumDAO proposals to be created, voted on, queued, and executed from Ethereum L1. Voting power is derived from ARB delegations proven against confirmed Arbitrum assertions. Approved actions would be routed through a new L1 timelock to the existing upgrade executors.

The system is intended as a last-resort recovery path if L2 governance is broken and the Security Council is unable to act. It does not replace normal L2 governance or modify the Security Council’s authority.

Motivation

A simultaneous failure of L2 governance and the Security Council could prevent the DAO from repairing its governance contracts. L2 governance could become unavailable because of a contract defect. Active delegates would still exist, but the DAO would have no independent path to authorize a repair.

The proposed system 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.

Rationale

  • Maintain an always-available L1 governance path so that it remains accessible during an emergency.
  • Use extended delays to preserve delegate reaction time, effective voting time, and a weaker form of the right to withdraw.

Specifications

For supporting technical documentation, see l1-voting.md.

Affected Governed Chains

To be confirmed before the temperature check. At that time this AIP will specify if it affects Arbitrum One and Arbitrum Nova.

System Components

  • L1ArbitrumGovernor: A modified OpenZeppelin governor that creates proposals, checks proven voting power, records votes, and queues successful proposals.
  • L1ArbitrumTimelock: A new deployment of the same timelock contract that exists on L1.
  • DelegateMapping: A contract deployed on L1 and L2 that links an L1 voting address to an L2 delegate.
  • L2StateMirror: A contract that checkpoints confirmed assertions and stores L2 state values proven against them.
  • ProofHelper: A helper contract for handling L2 block headers and storage proofs.
  • VotingTokenMirror: The governor-facing contract that resolves L1 voters to L2 delegates and returns proven voting power and quorum inputs.

Delegate Registration

  • Delegates using contract addresses: Must register an L1 voting address through DelegateMapping on Arbitrum One. Registration should preferably occur before an L1 proposal is created. Following proposal creation, delegates have 3 days to register so the updated mapping can be included in a confirmed assertion before voting begins.
  • Delegates using EOAs: May register an L1 voting address using an EIP-712 signature submitted through L2StateMirror.claimL1AddressBySig, without first registering the address on Arbitrum One. The signature is bound to the applicable assertion.
  • In both cases, the L1 voting address must claim the corresponding L2 delegate through the L1 DelegateMapping before proposing or voting.

Deployment Parameters

For more detail on the “7 day censorship budget”, see the BoLD whitepaper.

  • Voting delay: 17 days, comprising 3 days for delegate reaction, including acquiring voting power or registering in the L2 DelegateMapping, plus up to 14 days for assertion confirmation.
  • Voting period: 21 days, comprising 14 days of effective voting time plus a 7-day censorship budget
  • Timelock delay: 25 days, comprising a 14-day worst-case assertion-confirmation period plus 11 additional days corresponding to the current 8-day L2 timelock and 3-day L1 timelock.
  • Proposal block lookback: Up to 300 L1 blocks, approximately one hour, for the proposal-threshold checkpoint. This gives proposers time to prove prerequisite information in the L2StateMirror
  • Quorum numerator: 5000 (50%), applied to the totalDelegated Votable Tokens at the locked snapshot block, consistent with the core governor on L2.
  • Late-quorum extension period: 2 days, consistent with the core governor on L2.
  • Minimum and maximum quorum: 150 million and 450 million ARB, respectively, consistent with the core governor on L2.

Governance and Execution

  • Deploy the L1 governance components behind transparent proxies owned by the existing proxy admin or admins, as applicable. See DeployL1Voting.s.sol for the deployment procedure.
  • Grant the new L1 timelock the EXECUTOR_ROLE on the L1 upgrade executor.
  • Grant the L2 alias of the new L1 timelock the EXECUTOR_ROLE on the L2 upgrade executor.

Proposed Changes to the ArbitrumDAO Constitution

This proposal would amend Section 2 of the ArbitrumDAO Constitution to recognize an additional L1 voting procedure.

The existing AIP process on Arbitrum One would remain unchanged. The L1 Voting Procedure would operate as an additional DAO-controlled governance path using ARB voting power proven from confirmed Arbitrum state.

Clarify the Scope of the Existing Process

Location: Section 2: DAO Proposals and Voting Procedures

Current text:

The following process governs the rules and procedures by which the ArbitrumDAO may propose, vote on and implement Arbitrum Improvement Proposals (AIPs). No AIP may be in violation of applicable laws, in particular sanctions-related regulations.

Proposed new text:

The following process governs the rules and procedures by which the ArbitrumDAO may propose, vote on and implement Arbitrum Improvement Proposals (AIPs). For AIPs submitted through the L1 Voting Procedure described below, the rules and procedures in this Section apply except where expressly modified by the L1 Voting Procedure. No AIP may be in violation of applicable laws, in particular sanctions-related regulations.

Clarify the Existing Phase 2

Location: Section 2: DAO Proposals and Voting Procedures, Phase 2

Current text:

Phase 2: Formal AIP and call for voting (3 days): The AIP is submitted via governance contracts on Arbitrum One, with a user interface available on https://alt.gov.arbitrum.foundation/. The AIP proposer is required to have an address that is delegated at least 1,000,000 Votable Tokens. After 3 days, a voter distribution snapshot will be taken and the voting period will begin; this gives interested parties time to discuss the AIP and gather votes before the voter distribution snapshot is taken.

Proposed new text:

Phase 2: Formal AIP and call for voting (3 days): The AIP is submitted via governance contracts on Arbitrum One, with a user interface available on https://alt.gov.arbitrum.foundation/. The AIP proposer is required to have an address that is delegated at least 1,000,000 Votable Tokens.

After 3 days, a voter distribution snapshot will be taken and the voting period will begin;

this gives interested parties time to discuss the AIP and gather votes before the voter

distribution snapshot is taken.

For an AIP submitted through the L1 Voting Procedure, the requirements in the

preceding two paragraphs concerning submission, the proposer threshold, the voter

distribution snapshot and the start of voting are replaced by the corresponding

requirements of the L1 Voting Procedure. The remaining provisions of this Phase 2,

including those concerning labeling and classification of AIPs, specification of affected

Governed Chains, and the recommended AIP contents, apply to an AIP submitted

through the L1 Voting Procedure.

Clarify the Existing Phase 3

Location: Section 2: DAO Proposals and Voting Procedures, Phase 3

Current text:

Phase 3: DAO votes on AIP, on Arbitrum One (14-16 days): During this Phase 3, the ArbitrumDAO will be able to vote directly on-chain on a submitted AIP.

Proposed new text:

Phase 3: DAO votes on AIP, on Arbitrum One (14-16 days): During this Phase 3, the ArbitrumDAO will be able to vote directly on-chain on a submitted AIP, unless the AIP was submitted through the L1 Voting Procedure in which case voting takes place as provided in the L1 Voting Procedure. Threshold 1 and Threshold 2, as set out below, apply to every AIP, including an AIP submitted through the L1 Voting Procedure.

Add an L1 Voting Procedure

Location: Section 2: DAO Proposals and Voting Procedures

Current text:

No corresponding provision currently exists.

Proposed new text:

L1 Voting Procedure

In addition to the AIP process described above, the ArbitrumDAO may propose, vote on, approve, and implement AIPs through governance smart contracts deployed on Ethereum.

Voting power under this procedure must be derived from Votable Tokens delegated on Arbitrum One and proven on Ethereum against a confirmed Arbitrum One assertion.

The AIP proposer is required to have an address on Arbitrum One that is delegated at least 1,000,000 Votable Tokens, or an Ethereum address registered as the L1 voting address for such an address, in each case as proven against a confirmed Arbitrum One assertion.

Following submission of an AIP through the L1 Voting Procedure, voting will begin after 17 days . This comprises 3 days for delegates to gather voting power or register their L1 voting addresses, plus up to 14 days for assertion confirmation.

After the voting delay, the ArbitrumDAO will be able to vote directly on-chain through the governance smart contracts deployed on Ethereum. Before the first vote is cast, the voter distribution snapshot must be fixed to a confirmed Arbitrum One block.

The voting period ends 21 days after the start of voting. However, if Threshold 2 was reached within the last 2 days of the 21-day voting period, the voting period will be extended to end 2 days after Threshold 2 was reached.

An AIP submitted through the L1 Voting Procedure passes if Threshold 1 and the Constitutional AIP requirements under Threshold 2 are satisfied. Voting power and Delegated Votable Tokens will be determined using Arbitrum One state proven on Ethereum against the confirmed assertion used for the voter distribution snapshot.

If the AIP passes, it will be queued in the L1VotingTimelock, a governance timelock smart contract deployed on Ethereum, for a minimum period of 25 days. Following that period, the AIP may be implemented through the relevant upgrade executor or executors.

The provisions of Phases 2 and 3 identified above as replaced, and phases 4 through 7 of the ordinary AIP process, do not apply to an AIP submitted through the L1 Voting Procedure. Instead the 17-day voting delay, 21-day voting period, applicable late-quorum extension, and 25-day L1 timelock govern its submission, voting, approval, and implementation.

The provisions of this Section concerning forum discussion, temperature checks, AIP labeling and classification, affected Governed Chains, recommended AIP contents voting options, Threshold 1, and Threshold 2 apply to AIPs submitted through the L1 Voting Procedure, except that threshold 2 applies as provided above.

An AIP may not be submitted through the L1 Voting Procedure while another AIP proposing the same or conflicting actions is pending under the ordinary AIP process, and an AIP may not be submitted under the ordinary AIP process while another AIP proposing the same or conflicting actions is pending under the L1 Voting Procedure. An AIP is pending from its submission until it fails to pass or is implemented. As a recommended guideline, DAO members should vote against any AIP submitted in violation of this paragraph.

The L1 Voting Procedure does not replace or modify the ordinary AIP process. It does not modify the Security Council’s powers under Section 3 of this Constitution.

Steps to Implement

  1. Publish this proposal on the ArbitrumDAO governance forum for community and delegate review.
  2. Complete the forum discussion period.
  3. Submit the proposal to Snapshot for a temperature check.
  4. Incorporate applicable DAO feedback and finalize the contracts, deployment configuration, tests, and operating procedures.
  5. Complete an independent security audit and publish the audit report and applicable remediations.
  6. Test proposal creation, proof submission, voting, queuing, cross-chain execution, and recovery from stale checkpoints in a designated test environment.
  7. Publish the final contract addresses, verified source code, deployment parameters, audit materials, constitutional amendments, and executable governance payload.
  8. Submit the final Constitutional AIP through the standard ArbitrumDAO governance process.
  9. If approved, deploy and initialize the system, grant the required executor roles, and begin checkpoint monitoring.

Timeline

The implementation timeline will be finalized following technical review, audit scoping, and review by the Arbitrum Foundation and Legal.

  • Forum publication: This post
  • Temperature check: To be confirmed
  • Security audit and testing: Ongoing
  • Constitutional on-chain vote: Following successful technical review, audit, testing, and publication of the executable payload
  • Deployment: Subject to approval of the Constitutional AIP

Overall costs

All engineering and research conducted for this proposal was done so by Offchain Labs at no explicit or additional costs to the ArbitrumDAO

4 Likes
October 6, 2026 - Open Discussion of Proposals Governance Call
2

Excited to see this move forward, both as a fallback governance path and as potentially laying the groundwork for future changes. In favor!

3

@offchain, This proposal addresses a real recovery gap: it gives the DAO an L1 route while keeping voting power tied to delegated ARB proven from confirmed Arbitrum state. A few details would help delegates assess its safety and practical operation before the temperature check.

Could the authors clarify how old a cached assertion may be used, and when the system would pause rather than proceed on stale state? It would also help to show how the seven-day censorship allowance composes across assertion confirmation, snapshot proof, proposal and voting steps, and execution, including the sequencer assumptions. For delegation, please specify the EOA signature’s domain and replay protection, and how contract delegates can register and participate if L2 access is delayed.

Finally, could the specification state the completeness and immutability conditions for locking the snapshot, and demonstrate that delegates retain a practical exit window under worst-case delays? A concise permissions map showing which chains and actions the L1 timelock can reach would clarify the execution boundary. Before the temperature check, publishing the confirmed chain scope, final addresses and executable payload, test results, audit and remediation status, costs, and an operational runbook would give delegates a concrete basis for review.

2 Likes
4

There is no maximum assertion age and nothing pauses: checkpoints fall back to the last confirmed assertion, so the L1 route still works when the rollup stalls.

Each phase is padded for the full 7-day censorship budget: a 17d voting delay (3d + 14d worst-case confirmation), a 21d voting period (14d + 7d) and a 25d L1 timelock (14d + 8d + 3d), which keeps the same exit window as the L2 path. EOA claims are EIP-712 signatures bound to a single assertion hash on the L2StateMirror domain. Contract delegates register through the L2 DelegateMapping (force inclusion takes at most 24h).

The new L1 timelock holds the EXECUTOR_ROLE on both L1 and L2 upgrade executors, which is the same as the existing L1 timelock.

1 Like
5

Thanks for clarifying the design. The fallback to the last confirmed assertion and the separate seven-day censorship allowance in the voting delay, voting period, and L1 timelock make the intended timing model clearer. The EIP-712 assertion binding, DelegateMapping registration path, and executor roles matching the existing L1 timelock also address several of my questions.

One point still worth documenting is how delegates should assess the age of the state used when the rollup stalls, since the system does not impose a maximum assertion age or pause.

Could you also share tests showing that snapshot proofs are complete and remain fixed once voting begins, and that the stated delays preserve effective voting and exit time under the relevant failure conditions?

A permissions map would help confirm the practical reach of the L1 and L2 executor roles; links to tests, audit status, and deployment details would make those claims easier for delegates to verify.

1 Like
6

Entropy has posted this proposal to a temperature check vote on Snapshot on behalf of Offchain.

We are supportive of establishing an L1 Voting Recovery System, and as far as we can tell no other major L2 gives token holders an independent L1 route for governance recovery. We appreciate Offchain’s work in making Arbitrum’s governance system more resilient.

1 Like
7

I support establishing an independent Ethereum L1 recovery path if normal Arbitrum governance and the Security Council are unable to act. Keeping voting power tied to delegated ARB preserves tokenholder control, while extended delays allow time for review and participation.

The use of potentially old confirmed state needs clear documentation so delegates understand its implications during an outage.

Appreciate offchain thinking ahead and preparing for these tail scenarios before they occur.