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
    $185.75>1K%
  • Past day UOPSDaily UOPS
    0.02>1K%
  • Stage
  • Gas token
    AZTEC

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

  • Tokens 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.


    Total
    Canonically BridgedCanonically Bridged ValueCanonical
    Natively MintedNatively Minted TokensNative
    Externally BridgedExternally Bridged ValueExternal

    ETH & derivatives
    Stablecoins
    BTC & derivatives
    Other

    2026 Jul 14 — 24

    Past Day UOPS
    0.02>1K%
    Past Day Ops count
    2.12 K
    Max. UOPS
    0.02
    2026 Jul 23
    Past day UOPS/TPS Ratio
    1.00

    The section shows the operating costs that L2s pay to Ethereum.


    2026 Mar 30 — Jul 24


    Total cost
    $289.09 K
    Avg cost per L2 UOP
    $60.165504
    Avg cost per day
    $2.49 K

    This section shows how "live" the project's operators are by displaying how frequently they submit transactions of the selected type. It also highlights anomalies - significant deviations from their typical schedule.

    No ongoing anomalies detected

    2026 Jun 24 — Jul 24

    Avg. tx data subs. interval
    1 minute
    Avg. state updates interval
    2 minutes
    Past 30 days anomalies
    100% normal uptime

    Aztec v5 Upgrade

    2026 Jul 14th

    Governance makes v5 canonical which hardens the immutability and fixes vulnerabilities.

    Learn more

    Cut the Leash

    2026 Jun 22nd

    Ownership of the v4 Rollup is revoked, promoting it to Stage 2 (immutable).

    Learn more
    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)

    State diffs needed to reconstruct the L2 state are published in Ethereum blobs. Public transaction bodies and client CHONK proofs propagate offchain, so withholding them can prevent permissionless proving; the affected pending checkpoints expire and are pruned rather than finalized.

    Exit window

    Users can exit funds at any time because contracts are not upgradeable. Governance can register a new canonical rollup and bonus-instance validators automatically follow the latest version, but this does not mutate the current instance, its verifier, messaging contracts, or already-installed EscapeHatch. Governance can change bounded validator-entry parameters and can set the GSE proof-of-possession gas limit too low for new deposits; validators explicitly bound to this instance remain on it.

    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 2
    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 Stages
    Please keep in mind that these stages do not reflect project security, this is an opinionated assessment of project 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 for state diffs, checked against the blob hashes in the proposing transaction. The epoch proof revalidates the accumulated commitments before finalization. Public transaction bodies and client CHONK proofs propagate offchain; withholding them can prevent permissionless proving, causing the pending checkpoint to expire and be pruned rather than 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). The current maximum proof window is 1h 16m; checkpoints later in an epoch have less time, and unproven checkpoints are pruned.


    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 200 K AZTEC stake used to join the sequencer set and vote in governance can be slashed. The designated proposer for each slot can submit one separate signed ballot on L1. Ballots are grouped into rounds spanning 4 epochs (2h 33m).

    Slashing conditions are implemented in sequencer-node software and can change when operators update or modify that software. The onchain SlashingProposer enforces the voting and execution rules:

    • Ballots in a round target committee members from 2 rounds earlier.
    • Quorum is evaluated separately for each validator position and penalty level, not for the round as a whole. At least 65 matching ballots out of up to 128 slots are required. Votes for a higher penalty also count toward every lower level, and each validator is slashed once at the highest level that reaches quorum.
    • A round becomes executable after more than 28 rounds (approximately 2d 23h) and expires at age 34 rounds, leaving a 6-round execution window.
    • Anyone can call executeRound() during that window. It verifies committee commitments, skips escape-hatch epochs, deploys a deterministic payload for the approved actions, and asks the authorized Slasher to execute it.

    The current onchain penalty levels are large (5.00 K AZTEC), medium (5.00 K AZTEC), and small (2.00 K AZTEC). Offenses that node software can ballot for include:

    • Inactivity: a sequencer fails to attest or propose when selected.
    • Data withholding: a sequencer publishes state-diff blobs but withholds public transaction bodies or CHONK proofs needed for permissionless proving.
    • Invalidity or equivocation: a sequencer attests to an invalid proposal, signs conflicting proposals or attestations, or uses an invalid signature.

    This list and the mapping of offenses to penalty levels are not exhaustive or defined by the L1 contracts; they depend on the software each sequencer runs.

    The SlashVeto Council is a 5/9 Multisig. It can permanently veto a specific payload, repeatedly renew a global 3d pause, or re-enable slashing before a pause expires. Governance can submit Slasher payloads without ballot approval, but it cannot bypass these veto and pause checks.

    1. SlashingProposer.sol on Etherscan
    2. Slasher.sol on Etherscan
    3. SlashVeto Council - Github
    4. 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 (sequencer signaling)

    Sequencers stake AZTEC to secure the L2 and also participate in protocol governance. Every proposal is a smart contract payload on Ethereum. The public proposal flow takes at least 12d before execution, after which Governance can change the bounded parameters described below or deploy and register a new canonical rollup version.

    1. Signaling (GovernanceProposer)

    Aztec uses an onchain “Empire” signaling system. The designated proposer for each slot on the canonical rollup can separately signal support for one payload on L1. A round consists of 1,000 slots. A payload that receives at least 600 signals wins the round and can be submitted to Governance.

    2. Token voting (Governance)

    Once submitted, a proposal passes through these states:

    • Pending (3d): voting power is snapshotted at the end of this delay.
    • Active (7d): AZTEC holders vote. The snapshot must contain at least 100 M AZTEC of total voting power, at least 20% of that power must vote, and yea must be strictly greater than 66.5% of votes cast (the configured yea-minus-nay margin is 33%).
    • Queued (2d): a successful proposal waits before it can be executed. This final phase alone is shorter than the validator withdrawal delay, but the complete public process provides at least 12d of notice. Initiating an exit immediately removes a validator from the active set, while its stake becomes withdrawable after 4d.
    • Executable (7d): anyone can execute the proposal during this grace period; otherwise it expires.

    Emergency proposal path

    If sequencer signaling is unavailable, anyone can call proposeWithLock() directly on Governance. The proposer must lock 258 M AZTEC, roughly 2.5% of the total supply, for 3mo. The payload then follows the same pending, voting, queued, and executable phases as a signaled proposal.

    Immutable deployments and bounded ownership

    The Rollup, verifier, Inbox, Outbox, and installed EscapeHatch code cannot be upgraded in place. Feature upgrades deploy a new stack and use Governance to register its Rollup in the Registry and GSE. Validators staked to the bonus instance (0x9064Fb41156D300196d5Eb95E0B3c1f08eBc39a8) follow the newest GSE Rollup automatically; validators explicitly bound to an older Rollup remain associated with it.

    Governance owns the Rollup, but its setter surface is intentionally constrained: it can change the sequencer/prover reward split and checkpoint reward, only increase the mana target, change proving cost delayed and within bounds, and update validator-entry rate within non-zero values. It can queue a replacement Slasher with a 2mo delay. The outgoing Slasher then remains active for 1mo. The EscapeHatch, the reward distributor and reward-booster addresses are fixed for the deployment.

    Governance also owns the GSE and can register a new latest Rollup or set the proof-of-possession gas limit too low for new validator deposits. These powers can move incentives and bonus-instance validators away from the current version, but they do not mutate this deployment’s verifier, messaging contracts, or installed EscapeHatch.

    Slashing and the SlashVeto Council

    Aztec’s onchain slashing path uses SlashingProposer ballots and the Slasher. Governance can bypass the proposer and submit a payload directly to the Slasher, and can rotate the authorized Slasher through the delayed Rollup process described above. Both the ballot and direct-governance paths remain subject to payload vetoes and global pauses by the SlashVeto Council.

    The Vetoer role is held by the SlashVeto Council. It cannot upgrade the protocol or relay arbitrary calls. It can:

    • veto a specific payload permanently; and
    • disable all slashing for 3d. Calling the function again renews the pause, while the Council can also re-enable slashing early.

    Economics and treasury

    • CoinIssuer: the owner can mint AZTEC within an annual cap of 20% of the current total supply.
    • ProtocolTreasury: the DAO’s treasury is gated until approximately Nov 2026 and is additionally subject to an ATP-derived activation timestamp and proposal-ordering checks. Once every gate is satisfied, a Governance proposal can relay arbitrary calls and value through the treasury.
    2026 July 23, 13:53 UTC
    2changes

    Slashing was disabled for ~ three more days, until July 26.

    contract Slasher (eth:0xCD6855470A01aBcd989126A1183Fb50673952548) [aztecnetwork/Slasher] {
    +++ description: Executes payload actions submitted by the authorized slashing proposer or Governance. Execution is blocked while slashing is disabled or when the vetoer has vetoed the payload; voting and execution-delay rules are enforced by the proposer, while Governance can bypass the proposer.
    +++ description: Timestamp until which slash payload execution is disabled.
    values.slashingDisabledUntil:
    - 1784800907
    + 1785056291
    }
    2026 July 21, 08:48 UTC
    4changes

    Slashing vetoed for 3d (will be extended to cover payloads targeting epochs until incl. july 21 10pm). Reason: The grace period after the v5 upgrade was miscommunicated to be 1 week while it was actually 1 day only.

    contract Slasher (eth:0xCD6855470A01aBcd989126A1183Fb50673952548) [aztecnetwork/Slasher] {
    +++ description: Executes payload actions submitted by the authorized slashing proposer or Governance. Execution is blocked while slashing is disabled or when the vetoer has vetoed the payload; voting and execution-delay rules are enforced by the proposer, while Governance can bypass the proposer.
    +++ description: Whether slash payload execution is currently enabled.
    values.isSlashingEnabled:
    - true
    + false
    +++ description: Timestamp until which slash payload execution is disabled.
    values.slashingDisabledUntil:
    - 0
    + 1784800907
    }
    2026 July 15, 10:25 UTC
    50changes

    Aztec v5 is canonical with its current verifier, messaging, reward, and slashing stack; The immutable escape patch via Escape Hatch remains and the Rollup config is hardened against malicious governance.

    contract GovernanceProposer (eth:0x06Ef1DcF87E419C48B94a331B252819FADbD63ef) [aztecnetwork/GovernanceProposer] {
    +++ description: Intermediary contract through which the designated proposer for each L2 slot can signal support for an L1 payload. A signalling round comprises 1000 slots. A payload that receives at least 600 signals can be submitted to the L1 Governance contract within the configured lifetime.
    +++ description: Rollup instance whose checkpoint proposers can signal proposals.
    values.getInstance:
    - "eth:0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962"
    + "eth:0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34"
    }
    contract Governance (eth:0x1102471Eb3378FEE427121c9EfcEa452E4B6B75e) [aztecnetwork/Governance] {
    +++ description: DAO contract used for proposals and token voting. Heavily interdependent with the GSE for voting power snapshots.
    receivedPermissions.2:
    - {"permission":"interact","from":"eth:0x3D6A1B00C830C5f278FC5dFb3f6Ff0b74Db6dfe0","description":"recover AZTEC from any implicit or earmarked accounting bucket and recover any non-AZTEC token held by the distributor.","role":".registryOwner"}
    receivedPermissions.3.condition:
    - "slashing is enabled and the payload has not been vetoed."
    receivedPermissions.3.role:
    - ".GOVERNANCE"
    + ".registryOwner"
    receivedPermissions.3.description:
    - "execute arbitrary payload actions through the Slasher, bypassing all proposer validation including ballots, quorum, target construction, delay, and lifetime."
    + "recover AZTEC from any implicit or earmarked accounting bucket and recover any non-AZTEC token held by the distributor."
    receivedPermissions.3.from:
    - "eth:0x64E6e9Bb9f1E33D319578B9f8a9C719Ca6D46eBb"
    + "eth:0x555bAAc4757A89f1CE0c84fA35afE9dD7aa8E1d3"
    receivedPermissions.4:
    + {"permission":"interact","from":"eth:0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34","description":"change the sequencer reward share and checkpoint reward, only increase the mana target, update proving cost within its step and cooldown bounds, update validator entry-queue limits subject to nonzero normal-phase limits and bounded bootstrap settings, queue or cancel a Slasher replacement subject to the replacement delay, set the EscapeHatch once if still unset, and transfer or renounce ownership.","role":".owner"}
    receivedPermissions.5:
    + {"permission":"interact","from":"eth:0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34","description":"slash and eject validators while this contract is configured as the active Slasher.","role":".getSlasher","condition":"the active Slasher authorizes the call under its own execution rules.","via":[{"address":"eth:0xCD6855470A01aBcd989126A1183Fb50673952548","condition":"slashing is enabled and the payload has not been vetoed."}]}
    receivedPermissions.7:
    + {"permission":"interact","from":"eth:0xCD6855470A01aBcd989126A1183Fb50673952548","description":"execute arbitrary payload actions through the Slasher, bypassing all proposer validation including ballots, quorum, target construction, delay, and lifetime.","role":".GOVERNANCE","condition":"slashing is enabled and the payload has not been vetoed."}
    directlyReceivedPermissions.0:
    - {"permission":"act","from":"eth:0x64E6e9Bb9f1E33D319578B9f8a9C719Ca6D46eBb","description":"execute arbitrary payload actions through the Slasher, bypassing all proposer validation including ballots, quorum, target construction, delay, and lifetime.","role":".GOVERNANCE","condition":"slashing is enabled and the payload has not been vetoed."}
    directlyReceivedPermissions.1:
    + {"permission":"act","from":"eth:0xCD6855470A01aBcd989126A1183Fb50673952548","description":"execute arbitrary payload actions through the Slasher, bypassing all proposer validation including ballots, quorum, target construction, delay, and lifetime.","role":".GOVERNANCE","condition":"slashing is enabled and the payload has not been vetoed."}
    }
    - Status: DELETED
    contract RewardBooster (eth:0x1CbB707Bd7b4Fd2BcED6D96d84372fb428e93D80) [aztecnetwork/RewardBooster]
    +++ description: Calculates boosted reward shares for active provers based on a configured curve, incentivizing consistent participation.
    - Status: DELETED
    contract FeeJuicePortal (eth:0x2891F8b941067F8B5a3F34545A30Cf71E3E23617) [aztecnetwork/FeeJuicePortal]
    +++ description: 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.
    contract Registry (eth:0x35b22e09Ee0390539439E24f06Da43D83f90e298) [aztecnetwork/Registry] {
    +++ description: Central directory that tracks the current 'canonical' (active) Rollup contract address and key system contracts like the Reward Distributor.
    +++ description: The latest registered rollup instance, treated as canonical by the Aztec contracts.
    values.getCanonicalRollup:
    - "eth:0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962"
    + "eth:0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34"
    +++ description: The Registry-selected reward distributor. An existing Rollup keeps the distributor fixed at its deployment and is not retargeted when this pointer changes.
    values.getRewardDistributor:
    - "eth:0x3D6A1B00C830C5f278FC5dFb3f6Ff0b74Db6dfe0"
    + "eth:0x555bAAc4757A89f1CE0c84fA35afE9dD7aa8E1d3"
    +++ description: Registered rollup version identifiers in insertion order.
    values.getVersion.2:
    + 4248422647
    +++ description: Number of rollup versions registered in the registry.
    values.numberOfVersions:
    - 2
    + 3
    }
    - Status: DELETED
    contract RewardDistributor (eth:0x3D6A1B00C830C5f278FC5dFb3f6Ff0b74Db6dfe0) [aztecnetwork/RewardDistributor]
    +++ description: Holds tokens allocated for protocol rewards. The canonical Rollup contract, as defined by the Registry, can draw from the implicit reward pool while any address can claim only funds explicitly earmarked to it.
    - Status: DELETED
    contract Slasher (eth:0x64E6e9Bb9f1E33D319578B9f8a9C719Ca6D46eBb) [aztecnetwork/Slasher]
    +++ description: Executes payload actions submitted by the authorized slashing proposer or Governance. Execution is blocked while slashing is disabled or when the vetoer has vetoed the payload; voting and execution-delay rules are enforced by the proposer, while Governance can bypass the proposer.
    - Status: DELETED
    contract EscapeHatch (eth:0x8c189ead28D5987A48e522162f9225124D50AD1B) [aztecnetwork/EscapeHatch]
    +++ description: Provides a fallback mechanism for block production if the primary sequencer committee fails or censors. Candidates post a bond of 332,000,000 AZTEC and enter the candidate set. For each hatch, the contract snapshots the eligible set and uses RANDAO to select one designated proposer; posting a bond does not grant immediate proposal rights. 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 eligible bonded candidates.
    - Status: DELETED
    contract Inbox (eth:0x8Dbf0b6ed495baAb6062f5D5365aF3C1B2ed4578) [aztecnetwork/Inbox]
    +++ description: 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.
    - Status: DELETED
    contract TallySlashingProposer (eth:0xa4a38fD0108C00983E75616b638Ff3321FD26958) [N/A]
    +++ description: None
    contract GSE (eth:0xa92ecFD0E70c9cd5E5cd76c50Af0F7Da93567a4f) [aztecnetwork/GSE] {
    +++ description: Central staking manager independent of Rollup implementations. Sequencers deposit stake here through their chosen Rollup contract. Their stake is then transferred 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.
    +++ description: Latest rollup registered in the GSE. Validators assigned to the bonus instance follow this address.
    values.getLatestRollup:
    - "eth:0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962"
    + "eth:0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34"
    }
    - Status: DELETED
    contract SlashPayloadCloneable (eth:0xAA43220b7eb7c8Ffe75bc9C483f3C07b0a55B445) [aztecnetwork/SlashPayloadCloneable]
    +++ description: A template for specific slashing payload contracts deployed deterministically to encode one or more slashing actions (validators and amounts) that the Slasher executes.
    - Status: DELETED
    contract Rollup (eth:0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962) [N/A]
    +++ description: None
    contract SlashVeto Council (eth:0xBbB4aF368d02827945748b28CD4b2D42e4A37480) [GnosisSafe] {
    +++ description: None
    receivedPermissions.0.from:
    - "eth:0x64E6e9Bb9f1E33D319578B9f8a9C719Ca6D46eBb"
    + "eth:0xCD6855470A01aBcd989126A1183Fb50673952548"
    }
    - Status: DELETED
    contract Outbox (eth:0xc9698B7AdEf9ee63F3Bf5cFF38086e4E836579f0) [aztecnetwork/Outbox]
    +++ description: 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.
    + Status: CREATED
    contract HonkVerifier (eth:0x098f47c00F4df22a8030746Eb11378236C24b4bC) [aztecnetwork/HonkVerifier]
    +++ description: ZK proof verification contract.
    + Status: CREATED
    contract RewardBooster (eth:0x4490cAb7Ce3499353E1b0090b9e530c1AD03B551) [aztecnetwork/RewardBooster]
    +++ description: Calculates boosted reward shares for active provers based on a configured curve, incentivizing consistent participation.
    + Status: CREATED
    contract RollupOperationsExtLib (eth:0x516f010C9AB452d70E0c6f78b9E698249a66d2AC) [aztecnetwork/RollupOperationsExtLib]
    +++ description: Library immutably linked into the Rollup for checkpoint proposal, proof verification, pruning, and chain-tip operations. Its functions operate on the calling Rollup's storage through DELEGATECALL, so direct getter calls on the library are ignored.
    + Status: CREATED
    contract RewardDistributor (eth:0x555bAAc4757A89f1CE0c84fA35afE9dD7aa8E1d3) [aztecnetwork/RewardDistributor]
    +++ description: Holds tokens allocated for protocol rewards. The canonical Rollup contract, as defined by the Registry, can draw from the implicit reward pool while any address can claim only funds explicitly earmarked to it.
    + Status: CREATED
    contract SlashPayloadCloneable (eth:0x57576AbA1932df7Cc30F971ACC9d4Fc6E86B6e87) [aztecnetwork/SlashPayloadCloneable]
    +++ description: A template for specific slashing payload contracts deployed deterministically to encode one or more slashing actions (validators and amounts) that the Slasher executes.
    + Status: CREATED
    contract Outbox (eth:0x5B062aB5fD3A66BC7e73b04CeD38587673b6A2D7) [aztecnetwork/Outbox]
    +++ description: 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.
    + Status: CREATED
    contract Inbox (eth:0x7d4Ef0676c2032bbCC09227501D34d86641ab8cA) [aztecnetwork/Inbox]
    +++ description: 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.
    + Status: CREATED
    contract SlashingProposer (eth:0x8A36b8F2Ca71D8d8Bd98e03Ebf8B4D0939Daf0bA) [aztecnetwork/SlashingProposer]
    +++ description: Collects one signed slashing ballot from the designated proposer in each slot. After the execution delay, anyone can tally the ballots per validator and penalty level, deploy the resulting payload, and ask the Slasher to execute it before the round expires.
    + Status: CREATED
    contract Rollup (eth:0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34) [aztecnetwork/Rollup]
    +++ description: 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.
    + Status: CREATED
    contract FeeJuicePortal (eth:0xaf73Dd51D1eb8a079BB097f39c832cDD00ac691c) [aztecnetwork/FeeJuicePortal]
    +++ description: 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.
    + Status: CREATED
    contract Slasher (eth:0xCD6855470A01aBcd989126A1183Fb50673952548) [aztecnetwork/Slasher]
    +++ description: Executes payload actions submitted by the authorized slashing proposer or Governance. Execution is blocked while slashing is disabled or when the vetoer has vetoed the payload; voting and execution-delay rules are enforced by the proposer, while Governance can bypass the proposer.
    + Status: CREATED
    contract RewardExtLib (eth:0xD6E890c615d6f99681a00771C20ed04516288898) [aztecnetwork/RewardExtLib]
    +++ description: Library immutably linked into the Rollup for sequencer and prover reward accounting. Its functions operate on the calling Rollup's storage through DELEGATECALL, so direct getter calls on the library are ignored.
    + Status: CREATED
    contract ValidatorOperationsExtLib (eth:0xe4F0b9769Ca04a6E3d93b5BA732b5aD80797D411) [aztecnetwork/ValidatorOperationsExtLib]
    +++ description: Library immutably linked into the Rollup for validator entry, exits, slashing, and Slasher rotation. Its functions operate on the calling Rollup's storage through DELEGATECALL, so direct getter calls on the library are ignored.
    + Status: CREATED
    contract EscapeHatch (eth:0xF459348962F5eA3A9A101826B03A2CE1F459E51A) [aztecnetwork/EscapeHatch]
    +++ description: Provides a fallback mechanism for block production if the primary sequencer committee fails or censors. Candidates post a bond of 332,000,000 AZTEC and enter the candidate set. For each hatch, the contract snapshots the eligible set and uses RANDAO to select one designated proposer; posting a bond does not grant immediate proposal rights. 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 eligible bonded candidates.
    2026 July 08, 12:22 UTC
    2changes

    v5 upgrade payload passes signaling and is proposed to the Governance contract.

    contract Governance (eth:0x1102471Eb3378FEE427121c9EfcEa452E4B6B75e) [aztecnetwork/Governance] {
    +++ description: DAO contract used for proposals and token voting. Heavily interdependent with the GSE for voting power snapshots.
    values.proposalCount:
    - 4
    + 5
    }
    2026 June 22, 12:31 UTC
    5changes

    Execute 'cut the leash' upgrade. This revokes ownership of the current rollup contract. Gov execution delay is reduced to 2d (from 30d). Since gov cannot change the escape hatch or critical configs on the current rollup, Aztec Network is now Stage 2. At the same time, there are known vulnerabilities, which places all escrowed funds at risk.

    contract Governance (eth:0x1102471Eb3378FEE427121c9EfcEa452E4B6B75e) [aztecnetwork/Governance] {
    +++ description: DAO contract used for proposals and token voting. Heavily interdependent with the GSE for voting power snapshots.
    values.getConfiguration.executionDelay:
    - 2592000
    + 172800
    receivedPermissions.3:
    - {"permission":"interact","from":"eth:0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962","description":"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.","role":".owner"}
    }
    contract Rollup (eth:0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962) [aztecnetwork/Rollup] {
    +++ description: 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.
    values.owner:
    - "eth:0x1102471Eb3378FEE427121c9EfcEa452E4B6B75e"
    + "eth:0x0000000000000000000000000000000000000000"
    }

    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

    Bonded, probabilistic self-sequencing

    There is no L1 forced-transaction queue. A censored user must wait for an honest regular committee or for an honest, sufficiently capitalized escape-hatch candidate to enroll, become eligible, be selected, include the transaction, and produce a valid proof.

    • Users can be censored if no honest regular proposer or eligible bonded escape-hatch proposer includes and proves their transactions.

    1. EscapeHatch.sol on Etherscan

    Transactions are ordered by a staked validator committee

    Joining the sequencer set is permissionless and requires staking 200 K AZTEC. For each epoch, the Rollup samples a 48-member committee from the active set of 3449 and selects one proposer per slot. The proposer for slot N builds the checkpoint and collects attestations during slot N-1, then submits the assembled checkpoint to Ethereum in slot N. More than two-thirds of the sampled committee must attest; the proof path verifies the attestation data before the checkpoint can become final.

    Sequencer set spec sheet
    L2 block time6s
    Proposer rotation1m 12s
    Committee rotation38m 24s
    Number of block producers3449 sequencers
    Access to block production rightsOpen
    Stake per validator200 K AZTEC, constant
    Rate-limit to joinUp to 4 sequencers per epoch (current)
    Deterministic CR gadgetNo
    Additional CR gadgetsBonded escape hatch, private transactions

    Inclusion delay by censorship fraction

    T99 inclusion delay in a static sequencer set by censoring fraction of sequencers/validators

    Top 1: Nethermind
    Top 2: +Nansen | Stake to Stack Points
    Top 3: +Sigma Prime
    Top 4: +P2P.org
    Top 5: +snoopfear|PON

    The chart models live-chain selective censorship only. It does not model the escape hatch, validator-set changes, validator-set lag, and blanket-censorship resistance gadgets.

    Censorship resistance

    The regular committee can be circumvented by the escape hatch, which uses RANDAO to designate a previously enrolled bonded candidate that may publish checkpoints without committee attestations. Enrollment requires 332 M AZTEC, a high bond intended to protect the single-proof system while providing a last-resort path around the regular sequencer set. Aztec’s private execution environment can also make selective censorship harder because transaction contents are hidden.

    Selective censorship

    On a live network with some censoring sequencers, users can submit private transactions or wait for an honest committee and proposer to include their public transaction.

    Blanket censorship

    If the entire active set censors or stops producing checkpoints, a new sequencer can join through the permissionless staking queue, subject to its churn limits. A sufficiently capitalized account can instead enroll for the escape hatch, but enrollment, candidate-set snapshots, eligibility, and RANDAO selection are lagged. Specialized proving hardware is still required. Adversaries can also saturate the entry queue or candidate set and reduce an honest user’s inclusion probability.

    Walkaway

    Hatch opportunities occur approximately every 2d 23h, but the candidate set can be empty and selection, proposal, and proving can fail. The protocol therefore provides no deterministic maximum inclusion delay; permissionless validator entry and the bonded hatch only improve the probability that the chain eventually recovers.

    1. Aztec docs - Privacy considerations
    2. Rollup.sol - getProposerAt() on Etherscan
    3. 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 has been 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 initiated privately on L2, revealing only the L1-facing portion of the transaction. There is no canonical bridge escrow: only the canonical messaging layer is immutable, while each token bridged through a locking escrow may introduce additional trust assumptions tied to that specific escrow.

    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.

    1. Registry.sol - addRollup() on Etherscan
    2. Governance.sol - execute() on Etherscan

    No canonical bridge escrow

    There is no default canonical escrow. The rollup is deployed only with an immutable canonical messaging bridge, which can be used by any escrow. As a result, each token bridged to Aztec via Ethereum lock-mint must be assessed individually by examining its specific locking escrow. The trust assumptions of a given escrow may differ from those of the immutable rollup itself. Gas tokens are bridged through the FeeJuicePortal, an immutable one-way portal that only supports bridging to public L2 addresses. Although the rollup and its canonical messaging bridge are immutable, an upgradeable escrow could migrate its funds to a new rollup version without requiring users to migrate, effectively trading immutability for convenience.

    1. FeeJuicePortal.sol - on Etherscan
    2. Outbox.sol - on Etherscan

    Inclusion is probabilistic

    All protocol-level censorship-resistance tools are probabilistic. Unlike an L1 forced-transaction queue, they do not guarantee inclusion after a fixed delay. The launch-era decentralized-sequencer model estimated 20d to reach its target exit probability under its stated assumptions; it is not a current protocol guarantee and does not model validator-set changes, the escape hatch, or adversarial queue saturation. Private transactions and the bonded escape hatch can improve inclusion probability, but neither creates a deterministic deadline.

    1. CRsim - Simulated inclusion probability on Aztec
    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 within the annual cap, accept ownership of the AZTEC token when pending, and transfer or renounce CoinIssuer ownership
    • Can interact with Registry
      • register a new canonical rollup version, update the Registry-selected reward distributor pointer, and transfer or renounce Registry ownership. Updating the pointer does not change a distributor fixed in an already deployed Rollup
    • Can interact with RewardDistributor
      • recover AZTEC from any implicit or earmarked accounting bucket and recover any non-AZTEC token held by the distributor
    • Can interact with ProtocolTreasury
      • relay arbitrary calls and ETH from the ProtocolTreasury
    • Can interact with Rollup
      • change the sequencer reward share and checkpoint reward, only increase the mana target, update proving cost within its step and cooldown bounds, update validator entry-queue limits subject to nonzero normal-phase limits and bounded bootstrap settings, queue or cancel a Slasher replacement subject to the replacement delay, set the EscapeHatch once if still unset, and transfer or renounce ownership
      • slash and eject validators while this contract is configured as the active Slasher
    • Can interact with GSE
      • set Governance once if still unset, change the proof-of-possession gas limit (including to a value that prevents new deposits), add a new latest rollup that controls bonus-instance validators, and transfer or renounce ownership
    • Can interact with Slasher
      • execute arbitrary payload actions through the Slasher, bypassing all proposer validation including ballots, quorum, target construction, delay, and lifetime
    SlashingProposer0x8A36…f0bA

    Collects one signed slashing ballot from the designated proposer in each slot. After the execution delay, anyone can tally the ballots per validator and penalty level, deploy the resulting payload, and ask the Slasher to execute it before the round expires.

    • Can interact with Rollup
      • slash and eject validators while this contract is configured as the active Slasher
    • Can interact with Slasher
      • execute payload actions accepted by its validator-ballot tally after the proposer-enforced delay
    SlashVeto Council0xBbB4…7480

    A Multisig with 5/9 threshold.

    • Can interact with Slasher
      • veto specific payloads, repeatedly disable all slashing for 3d at a time, or re-enable slashing before a pause expires
    GovernanceProposer0x06Ef…63ef

    Intermediary contract through which the designated proposer for each L2 slot can signal support for an L1 payload. A signalling round comprises 1000 slots. A payload that receives at least 600 signals can be submitted to the L1 Governance contract within the configured lifetime.

    • Can interact with Governance
      • create proposals
    • Can interact with AztecTokenPositionRegistry_ProtocolTreasury
      • add and resolve milestones, register staker implementations, set revoker roles, only decrease the execution and token unlock timestamps, and transfer or renounce ownership
    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

    HonkVerifier0x098f…b4bC

    ZK proof verification contract.

    RewardBooster0x4490…B551

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

    RollupOperationsExtLib0x516f…d2AC

    Library immutably linked into the Rollup for checkpoint proposal, proof verification, pruning, and chain-tip operations. Its functions operate on the calling Rollup’s storage through DELEGATECALL, so direct getter calls on the library are ignored.

    RewardDistributor0x555b…E1d3

    Holds tokens allocated for protocol rewards. The canonical Rollup contract, as defined by the Registry, can draw from the implicit reward pool while any address can claim only funds explicitly earmarked to it.

    • Roles:
      • canonicalRollup: Rollup
      • registryOwner: Governance
    SlashPayloadCloneable0x5757…6e87

    A template for specific slashing payload contracts deployed deterministically to encode one or more slashing actions (validators and amounts) that the Slasher executes.

    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:
      • getSlasher: Slasher the active Slasher authorizes the call under its own execution rules; ultimately Governance the active Slasher authorizes the call under its own execution rules, SlashingProposer the active Slasher authorizes the call under its own execution rules
      • owner: Governance

    Executes payload actions submitted by the authorized slashing proposer or Governance. Execution is blocked while slashing is disabled or when the vetoer has vetoed the payload; voting and execution-delay rules are enforced by the proposer, while Governance can bypass the proposer.

    • Roles:
      • governance: Governance slashing is enabled and the payload has not been vetoed
      • proposer: SlashingProposer matching ballots meet the proposer quorum, the execution delay has elapsed, the voting round is still within its lifetime, slashing is enabled, and the payload has not been vetoed
      • vetoer: SlashVeto Council
    RewardExtLib0xD6E8…8898

    Library immutably linked into the Rollup for sequencer and prover reward accounting. Its functions operate on the calling Rollup’s storage through DELEGATECALL, so direct getter calls on the library are ignored.

    ValidatorOperationsExtLib0xe4F0…D411

    Library immutably linked into the Rollup for validator entry, exits, slashing, and Slasher rotation. Its functions operate on the calling Rollup’s storage through DELEGATECALL, so direct getter calls on the library are ignored.

    EscapeHatch0xF459…E51A

    Provides a fallback mechanism for block production if the primary sequencer committee fails or censors. Candidates post a bond of 332,000,000 AZTEC and enter the candidate set. For each hatch, the contract snapshots the eligible set and uses RANDAO to select one designated proposer; posting a bond does not grant immediate proposal rights. 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 eligible bonded candidates.

    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.

    • Roles:
      • owner: ProtocolTreasury; ultimately Governance

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

    • Roles:
      • owner: Governance
    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 GATED_UNTIL has passed, the oldest unmarked Governance proposal was created after the ATP-derived activation timestamp, and markNext was not called in the same block
    BaseStaker0x7907…082d

    Implementation registered by the ATP Registry for upgradeable staker proxies that manage locked AZTEC positions.

    AZTEC Token0xA27E…62D2

    AZTEC token contract

    • Roles:
      • owner: CoinIssuer

    Central staking manager independent of Rollup implementations. Sequencers deposit stake here through their chosen Rollup contract. Their stake is then transferred 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:
      • getLatestRollup: Rollup
      • owner: Governance
    AztecTokenPositionRegistry_ProtocolTreasury0xD938…0c80

    AZTEC token-position Registry referenced by the ProtocolTreasury for its activation cutoff and by other ecosystem vesting contracts.

    • Roles:
      • owner: EOA 1

    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.

    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.

    FeeJuicePortal
    Escrow
    0xaf73…691c

    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