# Aztec Network Markdown version of https://l2beat.com/layer2s/projects/aztecnetwork ## Summary - Total Value Secured: $58.43 K (+141% compared to seven days ago; canonically bridged $58.43 K, natively minted $0.00, externally bridged $0.00; 93.8% with additional trust assumptions compared to the tokens involved and the Stage assigned to the project's canonical messaging bridge) - TVS by asset: Stablecoins $54.84 K (93.8%), Other $3.58 K (6.14%) - Associated tokens: AZTEC: $3.58 K (6.14% of TVS) - Past day UOPS: <0.01 (0.00% compared to seven days ago) - Stage: Stage 2 - Gas token: AZTEC - Type: ZK Rollup - Purposes: Universal, Privacy - Host chain: Ethereum - Chain ID: 677868 ### Risks - Sequencer failure: Decentralized Sequencer Set (sentiment: good) - State validation: Validity proofs (SN) (No execution delay; sentiment: good) - Data availability: Onchain (SD) (sentiment: good) - Exit window: ∞ (sentiment: good) - Proposer failure: Self Propose (sentiment: good) ### About Aztec Network is a privacy-preserving ZK rollup that uses the AztecVM and Noir to support private and public smart contracts on Ethereum. ### Links - Website: https://aztec.network/, https://aztec.network/noir - Docs: https://docs.aztec.network/ - Explorer: https://aztecscan.xyz, https://aztecexplorer.xyz, https://dashtec.xyz/, https://slashveto.me/ - Repository: https://github.com/AztecProtocol/aztec-packages - Social: https://x.com/aztecnetwork, https://aztec.network/blog, https://t.me/AztecAnnouncements_Official, https://forum.aztec.network/, https://youtube.com/@aztecnetwork, https://discord.com/invite/aztec - Contracts explorer (Disco): https://disco.l2beat.com/ui/p/aztecnetwork ### Badges - AztecVM: This project uses the Aztec Virtual Machine to run its smart contracts and supports the Noir programming language - Ethereum with blobs: This project is posting its data to Ethereum as blobs - Governance: This project features token voting - Privacy: This project supports private transactions natively ## Value Secured The interactive TVS charts are shown on [the HTML page](https://l2beat.com/layer2s/projects/aztecnetwork#tvs). Token by token: [TVS breakdown](https://l2beat.com/layer2s/projects/aztecnetwork/tvs-breakdown). - [TVS chart (JSON)](https://l2beat.com/api/scaling/tvs/aztecnetwork) - [TVS breakdown by token (JSON)](https://l2beat.com/api/scaling/tvs/aztecnetwork/breakdown) ## Activity The interactive activity chart is shown on [the HTML page](https://l2beat.com/layer2s/projects/aztecnetwork#activity). - [Activity chart (JSON)](https://l2beat.com/api/scaling/activity/aztecnetwork) ## Onchain costs The section shows the operating costs that L2s pay to Ethereum. The interactive costs chart is shown on [the HTML page](https://l2beat.com/layer2s/projects/aztecnetwork#onchain-costs). ### Tracked transactions #### Batch submissions - functionCall: 2026-07-14 20:22 UTC - now; currently used; address: [0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34](https://etherscan.io/address/0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34); selector: 0x72636df9; signature: `function propose((bytes32,(int256),(bytes32,bytes32,bytes32,bytes32,bytes32,uint256,uint256,address,bytes32,(uint128,uint128),uint256,uint256)),(bytes,bytes),address[],(uint8,bytes32,bytes32),bytes)` #### State updates - functionCall: 2026-07-14 20:22 UTC - now; currently used; address: [0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34](https://etherscan.io/address/0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34); selector: 0x069d1525; signature: `function submitEpochRootProof((uint256,uint256,(bytes32,bytes32,bytes32,address),(bytes32,bytes32,bytes32,bytes32,bytes32,uint256,uint256,address,bytes32,(uint128,uint128),uint256,uint256)[],(bytes,bytes),bytes,bytes))` ## Data posted This section shows how much data the project publishes to Ethereum over time. It leaves out data posted to other data-availability (DA) layers. The project currently posts data to [Ethereum](https://l2beat.com/projects/ethereum). The interactive data posted chart is shown on [the HTML page](https://l2beat.com/layer2s/projects/aztecnetwork#data-posted). ### Tracked transactions #### Blob submissions - DA layer Ethereum: from block 25533241 to now; currently used; inbox: [0x0000000000000000000000000000000000000000](https://etherscan.io/address/0x0000000000000000000000000000000000000000); topics: 0x6ff492bf2b4ca1b93a175167d14b3e46085b935cab3f39ca94013000799b93a0 ## Liveness 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. The interactive liveness chart is shown on [the HTML page](https://l2beat.com/layer2s/projects/aztecnetwork#liveness). ### Tracked transactions #### Batch submissions - functionCall: 2026-07-14 20:22 UTC - now; currently used; address: [0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34](https://etherscan.io/address/0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34); selector: 0x72636df9; signature: `function propose((bytes32,(int256),(bytes32,bytes32,bytes32,bytes32,bytes32,uint256,uint256,address,bytes32,(uint128,uint128),uint256,uint256)),(bytes,bytes),address[],(uint8,bytes32,bytes32),bytes)` #### State updates - functionCall: 2026-07-14 20:22 UTC - now; currently used; address: [0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34](https://etherscan.io/address/0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34); selector: 0x069d1525; signature: `function submitEpochRootProof((uint256,uint256,(bytes32,bytes32,bytes32,address),(bytes32,bytes32,bytes32,bytes32,bytes32,uint256,uint256,address,bytes32,(uint128,uint128),uint256,uint256)[],(bytes,bytes),bytes,bytes))` ### Last 30 day anomalies All liveness anomalies detected for this project in the last 30 days, helping you review recent downtime and availability issues. - No tx data submissions were performed for 8m 24s (from 2026-10-08 18:44 UTC until 2026-10-08 18:53 UTC). These typically occur every 1m 17s on average. - No tx data submissions were performed for 8m 24s (from 2026-10-08 16:36 UTC until 2026-10-08 16:44 UTC). These typically occur every 1m 17s on average. - No tx data submissions were performed for 8m 24s (from 2026-10-08 10:41 UTC until 2026-10-08 10:49 UTC). These typically occur every 1m 17s on average. - No tx data submissions were performed for 8m 24s (from 2026-10-08 06:26 UTC until 2026-10-08 06:35 UTC). These typically occur every 1m 17s on average. - No tx data submissions were performed for 8m 24s (from 2026-09-29 09:14 UTC until 2026-09-29 09:23 UTC). These typically occur every 1m 17s on average. - No tx data submissions were performed for 8m 24s (from 2026-09-29 08:45 UTC until 2026-09-29 08:54 UTC). These typically occur every 1m 17s on average. - No tx data submissions were performed for 8m 24s (from 2026-09-29 05:05 UTC until 2026-09-29 05:13 UTC). These typically occur every 1m 17s on average. - No tx data submissions were performed for 8m 24s (from 2026-09-29 03:02 UTC until 2026-09-29 03:11 UTC). These typically occur every 1m 17s on average. - No tx data submissions were performed for 8m 24s (from 2026-09-29 01:33 UTC until 2026-09-29 01:42 UTC). These typically occur every 1m 17s on average. - No tx data submissions were performed for 8m 24s (from 2026-09-22 14:24 UTC until 2026-09-22 14:32 UTC). These typically occur every 1m 17s on average. - No tx data submissions were performed for 8m 24s (from 2026-09-18 17:01 UTC until 2026-09-18 17:09 UTC). These typically occur every 1m 17s on average. - No tx data submissions were performed for 8m 24s (from 2026-09-18 15:01 UTC until 2026-09-18 15:09 UTC). These typically occur every 1m 17s on average. - No tx data submissions were performed for 8m 24s (from 2026-09-18 13:23 UTC until 2026-09-18 13:31 UTC). These typically occur every 1m 17s on average. ## Milestones & Incidents - 2026-08-07 (incident): [v5 Proving System Vulnerability](https://aztec.network/blog/alpha-v5-proving-system-vulnerability). Aztec discloses a critical proving-system vulnerability that can allow invalid state transitions. - 2026-07-14: [Aztec v5 Upgrade](https://etherscan.io/tx/0xff2db4e4bba583f2451478bfe4703e16afc79f0b463fb60615ebe3494142437b). Governance makes v5 canonical which hardens the immutability and fixes vulnerabilities. - 2026-06-22: [Cut the Leash](https://github.com/AztecProtocol/governance/pull/7). Ownership of the v4 Rollup is revoked, promoting it to Stage 2 (immutable). - 2026-03-31 (incident): [v4 Vulnerabilities](https://aztec.network/blog/critical-vulnerability-in-alpha-v4). Aztec warns about critical security vulnerabilities that can lead to theft of funds. - 2026-03-30: [Aztec Alpha (v4) Launch](https://aztec.network/blog/announcing-the-alpha-network). Aztec launches its feature-complete Alpha network, allowing developers to deploy the first apps. ## Risk summary **Warning:** Aztec v5 has a [known critical proving-system vulnerability](https://aztec.network/blog/alpha-v5-proving-system-vulnerability) that puts funds, applications, and contract state at risk. A fix is planned for v6. ### Users can be censored if 1. no honest regular proposer or eligible bonded escape-hatch proposer includes and proves their transactions. ## Risk analysis **Warning:** Aztec v5 has a [known critical proving-system vulnerability](https://aztec.network/blog/alpha-v5-proving-system-vulnerability) that puts funds, applications, and contract state at risk. A fix is planned for v6. ### Sequencer failure Decentralized Sequencer Set (sentiment: good) Users can permissionlessly become a sequencer by staking 200.00 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.00 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) (No execution delay; sentiment: good) SNARKs are succinct zero knowledge proofs that ensure state correctness, but require trusted setup. ### Data availability Onchain (SD) (sentiment: good) 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 ∞ (sentiment: good) 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 (sentiment: good) 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. ## Stage 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. ### Scope of assessment #### In scope - L1 core contracts - Gas token - Derivation logic spec - Source code to program hash mapping - Source code to verification keys mapping - Sequencer policy - Trusted setup #### Not in scope - L2 core contracts - Non-gas tokens - Source code implementation of the spec ### Stage 0 5 requirements met. - Met: A complete and functional proof system is deployed. - Met: The project calls itself a rollup. - Met: State roots are posted to Ethereum L1. - Met: Inputs for the state transition function are posted to Ethereum L1. - Met: A source-available node exists that can recreate the state from Ethereum L1 data. Please note that the L2BEAT team has not verified the validity of the node source code. [View code](https://github.com/AztecProtocol/aztec-packages/tree/v5.0.0) ### Stage 1 6 requirements met. **Principle** - Met: Compromising ≥75% of the Security Council is the only way (other than bugs) for a rollup to indefinitely block an L2→L1 message (e.g. a withdrawal) or push an invalid L2→L1 message (e.g. an invalid withdrawal) with a <7d exit window. **Guidelines** - Met: Users are able to exit without the help of the permissioned operators. - Met: In case of an unwanted upgrade by actors more centralized than a Security Council, users have at least 7d to exit. - Met: The proof system meets the minimum trusted setup requirements defined in the L2BEAT [trusted setup assessment framework](https://forum.l2beat.com/t/the-trusted-setups-framework-for-zk-catalog/381). - Met: Prover source code is published. - Met: Onchain verifiers' smart contracts can be independently regenerated from the verifier source code. ### Stage 2 1 requirement met. - Met: The Rollup, verifier, Inbox and Outbox are immutable. Selecting a new canonical rollup does not mutate this deployed instance or its installed bonded EscapeHatch, although validator migration can affect normal proposer availability and inclusion remains probabilistic. [Learn more about Stages](https://l2beat.com/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. ## Data availability ### 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. **References** - [Rollup.sol - propose() on Etherscan](https://etherscan.io/address/0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34#code) - [Rollup.sol - validateBlobs() on Etherscan](https://etherscan.io/address/0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34#code) Learn more about the DA layer here: [Ethereum](https://l2beat.com/projects/ethereum) ## State validation ![A diagram of the state validation](https://l2beat.com/static/images/state-validation/aztecnetwork.4434b6a1.png) 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. **References** - [Rollup.sol - submitEpochRootProof() on Etherscan](https://etherscan.io/address/0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34#code) ### 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. **References** - [Rollup.sol - submitEpochRootProof() on Etherscan](https://etherscan.io/address/0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34#code) - [HonkVerifier.sol - verify() on Etherscan](https://etherscan.io/address/0x098f47c00F4df22a8030746Eb11378236C24b4bC#code) ### Slashing Each 200.00 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. **References** - [SlashingProposer.sol on Etherscan](https://etherscan.io/address/eth:0x8A36b8F2Ca71D8d8Bd98e03Ebf8B4D0939Daf0bA#code) - [Slasher.sol on Etherscan](https://etherscan.io/address/eth:0xCD6855470A01aBcd989126A1183Fb50673952548#code) - [SlashVeto Council - Github](https://github.com/aztec-slash-veto/council) - [slashveto.me - Monitor Slashing](https://slashveto.me) ### Prover: [Barretenberg](https://l2beat.com/zk-catalog/barretenberg) #### Trusted setups - UltraHonk (Plonk): - Aztec Ignition, risk green (lowest risk) per the [Trusted Setups Risk Framework](https://forum.l2beat.com/t/the-trusted-setups-framework-for-zk-catalog/381): Aztec Ignition is a trusted setup ceremony that was run by Aztec for KZG commitment over BN254 curve in 2019. It included 176 participants and was publicly open for participation. - Onchain verifiers: [HonkVerifier](https://etherscan.io/address/0x098f47c00F4df22a8030746Eb11378236C24b4bC#code) (1 successful (verified by [L2BEAT](https://l2beat.com))) - Used in: [Aztec Network](https://l2beat.com/layer2s/projects/aztecnetwork) - Verifiers: 1 successful (verified by [L2BEAT](https://l2beat.com)) ## Upgrades & Governance ![A diagram of the upgrades and governance](https://l2beat.com/static/images/upgrades-and-governance/aztecnetwork.b33efa78.png) ### 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.00 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.75 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. ## Updates Each date links the update on the HTML page, which also shows its contract diffs. ### [2026-10-13 07:44 UTC](https://l2beat.com/layer2s/projects/aztecnetwork?update=f06a5080) (13 changes) Track the Aztec v5 verification key hash and add sUSDS escrow (zkmoney). ### [2026-09-30 09:12 UTC](https://l2beat.com/layer2s/projects/aztecnetwork?update=32c985ef) (14 changes) Config: Add the zk.money escrow (ZkMoneyPortal), which uses the Aztec canonical messaging bridge. The full discovery is in the zkmoney config and not shown here for clarity. ### [2026-09-15 11:30 UTC](https://l2beat.com/layer2s/projects/aztecnetwork?update=4fc80441) (1 change) Revoker changed: This is used to revoke vesting token positions. ### [2026-08-19 14:18 UTC](https://l2beat.com/layer2s/projects/aztecnetwork?update=0eea7b7f) (1 change) The Registry owner (EOA) appointed a one-shot revocation payload, which then marked 29 milestone ATPs with a total allocation of 35,579,336 AZTEC as revoked. The ATPs are token vaults that vest over time to a given beneficiary address. This is Aztec Labs internal accounting, not DAO related. ### [2026-07-29 11:39 UTC](https://l2beat.com/layer2s/projects/aztecnetwork?update=574909e3) (1 change) The existing three-day slashing pause expired (the `slashingDisabledUntil` value did not change), so slash payload execution is enabled again. ### [2026-07-23 13:53 UTC](https://l2beat.com/layer2s/projects/aztecnetwork?update=04037c02) (1 change) Slashing was disabled for ~ three more days, until July 26. ### [2026-07-21 08:48 UTC](https://l2beat.com/layer2s/projects/aztecnetwork?update=6c8519bf) (2 changes) 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. ### [2026-07-15 10:25 UTC](https://l2beat.com/layer2s/projects/aztecnetwork?update=36d3cfc7) (42 changes) 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. ### [2026-07-08 12:22 UTC](https://l2beat.com/layer2s/projects/aztecnetwork?update=c47b6119) (1 change) [v5 upgrade payload](https://aztecgov.nethermind.io/4) passes signaling and is proposed to the Governance contract. ### [2026-06-22 12:31 UTC](https://l2beat.com/layer2s/projects/aztecnetwork?update=a96de870) (3 changes) 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. ### [2026-06-16 09:57 UTC](https://l2beat.com/layer2s/projects/aztecnetwork?update=90de911d) (1 change) Revoker switched back to EOA (see below). ### [2026-06-02 13:04 UTC](https://l2beat.com/layer2s/projects/aztecnetwork?update=b3046f7e) (1 change) Revoker of the vesting contracts registry switched from EOA to a revocation payload. This does not affect the ProtocolTreasury but rather the external vesting contracts, which are not in disco. ### [2026-05-13 13:06 UTC](https://l2beat.com/layer2s/projects/aztecnetwork?update=4cf6ec20) (1 change) AZUP-1: Cut the Leash is queued after a successful sequencer signaling round. The proposal aims to make the escape hatch of the current rollup immutable and get it to Stage 2. Details here: https://aztecgov.nethermind.io/3. The executable payload address is https://etherscan.io/address/0xa156E3a14f45099ecdF9C6A393a118809C5d06e6#code and is simple: - revoke ownership of the rollup - gov execution delay 30d -> 2d ### [2026-04-22 13:51 UTC](https://l2beat.com/layer2s/projects/aztecnetwork?update=9f35a88f) (1 change) slashing is back after a slashveto council pause. ### [2026-04-13 09:16 UTC](https://l2beat.com/layer2s/projects/aztecnetwork?update=bb632c3e) (3 changes) the slashVeto council vetoes slashing for 3d because of [this request](https://github.com/aztec-slash-veto/council/issues/7). Affected payloads can be seen on https://slashveto.me. The argument is that v4.1.3 was a bugfix release on a friday and the wave of slashing can be attributed to people not having updated in time. one slashVeto council member is replaced (https://forum.aztec.network/t/join-the-slashveto-council/8521). ### [2026-04-07 11:34 UTC](https://l2beat.com/layer2s/projects/aztecnetwork?update=2b94fb12) (1 change) Rollup contract has reached enough validators, so isBootstrapped is set to true. Now the rate of adding new validators is limited by the `getEntryQueueFlushSize` function (max 0.25% of the validator set growth per epoch, at least 1, at most 4). ### [2026-03-30 05:06 UTC](https://l2beat.com/layer2s/projects/aztecnetwork?update=37b1d883) (high severity, 56 changes) config: forcibly register post-alpha contracts. remove from config.jsonc as soon as the payload is executed. ### [2026-02-16 15:12 UTC](https://l2beat.com/layer2s/projects/aztecnetwork?update=d8113437) (1 change) TGE happened. Sequencers can claim block production rewards, AZTEC is transferable and tradable on uniswap. Token governance is launched. ### [2026-01-26 13:06 UTC](https://l2beat.com/layer2s/projects/aztecnetwork?update=0c33a716) (1 change) TGE proposal active after passing signaling by sequencers. voting will start soon, proposal will become executable on 9.2 and cause TGE on 11.2. as [explained here](https://forum.aztec.network/t/reference-for-triggering-the-aztec-token-generation-event-tge/8366). ### [2026-01-21 12:56 UTC](https://l2beat.com/layer2s/projects/aztecnetwork?update=66e1cfe0) (14 changes) add TGEPayload for verification by governance. entry queue flush increase payload was executed. ### [2026-01-07 14:29 UTC](https://l2beat.com/layer2s/projects/aztecnetwork?update=c9a53a8f) (1 change) First gov proposal passed signalling phase: [Increase Ignition Queue Throughput](https://forum.aztec.network/t/increase-ignition-queue-throughput/8211) - does what it says, goal is to flush the entire queue until TGE and especially before the first upgrade of the rollup contract. ### [2025-12-01 14:59 UTC](https://l2beat.com/layer2s/projects/aztecnetwork?update=6ec23382) (1 change) config: add zk verifier from constructor vars. ### [2025-11-24 09:56 UTC](https://l2beat.com/layer2s/projects/aztecnetwork?update=57137267) (4 changes) config: yeeted flushrewarder (not core contract), ignored more noisy vars, cleaned up the disco ### [2025-11-20 14:31 UTC](https://l2beat.com/layer2s/projects/aztecnetwork?update=60e547bd) (2 changes) config: silence disco. ### [2025-11-19 15:39 UTC](https://l2beat.com/layer2s/projects/aztecnetwork?update=784bc3d2) (19 changes) initial disco: aztec is in 'ignition' phase, network will launch with empty blocks for 3 months: https://aztec.network/aztec-roadmap. ## Operator ### There is no central operator There is no privileged sequencer. Anyone can stake 200.00 K AZTEC to join the sequencer queue, and anyone can call flushEntryQueue() to activate queued sequencers once the queue rules allow it. **References** - [Rollup.sol - deposit() on Etherscan](https://etherscan.io/address/0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34#code) - [Rollup.sol - flushEntryQueue() on Etherscan](https://etherscan.io/address/0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34#code) ### 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. **Risks** - Users can be censored if no honest regular proposer or eligible bonded escape-hatch proposer includes and proves their transactions. **References** - [EscapeHatch.sol on Etherscan](https://etherscan.io/address/0xF459348962F5eA3A9A101826B03A2CE1F459E51A#code) ## Sequencing ### Transactions are ordered by a staked validator committee Joining the sequencer set is permissionless and requires staking 200.00 K AZTEC. For each epoch, the Rollup samples a 48-member committee from the active set of 3136 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** | Property | Value | Description | | --- | --- | --- | | L2 block time | 6s | Current expected interval between L2 block proposals. Multiple blocks can be produced by the same proposer within one slot, so this interval can differ from the proposer rotation interval. | | Proposer rotation | 1m 12s | | | Committee rotation | 38m 24s | A random committee is sampled from the sequencer set for each epoch, a random block producer is sampled from the committee for each slot in the epoch | | Number of block producers | 3136 sequencers, 586.92 M AZTEC | | | Access to block production rights | Open (sentiment: good) | | | Stake per validator | 200.00 K AZTEC, constant | | | Rate-limit to join | 4 sequencers / epoch | Can be changed by onchain Governance, but the contract requires nonzero minimum, divisor, and maximum queue-flush parameters. | | Deterministic CR gadget | No (sentiment: warning) | | | Additional CR gadgets | Bonded escape hatch, private transactions, 332.00 M AZTEC; every 2d 23h (sentiment: good) | Escape hatch: 332.00 M AZTEC bond to enter a set from which one proposer is periodically selected every 2d 23h to bypass the regular committee, include transactions, and prove the resulting checkpoints. 1.66 M AZTEC proposal tax. Private transactions: allow users to cheaply resist censorship based on transaction content while the chain is live. | The inclusion delay chart is shown on [the HTML page](https://l2beat.com/layer2s/projects/aztecnetwork#sequencing). 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.00 M AZTEC, a high bond intended to protect the single-proof system while providing a last-resort path around the regular sequencer set. A designated candidate that fails to propose and prove loses 9.60 M AZTEC from their bond. 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. **References** - [Aztec docs - Privacy considerations](https://github.com/AztecProtocol/aztec-packages/blob/next/docs/docs-developers/docs/resources/considerations/privacy_considerations.md#function-fingerprints-and-tx-fingerprints) - [Rollup.sol - getProposerAt() on Etherscan](https://etherscan.io/address/0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34#code) - [EscapeHatch.sol - selectCandidates() on Etherscan](https://etherscan.io/address/0xF459348962F5eA3A9A101826B03A2CE1F459E51A#code) ## Withdrawals ### 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. **References** - [Rollup.sol - submitEpochRootProof() on Etherscan](https://etherscan.io/address/0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34#code) - [Outbox.sol - consume() on Etherscan](https://etherscan.io/address/0x5B062aB5fD3A66BC7e73b04CeD38587673b6A2D7#code) ## Other considerations ### 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. **References** - [Registry.sol - addRollup() on Etherscan](https://etherscan.io/address/0x35b22e09Ee0390539439E24f06Da43D83f90e298#code) - [Governance.sol - execute() on Etherscan](https://etherscan.io/address/0x1102471Eb3378FEE427121c9EfcEa452E4B6B75e#code) ### 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. **References** - [FeeJuicePortal.sol - on Etherscan](https://etherscan.io/address/eth:0xaf73Dd51D1eb8a079BB097f39c832cDD00ac691c#code) - [Outbox.sol - on Etherscan](https://etherscan.io/address/0x5B062aB5fD3A66BC7e73b04CeD38587673b6A2D7#code) ### 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. **References** - [CRsim - Simulated inclusion probability on Aztec](https://sekuba.github.io/crsim) ## Permissions Explore these contracts and permissions in Disco, L2BEAT's contract explorer: https://disco.l2beat.com/ui/p/aztecnetwork ### Ethereum #### Actors ##### Governance Addresses: [0x1102471Eb3378FEE427121c9EfcEa452E4B6B75e](https://etherscan.io/address/0x1102471Eb3378FEE427121c9EfcEa452E4B6B75e) 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 [via: ProtocolTreasury 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] - 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 [via: Slasher slashing is enabled and the payload has not been vetoed the active Slasher authorizes the call under its own execution rules] - 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 ##### SlashingProposer Addresses: [0x8A36b8F2Ca71D8d8Bd98e03Ebf8B4D0939Daf0bA](https://etherscan.io/address/0x8A36b8F2Ca71D8d8Bd98e03Ebf8B4D0939Daf0bA) 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 [via: Slasher 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 the active Slasher authorizes the call under its own execution rules] - Can interact with Slasher - execute payload actions accepted by its validator-ballot tally after the proposer-enforced delay ##### SlashVeto Council Addresses: [0xBbB4aF368d02827945748b28CD4b2D42e4A37480](https://etherscan.io/address/0xBbB4aF368d02827945748b28CD4b2D42e4A37480) 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 Participants (9): [0xb33a08eF4624eE8F409F749Ee73766E225bEd0F4](https://etherscan.io/address/0xb33a08eF4624eE8F409F749Ee73766E225bEd0F4), [0xb6Da7B7a0d8c7349630183f4Bd6F13D4a8AD9216](https://etherscan.io/address/0xb6Da7B7a0d8c7349630183f4Bd6F13D4a8AD9216), [0xB216FcaF63c6C0f73a557B342e1Da9710C95DA81](https://etherscan.io/address/0xB216FcaF63c6C0f73a557B342e1Da9710C95DA81), [0x81062F03742B88923eaB121243B69D0a0092089e](https://etherscan.io/address/0x81062F03742B88923eaB121243B69D0a0092089e), [0x32e90E88bb2E6Ee4382e6884cC5c299a6bA27920](https://etherscan.io/address/0x32e90E88bb2E6Ee4382e6884cC5c299a6bA27920), [0x23d4A9533627eA70915026638ff5989a967Be667](https://etherscan.io/address/0x23d4A9533627eA70915026638ff5989a967Be667), [0x8138c46A572D989E54837d5e5dEB506889edFb5D](https://etherscan.io/address/0x8138c46A572D989E54837d5e5dEB506889edFb5D), [0x0Fb6215099f48D723CfB89434C2cb887357Bc871](https://etherscan.io/address/0x0Fb6215099f48D723CfB89434C2cb887357Bc871), [0x7EAbE4F636B937628A7Fe503bD7F06772C047FEe](https://etherscan.io/address/0x7EAbE4F636B937628A7Fe503bD7F06772C047FEe) ##### GovernanceProposer Addresses: [0x06Ef1DcF87E419C48B94a331B252819FADbD63ef](https://etherscan.io/address/0x06Ef1DcF87E419C48B94a331B252819FADbD63ef) 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 ##### 3 EOAs Addresses: [0x05406F53174EC1bFE5C94aF253CdD62A4adF2F29](https://etherscan.io/address/0x05406F53174EC1bFE5C94aF253CdD62A4adF2F29) (EOA 1), [0x367eD02480809f5020234181B61D9069a08974dD](https://etherscan.io/address/0x367eD02480809f5020234181B61D9069a08974dD) (EOA 2), [0x5F03984126AdFDb72B2823b553988Ccebe1F781e](https://etherscan.io/address/0x5F03984126AdFDb72B2823b553988Ccebe1F781e) (EOA 3) - Can interact with ZkMoneyPortal_sUSDS - co-sign withdrawals and refunds. Without a signature from a registered TEE signer, no funds can leave the portal ##### 2 EOAs Addresses: [0xdFd008642F54aCD44A2a03438A86A25f55c4D3Bc](https://etherscan.io/address/0xdFd008642F54aCD44A2a03438A86A25f55c4D3Bc) (EOA 4), [0xefc45B71e9432a6149a7d52f11a125A19E3A11DC](https://etherscan.io/address/0xefc45B71e9432a6149a7d52f11a125A19E3A11DC) (EOA 5) - Can interact with ZkMoneyPortal - co-sign withdrawals and refunds. Without a signature from a registered TEE signer, no funds can leave the portal ##### EOA 6 Addresses: [0x92Ba0FD39658105FaC4dF2B9BADE998B5816b350](https://etherscan.io/address/0x92Ba0FD39658105FaC4dF2B9BADE998B5816b350) - 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 ## Smart contracts ![A diagram of the smart contract architecture](https://l2beat.com/static/images/architecture/aztecnetwork.b77a6af4.png) Explore these contracts and permissions in Disco, L2BEAT's contract explorer: https://disco.l2beat.com/ui/p/aztecnetwork ### Ethereum #### HonkVerifier Addresses: [0x098f47c00F4df22a8030746Eb11378236C24b4bC](https://etherscan.io/address/0x098f47c00F4df22a8030746Eb11378236C24b4bC#code) UltraHonk verifier for Aztec v5 epoch proofs with an immutable verification key. #### RewardBooster Addresses: [0x4490cAb7Ce3499353E1b0090b9e530c1AD03B551](https://etherscan.io/address/0x4490cAb7Ce3499353E1b0090b9e530c1AD03B551#code) Calculates boosted reward shares for active provers based on a configured curve, incentivizing consistent participation. - Roles: - **rollup**: Rollup #### RollupOperationsExtLib Addresses: [0x516f010C9AB452d70E0c6f78b9E698249a66d2AC](https://etherscan.io/address/0x516f010C9AB452d70E0c6f78b9E698249a66d2AC#code) 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. #### RewardDistributor Addresses: [0x555bAAc4757A89f1CE0c84fA35afE9dD7aa8E1d3](https://etherscan.io/address/0x555bAAc4757A89f1CE0c84fA35afE9dD7aa8E1d3#code) 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 #### SlashPayloadCloneable Addresses: [0x57576AbA1932df7Cc30F971ACC9d4Fc6E86B6e87](https://etherscan.io/address/0x57576AbA1932df7Cc30F971ACC9d4Fc6E86B6e87#code) A template for specific slashing payload contracts deployed deterministically to encode one or more slashing actions (validators and amounts) that the Slasher executes. #### Rollup Addresses: [0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34](https://etherscan.io/address/0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34#code) 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 #### Slasher Addresses: [0xCD6855470A01aBcd989126A1183Fb50673952548](https://etherscan.io/address/0xCD6855470A01aBcd989126A1183Fb50673952548#code) 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 #### RewardExtLib Addresses: [0xD6E890c615d6f99681a00771C20ed04516288898](https://etherscan.io/address/0xD6E890c615d6f99681a00771C20ed04516288898#code) 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. #### ZkMoneyPortal_sUSDS (custom escrow) Addresses: [0xD7Ae00b91ba0B8e0240B22Cd75fE447d177C260f](https://etherscan.io/address/0xD7Ae00b91ba0B8e0240B22Cd75fE447d177C260f#code) Escrow of zk.money on the Aztec Network. A withdrawal needs both a proven Aztec L2->L1 message from the zk.money L2 contract and a signature from a registered TEE signer. Anyone can register a TEE signer with a fresh AWS Nitro attestation of an approved enclave image. Once the Aztec Registry's canonical rollup is no longer ROLLUP, anyone can permanently freeze the portal, stopping deposits and fixing the refund snapshot at the last proven checkpoint. - Roles: - **teeSigners**: EOA 1, EOA 2, EOA 3 The following tokens are included in the value secured calculation: sUSDS Implementation used in: [zk.money](https://l2beat.com/privacy/projects/zkmoney#ZkMoneyPortal_sUSDS) #### ZkMoneyPortal (custom escrow) Addresses: [0xdf410ad448A0f7165181FBdB32f8896f4a0d9449](https://etherscan.io/address/0xdf410ad448A0f7165181FBdB32f8896f4a0d9449#code) Escrow of zk.money on the Aztec Network. A withdrawal needs both a proven Aztec L2->L1 message from the zk.money L2 contract and a signature from a registered TEE signer. Anyone can register a TEE signer with a fresh AWS Nitro attestation of an approved enclave image. Once the Aztec Registry's canonical rollup is no longer ROLLUP, anyone can permanently freeze the portal, stopping deposits and fixing the refund snapshot at the last proven checkpoint. - Roles: - **teeSigners**: EOA 4, EOA 5 The following tokens are included in the value secured calculation: DAI Implementation used in: [zk.money](https://l2beat.com/privacy/projects/zkmoney#ZkMoneyPortal) #### ValidatorOperationsExtLib Addresses: [0xe4F0b9769Ca04a6E3d93b5BA732b5aD80797D411](https://etherscan.io/address/0xe4F0b9769Ca04a6E3d93b5BA732b5aD80797D411#code) 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. #### EscapeHatch Addresses: [0xF459348962F5eA3A9A101826B03A2CE1F459E51A](https://etherscan.io/address/0xF459348962F5eA3A9A101826B03A2CE1F459E51A#code) 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. - Roles: - **getRollup**: Rollup #### CoinIssuer Addresses: [0x02FAdF157d551aa6d761b2A2237D03Af68E41CA6](https://etherscan.io/address/0x02FAdF157d551aa6d761b2A2237D03Af68E41CA6#code) 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 #### Registry Addresses: [0x35b22e09Ee0390539439E24f06Da43D83f90e298](https://etherscan.io/address/0x35b22e09Ee0390539439E24f06Da43D83f90e298#code) Central directory that tracks the current 'canonical' (active) Rollup contract address and key system contracts like the Reward Distributor. - Roles: - **owner**: Governance #### ProtocolTreasury Addresses: [0x662De311f94bdbB571D95B5909e9cC6A25a6802a](https://etherscan.io/address/0x662De311f94bdbB571D95B5909e9cC6A25a6802a#code) 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 #### BaseStaker Addresses: [0x79075C8E314Ab4A84d54F90b1c7032Dc5469082d](https://etherscan.io/address/0x79075C8E314Ab4A84d54F90b1c7032Dc5469082d#code) Implementation registered by the ATP Registry for upgradeable staker proxies that manage locked AZTEC positions. #### AZTEC Token Addresses: [0xA27EC0006e59f245217Ff08CD52A7E8b169E62D2](https://etherscan.io/address/0xA27EC0006e59f245217Ff08CD52A7E8b169E62D2#code) AZTEC token contract - Roles: - **owner**: CoinIssuer #### GSE Addresses: [0xa92ecFD0E70c9cd5E5cd76c50Af0F7Da93567a4f](https://etherscan.io/address/0xa92ecFD0E70c9cd5E5cd76c50Af0F7Da93567a4f#code) 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_ProtocolTreasury Addresses: [0xD938bE4A2cB41105Bc2FbE707dca124A2e5d0c80](https://etherscan.io/address/0xD938bE4A2cB41105Bc2FbE707dca124A2e5d0c80#code) AZTEC token-position Registry referenced by the ProtocolTreasury for its activation cutoff and by other ecosystem vesting contracts. - Roles: - **owner**: EOA 6 #### Outbox Addresses: [0x5B062aB5fD3A66BC7e73b04CeD38587673b6A2D7](https://etherscan.io/address/0x5B062aB5fD3A66BC7e73b04CeD38587673b6A2D7#code) 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. - Roles: - **rollup**: Rollup #### Inbox Addresses: [0x7d4Ef0676c2032bbCC09227501D34d86641ab8cA](https://etherscan.io/address/0x7d4Ef0676c2032bbCC09227501D34d86641ab8cA#code) 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. - Roles: - **rollup**: Rollup #### FeeJuicePortal (escrow) Addresses: [0xaf73Dd51D1eb8a079BB097f39c832cDD00ac691c](https://etherscan.io/address/0xaf73Dd51D1eb8a079BB097f39c832cDD00ac691c#code) 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. - Roles: - **rollup**: Rollup The following tokens are included in the value secured calculation: AZTEC