Transfer Rollup Ownership to a Gating Contract

[just-mitch]

This proposal transfers ownership of the current rollup from direct governance control to a "Gating Contract" that classifies rollup owner functions into two tiers:

• Critical actions (escape hatch changes, ownership transfers) are subject to a 60-day timelock, giving users and operators a guaranteed long window to react and exit.
• Operational parameters (reward config, mana target, proving cost, slasher, ejection threshold, staking queue config) can be executed immediately after the standard governance approval/delay, but are subject to per-parameter rate-of-change constraints that limit how much they can move in a single update.

It is also suggested that all future rollups use this Gating Contract mechanism.

Background: How Governance Controls the Rollup Today

Governance owns the Registry, which tracks the canonical rollup instance, and the GSE (Governance Staking Escrow), which manages validator stake. When governance approves a proposal — for example, one that registers a new rollup version — it executes a payload contract that calls Registry.addRollup() and GSE.addRollup(). Further, Governance is the owner of each individual Rollup.

Today, the only delay between an approved proposal and its execution of any change to a rollup it owns is the governance execution delay (the timelock phase built into the Governance contract's proposal lifecycle). This means the rollup shares the same delay as every other governance action — parameter changes, treasury operations, etc. There is no separate, dedicated protection for rollup upgrades.

The governance proposal lifecycle is:

Pending (votingDelay) → Active (votingDuration) → Queued (executionDelay) → Executable (gracePeriod)

The executionDelay phase is the only timelock today. It applies uniformly to all governance actions.

Rollup Owner Functions

The rollup exposes the following owner-restricted functions. This proposal classifies each into one of two tiers:

Critical (60-day timelock)

These functions can change the trust assumptions of the chain or redirect control entirely. Users must have time to evaluate and exit before they take effect.

Function	Effect
updateEscapeHatch	Sets the escape hatch contract (fallback block production)
transferOwnership	Transfers ownership of the rollup itself

Operational (immediate, rate-constrained)

These functions tune economic and operational parameters. They need to be adjustable without a 60-day wait, but should be bounded so that a single governance action cannot make a drastic change.

Function	Effect	Suggested constraint
setRewardConfig	Sequencer/prover reward rates and booster settings	Individual fields cannot change by more than X% per update
updateManaTarget	Target mana per slot	Already constrained (can only increase); additional cap of X% per update
setProvingCostPerMana	Proving cost per mana unit (fee model input)	Cannot change by more than X% per update
setSlasher	Which contract can slash validators	None
setLocalEjectionThreshold	Minimum stake after slashing before ejection	Cannot change by more than X% per update
updateStakingQueueConfig	How validators enter the active set	Individual fields cannot change by more than X% per update

Note: The exact constraint values (the "X%" bounds) are to be determined. The intent is that no single governance action can, for example, set the proving cost per mana to basically infinity, making it impossible to include transactions.

Motivation

L2Beat's classification framework requires that users have roughly 30 days to react and still get an exit transaction included before a governance-triggered rollup change takes effect. If inclusion and exit can pessimistically take up to 20 days, a 60-day timelock still leaves ~40 days of real reaction time — well above the threshold.

The current approach of encoding this protection in the global governance execution delay is problematic because it couples rollup upgrade safety to the pacing of all governance actions, including sequencer withdrawals (whose delay formula includes executionDelay). A Gating Contract decouples these concerns:

• Critical rollup changes that affect Stage-2 status (escape hatch, ownership) get a 60-day timelock.
• Operational parameters (rewards, fees, staking config) can be updated promptly but within bounded ranges.
• Ordinary governance actions (and sequencer exits) use a shorter execution delay without weakening rollup protection.

Specification

A gating contract SHALL be deployed that becomes the owner of the current rollup. Further, all future canonical rollups SHALL be owned by a similar gating contract. The gating contract classifies incoming calls into two tiers:

Critical-tier calls (those listed in the Critical table above) MUST be routed through a timelock with a minimum delay of 60 days (5,184,000 seconds). The flow for critical actions:

Governance approves proposal
    → Proposal executes, scheduling action on timelock
    → 60-day timelock delay
    → Action executed on rollup

Operational-tier calls (those listed in the Operational table above) MAY be executed immediately after governance approval, but the gating contract MUST enforce per-parameter rate-of-change constraints. If a proposed parameter change exceeds the allowed bound, the call MUST revert.

The gating contract MUST be configured such that only governance (via approved proposals) can trigger either tier, and no actor can bypass the 60-day delay for critical-tier calls or the rate constraints for operational-tier calls.

No change to voting mechanics: This proposal does not modify voting thresholds, quorum requirements, or any other governance approval mechanism.

[sekuba]

Thank you for this swift proposal!
We were internally preparing to make a very similar proposal, and i will paste it below for reference and then, in another post, provide direct feedback to your OP.

There are two important hedges from my side:

1. To give you feedback asap, i am posting all this before our mandatory internal peer review among the full research team. This means that it is my opinion for now, L2BEAT will endorse it or comment on it next week when they are done reviewing my work.
2. L2BEAT never assesses a stage prospectively, meaning none of this guarantees stage 0, 1 or 2 for any Aztec deployment. The full final assessment will be published on l2beat.com

here is the AZIP draft i prepared for reference (it was not created with the knowledge of the two governance discussions here):

Summary

This AZIP describes a path to improve the decentralization and immutability of the current and future Aztec rollups, with the secondary objective of reaching stage 2 on L2BEAT.

Motivation

Decentralization is a core value of the Aztec Network. The network launched with ‘Day-1 Decentralization’ because perfecting this trait is a precondition for its neutrality and credibility as a privacy-focused rollup.

Problem

The currently deployed ‘Alpha’ version of the rollup system combines an unnecessarily long governance execution delay of 30d with practical mutability vectors in the rollup smart contract. This creates sluggish upgrades on the one hand and short exit windows for users on the other. The purpose of execution delays is creating an exit window in mutable rollup contexts. If Aztec rollups would include immutable exit guarantees, execution delays could decrease.

Mutability

Governance has access to configuration that can permanently affect the liveness of the rollup:

• Rollup.setSlasher() and Rollup.setLocalEjectionThreshold(): Set a malicious slasher contract and/or ejection threshold, allowing to slash any sequencer and eject them from the set
• Slasher.slash(): Slash any sequencer and eject them from the set
• unbounded configuration functions like Rollup.setRewardConfig(booster, rewardDistributor, ...) or Rollup.updateManaTarget(uint.max), Rollup.setProvingCostPerMana(uint.max) and GSE.setProofOfPossessionGasLimit(0): Freeze finalization, L2 transactions and staking respectively by using extreme values
• Rollup.updateStakingQueueConfig(normalFlushSizeMin=0, normalFlushSizeQuotient=max): Stop any new sequencers from joining the active set
• Rollup.updateEscapeHatch(ADDRESS): Use a dead or malicious ADDRESS to remove the escape hatch guarantee
• CoinIssuer.acceptTokenOwnership(): Change ownership of the AZTEC token and bypass minting limits (depends on ProtocolTreasury.GATED_UNTIL so can only be cleanly addressed in oct/nov 2026 unless using an esoteric filtering contract in front of the ProtocolTreasury)

Governance Delay

The 'Alpha' upgrade increased the Governance.getConfiguration().executionDelay from 7d to 30d. This increases the onchain minimum total upgrade latency to 40d, which may hinder the agility of the project in this early phase of development.

Goal

Making Aztec rollup exits fully immutable provides all users a perpetual exit guarantee, even under comparably short governance execution delays <30d.

Proposed Changes

Short term solution for the 'Alpha' rollup

1. Revoke ownership of the Rollup contract
2. Limit indirect full ownership of the AZTEC token (by changing the CoinIssuer to a more restricted variant or making it immutable, also see GATED_UNTIL comment above)
3. Governance.getConfiguration().executionDelay is decreased from 30d to 7d

Governance would still be able to access the GSE.setProofOfPossessionGasLimit(0) and Slasher.slash() vectors which prevents staking of new sequencers and can remove any active ones, but users would gain an immutable worst case exit guarantee through the escape hatch.

Long term solution for all future rollups

1. The configuration permissions Rollup.setRewardConfig(), Rollup.updateManaTarget(), Rollup.setProvingCostPerMana(), Rollup.updateStakingQueueConfig() and GSE.setProofOfPossessionGasLimit() are bounded / constrained so that they cannot cause reverts or prevent exit OR removed OR gated behind a specific extra long delay
2. Slashing/ejection permissions Rollup.setSlasher(), Rollup.setLocalEjectionThreshold() and Slasher.slash() are removed, bounded and throttled respectively
3. Remove Rollup.updateEscapeHatch(ADDRESS) or restrict the permission to decreasing the escape hatch bond
4. Revoke AZTEC token ownership via CoinIssuer.acceptTokenOwnership() to cap max supply (e.g. move to a new immutable CoinIssuer that has more granular permissions).

[sekuba]

in direct reply to the OP, i am commenting on the table here:

Function	Effect	Suggested constraint	comment
setRewardConfig	Sequencer/prover reward rates and booster settings	Individual fields cannot change by more than X% per update	fee fields cap %/time ; booster, rewardDistributor must not revert
updateManaTarget	Target mana per slot	Already constrained (can only increase); additional cap of X% per update	cap %/time
setProvingCostPerMana	Proving cost per mana unit (fee model input)	Cannot change by more than X% per update	cap %/time
setSlasher	Which contract can slash validators	None	None
setLocalEjectionThreshold	Minimum stake after slashing before ejection	Cannot change by more than X% per update	cap %/time
updateStakingQueueConfig	How validators enter the active set	Individual fields cannot change by more than X% per update	cap %/time ; normalFlushSizeMin > 0
CoinIssuer.acceptTokenOwnership()	Allows Governance to transfer the AZTEC token ownership after ProtocolTreasury.GATED_UNTIL		must be constrained at exactly or before ProtocolTreasury.GATED_UNTIL

main changes:

• multicalls could bypass the %/update cap, the throttling has to be solid under any circumstance
• provide a minimum flush size of 1
• booster and rewardDistributor must never revert so that setRewardConfig() cannot block finalization

The high-level constraint here is: The escape hatch must be immutable from the Governance perspective.

This includes hardening of all the fee change validations that would be able to block L2 transactions, proposing or proving. It also includes immutability of the AZTEC token because it is used as bond and fee asset.