Skip to main content
Version: Testnet (v3.0.1)

Governance

The Aztec network is governed by its community through an onchain governance system. This system allows the network to upgrade rollup contracts, adjust parameters, and evolve over time while maintaining security and decentralization.

Design Goals​

The governance system is designed around two core requirements:

  1. Backwards Compatibility: Users must always be able to bridge assets in and out of any rollup version that has ever existed
  2. Canonical Rewards: Only the most recent (canonical) rollup should receive block rewards

These goals shape the entire governance architecture, from how rollups are tracked to how upgrades are proposed and executed.

How Governance Works​

Governance follows a multi-stage process:

  1. Signaling: Block producers on the canonical rollup signal support for a payload by calling signal() on the Governance Proposer during their assigned slots
  2. Quorum: When enough signals are received within a round (e.g., 151 out of 300 slots), the payload qualifies for proposal
  3. Proposal Creation: Anyone can call submitRoundWinner() to formally submit the payload as a proposal to Governance
  4. Voting: Token holders vote on the proposal using their voting power (determined at the moment voting opens)
  5. Execution: After the voting period and execution delay, anyone can trigger execution of approved proposals

All signaling and voting happen on L1 (Ethereum).

Core Contracts​

The governance system consists of several interconnected smart contracts:

Registry​

The Registry maintains a list of all rollup contract instances. The most recent entry is considered "canonical" and is eligible to receive block rewards. The Registry's addRollup() function can only be called by the Governance contract.

Governance​

The Governance contract is the core of the system. It:

  • Receives proposals from the Governance Proposer
  • Tracks proposal state through their lifecycle
  • Manages voting power through deposits and withdrawals
  • Executes approved proposals

Governance Proposer​

The Governance Proposer is the gateway for submitting proposals. Only this contract can propose to Governance, ensuring that proposals have community support before entering the voting phase.

The Governance Proposer extends the EmpireBase contract, which implements the round-based signaling mechanism.

Governance Staking Escrow (GSE)​

The GSE bridges staking and governance. It:

  • Holds validator stakes on behalf of rollup contracts
  • Tracks voting power delegation
  • Enables stake to automatically move to new rollup versions
  • Allows validators to vote independently or delegate to the rollup

See GSE and Stake Mobility for details.

Key Concepts​

Payloads​

A payload is a contract that defines the actions to be executed if a proposal passes. Payloads implement the IPayload interface, which has a getActions() function returning a list of calls to make.

For example, a payload to register a new rollup would include a call to Registry.addRollup(newRollupAddress).

Rounds and Slots​

The signaling system operates in rounds, where each round consists of a fixed number of slots (e.g., 300 slots per round). A slot corresponds to approximately 36 seconds of L2 time.

During each slot, only the designated block proposer can signal for a payload. This prevents timing games and ensures signaling reflects genuine validator support.

Quorum​

For a payload to become a proposal, it must receive signals from a quorum of slots within a single round. For example, if quorum is set to 151 out of 300 slots, at least 151 different block proposers must signal for the same payload address within one round.

Voting Power​

Voting power in Governance comes from depositing tokens. Key points:

  • Power is timestamped at deposit time
  • When voting on a proposal, only power you had before the proposal became active counts
  • Withdrawing requires a two-step process with a delay (on the order of days)
  • Partial voting is allowed (e.g., vote "yea" with half your power, "nay" with the other half)

Topics in This Section​

For Sequencer Operators

To participate in governance as a sequencer (signaling and voting), see Governance Participation.

For Token Holders

To vote on proposals with your staked tokens, see Voting on Proposals.