{
"dataAvailability": [
{
"name": "All transaction results (state diffs) are published in Ethereum blobs",
"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/0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34#code"
},
{
"title": "Rollup.sol - validateBlobs() on Etherscan",
"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/0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34#code"
},
{
"title": "Outbox.sol - consume() on Etherscan",
"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/0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34#code"
},
{
"title": "Rollup.sol - flushEntryQueue() on Etherscan",
"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:0xaf73Dd51D1eb8a079BB097f39c832cDD00ac691c#code"
},
{
"title": "Outbox.sol - on Etherscan",
"url": "https://etherscan.io/address/0x5B062aB5fD3A66BC7e73b04CeD38587673b6A2D7#code"
}
],
"risks": []
},
{
"name": "Inclusion is probabilistic",
"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 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.",
"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 3451 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": {
"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"
},
"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": "3462 sequencers"
"value": "3451 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 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": 3462,
"validatorCount": 3451,
"committeeSize": 48,
"epochSlots": 32,
"slotSeconds": 72,
"blockingThreshold": 15,
"target": 0.99,
"maxCensorFraction": 0.5,
"stakeDistribution": {
"stakeToken": "AZTEC",
"totalStake": 610642000,
"entities": [
{
"name": "Nethermind",
"stake": 113600000
},
{
"name": "Nansen | Stake to Stack Points",
"stake": 75800000
},
{
"name": "Sigma Prime",
"stake": 66800000
},
{
"name": "P2P.org",
"stake": 41600000
},
{
"name": "snoopfear|PON",
"stake": 37200000
},
{
"name": "ZKV",
"stake": 30816000
},
{
"name": "GabbexNodes",
"stake": 27400000
},
{
"name": "Wonderland",
"stake": 26600000
},
{
"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 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/0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34#code"
},
{
"title": "EscapeHatch.sol - selectCandidates() on Etherscan",
"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). 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/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/0x91fF8bbD8Ebb07893010D50A48A1609e5EBd8E34#code"
},
{
"title": "HonkVerifier.sol - verify() on Etherscan",
"url": "https://etherscan.io/address/0x098f47c00F4df22a8030746Eb11378236C24b4bC#code"
}
]
},
{
"title": "Slashing",
"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": "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 (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."
}
}