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.


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
Compare with other projects
Past Day UOPS
Past Day Ops count
Max. UOPS
Past day UOPS/TPS Ratio
Compare with other projects

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



Total cost
Avg cost per L2 UOP
Avg cost per day

Compare with other projects

This section shows how much data the project publishes to its data-availability (DA) layer over time. The project currently posts data toEthereumEthereum.



Data posted
Avg size per day
Avg size per L2 UOP

Compare with other projects

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

Avg. tx data subs. interval
Avg. state updates interval
Past 30 days anomalies
99% normal uptime

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 Sep 22, 14:24 UTC until 2026 Sep 22, 14:32 UTC). These typically occur every 1m 17s on average.

No Tx data submissions were performed for 8m 24s (from 2026 Sep 18, 17:01 UTC until 2026 Sep 18, 17:09 UTC). These typically occur every 1m 17s on average.

No Tx data submissions were performed for 8m 24s (from 2026 Sep 18, 15:01 UTC until 2026 Sep 18, 15:09 UTC). These typically occur every 1m 17s on average.

No Tx data submissions were performed for 8m 24s (from 2026 Sep 18, 13:23 UTC until 2026 Sep 18, 13:31 UTC). These typically occur every 1m 17s on average.

No Tx data submissions were performed for 8m 24s (from 2026 Sep 08, 17:36 UTC until 2026 Sep 08, 17:44 UTC). These typically occur every 1m 17s on average.

v5 Proving System Vulnerability

2026 Aug 7th

Aztec discloses a critical proving-system vulnerability that can allow invalid state transitions.

Learn more

Aztec v5 Upgrade

2026 Jul 14th

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

Learn more
Aztec v5 has a known critical proving-system vulnerability that puts funds, applications, and contract state at risk. A fix is planned for v6.
Aztec v5 has a known critical proving-system vulnerability that puts funds, applications, and contract state at risk. A fix is planned for v6.
Sequencer failureState validationData availabilityExit windowProposer failure
Sequencer failure
Decentralized Sequencer Set

Users can permissionlessly become a sequencerA party responsible for ordering and executing transactions on the rollup. The sequencer verifies transactions, compresses the data into a block, and submits the data related to it to enable state reconstruction to Ethereum L1 as a single transaction. The data can be either transaction data or state diffs. by staking 200.00 K AZTEC to join the queue and wait to obtain committee-based blockAn ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over. production rights. If the pseudo-randomly sampled committees censor proposals, anyone who bonds 332.00 M AZTEC will join the escape hatchThe facility for any user of a rollup to exit the system with their assets under any circumstance. Most relevant in rollups with a centralized proposer, wherein users do not have the ability to propose blocks, but can nonetheless exit the rollup by interacting with a smart contract on L1. 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 setupGeneration of a piece of data that must then be used for some cryptographic protocol to run. Generating this data requires some secret information. The "trust" comes from the fact the secret must be destroyed after the ceremony, otherwise cryptographic properties of the protocol could be broken. Once the data is generated, and the secrets are forgotten, no further participation from the creators of the ceremony is required. There are two types of trusted setups for SNARKs: (i) trusted setup per circuit where it is generated from scratch for each circuit, (ii) trusted universal setup per proving system where it can be used for several circuits..

Data availability
Onchain (SD)

State diffs needed to reconstruct the L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. state are published in Ethereum blobsThe data that a rollup publishes to its L1/data availability (DA) layer. They consist of the L2 transactions that are rolled up, along with some metadata. Blobs are introduced as a new transaction type within Ethereum with EIP-4844, and has rollup scaling specifically in mind. Blobs persist on Ethereum’s Beacon Chain ephemerally.. Public transaction bodies and clientSometimes labelled interchangeably as a “node”, they are tasked with processing transactions and managing the blockchains's state. They run the computations for each transaction according to the rollup's virtual machine and protocol rules. If comparing to Ethereum clients, these would be execution clients such as Geth, as opposed to consensus clients. CHONK proofs propagate offchain, so withholding them can prevent permissionlessAnyone willing should be able to join and leave the network at any time, without causing significant disturbance to the network or being detrimental to the party in question. No single entity should have the power to allowlist or blocklist participants. 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 rollupA blockchain that inherits consensus and data availability from another blockchain called L1. Rollups enable trust minimized bridges with the base layer via proof systems, either optimistic or zero-knowledge. A rollup without a bridge, or without considering the bridge, is called a sovereign rollup. and bonus-instance validatorsIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier automatically follow the latest version, but this does not mutate the current instance, its verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover., messaging contracts, or already-installed EscapeHatch. Governance can change bounded validator-entry parameters and can set the GSE proof-of-possession gas limitThe maximum amount of gas a transaction or block may consume. too low for new deposits; validators explicitly bound to this instance remain on it.

Proposer failure
Self Propose

Checkpoint proposals come from the open sequencerA party responsible for ordering and executing transactions on the rollup. The sequencer verifies transactions, compresses the data into a block, and submits the data related to it to enable state reconstruction to Ethereum L1 as a single transaction. The data can be either transaction data or state diffs. set, with the escape hatchThe facility for any user of a rollup to exit the system with their assets under any circumstance. Most relevant in rollups with a centralized proposer, wherein users do not have the ability to propose blocks, but can nonetheless exit the rollup by interacting with a smart contract on L1. 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 blobThe data that a rollup publishes to its L1/data availability (DA) layer. They consist of the L2 transactions that are rolled up, along with some metadata. Blobs are introduced as a new transaction type within Ethereum with EIP-4844, and has rollup scaling specifically in mind. Blobs persist on Ethereum’s Beacon Chain ephemerally. 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 clientSometimes labelled interchangeably as a “node”, they are tasked with processing transactions and managing the blockchains's state. They run the computations for each transaction according to the rollup's virtual machine and protocol rules. If comparing to Ethereum clients, these would be execution clients such as Geth, as opposed to consensus clients. CHONK proofs propagate offchain; withholding them can prevent permissionlessAnyone willing should be able to join and leave the network at any time, without causing significant disturbance to the network or being detrimental to the party in question. No single entity should have the power to allowlist or blocklist participants. 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 rootA cryptographic hash succinctly representing a state using a Merkle tree. is inserted into the Outbox. Proving is permissionlessAnyone willing should be able to join and leave the network at any time, without causing significant disturbance to the network or being detrimental to the party in question. No single entity should have the power to allowlist or blocklist participants., 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 rollupA blockchain that inherits consensus and data availability from another blockchain called L1. Rollups enable trust minimized bridges with the base layer via proof systems, either optimistic or zero-knowledge. A rollup without a bridge, or without considering the bridge, is called a sovereign rollup. only advances the proven chain after submitEpochRootProof() succeeds. That call verifies the epoch proof and then inserts the epoch outbox state rootA cryptographic hash succinctly representing a state using a Merkle tree. for L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups.->L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. 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.00 K AZTEC stake used to join the sequencerA party responsible for ordering and executing transactions on the rollup. The sequencer verifies transactions, compresses the data into a block, and submits the data related to it to enable state reconstruction to Ethereum L1 as a single transaction. The data can be either transaction data or state diffs. set and vote in governance can be slashed. The designated proposerIn the context of L2s, the actor that proposes a claimed state root on L1. The term is also used in the context of Ethereum to refer to the actor that proposes a new block. for each slot can submit one separate signed ballot on L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development.. Ballots are grouped into rounds spanning 4 epochs (2h 33m).

Slashing conditions are implemented in sequencer-nodeA software client that participates in the network. 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 validatorIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier 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 blobsThe data that a rollup publishes to its L1/data availability (DA) layer. They consist of the L2 transactions that are rolled up, along with some metadata. Blobs are introduced as a new transaction type within Ethereum with EIP-4844, and has rollup scaling specifically in mind. Blobs persist on Ethereum’s Beacon Chain ephemerally. but withholds public transaction bodies or CHONK proofs needed for permissionlessAnyone willing should be able to join and leave the network at any time, without causing significant disturbance to the network or being detrimental to the party in question. No single entity should have the power to allowlist or blocklist participants. 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 (sequencerA party responsible for ordering and executing transactions on the rollup. The sequencer verifies transactions, compresses the data into a block, and submits the data related to it to enable state reconstruction to Ethereum L1 as a single transaction. The data can be either transaction data or state diffs. signaling)

Sequencers stake AZTEC to secure the L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. 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 rollupA blockchain that inherits consensus and data availability from another blockchain called L1. Rollups enable trust minimized bridges with the base layer via proof systems, either optimistic or zero-knowledge. A rollup without a bridge, or without considering the bridge, is called a sovereign rollup. version.

1. Signaling (GovernanceProposer)

Aztec uses an onchain “Empire” signaling system. The designated proposerIn the context of L2s, the actor that proposes a claimed state root on L1. The term is also used in the context of Ethereum to refer to the actor that proposes a new block. for each slot on the canonical rollup can separately signal support for one payload on L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development.. 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 validatorIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier 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, verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover., 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/proverAn entity that generates the cryptographic proof to convince the verifier that the statement is true. In a ZK-Rollup, the prover generates the ZK (validity) proof to submit to the verifier contract. 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 limitThe maximum amount of gas a transaction or block may consume. 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 September 15, 11:30 UTC
1change

Revoker changed: This is used to revoke vesting token positions.

contract AztecTokenPositionRegistry_ProtocolTreasury (eth:0xD938bE4A2cB41105Bc2FbE707dca124A2e5d0c80) [aztecnetwork/AztecTokenPositionRegistry] {
+++ description: AZTEC token-position Registry referenced by the ProtocolTreasury for its activation cutoff and by other ecosystem vesting contracts.
+++ description: Address used by ATP positions as the revocation authority.
values.getRevoker:
- "eth:0xA70D1A21b251eE5F15C4aD77179114d70917F0Bf"
+ "eth:0x92Ba0FD39658105FaC4dF2B9BADE998B5816b350"
}
2026 August 19, 14:18 UTC
1change

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.

contract AztecTokenPositionRegistry_ProtocolTreasury (eth:0xD938bE4A2cB41105Bc2FbE707dca124A2e5d0c80) [aztecnetwork/AztecTokenPositionRegistry] {
+++ description: AZTEC token-position Registry referenced by the ProtocolTreasury for its activation cutoff and by other ecosystem vesting contracts.
+++ description: Address used by ATP positions as the revocation authority.
values.getRevoker:
- "eth:0x92Ba0FD39658105FaC4dF2B9BADE998B5816b350"
+ "eth:0xA70D1A21b251eE5F15C4aD77179114d70917F0Bf"
}
2026 July 29, 11:39 UTC
1change

The existing three-day slashing pause expired (the slashingDisabledUntil value did not change), so slash payload execution is enabled again.

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:
- false
+ true
}
2026 July 23, 13:53 UTC
1change

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
2changes

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
}

There is no central operator

There is no privileged sequencerA party responsible for ordering and executing transactions on the rollup. The sequencer verifies transactions, compresses the data into a block, and submits the data related to it to enable state reconstruction to Ethereum L1 as a single transaction. The data can be either transaction data or state diffs.. 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.

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

Bonded, probabilistic self-sequencing

There is no L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. 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 sequencerA party responsible for ordering and executing transactions on the rollup. The sequencer verifies transactions, compresses the data into a block, and submits the data related to it to enable state reconstruction to Ethereum L1 as a single transaction. The data can be either transaction data or state diffs. set is permissionlessAnyone willing should be able to join and leave the network at any time, without causing significant disturbance to the network or being detrimental to the party in question. No single entity should have the power to allowlist or blocklist participants. and requires staking 200.00 K AZTEC. For each epoch, the RollupA blockchain that inherits consensus and data availability from another blockchain called L1. Rollups enable trust minimized bridges with the base layer via proof systems, either optimistic or zero-knowledge. A rollup without a bridge, or without considering the bridge, is called a sovereign rollup. samples a 48-member committee from the active set of 3187 and selects one proposerIn the context of L2s, the actor that proposes a claimed state root on L1. The term is also used in the context of Ethereum to refer to the actor that proposes a new block. 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 time
Proposer rotation1m 12s
Committee rotation
Number of block producers3187 sequencers
586.92 M AZTEC
Access to block production rightsOpen
Stake per validator200.00 K AZTEC, constant
Rate-limit to join
Deterministic CR gadgetNo
Additional CR gadgets
332.00 M AZTEC; every 2d 23h

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 hatchThe facility for any user of a rollup to exit the system with their assets under any circumstance. Most relevant in rollups with a centralized proposer, wherein users do not have the ability to propose blocks, but can nonetheless exit the rollup by interacting with a smart contract on L1., validatorIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier-set changes, validator-set lag, and blanket-censorship resistance gadgets.

Censorship resistance

The regular committee can be circumvented by the escape hatchThe facility for any user of a rollup to exit the system with their assets under any circumstance. Most relevant in rollups with a centralized proposer, wherein users do not have the ability to propose blocks, but can nonetheless exit the rollup by interacting with a smart contract on L1., 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 systemThe infrastructure that allows projects to verify their state transitions. It is composed by onchain verifiers and offchain provers. The main two flavors are optimistic and ZK proof systems, but they can be combined in a hybrid model. In general though, if a system is able to accept state roots optimistically, even if it has a ZK component, it is considered an optimistic proof system. while providing a last-resort path around the regular sequencerA party responsible for ordering and executing transactions on the rollup. The sequencer verifies transactions, compresses the data into a block, and submits the data related to it to enable state reconstruction to Ethereum L1 as a single transaction. The data can be either transaction data or state diffs. set. A designated candidate that fails to propose and prove loses 9.60 M AZTEC from their bond. Aztec’s private execution environmentRefers to both the environment where transactions are processed, constituted by the execution clients, as well as the virtual machine model which the clients run. can also make selective censorship harder because transaction contents are hidden.

Selective censorship

On a live networkA constellation of nodes (peers) that communicate via a peer-to-peer protocol, for example, in propagating transactions and blocks to other nodes. with some censoring sequencers, users can submit private transactions or wait for an honest committee and proposerIn the context of L2s, the actor that proposes a claimed state root on L1. The term is also used in the context of Ethereum to refer to the actor that proposes a new block. to include their public transaction.

Blanket censorship

If the entire active set censors or stops producing checkpoints, a new sequencer can join through the permissionlessAnyone willing should be able to join and leave the network at any time, without causing significant disturbance to the network or being detrimental to the party in question. No single entity should have the power to allowlist or blocklist participants. 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 validatorIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier 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 L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups.->L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. messages by submitting a regular transaction on this chain. When the blockAn ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over. 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 rollupA blockchain that inherits consensus and data availability from another blockchain called L1. Rollups enable trust minimized bridges with the base layer via proof systems, either optimistic or zero-knowledge. A rollup without a bridge, or without considering the bridge, is called a sovereign 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 bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a 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 rollupA blockchain that inherits consensus and data availability from another blockchain called L1. Rollups enable trust minimized bridges with the base layer via proof systems, either optimistic or zero-knowledge. A rollup without a bridge, or without considering the bridge, is called a sovereign 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 rollupA blockchain that inherits consensus and data availability from another blockchain called L1. Rollups enable trust minimized bridges with the base layer via proof systems, either optimistic or zero-knowledge. A rollup without a bridge, or without considering the bridge, is called a sovereign rollup. is deployed only with an immutable canonical messaging bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a 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. GasA virtual fuel used to execute smart contracts on a rollup. The EVM (or other VM within the rollup) uses an accounting mechanism to correspond the consumption of gas to the consumption of computing resources, and to limit the consumption of computing resources. tokens are bridged through the FeeJuicePortal, an immutable one-way portal that only supports bridging to public L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. 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 L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. forced-transaction queue, they do not guarantee inclusion after a fixed delay. The launch-era decentralized-sequencerA party responsible for ordering and executing transactions on the rollup. The sequencer verifies transactions, compresses the data into a block, and submits the data related to it to enable state reconstruction to Ethereum L1 as a single transaction. The data can be either transaction data or state diffs. model estimated 20d to reach its target exit probability under its stated assumptions; it is not a current protocol guarantee and does not model validatorIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier-set changes, the escape hatchThe facility for any user of a rollup to exit the system with their assets under any circumstance. Most relevant in rollups with a centralized proposer, wherein users do not have the ability to propose blocks, but can nonetheless exit the rollup by interacting with a smart contract on L1., 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 rollupA blockchain that inherits consensus and data availability from another blockchain called L1. Rollups enable trust minimized bridges with the base layer via proof systems, either optimistic or zero-knowledge. A rollup without a bridge, or without considering the bridge, is called a sovereign 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 sequencerA party responsible for ordering and executing transactions on the rollup. The sequencer verifies transactions, compresses the data into a block, and submits the data related to it to enable state reconstruction to Ethereum L1 as a single transaction. The data can be either transaction data or state diffs. reward share and checkpoint reward, only increase the mana target, update proving cost within its step and cooldown bounds, update validatorIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier 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 limitThe maximum amount of gas a transaction or block may consume. (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 proposerIn the context of L2s, the actor that proposes a claimed state root on L1. The term is also used in the context of Ethereum to refer to the actor that proposes a new block. validation including ballots, quorum, target construction, delay, and lifetime
SlashingProposer0x8A36…f0bA

Collects one signed slashing ballot from the designated proposerIn the context of L2s, the actor that proposes a claimed state root on L1. The term is also used in the context of Ethereum to refer to the actor that proposes a new block. in each slot. After the execution delay, anyone can tally the ballots per validatorIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier and penalty level, deploy the resulting payload, and ask the Slasher to execute it before the round expires.

  • Can interact with RollupA blockchain that inherits consensus and data availability from another blockchain called L1. Rollups enable trust minimized bridges with the base layer via proof systems, either optimistic or zero-knowledge. A rollup without a bridge, or without considering the bridge, is called a sovereign 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 proposerIn the context of L2s, the actor that proposes a claimed state root on L1. The term is also used in the context of Ethereum to refer to the actor that proposes a new block. for each L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. slot can signal support for an L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. 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.

  • Roles:
    • rollupA blockchain that inherits consensus and data availability from another blockchain called L1. Rollups enable trust minimized bridges with the base layer via proof systems, either optimistic or zero-knowledge. A rollup without a bridge, or without considering the bridge, is called a sovereign rollup.: Rollup
RollupOperationsExtLib0x516f…d2AC

Library immutably linked into the RollupA blockchain that inherits consensus and data availability from another blockchain called L1. Rollups enable trust minimized bridges with the base layer via proof systems, either optimistic or zero-knowledge. A rollup without a bridge, or without considering the bridge, is called a sovereign 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 RollupA blockchain that inherits consensus and data availability from another blockchain called L1. Rollups enable trust minimized bridges with the base layer via proof systems, either optimistic or zero-knowledge. A rollup without a bridge, or without considering the bridge, is called a sovereign 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 (validatorsIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier and amounts) that the Slasher executes.

Core rollupA blockchain that inherits consensus and data availability from another blockchain called L1. Rollups enable trust minimized bridges with the base layer via proof systems, either optimistic or zero-knowledge. A rollup without a bridge, or without considering the bridge, is called a sovereign rollup. logic contract. It processes checkpoint proposals, verifies ZK proofs for state transitions, manages data availabilityThe property of a rollup's data being reachable by any node retrieving the data that were rolled up and executed to reach the proposed state. Data availability (DA), specifically decoupling it from the rollup nodes themselves, is one of the preeminent factors which allows a rollup to scale securely. A rollup is faced with a decision of what to use as a DA layer to guarantee that any node can retrieve this data--permissionlessly under any circumstance. For this reason, using Ethereum for DA currently provides the strongest security guarantees. If data is stored somewhere other than a permissionless L1, then the project is not a rollup, but rather a validium or an optimium., and coordinates validatorIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier 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 proposerIn the context of L2s, the actor that proposes a claimed state root on L1. The term is also used in the context of Ethereum to refer to the actor that proposes a new block. 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 RollupA blockchain that inherits consensus and data availability from another blockchain called L1. Rollups enable trust minimized bridges with the base layer via proof systems, either optimistic or zero-knowledge. A rollup without a bridge, or without considering the bridge, is called a sovereign rollup. for sequencerA party responsible for ordering and executing transactions on the rollup. The sequencer verifies transactions, compresses the data into a block, and submits the data related to it to enable state reconstruction to Ethereum L1 as a single transaction. The data can be either transaction data or state diffs. and proverAn entity that generates the cryptographic proof to convince the verifier that the statement is true. In a ZK-Rollup, the prover generates the ZK (validity) proof to submit to the verifier contract. 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 RollupA blockchain that inherits consensus and data availability from another blockchain called L1. Rollups enable trust minimized bridges with the base layer via proof systems, either optimistic or zero-knowledge. A rollup without a bridge, or without considering the bridge, is called a sovereign rollup. for validatorIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier 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 blockAn ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over. production if the primary sequencerA party responsible for ordering and executing transactions on the rollup. The sequencer verifies transactions, compresses the data into a block, and submits the data related to it to enable state reconstruction to Ethereum L1 as a single transaction. The data can be either transaction data or state diffs. 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 proposerIn the context of L2s, the actor that proposes a claimed state root on L1. The term is also used in the context of Ethereum to refer to the actor that proposes a new block.; 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 hatchThe facility for any user of a rollup to exit the system with their assets under any circumstance. Most relevant in rollups with a centralized proposer, wherein users do not have the ability to propose blocks, but can nonetheless exit the rollup by interacting with a smart contract on L1. regularly opens every 112 epochs, given there are any eligible bonded candidates.

  • Roles:
    • getRollup: RollupA blockchain that inherits consensus and data availability from another blockchain called L1. Rollups enable trust minimized bridges with the base layer via proof systems, either optimistic or zero-knowledge. A rollup without a bridge, or without considering the bridge, is called a sovereign rollup.
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) RollupA blockchain that inherits consensus and data availability from another blockchain called L1. Rollups enable trust minimized bridges with the base layer via proof systems, either optimistic or zero-knowledge. A rollup without a bridge, or without considering the bridge, is called a sovereign 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 blockAn ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over.
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 RollupA blockchain that inherits consensus and data availability from another blockchain called L1. Rollups enable trust minimized bridges with the base layer via proof systems, either optimistic or zero-knowledge. A rollup without a bridge, or without considering the bridge, is called a sovereign 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 validatorsIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier 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 L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. to L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. communication. It stores the roots of L2 to L1 message trees per epoch, which are inserted by the RollupA blockchain that inherits consensus and data availability from another blockchain called L1. Rollups enable trust minimized bridges with the base layer via proof systems, either optimistic or zero-knowledge. A rollup without a bridge, or without considering the bridge, is called a sovereign 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 L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. to L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. 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 RollupA blockchain that inherits consensus and data availability from another blockchain called L1. Rollups enable trust minimized bridges with the base layer via proof systems, either optimistic or zero-knowledge. A rollup without a bridge, or without considering the bridge, is called a sovereign rollup. contract to sequentially consume the roots of these message trees, ensuring message inclusion.

FeeJuicePortal
Escrow
0xaf73…691c

One-way gasA virtual fuel used to execute smart contracts on a rollup. The EVM (or other VM within the rollup) uses an accounting mechanism to correspond the consumption of gas to the consumption of computing resources, and to limit the consumption of computing resources. bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge.: Escrows the fee asset (AZTEC) used to pay for L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. mana (gas). Users deposit tokens here, which are minted on L2 via the Inbox. The RollupA blockchain that inherits consensus and data availability from another blockchain called L1. Rollups enable trust minimized bridges with the base layer via proof systems, either optimistic or zero-knowledge. A rollup without a bridge, or without considering the bridge, is called a sovereign rollup. contract holds exclusive rights to withdraw tokens from this portal to distribute them as rewards to L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. 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