Search

Search for projects by name or address

Aztec Network logo
Aztec Network

Badges

About

Aztec Network is a privacy-preserving ZK rollup that uses the AztecVM and Noir to support private and public smart contracts on Ethereum.


  • Total Value SecuredTVS
    No data
  • Past day UOPSDaily UOPS
    No data
  • Stage
  • Gas token
    AZTEC

  • Type
    ZK Rollup
  • Purposes
    Universal, Privacy
  • Chain ID
    677868

  • Tokens breakdown

    Value secured breakdown

    View TVS breakdown
    Sequencer failureState validationData availabilityExit windowProposer failure

    Badges

    About

    Aztec Network is a privacy-preserving ZK rollup that uses the AztecVM and Noir to support private and public smart contracts on Ethereum.

    Sequencer failureState validationData availabilityExit windowProposer failure
    Sequencer failure
    Decentralized Sequencer Set

    Users can permissionlessly become a sequencer by staking 200 K AZTEC to join the queue and wait to obtain committee-based block production rights. If the pseudo-randomly sampled committees censor proposals, anyone who bonds 332 M AZTEC will join the escape hatch candidate set. Every 2d 23h, a candidate is pseudo-randomly selected to propose and prove checkpoints fully autonomously. A candidate remains in the set until they are selected or leave voluntarily.

    State validation
    Validity proofs (SN)

    SNARKs are succinct zero knowledge proofs that ensure state correctness, but require trusted setup.

    Data availability
    Onchain (SD)

    All of the data (SD = state diffs) needed for proof construction is published onchain.

    Exit window
    10d

    Users have 10d to exit funds in case of an unwanted regular upgrade. There is a 1mo delay before a regular upgrade is applied, and withdrawal inclusion via the decentralized sequencer set is probabilistic and simulated to take up to 20d to be processed. Although core contracts are immutable, the onchain Governance system can designate a new ‘canonical’ rollup with a 1mo delay and has access to critical configuration permissions that can freeze or compromise the Rollup system, counting as an upgrade for the exit window.

    Proposer failure
    Self Propose

    Checkpoint proposals come from the open sequencer set, with the escape hatch providing a bonded fallback if the sampled committees are censoring or unavailable. Anyone with access to the required hardware can submit epoch root proofs which finalize the proven checkpoints.

    Aztec Network
    Aztec Network is a
    Stage 1
    ZK Rollup.
    The project passes the walkaway test: users can exit in the presence of malicious operators even if the Security Council disappears.

    Learn more about Rollup stages
    Please keep in mind that these stages do not reflect rollup security, this is an opinionated assessment of rollup maturity based on subjective criteria, created with a goal of incentivizing projects to push toward better decentralization. Each team may have taken different paths to achieve this goal.

    All transaction results (state diffs) are published in Ethereum blobs

    Each checkpoint proposal includes EIP-4844 blob commitments that are checked against the blob hashes in the proposing transaction. The epoch proof revalidates the accumulated blob commitments before the epoch is finalized.

    1. Rollup.sol - propose() on Etherscan
    2. Rollup.sol - validateBlobs() on Etherscan
    Learn more about the DA layer here: Ethereum logoEthereum
    A diagram of the state validation
    A diagram of the state validation

    Each epoch root proof is verified by the HonkVerifier smart contract on Ethereum before the proven checkpoint number is advanced and the epoch outbox state root is inserted into the Outbox. Proving is permissionless, and a single proof can cover one Checkpoint (1m 12s) to one epoch (38m 24s). Unproven checkpoints are pruned after the proof submission window of 1h 16m expires.


    State root proposals

    The rollup only advances the proven chain after submitEpochRootProof() succeeds. That call verifies the epoch proof and then inserts the epoch outbox state root for L2->L1 messaging.

    1. Rollup.sol - submitEpochRootProof() on Etherscan
    Validity proofs

    Each update to the system state must be accompanied by a ZK proof that ensures that the new state was derived by correctly applying a series of valid user transactions to the previous state. These proofs are then verified on Ethereum by a smart contract.

    1. Rollup.sol - submitEpochRootProof() on Etherscan
    2. HonkVerifier.sol - verify() on Etherscan
    Slashing

    Each stake of 200 K AZTEC that is locked to join the sequencer set and vote in governance can be slashed under certain conditions. Slashing is voted on by sequencers each time they propose a checkpoint and is grouped in rounds that span 4 epochs (2h 33m) each.

    Slashing conditions are programmed into each sequencer node and can be changed by node operators by updating or editing their node software. Nodes usually submit votes to slash automatically on L1. The TallySlashingProposer contract only enforces the formalities of the slashing system:

    • A given slashing round’s votes always target the checkpoint proposals from 2 rounds ago.
    • As soon as a round’s votes have reached a quorum of 65/128, it enters an execution delay of 28 rounds (2d 23h)
    • An automatically generated slashing payload is executable by anyone on L1 after the execution delay, applying the slashing penalties defined by the sequencer votes.

    Slashing penalties are defined onchain in three levels: large (2.00 K AZTEC), medium (2.00 K AZTEC), and small (2.00 K AZTEC). Offenses that lead to slashing usually include:

    • Inactivity: A sequencer fails to attest or propose when selected.
    • Data Withholding: A sequencer proposes a checkpoint including state diff data availability on L1 but withholds the public transaction bodies and/or CHONK proofs required for permissionless proving.
    • Invalidity: A sequencer attests to invalid proposals, multiple conflicting proposals, with invalid signatures, or proposes a block that is not proven in time.

    The above offense list is not exhaustive and not defined onchain but usually in the software the sequencers decide to run. This is also where the mapping of offenses to the slashing penalty levels can be defined.

    The SlashVeto Council is a 5/9 Multisig that can veto specific proposals and/or all slashing for 3d at a time.

    1. Slashing - Aztec Docs
    2. SlashVeto Council - Github
    3. slashveto.me - Monitor Slashing

    Trusted Setups

    Onchain verifier

    Used in

    Aztec Network logo

    Onchain verifier

    Used in

    Aztec Network logo
    A diagram of the upgrades and governance
    A diagram of the upgrades and governance

    Standard Path (Signaling)

    Because sequencers stake AZTEC tokens to secure the L2 network, they are also the primary governors of the system. Any governance proposal must be encoded and deployed as a smart contract payload on Ethereum. While core contracts are immutable, the onchain Governance system can designate a new ‘canonical’ rollup with a 1mo delay and has access to critical configuration permissions that can freeze or compromise the Rollup system. These permissions can only be accessed through the process described below.

    1. The Signaling Phase (GovernanceProposer)

    Aztec uses an onchain “Empire” signaling system. Active sequencers operating on the ‘canonical rollup’ (as defined by the Registry) call signal(payloadAddress) on the L1 GovernanceProposer contract during their designated L2 slots to support a specific upgrade payload. A voting round consists of 1,000 slots. To win a round and become a formal proposal, a payload must receive signals from at least 600 slots. Once quorum is reached, the payload is submitted to the L1 Governance contract.

    2. The Voting Phase (Governance)

    Once submitted, the proposal enters a delay and voting flow:

    • Pending (3d): At the end of this delay, voting power is snapshotted.
    • Active (7d): AZTEC token holders can vote. To pass, a proposal must reach a 20% Quorum of all staked power, and the yea votes must exceed a required margin of 33%.
    • Queued (1mo): If successful, the proposal enters an execution delay. This acts as an exit window, allowing dissenting sequencers to initiate a withdrawal of their staked tokens before the malicious/disagreed-upon code is executed.
    • Executable (7d): The proposal enters a grace period where anyone can call execute(). If not executed, it expires.

    Total standard delay from proposal to execution: 1mo 10d.

    Emergency Path (Circumvent Signaling)

    If the L2 sequencer set is offline, censoring, or acting maliciously, the GovernanceProposer cannot be used. To ensure liveness, anyone can bypass the Sequencer signaling phase using the proposeWithLock() function directly on the Governance contract.

    • An actor must lock 258 M AZTEC, roughly 2.5% of total supply
    • These funds are locked for an extended 3mo.
    • Once proposed, the payload enters the exact same 1mo 10d Voting Phase (Pending -> Active -> Queued -> Executable) as the standard path.

    Rollup Immutability

    The smart contract code of Rollup, its verifier and its canonical messaging contracts cannot be changed. However, Governance owns critical permissions for configuration parameters that can freeze the L2 indefinitely. ‘Upgrading’ a Rollup contract involves a Governance action that designates a new Rollup contract address as canonical. The GSE (Governance Staking Escrow) automatically migrates the voting power and stake of all active sequencers to the new rollup version if they staked to the default magic address 0x9064Fb41156D300196d5Eb95E0B3c1f08eBc39a8 instead of a specific immutable rollup. Importantly, Governance retains ownership of the old rollup, with the permissions to freeze it in the same or any future governance proposal. In summary and practice, the current Aztec rollup system is not immutable and prone to governance changes with the configured 1mo delay.

    Slashing and the SlashVeto Council

    Aztec features onchain slashing for equivocation or missing attestations, managed by Slasher and TallySlashingProposer.

    There is a protective Vetoer role held by the SlashVeto Council. The Council cannot upgrade the protocol, alter governance, or steal funds. Instead it is limited to two permissions:

    • call vetoPayload() to stop a specific slashing event.
    • call setSlashingEnabled(false), which pauses all slashing in the protocol for a period of 3d.

    Economics & Treasury

    • Coin Issuer: The CoinIssuer contract is owned by Governance and is authorized to mint new AZTEC tokens up to a cap of 20%.
    • Protocol Treasury: Funds owned by the DAO sit in the ProtocolTreasury. The Treasury has a hardcoded timestamp (approx. Nov 2026). Before this date, the DAO cannot spend Treasury funds. After this date, Treasury funds and token ownership can be moved with a Governance Proposal.

    There is no central operator

    There is no privileged sequencer. Anyone can stake 200 K AZTEC to join the sequencer queue, and anyone can call flushEntryQueue() to activate queued sequencers once the queue rules allow it.

    1. Rollup.sol - deposit() on Etherscan
    2. Rollup.sol - flushEntryQueue() on Etherscan

    Transactions are ordered by a staked committee

    Joining the sequecer set is permissionless and requires staking 200 K AZTEC. For each epoch, the rollup samples a 48-member committee from the active sequencer set of 0 and selects one proposer per slot. The committe and regular sequencer set can be circumvented via the escape hatch, which designates a bonded proposer (via RANDAO) who can publish checkpoints without committee attestations.

    1. Rollup.sol - getProposerAt() on Etherscan
    2. EscapeHatch.sol - selectCandidates() on Etherscan

    Regular messaging

    The user initiates L2->L1 messages by submitting a regular transaction on this chain. When the block containing that transaction is settled, the message becomes available for processing on L1. ZK proofs are required to settle blocks. Once the epoch root proof is verified, the rollup inserts the epoch root into the Outbox, from which withdrawals and other L2->L1 messages can be consumed on Ethereum. Withdrawals can be triggered privately on L2, revealing only the L1 part of the withdrawal.

    1. Rollup.sol - submitEpochRootProof() on Etherscan
    2. Outbox.sol - consume() on Etherscan

    Upgrades replace the canonical rollup

    The core contracts are immutable, but Governance owns the Registry and GSE and can register a new rollup version as canonical after the governance delay. Governance also owns critical config parameters that can freeze or compromise the Rollup system.

    1. Registry.sol - addRollup() on Etherscan
    2. Governance.sol - execute() on Etherscan
    A dashboard to explore contracts and permissions
    Go to Disco
    Disco UI Banner

    Ethereum

    Actors:

    Governance0x1102…B75e

    DAO contract used for proposals and token voting. Heavily interdependent with the GSE for voting power snapshots.

    • Can interact with CoinIssuer
      • mint new AZTEC in the bounds of the minting caps and forward the acceptOwnership() call to the AZTEC Token
    • Can interact with Slasher
      • slash sequencers from the active set
    • Can interact with GSE
      • add a new rollup address, which automatically triggers all sequencers staked in the bonus address to be migrated to the new rollup
    • Can interact with Rollup
      • change the escape hatch address and disable the escape hatch, change the slasher address which can slash arbitrary sequencers, change the sequencer queue config and disallow new sequencers joining, set the ejection threshold that exits sequencers from the active set, change various critical fee and reward configurations
    GovernanceProposer0x06Ef…63ef

    Intermediary contract that allows the L2 Sequencers operating the canonical rollup (as defined by the Registry) to submit formal proposals to the L1 Governance contract by signalling their support of any smart contract payload on L1 with each checkpoint proposal. A signalling round comprises 1000 checkpoints. 600 signals or more during one round allow submitting the payload as a governance proposal.

    • Can interact with Governance
      • create proposals
    CoinIssuer0x02FA…1CA6

    Manages the inflation and minting schedule of the Aztec token. It enforces an annual percentage cap and mints new tokens for the budget.

    • Can interact with AZTEC Token
      • mint unlimited amounts of the AZTEC token and transfer the ownership of the contract
    SlashVeto Council0xBbB4…7480

    A Multisig with 5/9 threshold.

    • Can interact with Slasher
      • veto specific slashing payloads and/or disable all slashing for 3d at a time
    • Can interact with AztecTokenPositionRegistry_ProtocolTreasury
      • set the time at which the ProtocolTreasury funds can be transfered and manage staker implementations referenced by this contract
    A dashboard to explore contracts and permissions
    Go to Disco
    Disco UI Banner
    A diagram of the smart contract architecture
    A diagram of the smart contract architecture

    Ethereum

    HonkVerifier0x70aE…1348

    ZK proof verification contract.

    EscapeHatch0x8c18…AD1B

    Provides a fallback mechanism for block production if the primary sequencer committee fails or censors. The committee is circumvented by allowing proposals by anyone who is able to post a large bond of 332,000,000 AZTEC. It maintains a set of bonded candidates and deterministically selects a designated proposer for a given ‘hatch’ period using RANDAO. If the designated proposer fails to propose and prove, their bond is slashed by 9,600,000 AZTEC. The minimum tax deducted from their bond is 1,660,000 AZTEC, even if the proposal is successful. The escape hatch regularly opens every 112 epochs, given there are any bonded candidates.

    Core rollup logic contract. It processes checkpoint proposals, verifies ZK proofs for state transitions, manages data availability, and coordinates validator selection and chain tip updates.

    • Roles:
      • owner: Governance

    Central directory that tracks the current ‘canonical’ (active) Rollup contract address and key system contracts like the Reward Distributor.

    Central staking manager independent of Rollup implementations. Sequencers deposit stake here through their chosen Rollup contract. Their stake is then transfered to the Governance contract and activated for voting. The GSE tracks which rollup instance validators are securing, and gives them an option to automatically move to the latest Rollup version.

    • Roles:
      • owner: Governance
    FeeJuicePortal
    Escrow
    0x2891…3617

    One-way gas bridge: Escrows the fee asset (AZTEC) used to pay for L2 mana (gas). Users deposit tokens here, which are minted on L2 via the Inbox. The Rollup contract holds exclusive rights to withdraw tokens from this portal to distribute them as rewards to L1 sequencers and provers. Apart from that, this escrow does NOT afford a way to withdraw tokens.

    The following tokens are included in the value secured calculation:
    AZTEC token logo

    Facilitates canonical L1 to L2 communication. It accepts messages (including fee asset deposits) from L1, accumulates them in an append-only frontier tree per checkpoint, and forces the Sequencers and the Rollup contract to sequentially consume the roots of these message trees, ensuring message inclusion.

    Facilitates L2 to L1 communication. It stores the roots of L2 to L1 message trees per epoch, which are inserted by the Rollup contract. Users and portals can consume these messages on L1 by providing a Merkle proof against the stored root. A nullifier bitmap prevents double consumption.

    RewardBooster0x1CbB…3D80

    Calculates ‘boosted’ reward shares for active provers based on a configured curve, incentivizing consistent participation.

    RewardDistributor0x3D6A…dfe0

    Holds tokens allocated for protocol rewards. The canonical Rollup contract (as defined by the Registry) calls this to distribute payments to sequencers and provers.

    The executor contract for penalties. It receives authorization to slash validator stakes, subject to an execution delay and a vetoer.

    • Roles:
      • governance: Governance
      • vetoer: SlashVeto Council
    ProtocolTreasury0x662D…802a

    Holds the protocol’s funds controlled by Governance. It acts as a timelocked executor for spending or relaying transactions approved by the DAO.

    • Roles:
      • governance: Governance the GATED_UNTIL timestamp has passed
    AZTEC Token0xA27E…62D2

    AZTEC token contract

    • Roles:
      • owner: CoinIssuer
    TallySlashingProposer0xa4a3…6958

    Allows the validator committee to vote on slashing a specific peer. Once a quorum is reached, it proposes a slash action to the Slasher.

    SlashPayloadCloneable0xAA43…B445

    A template for specific slashing payload contracts deployed deterministically to encode a slashing action (who to slash and how much) that the Slasher executes.

    AztecTokenPositionRegistry_ProtocolTreasury0xD938…0c80

    Used to set the time at which AZTEC tokens owned by the ProtocolTreasury are unlocked.

    • Roles:
      • owner: EOA 1