{
"stage": "Stage 2",
"summary": [
{
"stage": "Stage 0",
"requirements": [
{
"satisfied": true,
"description": "A complete and functional proof system is deployed."
},
{
"satisfied": true,
"description": "The project calls itself a rollup."
},
{
"satisfied": true,
"description": "State roots are posted to Ethereum L1."
},
{
"satisfied": true,
"description": "Inputs for the state transition function are posted to Ethereum L1."
},
{
"satisfied": true,
"description": "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://docs.aztec.network/operate/operators/setup/running_a_node)"
"description": "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": "Stage 1",
"requirements": [
{
"satisfied": true,
"description": "Users are able to exit without the help of the permissioned operators."
},
{
"satisfied": true,
"description": "In case of an unwanted upgrade by actors more centralized than a Security Council, users have at least 7d to exit."
},
{
"satisfied": true,
"description": "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).",
"upcoming": true
},
{
"satisfied": true,
"description": "Prover source code is published.",
"upcoming": true
},
{
"satisfied": true,
"description": "Onchain verifiers' smart contracts can be independently regenerated from the verifier source code.",
"upcoming": true
}
],
"principle": {
"satisfied": true,
"description": "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."
}
},
{
"stage": "Stage 2",
"requirements": [
{
"satisfied": true,
"description": "Upgrades unrelated to onchain provable bugs provide at least 30d to exit."
"description": "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."
}
]
}
]
}
scalingRisks+2-2
{
"self": {
"stateValidation": {
"value": "Validity proofs (SN)",
"description": "SNARKs are succinct zero knowledge proofs that ensure state correctness, but require trusted setup.",
"sentiment": "good",
"orderHint": null,
"permissioned": false,
"executionDelay": 0,
"secondLine": "No execution delay"
},
"dataAvailability": {
"value": "Onchain (SD)",
"description": "All of the data (SD = state diffs) needed for proof construction is published onchain.",
"description": "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.",
"sentiment": "good",
"orderHint": null
},
"exitWindow": {
"value": "∞",
"description": "Users can exit funds at any time because contracts are not upgradeable. Governance can remove Sequencers and prevent new sequencers from joining, making the bonded escape hatch the only exit path in the worst case.",
"description": "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.",
"sentiment": "good",
"orderHint": null
},
"sequencerFailure": {
"value": "Decentralized Sequencer Set",
"sentiment": "good",
"description": "Users can permissionlessly become a sequencer by staking 200 K AZTEC to join the queue and wait to obtain committee-based block production rights. If the pseudo-randomly sampled committees censor proposals, anyone who bonds 332 M AZTEC will join the escape hatch candidate set. Every 2d 23h, a candidate is pseudo-randomly selected to propose and prove checkpoints fully autonomously. A candidate remains in the set until they are selected or leave voluntarily."
},
"proposerFailure": {
"value": "Self Propose",
"sentiment": "good",
"description": "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."
}
}
}
scalingTechnology+69-46
{
"dataAvailability": [
{
"name": "All transaction results (state diffs) are published in Ethereum blobs",
"description": "Each checkpoint proposal includes EIP-4844 blob commitments that are checked against the blob hashes in the proposing transaction. The epoch proof revalidates the accumulated blob commitments before the epoch is finalized.",
"description": "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": [
{
"title": "Rollup.sol - propose() on Etherscan",
"url": "https://etherscan.io/address/0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962#code"
"url": "https://etherscan.io/address/0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34#code"
},
{
"title": "Rollup.sol - validateBlobs() on Etherscan",
"url": "https://etherscan.io/address/0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962#code"
"url": "https://etherscan.io/address/0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34#code"
}
],
"risks": []
}
],
"exitMechanisms": [
{
"name": "Regular messaging",
"description": "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.",
"risks": [],
"references": [
{
"title": "Rollup.sol - submitEpochRootProof() on Etherscan",
"url": "https://etherscan.io/address/0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962#code"
"url": "https://etherscan.io/address/0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34#code"
},
{
"title": "Outbox.sol - consume() on Etherscan",
"url": "https://etherscan.io/address/0xc9698B7AdEf9ee63F3Bf5cFF38086e4E836579f0#code"
"url": "https://etherscan.io/address/0x5B062aB5fD3A66BC7e73b04CeD38587673b6A2D7#code"
}
]
}
],
"forceTransactions": {
"name": "Bonded, probabilistic self-sequencing",
"description": "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": [
{
"category": "Users can be censored if",
"text": "no honest regular proposer or eligible bonded escape-hatch proposer includes and proves their transactions."
}
],
"references": [
{
"title": "EscapeHatch.sol on Etherscan",
"url": "https://etherscan.io/address/0xF459348962F5eA3A9A101826B03A2CE1F459E51A#code"
}
]
},
"operator": {
"name": "There is no central operator",
"description": "There is no privileged sequencer. Anyone can stake 200 K AZTEC to join the sequencer queue, and anyone can call flushEntryQueue() to activate queued sequencers once the queue rules allow it.",
"risks": [],
"references": [
{
"title": "Rollup.sol - deposit() on Etherscan",
"url": "https://etherscan.io/address/0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962#code"
"url": "https://etherscan.io/address/0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34#code"
},
{
"title": "Rollup.sol - flushEntryQueue() on Etherscan",
"url": "https://etherscan.io/address/0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962#code"
"url": "https://etherscan.io/address/0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34#code"
}
]
},
"otherConsiderations": [
{
"name": "Upgrades replace the canonical rollup",
"description": "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": [
{
"title": "Registry.sol - addRollup() on Etherscan",
"url": "https://etherscan.io/address/0x35b22e09Ee0390539439E24f06Da43D83f90e298#code"
},
{
"title": "Governance.sol - execute() on Etherscan",
"url": "https://etherscan.io/address/0x1102471Eb3378FEE427121c9EfcEa452E4B6B75e#code"
}
],
"risks": []
},
{
"name": "No canonical bridge escrow",
"description": "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": [
{
"title": "FeeJuicePortal.sol - on Etherscan",
"url": "https://etherscan.io/address/eth:0x2891F8b941067F8B5a3F34545A30Cf71E3E23617#code"
"url": "https://etherscan.io/address/eth:0xaf73Dd51D1eb8a079BB097f39c832cDD00ac691c#code"
},
{
"title": "Outbox.sol - on Etherscan",
"url": "https://etherscan.io/address/0xc9698B7AdEf9ee63F3Bf5cFF38086e4E836579f0#code"
"url": "https://etherscan.io/address/0x5B062aB5fD3A66BC7e73b04CeD38587673b6A2D7#code"
}
],
"risks": []
},
{
"name": "Inclusion is probabilistic",
"description": "All censorship resistance tools that are part of the protocol rely on probabilistic inclusion. In contrast to \"forced transactions\", there is no simple deterministic inclusion after some maximum delay, but rather different inclusion probabilities after different time horizons. The \"time needed to exit\" of 20d for the exit window was simulated by using a simple model of the decentralized sequencer set at launch. The escape hatch and private transactions can give additional inclusion guarantees.",
"description": "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": [
{
"title": "CRsim - Simulated inclusion probability on Aztec",
"url": "https://sekuba.github.io/crsim"
}
],
"risks": []
}
],
"sequencing": {
"name": "Transactions are ordered by a staked validator committee",
"description": "Joining the sequencer set is permissionless and requires staking 200 K AZTEC. For each epoch, the rollup samples a 48-member committee from the active sequencer set of 3334 and selects one proposer from the current committee per slot. More than 2/3 of the sequencers in the committee need to attest to each proposed block in an epoch for it to be valid.",
"description": "Joining the sequencer set is permissionless and requires staking 200 K AZTEC. For each epoch, the Rollup samples a 48-member committee from the active set of 3462 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.",
"sequencerSetSpec": {
"slotTime": {
"blockTime": {
"value": "6s",
"description": "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."
},
"proposerRotationTime": {
"value": "1m 12s"
},
"epochTime": {
"committeeRotationTime": {
"value": "38m 24s",
"description": "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"
},
"sequencerCount": {
"value": "3334 sequencers"
"value": "3462 sequencers"
},
"blockProductionAccess": {
"value": "Open",
"sentiment": "good"
},
"stakePerValidator": {
"value": "200 K AZTEC, constant"
},
"rateLimit": {
"value": "Up to 4 sequencers per epoch (current)",
"description": "Can be changed (or set to 0) by onchain Governance"
"description": "Can be changed by onchain Governance, but the contract requires nonzero minimum, divisor, and maximum queue-flush parameters."
},
"deterministicCrGadget": {
"value": "No",
"sentiment": "warning"
},
"additionalCrGadgets": {
"value": "Bonded escape hatch, private transactions",
"sentiment": "good"
}
},
"inclusionDelayChart": {
"type": "committeelike",
"validatorCount": 3334,
"validatorCount": 3462,
"committeeSize": 48,
"epochSlots": 32,
"slotSeconds": 72,
"blockingThreshold": 15,
"target": 0.99,
"maxCensorFraction": 0.5,
"stakeDistribution": {
"stakeToken": "AZTEC",
"totalStake": 609016000,
"totalStake": 610642000,
"entities": [
{
"name": "Nethermind",
"stake": 113800000
"stake": 113600000
},
{
"name": "Nansen | Stake to Stack Points",
"stake": 77200000
"stake": 75800000
},
{
"name": "Sigma Prime",
"stake": 53200000
"stake": 66800000
},
{
"name": "snoopfear|PON",
"stake": 47400000
},
{
"name": "P2P.org",
"stake": 42398000
"stake": 41600000
},
{
"name": "Wonderland",
"stake": 39000000
"name": "snoopfear|PON",
"stake": 37200000
},
{
"name": "ZKV",
"stake": 29416000
"stake": 30816000
},
{
"name": "GabbexNodes",
"stake": 28000000
"stake": 27400000
},
{
"name": "01node",
"stake": 21400000
"name": "Wonderland",
"stake": 26600000
},
{
"name": "Aztec-Scan",
"stake": 18600000
"name": "Nightwolf Labs",
"stake": 22800000
},
{
"name": "01node",
"stake": 21600000
}
]
}
},
"inclusionDelayChartDescription": "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.",
"censorshipResistance": "The committee and regular sequencer set can be circumvented via the escape hatch, which designates a bonded proposer (via RANDAO) who can publish checkpoints without committee attestations. The bond is 332 M AZTEC, a high amount that is supposed to protect the single-proof system in case of bugs while still providing a last resort opportunity to circumvent the sequencer set. Aztec has developed a full private execution environment on the L2. This can benefit users because they cannot be censored based on their transaction content.\n### Selective censorship\nOn a live Aztec L2 with a given fraction of censoring sequencers, users can either send private transactions or wait for a non-censoring committee and proposing sequencer to include their public transaction.\n### Blanket censorship\nIf users are censored by the entire sequencer set, even if it stops block production just to censor, anyone can join the sequencer set permissionlessly at the churn rate or circumvent it completely by bonding and using the escape hatch. In both cases, expensive hardware is required to provide the required validity proof. Motivated censorers can try to saturate the entry queue and the escape hatch with their own new sequencers and thus lower the inclusion chances of the censored.\n### Walkaway\nIn the scenario of all sequencers stopping their service, the escape hatch provides an inclusion guarantee of 2d 23h in the worst case and the sequencer set can heal long-term by permissionless entry and churn.",
"censorshipResistance": "The regular committee can be circumvented by the escape hatch, which uses RANDAO to designate a previously enrolled bonded candidate that may publish checkpoints without committee attestations. Enrollment requires 332 M AZTEC, a high bond intended to protect the single-proof system while providing a last-resort path around the regular sequencer set. Aztec's private execution environment can also make selective censorship harder because transaction contents are hidden.\n\n### Selective censorship\n\nOn 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.\n\n### Blanket censorship\n\nIf 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.\n\n### Walkaway\n\nHatch 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": [
{
"title": "Aztec docs - Privacy considerations",
"url": "https://github.com/AztecProtocol/aztec-packages/blob/next/docs/docs-developers/docs/resources/considerations/privacy_considerations.md#function-fingerprints-and-tx-fingerprints"
},
{
"title": "Rollup.sol - getProposerAt() on Etherscan",
"url": "https://etherscan.io/address/0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962#code"
"url": "https://etherscan.io/address/0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34#code"
},
{
"title": "EscapeHatch.sol - selectCandidates() on Etherscan",
"url": "https://etherscan.io/address/0x8c189ead28D5987A48e522162f9225124D50AD1B#code"
"url": "https://etherscan.io/address/0xF459348962F5eA3A9A101826B03A2CE1F459E51A#code"
}
],
"risks": []
},
"stateValidation": {
"description": "Each epoch root proof is verified by the HonkVerifier smart contract on Ethereum before the proven checkpoint number is advanced and the epoch outbox state root is inserted into the Outbox. Proving is permissionless, and a single proof can cover one Checkpoint (1m 12s) to one epoch (38m 24s). Unproven checkpoints are pruned after the proof submission window of 1h 16m expires.",
"description": "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.",
"categories": [
{
"title": "State root proposals",
"description": "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": [
{
"title": "Rollup.sol - submitEpochRootProof() on Etherscan",
"url": "https://etherscan.io/address/0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962#code"
"url": "https://etherscan.io/address/0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34#code"
}
],
"risks": []
},
{
"title": "Validity proofs",
"description": "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.",
"risks": [],
"references": [
{
"title": "Rollup.sol - submitEpochRootProof() on Etherscan",
"url": "https://etherscan.io/address/0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962#code"
"url": "https://etherscan.io/address/0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34#code"
},
{
"title": "HonkVerifier.sol - verify() on Etherscan",
"url": "https://etherscan.io/address/0x70aEDda427f26480D240bc0f4308ceDec8d31348#code"
"url": "https://etherscan.io/address/0x098f47c00F4df22a8030746Eb11378236C24b4bC#code"
}
]
},
{
"title": "Slashing",
"description": "Each stake of 200 K AZTEC that is locked to join the sequencer set and vote in governance can be slashed under certain conditions. Slashing is voted on by sequencers each time they propose a checkpoint and is grouped in rounds that span 4 epochs (2h 33m) each.\n\nSlashing conditions are programmed into each sequencer node and can be changed by node operators by updating or editing their node software. Nodes usually submit votes to slash automatically on L1. The `TallySlashingProposer` contract only enforces the formalities of the slashing system:\n* A given slashing round's votes always target the checkpoint proposals from 2 rounds ago.\n* As soon as a round's votes have reached a quorum of 65/128, it enters an execution delay of 28 rounds (2d 23h)\n* An automatically generated slashing payload is executable by anyone on L1 after the execution delay, applying the slashing penalties defined by the sequencer votes.\n\nSlashing penalties are defined onchain in three levels: large (2.00 K AZTEC), medium (2.00 K AZTEC), and small (2.00 K AZTEC). Offenses that lead to slashing usually include:\n* Inactivity: A sequencer fails to attest or propose when selected.\n* Data Withholding: A sequencer proposes a checkpoint including state diff data availability on L1 but withholds the public transaction bodies and/or CHONK proofs required for permissionless proving.\n* Invalidity: A sequencer attests to invalid proposals, multiple conflicting proposals, with invalid signatures, or proposes a block that is not proven in time.\n\nThe above offense list is not exhaustive and not defined onchain but usually in the software the sequencers decide to run. This is also where the mapping of offenses to the slashing penalty levels can be defined.\n\nThe SlashVeto Council is a 5/9 Multisig that can veto specific proposals and/or all slashing for 3d at a time.",
"description": "Each 200 K AZTEC stake used to join the sequencer set and vote in governance can be slashed. The designated proposer for each slot can submit one separate signed ballot on L1. Ballots are grouped into rounds spanning 4 epochs (2h 33m).\n\nSlashing 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:\n\n* Ballots in a round target committee members from 2 rounds earlier.\n* 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.\n* A round becomes executable after more than 28 rounds (approximately 2d 23h) and expires at age 34 rounds, leaving a 6-round execution window.\n* 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.\n\nThe 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:\n\n* **Inactivity:** a sequencer fails to attest or propose when selected.\n* **Data withholding:** a sequencer publishes state-diff blobs but withholds public transaction bodies or CHONK proofs needed for permissionless proving.\n* **Invalidity or equivocation:** a sequencer attests to an invalid proposal, signs conflicting proposals or attestations, or uses an invalid signature.\n\nThis 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.\n\nThe 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": [
{
"title": "Slashing - Aztec Docs",
"url": "https://docs.aztec.network/operate/operators/sequencer-management/slashing_and_offenses"
"title": "SlashingProposer.sol on Etherscan",
"url": "https://etherscan.io/address/eth:0x8A36b8F2Ca71D8d8Bd98e03Ebf8B4D0939Daf0bA#code"
},
{
"title": "Slasher.sol on Etherscan",
"url": "https://etherscan.io/address/eth:0xCD6855470A01aBcd989126A1183Fb50673952548#code"
},
{
"title": "SlashVeto Council - Github",
"url": "https://github.com/aztec-slash-veto/council"
},
{
"title": "slashveto.me - Monitor Slashing",
"url": "https://slashveto.me"
}
],
"risks": []
}
]
},
"upgradesAndGovernance": {
"content": "# Standard Path (Signaling)\nBecause sequencers stake AZTEC tokens to secure the L2 network, they are also the primary governors of the system. Any governance proposal must be encoded and deployed as a smart contract payload on Ethereum. While core contracts are immutable, the onchain Governance system can designate a new 'canonical' rollup with a 2d delay and has access to critical configuration permissions that can freeze or compromise the Rollup system. These permissions can only be accessed through the process described below.\n\n## 1. The Signaling Phase (`GovernanceProposer`)\nAztec uses an onchain \"Empire\" signaling system. Active sequencers operating on the 'canonical rollup' (as defined by the Registry) call `signal(payloadAddress)` on the L1 `GovernanceProposer` contract during their designated L2 slots to support a specific upgrade payload. A voting round consists of 1,000 slots. To win a round and become a formal proposal, a payload must receive signals from at least 600 slots. Once quorum is reached, the payload is submitted to the L1 `Governance` contract.\n\n## 2. The Voting Phase (`Governance`)\nOnce submitted, the proposal enters a delay and voting flow:\n* **Pending (3d):** At the end of this delay, voting power is snapshotted.\n* **Active (7d):** AZTEC token holders can vote. To pass, a proposal must reach a 20% Quorum of all staked power, and the `yea` votes must exceed a required margin of 33%.\n* **Queued (2d):** If successful, the proposal enters an execution delay. This acts as an exit window, allowing dissenting sequencers to initiate a withdrawal of their staked tokens before the malicious/disagreed-upon code is executed.\n* Executable (7d): The proposal enters a grace period where anyone can call `execute()`. If not executed, it expires.\n\nTotal standard delay from proposal to execution: **12d**.\n\n### Emergency Path (Circumvent Signaling)\nIf the L2 sequencer set is offline, censoring, or acting maliciously, the `GovernanceProposer` cannot be used. To ensure liveness, anyone can bypass the Sequencer signaling phase using the `proposeWithLock()` function directly on the `Governance` contract.\n* An actor must lock **258 M AZTEC**, roughly 2.5% of total supply\n* These funds are locked for an extended 3mo.\n* Once proposed, the payload enters the exact same 12d Voting Phase (Pending -> Active -> Queued -> Executable) as the standard path.\n\n### Rollup Immutability\nThe smart contract code of `Rollup`, its verifier and its canonical messaging contracts cannot be changed. For feature upgrades, users need to migrate to a new Rollup. Migrating Rollups involves a `Governance` action that designates a new `Rollup` contract address as canonical. The `GSE` (Governance Staking Escrow) automatically migrates the voting power and stake of all active sequencers to the new rollup version if they staked to the default magic address `0x9064Fb41156D300196d5Eb95E0B3c1f08eBc39a8` instead of a specific immutable rollup. Importantly, `Governance` has revoked ownership and access to all critical config options of the current core Rollup contract, which makes it fully autonomous via the Escape Hatch. Governance can only remove staking incentives by creating a new 'canonical' Rollup and brick the sequencer queue via `GSE.setProofOfPossessionGasLimit(0)`, leaving the Escape Hatch as the fully immutable option to progress the L2 in the worst case.\n\n### Slashing and the SlashVeto Council\nAztec features onchain slashing for equivocation or missing attestations, managed by `Slasher` and `TallySlashingProposer`. \n\nThere is a protective **Vetoer** role held by the SlashVeto Council. The Council cannot upgrade the protocol, alter governance, or steal funds. Instead it is limited to two permissions:\n* call `vetoPayload()` to stop a specific slashing event.\n* call `setSlashingEnabled(false)`, which pauses all slashing in the protocol for a period of 3d.\n\n### Economics & Treasury\n* **Coin Issuer:** The `CoinIssuer` contract is owned by Governance and is authorized to mint new AZTEC tokens up to a cap of 20% of the current total supply per year.\n* **Protocol Treasury:** Funds owned by the DAO sit in the `ProtocolTreasury`. The Treasury has a hardcoded timestamp (approx. Nov 2026). Before this date, the DAO cannot spend Treasury funds. After this date, Treasury funds and token ownership can be moved with a Governance Proposal."
},
"warning": "Aztec v4 has [know security vulnerabilities](https://aztec.network/blog/critical-vulnerability-in-alpha-v4) that can only be fixed in a new deployment."
"content": "# Standard path (sequencer signaling)\n\nSequencers 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.\n\n## 1. Signaling (`GovernanceProposer`)\n\nAztec 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`.\n\n## 2. Token voting (`Governance`)\n\nOnce submitted, a proposal passes through these states:\n\n* **Pending (3d):** voting power is snapshotted at the end of this delay.\n* **Active (7d):** AZTEC holders vote. The snapshot must contain at least 100 M AZTEC of total voting power, at least 20% of that power must vote, and `yea` must be strictly greater than 66.5% of votes cast (the configured `yea`-minus-`nay` margin is 33%).\n* **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.\n* **Executable (7d):** anyone can execute the proposal during this grace period; otherwise it expires.\n\n## Emergency proposal path\n\nIf sequencer signaling is unavailable, anyone can call `proposeWithLock()` directly on `Governance`. The proposer must lock **258 M AZTEC**, roughly 2.5% of the total supply, for 3mo. The payload then follows the same pending, voting, queued, and executable phases as a signaled proposal.\n\n## Immutable deployments and bounded ownership\n\nThe `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.\n\nGovernance 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.\n\nGovernance 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.\n\n## Slashing and the SlashVeto Council\n\nAztec'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.\n\nThe **Vetoer** role is held by the SlashVeto Council. It cannot upgrade the protocol or relay arbitrary calls. It can:\n\n* veto a specific payload permanently; and\n* disable all slashing for 3d. Calling the function again renews the pause, while the Council can also re-enable slashing early.\n\n## Economics and treasury\n\n* **CoinIssuer:** the owner can mint AZTEC within an annual cap of 20% of the current total supply.\n* **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."
}
}
{
"explanation": "Aztec posts checkpoint data to Ethereum blobs and finalizes checkpoints once an epoch root proof is verified on Ethereum. Transactions should be considered final only after the corresponding epoch proof is accepted on L1.",
"warnings": {
"batchSubmissions": "Checkpoints that are posted to Ethereum but not yet proven can be pruned once the proof submission window of 1h 16m expires."
"batchSubmissions": "Checkpoints posted to Ethereum remain pending until proven and can be pruned after their epoch proof deadline. With the current configuration, the maximum window is 1h 16m; the effective window ranges from roughly one to two epochs depending on a checkpoint's position in its epoch."
}
}
{
"ethereum": {
"roles": [],
"actors": [
{
"id": "Rollup",
"name": "Rollup",
"accounts": [
{
"address": "eth:0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962",
"type": "Contract",
"isVerified": true,
"name": "0xAe20…4962",
"url": "https://etherscan.io/address/0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962"
}
],
"chain": "ethereum",
"description": "Core rollup logic contract. It processes checkpoint proposals, verifies ZK proofs for state transitions, manages data availability, and coordinates validator selection and chain tip updates.\n* Can interact with RewardBooster\n * update prover activity scores used to calculate boosted prover reward shares \n* Can interact with FeeJuicePortal\n * distribute fee-asset funds escrowed in the portal to sequencers and provers \n* Can interact with RewardDistributor\n * claim protocol reward funds and direct them to sequencers and provers \n* Can interact with EscapeHatch\n * record submitted archives for designated escape-hatch proposers, which are later used to validate or slash them \n* Can interact with Inbox\n * consume L1 to L2 message tree roots for checkpoint processing \n* Can interact with Outbox\n * insert L2 to L1 message roots that recipients later prove against to consume withdrawals or messages ",
"discoveryDrivenData": true
},
{
"id": "Governance",
"name": "Governance",
"accounts": [
{
"address": "eth:0x1102471Eb3378FEE427121c9EfcEa452E4B6B75e",
"type": "Contract",
"isVerified": true,
"name": "0x1102…B75e",
"url": "https://etherscan.io/address/0x1102471Eb3378FEE427121c9EfcEa452E4B6B75e"
}
],
"chain": "ethereum",
"description": "DAO contract used for proposals and token voting. Heavily interdependent with the GSE for voting power snapshots.\n* Can interact with CoinIssuer\n * mint new AZTEC in the bounds of the minting caps [via: ProtocolTreasury the GATED_UNTIL timestamp has passed]\n* Can interact with Registry\n * register a new canonical rollup version and replace the reward distributor used by the network \n* Can interact with Slasher\n * execute slashing payloads directly, bypassing the proposer address but still subject to vetoes and temporary slashing disablement \n* Can interact with GSE\n * set governance once, change the proof-of-possession gas limit, and add new rollup addresses that make bonus-instance validators effective on the latest rollup ",
"description": "DAO contract used for proposals and token voting. Heavily interdependent with the GSE for voting power snapshots.\n* Can interact with CoinIssuer\n * 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]\n* Can interact with Registry\n * 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 \n* Can interact with RewardDistributor\n * recover AZTEC from any implicit or earmarked accounting bucket and recover any non-AZTEC token held by the distributor \n* Can interact with ProtocolTreasury\n * relay arbitrary calls and ETH from the ProtocolTreasury \n* Can interact with Rollup\n * 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 \n * 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]\n* Can interact with GSE\n * 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 \n* Can interact with Slasher\n * execute arbitrary payload actions through the Slasher, bypassing all proposer validation including ballots, quorum, target construction, delay, and lifetime ",
"discoveryDrivenData": true
},
{
"id": "TallySlashingProposer",
"name": "TallySlashingProposer",
"id": "SlashingProposer",
"name": "SlashingProposer",
"accounts": [
{
"address": "eth:0xa4a38fD0108C00983E75616b638Ff3321FD26958",
"address": "eth:0x8A36b8F2Ca71D8d8Bd98e03Ebf8B4D0939Daf0bA",
"type": "Contract",
"isVerified": true,
"name": "0xa4a3…6958",
"url": "https://etherscan.io/address/0xa4a38fD0108C00983E75616b638Ff3321FD26958"
"name": "0x8A36…f0bA",
"url": "https://etherscan.io/address/0x8A36b8F2Ca71D8d8Bd98e03Ebf8B4D0939Daf0bA"
}
],
"chain": "ethereum",
"description": "Aggregates validator committee votes for slashing. Once a round reaches quorum and the execution delay has passed, it builds a slash payload and asks the Slasher to execute it.\n* Can interact with Slasher\n * execute slashing payloads that slash validators, unless slashing is currently disabled or the payload has been vetoed ",
"description": "Collects one signed slashing ballot from the designated proposer in each slot. After the execution delay, anyone can tally the ballots per validator and penalty level, deploy the resulting payload, and ask the Slasher to execute it before the round expires.\n* Can interact with Rollup\n * 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]\n* Can interact with Slasher\n * execute payload actions accepted by its validator-ballot tally after the proposer-enforced delay ",
"discoveryDrivenData": true
},
{
"id": "SlashVeto Council",
"name": "SlashVeto Council",
"description": "A Multisig with 5/9 threshold. \n* Can interact with Slasher\n * veto specific slashing payloads and/or disable all slashing for 3d at a time ",
"description": "A Multisig with 5/9 threshold. \n* Can interact with Slasher\n * veto specific payloads, repeatedly disable all slashing for 3d at a time, or re-enable slashing before a pause expires ",
"accounts": [
{
"address": "eth:0xBbB4aF368d02827945748b28CD4b2D42e4A37480",
"type": "Contract",
"isVerified": true,
"name": "0xBbB4…7480",
"url": "https://etherscan.io/address/0xBbB4aF368d02827945748b28CD4b2D42e4A37480"
}
],
"chain": "ethereum",
"references": [],
"participants": [
{
"address": "eth:0xb33a08eF4624eE8F409F749Ee73766E225bEd0F4",
"type": "EOA",
"isVerified": true,
"name": "0xb33a…d0F4",
"url": "https://etherscan.io/address/0xb33a08eF4624eE8F409F749Ee73766E225bEd0F4"
},
{
"address": "eth:0xb6Da7B7a0d8c7349630183f4Bd6F13D4a8AD9216",
"type": "EOA",
"isVerified": true,
"name": "0xb6Da…9216",
"url": "https://etherscan.io/address/0xb6Da7B7a0d8c7349630183f4Bd6F13D4a8AD9216"
},
{
"address": "eth:0xB216FcaF63c6C0f73a557B342e1Da9710C95DA81",
"type": "EOA",
"isVerified": true,
"name": "0xB216…DA81",
"url": "https://etherscan.io/address/0xB216FcaF63c6C0f73a557B342e1Da9710C95DA81"
},
{
"address": "eth:0x81062F03742B88923eaB121243B69D0a0092089e",
"type": "EOA",
"isVerified": true,
"name": "0x8106…089e",
"url": "https://etherscan.io/address/0x81062F03742B88923eaB121243B69D0a0092089e"
},
{
"address": "eth:0x32e90E88bb2E6Ee4382e6884cC5c299a6bA27920",
"type": "EOA",
"isVerified": true,
"name": "0x32e9…7920",
"url": "https://etherscan.io/address/0x32e90E88bb2E6Ee4382e6884cC5c299a6bA27920"
},
{
"address": "eth:0x23d4A9533627eA70915026638ff5989a967Be667",
"type": "EOA",
"isVerified": true,
"name": "0x23d4…e667",
"url": "https://etherscan.io/address/0x23d4A9533627eA70915026638ff5989a967Be667"
},
{
"address": "eth:0x8138c46A572D989E54837d5e5dEB506889edFb5D",
"type": "EOA",
"isVerified": true,
"name": "0x8138…Fb5D",
"url": "https://etherscan.io/address/0x8138c46A572D989E54837d5e5dEB506889edFb5D"
},
{
"address": "eth:0x0Fb6215099f48D723CfB89434C2cb887357Bc871",
"type": "EOA",
"isVerified": true,
"name": "0x0Fb6…c871",
"url": "https://etherscan.io/address/0x0Fb6215099f48D723CfB89434C2cb887357Bc871"
},
{
"address": "eth:0x7EAbE4F636B937628A7Fe503bD7F06772C047FEe",
"type": "EOA",
"isVerified": true,
"name": "0x7EAb…7FEe",
"url": "https://etherscan.io/address/0x7EAbE4F636B937628A7Fe503bD7F06772C047FEe"
}
],
"discoveryDrivenData": true
},
{
"id": "CoinIssuer",
"name": "CoinIssuer",
"accounts": [
{
"address": "eth:0x02FAdF157d551aa6d761b2A2237D03Af68E41CA6",
"type": "Contract",
"isVerified": true,
"name": "0x02FA…1CA6",
"url": "https://etherscan.io/address/0x02FAdF157d551aa6d761b2A2237D03Af68E41CA6"
}
],
"chain": "ethereum",
"description": "Manages the inflation and minting schedule of the Aztec token. It enforces an annual percentage cap and mints new tokens for the budget.\n* Can interact with AZTEC Token\n * mint unlimited amounts of the AZTEC token and transfer the ownership of the contract ",
"discoveryDrivenData": true
},
{
"id": "GovernanceProposer",
"name": "GovernanceProposer",
"accounts": [
{
"address": "eth:0x06Ef1DcF87E419C48B94a331B252819FADbD63ef",
"type": "Contract",
"isVerified": true,
"name": "0x06Ef…63ef",
"url": "https://etherscan.io/address/0x06Ef1DcF87E419C48B94a331B252819FADbD63ef"
}
],
"chain": "ethereum",
"description": "Intermediary contract that allows the L2 Sequencers operating the canonical rollup (as defined by the Registry) to submit formal proposals to the L1 Governance contract by signalling their support of any smart contract payload on L1 with each checkpoint proposal. A signalling round comprises 1000 checkpoints. 600 signals or more during one round allow submitting the payload as a governance proposal.\n* Can interact with Governance\n * create proposals ",
"description": "Intermediary contract through which the designated proposer for each L2 slot can signal support for an L1 payload. A signalling round comprises 1000 slots. A payload that receives at least 600 signals can be submitted to the L1 Governance contract within the configured lifetime.\n* Can interact with Governance\n * create proposals ",
"discoveryDrivenData": true
},
{
"id": "EOA-1",
"name": "EOA 1",
"accounts": [
{
"address": "eth:0x92Ba0FD39658105FaC4dF2B9BADE998B5816b350",
"type": "EOA",
"isVerified": true,
"name": "0x92Ba…b350",
"url": "https://etherscan.io/address/0x92Ba0FD39658105FaC4dF2B9BADE998B5816b350",
"displayName": "EOA 1"
}
],
"chain": "ethereum",
"description": "* Can interact with AztecTokenPositionRegistry_ProtocolTreasury\n * set the time at which the ProtocolTreasury funds can be transfered and manage staker implementations referenced by this contract ",
"description": "* Can interact with AztecTokenPositionRegistry_ProtocolTreasury\n * add and resolve milestones, register staker implementations, set revoker roles, only decrease the execution and token unlock timestamps, and transfer or renounce ownership ",
"discoveryDrivenData": true
}
]
}
}
contracts+140-47
{
"addresses": {
"ethereum": [
{
"name": "HonkVerifier",
"isVerified": true,
"address": "eth:0x098f47c00F4df22a8030746Eb11378236C24b4bC",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "ZK proof verification contract.\n",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0x098f47c00F4df22a8030746Eb11378236C24b4bC#code"
},
{
"name": "RewardBooster",
"isVerified": true,
"address": "eth:0x1CbB707Bd7b4Fd2BcED6D96d84372fb428e93D80",
"address": "eth:0x4490cAb7Ce3499353E1b0090b9e530c1AD03B551",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "Calculates boosted reward shares for active provers based on a configured curve, incentivizing consistent participation.\n* Roles:\n * **rollup**: Rollup",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0x1CbB707Bd7b4Fd2BcED6D96d84372fb428e93D80#code"
"url": "https://etherscan.io/address/0x4490cAb7Ce3499353E1b0090b9e530c1AD03B551#code"
},
{
"name": "RollupOperationsExtLib",
"isVerified": true,
"address": "eth:0x516f010C9AB452d70E0c6f78b9E698249a66d2AC",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "Library immutably linked into the Rollup for checkpoint proposal, proof verification, pruning, and chain-tip operations. Its functions operate on the calling Rollup's storage through DELEGATECALL, so direct getter calls on the library are ignored.\n",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0x516f010C9AB452d70E0c6f78b9E698249a66d2AC#code"
},
{
"name": "RewardDistributor",
"isVerified": true,
"address": "eth:0x3D6A1B00C830C5f278FC5dFb3f6Ff0b74Db6dfe0",
"address": "eth:0x555bAAc4757A89f1CE0c84fA35afE9dD7aa8E1d3",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "Holds tokens allocated for protocol rewards. The canonical Rollup contract, as defined by the Registry, can draw from the implicit reward pool while any address can claim only funds explicitly earmarked to it.\n* Roles:\n * **canonicalRollup**: Rollup",
"description": "Holds tokens allocated for protocol rewards. The canonical Rollup contract, as defined by the Registry, can draw from the implicit reward pool while any address can claim only funds explicitly earmarked to it.\n* Roles:\n * **canonicalRollup**: Rollup\n * **registryOwner**: Governance",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0x3D6A1B00C830C5f278FC5dFb3f6Ff0b74Db6dfe0#code"
"url": "https://etherscan.io/address/0x555bAAc4757A89f1CE0c84fA35afE9dD7aa8E1d3#code"
},
{
"name": "SlashPayloadCloneable",
"isVerified": true,
"address": "eth:0x57576AbA1932df7Cc30F971ACC9d4Fc6E86B6e87",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "A template for specific slashing payload contracts deployed deterministically to encode one or more slashing actions (validators and amounts) that the Slasher executes.\n",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0x57576AbA1932df7Cc30F971ACC9d4Fc6E86B6e87#code"
},
{
"name": "Rollup",
"isVerified": true,
"address": "eth:0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "Core rollup logic contract. It processes checkpoint proposals, verifies ZK proofs for state transitions, manages data availability, and coordinates validator selection and chain tip updates.\n* Roles:\n * **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\n * **owner**: Governance",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34#code"
},
{
"name": "Slasher",
"isVerified": true,
"address": "eth:0x64E6e9Bb9f1E33D319578B9f8a9C719Ca6D46eBb",
"address": "eth:0xCD6855470A01aBcd989126A1183Fb50673952548",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "The executor contract for penalties. It receives authorization to slash validator stakes, subject to an execution delay and a vetoer.\n* Roles:\n * **governance**: Governance\n * **proposer**: TallySlashingProposer\n * **vetoer**: SlashVeto Council",
"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.\n* Roles:\n * **governance**: Governance slashing is enabled and the payload has not been vetoed\n * **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\n * **vetoer**: SlashVeto Council",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0x64E6e9Bb9f1E33D319578B9f8a9C719Ca6D46eBb#code"
"url": "https://etherscan.io/address/0xCD6855470A01aBcd989126A1183Fb50673952548#code"
},
{
"name": "HonkVerifier",
"name": "RewardExtLib",
"isVerified": true,
"address": "eth:0x70aEDda427f26480D240bc0f4308ceDec8d31348",
"address": "eth:0xD6E890c615d6f99681a00771C20ed04516288898",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "ZK proof verification contract.\n",
"description": "Library immutably linked into the Rollup for sequencer and prover reward accounting. Its functions operate on the calling Rollup's storage through DELEGATECALL, so direct getter calls on the library are ignored.\n",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0x70aEDda427f26480D240bc0f4308ceDec8d31348#code"
"url": "https://etherscan.io/address/0xD6E890c615d6f99681a00771C20ed04516288898#code"
},
{
"name": "ValidatorOperationsExtLib",
"isVerified": true,
"address": "eth:0xe4F0b9769Ca04a6E3d93b5BA732b5aD80797D411",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "Library immutably linked into the Rollup for validator entry, exits, slashing, and Slasher rotation. Its functions operate on the calling Rollup's storage through DELEGATECALL, so direct getter calls on the library are ignored.\n",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0xe4F0b9769Ca04a6E3d93b5BA732b5aD80797D411#code"
},
{
"name": "EscapeHatch",
"isVerified": true,
"address": "eth:0x8c189ead28D5987A48e522162f9225124D50AD1B",
"address": "eth:0xF459348962F5eA3A9A101826B03A2CE1F459E51A",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "Provides a fallback mechanism for block production if the primary sequencer committee fails or censors. The committee is circumvented by allowing proposals by anyone who is able to post a large bond of 332,000,000 AZTEC. It maintains a set of bonded candidates and deterministically selects a designated proposer for a given 'hatch' period using RANDAO. If the designated proposer fails to propose and prove, their bond is slashed by 9,600,000 AZTEC. The minimum tax deducted from their bond is 1,660,000 AZTEC, even if the proposal is successful. The escape hatch regularly opens every 112 epochs, given there are any bonded candidates.\n* Roles:\n * **getRollup**: Rollup",
"description": "Provides a fallback mechanism for block production if the primary sequencer committee fails or censors. Candidates post a bond of 332,000,000 AZTEC and enter the candidate set. For each hatch, the contract snapshots the eligible set and uses RANDAO to select one designated proposer; posting a bond does not grant immediate proposal rights. If the designated proposer fails to propose and prove, their bond is slashed by 9,600,000 AZTEC. The minimum tax deducted from their bond is 1,660,000 AZTEC, even if the proposal is successful. The escape hatch regularly opens every 112 epochs, given there are any eligible bonded candidates.\n* Roles:\n * **getRollup**: Rollup",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0x8c189ead28D5987A48e522162f9225124D50AD1B#code"
"url": "https://etherscan.io/address/0xF459348962F5eA3A9A101826B03A2CE1F459E51A#code"
},
{
"name": "CoinIssuer",
"isVerified": true,
"address": "eth:0x02FAdF157d551aa6d761b2A2237D03Af68E41CA6",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "Manages the inflation and minting schedule of the Aztec token. It enforces an annual percentage cap and mints new tokens for the budget.\n* Roles:\n * **owner**: ProtocolTreasury; ultimately Governance",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0x02FAdF157d551aa6d761b2A2237D03Af68E41CA6#code"
},
{
"name": "Registry",
"isVerified": true,
"address": "eth:0x35b22e09Ee0390539439E24f06Da43D83f90e298",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "Central directory that tracks the current 'canonical' (active) Rollup contract address and key system contracts like the Reward Distributor.\n* Roles:\n * **owner**: Governance",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0x35b22e09Ee0390539439E24f06Da43D83f90e298#code"
},
{
"name": "ProtocolTreasury",
"isVerified": true,
"address": "eth:0x662De311f94bdbB571D95B5909e9cC6A25a6802a",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "Holds the protocol's funds controlled by Governance. It acts as a timelocked executor for spending or relaying transactions approved by the DAO.\n* Roles:\n * **governance**: Governance the GATED_UNTIL timestamp has passed",
"description": "Holds the protocol's funds controlled by Governance. It acts as a timelocked executor for spending or relaying transactions approved by the DAO.\n* Roles:\n * **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",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0x662De311f94bdbB571D95B5909e9cC6A25a6802a#code"
},
{
"name": "AZTEC Token",
"name": "BaseStaker",
"isVerified": true,
"address": "eth:0xA27EC0006e59f245217Ff08CD52A7E8b169E62D2",
"address": "eth:0x79075C8E314Ab4A84d54F90b1c7032Dc5469082d",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "AZTEC token contract\n* Roles:\n * **owner**: CoinIssuer",
"description": "Implementation registered by the ATP Registry for upgradeable staker proxies that manage locked AZTEC positions.\n",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0xA27EC0006e59f245217Ff08CD52A7E8b169E62D2#code"
"url": "https://etherscan.io/address/0x79075C8E314Ab4A84d54F90b1c7032Dc5469082d#code"
},
{
"name": "GSE",
"name": "AZTEC Token",
"isVerified": true,
"address": "eth:0xa92ecFD0E70c9cd5E5cd76c50Af0F7Da93567a4f",
"address": "eth:0xA27EC0006e59f245217Ff08CD52A7E8b169E62D2",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "Central staking manager independent of Rollup implementations. Sequencers deposit stake here through their chosen Rollup contract. Their stake is then transfered to the Governance contract and activated for voting. The GSE tracks which rollup instance validators are securing, and gives them an option to automatically move to the latest Rollup version.\n* Roles:\n * **owner**: Governance",
"description": "AZTEC token contract\n* Roles:\n * **owner**: CoinIssuer",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0xa92ecFD0E70c9cd5E5cd76c50Af0F7Da93567a4f#code"
"url": "https://etherscan.io/address/0xA27EC0006e59f245217Ff08CD52A7E8b169E62D2#code"
},
{
"name": "FeeJuicePortal",
"name": "GSE",
"isVerified": true,
"address": "eth:0x2891F8b941067F8B5a3F34545A30Cf71E3E23617",
"address": "eth:0xa92ecFD0E70c9cd5E5cd76c50Af0F7Da93567a4f",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "One-way gas bridge: Escrows the fee asset (AZTEC) used to pay for L2 mana (gas). Users deposit tokens here, which are minted on L2 via the Inbox. The Rollup contract holds exclusive rights to withdraw tokens from this portal to distribute them as rewards to L1 sequencers and provers. Apart from that, this escrow does NOT afford a way to withdraw tokens.\n* Roles:\n * **rollup**: Rollup",
"description": "Central staking manager independent of Rollup implementations. Sequencers deposit stake here through their chosen Rollup contract. Their stake is then transferred to the Governance contract and activated for voting. The GSE tracks which rollup instance validators are securing, and gives them an option to automatically move to the latest Rollup version.\n* Roles:\n * **getLatestRollup**: Rollup\n * **owner**: Governance",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0x2891F8b941067F8B5a3F34545A30Cf71E3E23617#code"
"url": "https://etherscan.io/address/0xa92ecFD0E70c9cd5E5cd76c50Af0F7Da93567a4f#code"
},
{
"name": "Inbox",
"name": "AztecTokenPositionRegistry_ProtocolTreasury",
"isVerified": true,
"address": "eth:0x8Dbf0b6ed495baAb6062f5D5365aF3C1B2ed4578",
"address": "eth:0xD938bE4A2cB41105Bc2FbE707dca124A2e5d0c80",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "Facilitates canonical L1 to L2 communication. It accepts messages (including fee asset deposits) from L1, accumulates them in an append-only frontier tree per checkpoint, and forces the Sequencers and the Rollup contract to sequentially consume the roots of these message trees, ensuring message inclusion.\n* Roles:\n * **rollup**: Rollup",
"description": "AZTEC token-position Registry referenced by the ProtocolTreasury for its activation cutoff and by other ecosystem vesting contracts.\n* Roles:\n * **owner**: EOA 1",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0x8Dbf0b6ed495baAb6062f5D5365aF3C1B2ed4578#code"
"url": "https://etherscan.io/address/0xD938bE4A2cB41105Bc2FbE707dca124A2e5d0c80#code"
},
{
"name": "Outbox",
"isVerified": true,
"address": "eth:0xc9698B7AdEf9ee63F3Bf5cFF38086e4E836579f0",
"address": "eth:0x5B062aB5fD3A66BC7e73b04CeD38587673b6A2D7",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "Facilitates L2 to L1 communication. It stores the roots of L2 to L1 message trees per epoch, which are inserted by the Rollup contract. Users and portals can consume these messages on L1 by providing a Merkle proof against the stored root. A nullifier bitmap prevents double consumption.\n* Roles:\n * **rollup**: Rollup",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0xc9698B7AdEf9ee63F3Bf5cFF38086e4E836579f0#code"
"url": "https://etherscan.io/address/0x5B062aB5fD3A66BC7e73b04CeD38587673b6A2D7#code"
},
{
"name": "SlashPayloadCloneable",
"name": "Inbox",
"isVerified": true,
"address": "eth:0xAA43220b7eb7c8Ffe75bc9C483f3C07b0a55B445",
"address": "eth:0x7d4Ef0676c2032bbCC09227501D34d86641ab8cA",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "A template for specific slashing payload contracts deployed deterministically to encode a slashing action (who to slash and how much) that the Slasher executes.\n",
"description": "Facilitates canonical L1 to L2 communication. It accepts messages (including fee asset deposits) from L1, accumulates them in an append-only frontier tree per checkpoint, and forces the Sequencers and the Rollup contract to sequentially consume the roots of these message trees, ensuring message inclusion.\n* Roles:\n * **rollup**: Rollup",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0xAA43220b7eb7c8Ffe75bc9C483f3C07b0a55B445#code"
"url": "https://etherscan.io/address/0x7d4Ef0676c2032bbCC09227501D34d86641ab8cA#code"
},
{
"name": "AztecTokenPositionRegistry_ProtocolTreasury",
"name": "FeeJuicePortal",
"isVerified": true,
"address": "eth:0xD938bE4A2cB41105Bc2FbE707dca124A2e5d0c80",
"address": "eth:0xaf73Dd51D1eb8a079BB097f39c832cDD00ac691c",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "Used to set the time at which AZTEC tokens owned by the ProtocolTreasury are unlocked. Is also used as source of truth for other vesting contracts in the Aztec ecosystem.\n* Roles:\n * **owner**: EOA 1",
"description": "One-way gas bridge: Escrows the fee asset (AZTEC) used to pay for L2 mana (gas). Users deposit tokens here, which are minted on L2 via the Inbox. The Rollup contract holds exclusive rights to withdraw tokens from this portal to distribute them as rewards to L1 sequencers and provers. Apart from that, this escrow does NOT afford a way to withdraw tokens.\n* Roles:\n * **rollup**: Rollup",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0xD938bE4A2cB41105Bc2FbE707dca124A2e5d0c80#code"
"url": "https://etherscan.io/address/0xaf73Dd51D1eb8a079BB097f39c832cDD00ac691c#code"
}
]
},
"escrows": [
{
"address": "0x2891F8b941067F8B5a3F34545A30Cf71E3E23617",
"sinceTimestamp": 1772654159,
"address": "0xaf73Dd51D1eb8a079BB097f39c832cDD00ac691c",
"sinceTimestamp": 1782803327,
"tokens": [
"AZTEC"
],
"contract": {
"isVerified": true,
"address": "eth:0x2891F8b941067F8B5a3F34545A30Cf71E3E23617",
"address": "eth:0xaf73Dd51D1eb8a079BB097f39c832cDD00ac691c",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"url": "https://etherscan.io/address/0x2891F8b941067F8B5a3F34545A30Cf71E3E23617#code"
"url": "https://etherscan.io/address/0xaf73Dd51D1eb8a079BB097f39c832cDD00ac691c#code"
},
"chain": "ethereum",
"includeInTotal": true,
"chainId": 1
}
],
"risks": []
"risks": [],
"zkVerifiers": [
"eth:0x098f47c00F4df22a8030746Eb11378236C24b4bC"
]
}
{
"creator": "Aztec",
"projectsForTvs": [
{
"projectId": "aztecnetwork",
"sinceTimestamp": 1774821600
}
],
"proofSystemInfo": "## Description\n\nBarretenberg is a C++ library that implements several Plonk-based proof systems, developed by Aztec. It notably includes UltraHonk SNARK as an optimized version of previous Plonk implementation, and CHONK (Client-side Highly Optimized ploNK) SNARK for client-side proving on weaker devices. Barretenberg implements actual zero-knowledge SNARK modifications that allow proving over private data, and provides tools to generate UltraHonk smart contract verifiers. It also contains circuits to prove private and public transactions on Aztec L2.\n\n## Proof system\n\nThe main application of Barretenberg is proving Aztec L2 state transition, which includes users locally proving private transactions with true ZK CHONK and more powerful nodes proving public transactions using UltraHonk. CHONK proofs must be verified within UltraHonk, so Barretenberg also includes tools for recursive proving. Both proving systems operate on arithmetic circuits that could be compiled from [Noir](https://github.com/noir-lang/noir) programs into ACIR, which is a [native circuit representation for Barretenberg](https://barretenberg.aztec.network/docs/#relationship-with-noir). \n\n### UltraHonk\n\nUltraHonk is built on top of [Plonk](https://eprint.iacr.org/archive/2019/953/1624533038.pdf) proof system, with several optimizations for performance. It also serves as a basis for CHONK. The main optimization comes from using sumcheck protocol over the boolean hypercube as described in the [HyperPlonk paper](https://eprint.iacr.org/2022/1355). This trick allows reducing prover time and memory requirements at the expense of larger proofs. Barretenberg also contains code for circuits [verifying Honk proofs within UltraHonk verifier](https://github.com/AztecProtocol/aztec-packages/tree/next/barretenberg/cpp/src/barretenberg/stdlib/honk_verifier), allowing prover recursion. For more technical details on UltraHonk see [here](https://github.com/AztecProtocol/aztec-packages/tree/99c1647e91c83a3b1b3e040fce481fb4c7265522/barretenberg/cpp/src/barretenberg/ultra_honk#readme).\n\n### CHONK\n\nCHONK is the proof system that is most optimized for client side proving in memory-restricted environments like mobile and browsers. In addition, CHONK has zero-knowledge property to protect prover private inputs, which is achieved by adding random masking polynomials at several stages of the pipeline and some other measures. For the full description of ZK-related modifications see [here](https://github.com/AztecProtocol/aztec-packages/tree/99c1647e91c83a3b1b3e040fce481fb4c7265522/barretenberg/cpp/src/barretenberg/ultra_honk#zero-knowledge).\n\nOne of CHONK’s key innovations is Goblin architecture that efficiently manages elliptic curve operations over BN254 used e.g. in signatures. Elliptic curve operations are collected in a queue during the circuit proving, but the proof of their correctness is deferred to the very end of the proving process. The final step of the proving is done over a different curve called Grumpkin, which is chosen to make these EC operations native (i.e. extremely efficient). The correctness of translation between BN254 and Grumpkin is handled by the [Translator VM](https://github.com/AztecProtocol/aztec-packages/blob/7d03c441df4935ec5b08069446f3e8d59966532e/barretenberg/cpp/src/barretenberg/translator_vm/README.md) and the correctness of EC operations is proven by the [ECCVM](https://github.com/AztecProtocol/aztec-packages/blob/7d03c441df4935ec5b08069446f3e8d59966532e/barretenberg/cpp/src/barretenberg/eccvm/README.md).\n\nCHONK also introduces a folding scheme inspired by [HyperNova](https://eprint.iacr.org/2023/573) for more memory-efficient proving of recursive smart contract calls. In this case different smart contract are represented by different circuits, which are proven separately and then aggregated. The folding scheme allows efficient aggregation of these proofs that results in only one expensive polynomial commitment check in the end, instead of having to check it for each smart contract call.\n\nFor more technical details on CHONK see [here](https://github.com/AztecProtocol/aztec-packages/tree/7d03c441df4935ec5b08069446f3e8d59966532e/barretenberg/cpp/src/barretenberg/chonk#readme).\n\n### Noir and trusted setups\n\nAlthough not technically a part of Barretenberg proving repo, [Noir language](https://noir-lang.org) represents the most developer-friendly way to create circuits to be proven with UltraHonk or CHONK. It’s a domain-specific language inspired by Rust.\n\nAll Barretenberg proving systems extend Plonk, which is based on KZG commitment schemes. That requires a trusted setup, which is chosen to be Aztec Ignition trusted setup. Some internal proofs, like ECCVM proof, are based on IPA (inner product argument) and thus they require no trusted setup.",
"techStack": {
"zkVM": [
{
"id": "UltraHonk",
"type": "Plonk",
"name": "UltraHonk",
"description": "A KZG-based PLONKish proving system featuring many optimizations, including a sumcheck argument over a boolean hypercube. Developed by Aztec as a part of Barretenberg library."
},
{
"id": "CHONK",
"type": "Plonk",
"name": "CHONK",
"description": "PLONKish proving system, designed for client-side proving. Includes sumcheck argument over a hypercube, HyperNova-like folding schemes and GoblinPlonk EC operation optimization over Grumpkin curve. Developed by Aztec as a part of Barretenberg library."
},
{
"id": "BN254",
"type": "curve",
"name": "BN254",
"description": "BN254, aka BN256, aka alt_bn128 pairing-friendly 254-bit prime field Weierstrass elliptic curve."
},
{
"id": "Grumpkin",
"type": "curve",
"name": "Grumpkin",
"description": "Curve that forms a curve cycle together with BN254, which allows highly efficient recursive proof composition by switching between these two curves."
},
{
"id": "AVM",
"type": "ISA",
"name": "AVM",
"description": "VM that executes the public part of Aztec L2 transactions, conceptually similar to EVM."
}
]
},
"trustedSetups": [
{
"proofSystem": {
"id": "UltraHonk",
"type": "Plonk",
"name": "UltraHonk",
"description": "A KZG-based PLONKish proving system featuring many optimizations, including a sumcheck argument over a boolean hypercube. Developed by Aztec as a part of Barretenberg library."
},
"id": "AztecIgnition",
"name": "Aztec Ignition",
"participantCount": 176,
"risk": "green",
"shortDescription": "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.",
"longDescription": "Aztec Ignition is a trusted setup ceremony for KZG commitments over BN254 curve that was run by Aztec for KZG commitment over BN254 curve in 2019. \nIt included 176 participants and was publicly open for participation.\n\n- Github repo to download and verify the ceremony artifacts: [https://github.com/AztecProtocol/ignition-verification](https://github.com/AztecProtocol/ignition-verification).\n- Github repo with instructions for ceremony participants: [https://github.com/AztecProtocol/Setup](https://github.com/AztecProtocol/Setup).\n- Ceremony announcement with a call to participate: [https://aztec.network/blog/announcing-ignition](https://aztec.network/blog/announcing-ignition)."
}
],
"verifierHashes": [
{
"hash": "0x059ad02b037fcfd4df2b9db771777d067a400f06fc55cf45fa601511e58e2c3e",
"name": "Barretenberg Aztec verifier v4",
"sourceLink": "https://github.com/AztecProtocol/aztec-packages/tree/v4/noir-projects/noir-protocol-circuits",
"hash": "0x2f0ca3e610369fc41f7fb8a69995a96428fbf69d7dffd2b576e63ba4d9511ee1",
"name": "Barretenberg Aztec verifier v5",
"sourceLink": "https://github.com/AztecProtocol/aztec-packages/tree/v5.0.0/noir-projects/noir-protocol-circuits",
"proofSystem": {
"id": "UltraHonk",
"type": "Plonk",
"name": "UltraHonk",
"description": "A KZG-based PLONKish proving system featuring many optimizations, including a sumcheck argument over a boolean hypercube. Developed by Aztec as a part of Barretenberg library."
},
"knownDeployments": [
{
"address": "eth:0x70aEDda427f26480D240bc0f4308ceDec8d31348"
"address": "eth:0x098f47c00F4df22a8030746Eb11378236C24b4bC"
}
],
"verificationStatus": "successful",
"attesters": [
{
"id": "l2beat",
"name": "L2BEAT",
"link": "https://l2beat.com"
}
],
"verificationSteps": "The regeneration process consumed 32 GiB memory on the peak. It could be done on macOS or Linux machines, however in our experience Linux setup was smoother. \nThe steps below worked for clean Ubuntu 22.04.\n\n1. Install necessary dependencies.\n\n```\nsudo apt-get install jq build-essential parallel ninja-build\n\n# Install clang-format-20\nwget https://apt.llvm.org/llvm.sh \nchmod +x llvm.sh \nsudo ./llvm.sh 20 \nsudo apt-get install clang-format-20\n\n# Install latest cmake\ncurl -fsSL https://apt.kitware.com/kitware-archive.sh | sudo sh\nsudo apt-get install cmake\n\n# Install zig 0.13.0\nwget https://ziglang.org/download/0.13.0/zig-linux-x86_64-0.13.0.tar.xz \ntar xf zig-linux-x86_64-0.13.0.tar.xz \nsudo mv zig-linux-x86_64-0.13.0 /usr/local/zig \nsudo ln -s /usr/local/zig/zig /usr/local/bin/zig\n\n# Install yarn\ncurl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.0/install.sh | bash\nnvm install 20\nnpm install -g yarn\n\n# Install gcc 13\nsudo add-apt-repository ppa:ubuntu-toolchain-r/test\nsudo apt-get update\nsudo apt-get install g++-13\n\n# Install docker\ncurl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -\nsudo add-apt-repository \"deb [arch=amd64] https://download.docker.com/linux/ubuntu focal stable\"\nsudo apt install -y docker-ce\nsudo usermod -aG docker ${USER}\n\n# Install rust\ncurl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh\n. .cargo/env\n```\n\n2. Clone the repo and checkout the correct version\n```\ngit clone https://github.com/AztecProtocol/aztec-packages.git\ncd aztec-packages\ngit checkout v4 # commit hash 408ff4d64fad09b8a11b0f54b56295271a113325\ngit submodule update --init --recursive\n```\n\n3. Build preliminary components\n```\n# build avm-transpiler binary\ncd avm-transpiler\nNO_CACHE=1 ./bootstrap.sh build_native\n\n# build barretenberg binary\ncd ../barretenberg/cpp\nNO_CACHE=1 ./bootstrap.sh build_native\n\n# build nargo binary\ncd ../../noir\nNO_CACHE=1 ./bootstrap.sh\n```\n\n4. Remove the pinned build files and build the verifier smart contract:\n```\ncd ../noir-projects/noir-protocol-circuits\nrm pinned-build.tar.gz\ncorepack enable\nNO_CACHE=1 ./bootstrap.sh\n```\nThe build should produce correct onchain verifier in `target/keys/rollup_root_verifier.sol`."
"verificationSteps": "The verifier was regenerated on Linux. VK generation peaked at approximately 11.3 GiB of memory.\n\nPrepare:\n\n1. Install the toolchain expected by the repository: Node.js 24.12.0 or newer, Yarn 4.13.0, Rust 1.89.0, CMake 3.24 or newer, Clang 20, Zig 0.15.1, Ninja, `jq`, `xxd`, `base64`, and `gzip`.\n2. Ensure at least 16 GiB of combined memory and swap is available.\n\nVerify:\n\n1. Clone [AztecProtocol/aztec-packages](https://github.com/AztecProtocol/aztec-packages), then check out tag `v5.0.0`. It should resolve to commit `7aa2bd616d632801fe65d97ee8a4434f26886b40`.\n2. Initialize the Noir source pinned by the tag: `git submodule update --init --depth 1 noir/noir-repo`. It should resolve to commit `c57152f91260ecdb9faad4efc20abb14b6d2ece7`.\n3. Build Nargo from the pinned source:\n ```bash\n cd noir/noir-repo\n cargo +1.89.0 build --locked --release --target-dir target --bin nargo\n cd ../..\n ```\n4. Build the Barretenberg CLI from source without AVM components:\n ```bash\n cd barretenberg/cpp\n cmake --fresh --preset clang20-no-avm -DAVM_TRANSPILER_LIB=\n cmake --build --preset clang20-no-avm --target bb --parallel 4\n cd ../..\n ```\n5. Generate the ignored Noir workspace files. Do not run the protocol-circuits bootstrap because it consumes the tracked `pinned-build.tar.gz` instead of compiling the circuit source.\n ```bash\n cd noir-projects/noir-protocol-circuits\n corepack [email protected] install\n corepack [email protected] generate_variants\n ```\n6. Compile `rollup_root` from source:\n ```bash\n ../../noir/noir-repo/target/release/nargo check \\\n --package rollup_root --silence-warnings --show-program-hash\n ../../noir/noir-repo/target/release/nargo compile \\\n --package rollup_root --skip-brillig-constraints-check\n ```\n The monomorphized Noir program hash printed by the first command should be `62fd003ca75d0cd7`.\n7. Generate the UltraHonk verification key from the newly compiled bytecode:\n ```bash\n mkdir -p /tmp/aztec-v5-repro\n jq -r '.bytecode' target/rollup_root.json \\\n | base64 -d \\\n | gunzip \\\n | ../../barretenberg/cpp/build/bin/bb write_vk \\\n --scheme ultra_honk --oracle_hash keccak \\\n -b - -o /tmp/aztec-v5-repro\n xxd -p -c 0 /tmp/aztec-v5-repro/vk_hash\n ```\n The final command should print `2f0ca3e610369fc41f7fb8a69995a96428fbf69d7dffd2b576e63ba4d9511ee1`.\n8. Regenerate the Solidity verifier:\n ```bash\n ../../barretenberg/cpp/build/bin/bb write_solidity_verifier \\\n --scheme ultra_honk --disable_zk \\\n -k /tmp/aztec-v5-repro/vk \\\n -o /tmp/aztec-v5-repro/HonkVerifier.sol \\\n --optimized\n diff -u \\\n /tmp/aztec-v5-repro/HonkVerifier.sol \\\n ../../l1-contracts/script/deploy/HonkVerifier.sol\n ```\n The generated verifier should be identical to the repository copy except for the latter's provenance comment after the Solidity pragma."
}
]
}
gnosis+3-3
scalingTechnology+3-3
{
"dataAvailability": [
{
"name": "Transaction data is stored on Gnosis Chain",
"description": "Gnosis Chain transaction data is published to Gnosis Chain and propagated by its validator and node network. The Ethereum bridge contracts do not verify data availability and only process bridge messages after bridge-validator signatures are submitted.",
"references": [
{
"title": "Gnosis specifications",
"url": "https://docs.gnosischain.com/about/specs/"
}
],
"risks": [
{
"category": "Funds can be frozen if",
"text": "transaction data is unavailable and bridge validators cannot reconstruct or sign the messages needed to exit."
}
]
}
],
"detailedDescription": "Gnosis chain in its current form does not derive or benefit from Ethereum's decentralisation apart from being developed as a close fork to re-use Ethereum tooling and infrastructure. Its censorship resistance relies on an open validator set with over 100 thousand diverse validators, although the clustering and stake distribution among entities is intransparent. Users who are censored selectively on an otherwise live network benefit from the fast 5s block time and non-committee-gated, stake-weighted proposer rotation, resulting in an inclusion probability of 99% in less than a minute even if up to 50% of the Gnosis stake is censoring them. There are also a few thousand validators who run custom 'shutter network' nodes that support threshold-encrypted transactions. For a case of active blanket censorship (>50% stake) by all current validators, users have no way apart from a hardfork to get their transactions included or save the chain. In the operator walkaway scenario, new sequencers could stake and join the set permissionlessly.",
"otherConsiderations": [
{
"name": "Encrypted mempool (Shutter Network Beta)",
"description": "A subset of Gnosis Chain validators is currently running a modified node version that supports threshold-encrypted transaction payloads. This allows to 'encrypt the mempool' and protect against malicious MEV and censorship with significant caveats. To encrypt the transaction, users have to either use custom wallets or a trusted encrypting rpc proxy. Decryption is handled by participating validators sharing their decryption key shares at the target block, allowing the proposer to decrypt the transaction and include and execute (or censor) it.",
"references": [
{
"title": "Shutterized Gnosis Chain Beta Release",
"url": "https://blog.shutter.network/shutterized-gnosis-chain-is-now-live/"
},
{
"title": "Gnosis Docs: Shutterized Gnosis Chain",
"url": "https://docs.gnosischain.com/shutterized-gc/"
}
],
"risks": []
},
{
"name": "Destination tokens can be upgradeable",
"description": "Omnibridge uses token factories to deploy wrapped ERC20 representations for assets native to the other chain. The token factory owner can change the implementation used for newly deployed wrapped tokens.",
"references": [
{
"title": "Omnibridge documentation",
"url": "https://docs.gnosischain.com/bridges/About%20Token%20Bridges/omnibridge"
}
],
"risks": [
{
"category": "Funds can be stolen if",
"text": "a malicious or vulnerable wrapped token implementation is configured for newly bridged assets."
}
]
}
],
"sequencing": {
"name": "Transactions are ordered by Gnosis Chain validators",
"description": "Gnosis Chain uses a permissionless proof-of-stake validator set with stake-weighted proposer rotation and a 5 second slot time. The Ethereum-like committee-free block production architecture combined with the short block time lead to fast theoretical inclusion times, even with high rates of censorship. In contrast to Ethereum, blocks on Gnosis chain are usually built *locally*, meaning that validators do not delegate block production to specialised builders. There is no public information on the decentralisation of the Gnosis validator set.",
"sequencerSetSpec": {
"slotTime": {
"blockTime": {
"value": "5s"
},
"epochTime": {
"value": "1m 20s",
"proposerRotationTime": {
"value": "5s",
"description": "Block production is not committee-based, sequencers rotate every block (epochs do not affect sequencer rotation)"
},
"sequencerCount": {
"value": "100,000 validators"
},
"blockProductionAccess": {
"value": "Open",
"sentiment": "good"
},
"stakePerValidator": {
"value": "1 GNO minimum, variable",
"description": "stake-weighted block production rights, no maximum"
},
"rateLimit": {
"value": "~1-2 GNO per epoch",
"description": "defined by the consensus clients"
},
"deterministicCrGadget": {
"value": "No",
"sentiment": "warning"
},
"additionalCrGadgets": {
"value": "Shutter encrypted mempool beta",
"sentiment": "warning"
}
},
"inclusionDelayChart": {
"type": "ethereumlike",
"validatorCount": 100000,
"slotSeconds": 5,
"target": 0.99,
"maxCensorFraction": 0.5
},
"inclusionDelayChartDescription": "The chart uses the Ethereum-style single-proposer formula with Gnosis-specific constants. It excludes finality, inactivity leaks, validator-set changes, hard forks, and blanket-censorship resistance gadgets.",
"censorshipResistance": "Gnosis Chain does not have dedicated censorship resistance gadgets, but the sequencer set is open and there are no committees that can block inclusion.\n### Selective censorship\nEven with high percentages of stake censoring, users have very fast inclusion times. There are also initial tests of an out-of-protocol solution for encrypting transactions in the mempool (Shutterized Gnosis Chain).\n### Blanket censorship\nThere is no way to circumvent the validator set from Ethereum in a case of active censorship by all (or a majority of) validators.\n### Walkaway\nSince the validator set is open, new validators can join it in case validators passively stop block production. If all validators stop at the same time, a social recovery and hard fork would be necessary.",
"references": [
{
"title": "Gnosis Chain specifications",
"url": "https://docs.gnosischain.com/about/specs/"
}
],
"risks": [
{
"category": "Users can be censored if",
"text": "at least half of the active stake censors them, or if current validators coordinate blanket censorship and the chain requires social recovery."
}
]
},
"stateValidation": {
"categories": [
{
"title": "No state validation",
"description": "Gnosis Chain is an independent proof-of-stake chain. Ethereum contracts do not check whether Gnosis state transitions are valid. Cross-chain messages are executed when the relevant bridge contract receives enough validator signatures: 4/7 for the xDAI bridge and 4/7 for AMB and Omnibridge.",
"references": [
{
"title": "xDAI Bridge documentation",
"url": "https://docs.gnosischain.com/bridges/About%20Token%20Bridges/xdai-bridge"
},
{
"title": "Omnibridge documentation",
"url": "https://docs.gnosischain.com/bridges/About%20Token%20Bridges/omnibridge"
}
],
"risks": [
{
"category": "Funds can be stolen if",
"text": "bridge validators sign fraudulent messages that release more assets on Ethereum than were burned or locked on Gnosis."
},
{
"category": "Funds can be stolen if",
"text": "the Gnosis validator set finalizes an invalid chain state and the bridge validators sign messages derived from it."
},
{
"category": "Funds can be frozen if",
"text": "bridge validators stop signing messages or Gnosis Chain stops finalizing blocks."
}
]
}
]
}
}
polygon-pos+17-17
scalingTechnology+17-17
{
"otherConsiderations": [
{
"name": "Destination tokens are upgradeable",
"description": "Tokens transferred end up as wrapped ERC20 proxies, some of them are upgradable. The contract is named UChildERC20Proxy.",
"references": [],
"risks": [
{
"category": "Funds can be stolen if",
"text": "destination token contract is maliciously upgraded."
}
],
"isIncomplete": true
}
],
"sequencing": {
"name": "Transactions are ordered by Polygon PoS validators",
"description": "Polygon PoS is operated by a closed proof-of-stake validator set with 101 active validators. Block production rights are given to validators randomly (stake-weighted) for the duration of a *span*. In practice, validators delegate the block production further to centralised validator-elected block producers (VeBloPs). Ethereum smart contracts accept checkpoints signed by more than two thirds of Polygon PoS validator stake.",
"sequencerSetSpec": {
"slotTime": {
"blockTime": {
"value": "2s"
},
"epochTime": {
"proposerRotationTime": {
"value": "3h 33m",
"description": "Randomly sampled validators delegate block production for the duration of a span: 6400 blocks"
},
"sequencerCount": {
"value": "101 validators"
},
"blockProductionAccess": {
"value": "Closed and capped",
"sentiment": "bad",
"description": "The current validator cap is 105. Joining the set is permissioned (Multisig)."
},
"stakePerValidator": {
"value": "100,000 POL minimum, variable",
"description": "stake-weighted block production rights, no maximum"
},
"rateLimit": {
"value": "No (permissioned)"
},
"deterministicCrGadget": {
"value": "No",
"sentiment": "warning"
},
"additionalCrGadgets": {
"value": "No",
"sentiment": "bad"
}
},
"inclusionDelayChart": {
"type": "spanlike",
"validatorCount": 101,
"spanBlocks": 6400,
"blockSeconds": 2,
"target": 0.99,
"maxCensorFraction": 0.33,
"stakeDistribution": {
"stakeToken": "POL",
"totalStake": 3584180072,
"totalStake": 3578982515,
"entities": [
{
"name": "Upbit Staking",
"stake": 413573181
"stake": 417333126
},
{
"name": "Coinbase",
"stake": 363170203
"stake": 366375736
},
{
"name": "Luganodes",
"stake": 283172194
"stake": 258378187
},
{
"name": "Anonymous 194",
"stake": 244531424
},
{
"name": "Binance Node",
"stake": 258927770
"stake": 236806959
},
{
"name": "Figment",
"stake": 225661576
"stake": 226257073
},
{
"name": "Anonymous 194",
"stake": 208026879
},
{
"name": "Matic Power",
"stake": 207786172
"stake": 207786330
},
{
"name": "Blockdaemon",
"stake": 181572004
"stake": 181375563
},
{
"name": "Kraken",
"stake": 154483521
"stake": 158562769
},
{
"name": "Kiln x Ownest 🔸 Pro Staking 🔸",
"stake": 133742516
"name": "Anonymous 95",
"stake": 146004660
}
]
}
},
"inclusionDelayChartDescription": "The chart models live-chain selective censorship only. Since proposing is stake-weighted, the x-axis represents the censoring POL stake, and does not cover validator-set changes, or blanket-censorship resistance gadgets.",
"censorshipResistance": "The validator set (on Polygon PoS, validators are both proposers and sequencers) is closed and capped, but includes a diverse set of known entities who share block production rights. There are no specific censorship resistance gadgets built into the protocol.\n### Selective censorship\nAs long as the Polygon PoS blockchain is producing blocks, users can expect to include their transactions due to the rotating, diverse block producers, even if they are censored by some of them. Unfortunately, the rotation is very slow (see *span* time) and even just a few entities censoring can cause long inclusion delays.\n### Blanket censorship\nValidators holding more than 1/3 of Polygon PoS stake among them can censor users if they actively refuse to attest to blocks with their transactions. Polygon Multisig controls the core smart contracts on Ethereum and can administer the validator set (including malicious changes) as a consequence.\n### Walkaway\nIf validators holding more than 1/3 of the stake on Polygon PoS stop block production, the chain stops and there is no way for users to include any transactions. As the validator set is currently closed by a permissioned smart contract setting on ethereum, walkaway of the permissioned actor would require social coordination and a hard fork to progress the chain.",
"references": [
{
"title": "Polygon PoS architecture documentation",
"url": "https://docs.polygon.technology/pos/architecture/"
}
],
"risks": [
{
"category": "Users can be censored if",
"text": "the active span proposer censors them, or if at least one third of Polygon PoS stake refuses to attest blocks that include their transactions."
}
]
},
"stateValidation": {
"categories": [
{
"title": "No state validation",
"description": "State updates are settled on Ethereum if signed by at least 2/3+1 of the Polygon PoS validators stake. Contracts on Ethereum do not check whether the state transitions are valid.",
"references": [],
"risks": [
{
"category": "Users can be censored if",
"text": "validators on Polygon decide to not mint tokens after observing an event on Ethereum."
},
{
"category": "Funds can be stolen if",
"text": "validators decide to mint more tokens than there are locked on Ethereum thus preventing some existing holders from being able to bring their funds back to Ethereum."
},
{
"category": "Funds can be stolen if",
"text": "validators submit a fraudulent checkpoint allowing themselves to withdraw all locked funds."
}
]
}
]
}
}