{
"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.",
"references": [
{
"title": "Rollup.sol - propose() on Etherscan",
"url": "https://etherscan.io/address/0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962#code"
},
{
"title": "Rollup.sol - validateBlobs() on Etherscan",
"url": "https://etherscan.io/address/0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962#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"
},
{
"title": "Outbox.sol - consume() on Etherscan",
"url": "https://etherscan.io/address/0xc9698B7AdEf9ee63F3Bf5cFF38086e4E836579f0#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"
},
{
"title": "Rollup.sol - flushEntryQueue() on Etherscan",
"url": "https://etherscan.io/address/0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962#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. Governance also owns critical config parameters that can freeze or compromise the Rollup system.",
"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"
},
{
"title": "Outbox.sol - on Etherscan",
"url": "https://etherscan.io/address/0xc9698B7AdEf9ee63F3Bf5cFF38086e4E836579f0#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.",
"references": [
{
"title": "CRsim - Simulated inclusion probability on Aztec",
"url": "https://sekuba.github.io/crsim"
}
],
"risks": []
}
],
"sequencing": {
"name": "Transactions are ordered by a staked 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 3709 and selects one proposer per slot. 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.",
"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 3740 and selects one proposer per slot. 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.",
"references": [
{
"title": "Rollup.sol - getProposerAt() on Etherscan",
"url": "https://etherscan.io/address/0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962#code"
},
{
"title": "EscapeHatch.sol - selectCandidates() on Etherscan",
"url": "https://etherscan.io/address/0x8c189ead28D5987A48e522162f9225124D50AD1B#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.",
"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"
}
],
"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"
},
{
"title": "HonkVerifier.sol - verify() on Etherscan",
"url": "https://etherscan.io/address/0x70aEDda427f26480D240bc0f4308ceDec8d31348#code"
}
]
},
{
"title": "Slashing",
"description": "\nEach 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.",
"references": [
{
"title": "Slashing - Aztec Docs",
"url": "https://docs.aztec.network/operate/operators/sequencer-management/slashing_and_offenses"
},
{
"title": "SlashVeto Council - Github",
"url": "https://github.com/aztec-slash-veto/council"
},
{
"title": "slashveto.me - Monitor Slashing",
"url": "https://slashveto.me"
}
],
"risks": []
}
]
},
"upgradesAndGovernance": "\n# 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 1mo 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 (1mo):** 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: **1mo 10d**.\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 1mo 10d 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. However, `Governance` owns critical permissions for configuration parameters that can freeze the L2 indefinitely. 'Upgrading' a Rollup contract 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` retains ownership of the old rollup, with the permissions to freeze it in the same or any future governance proposal. In summary and practice, the current Aztec rollup system is not immutable and prone to governance changes with the configured 1mo delay.\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%.\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."
}
permissions+3-3
{
"ethereum": {
"roles": [],
"actors": [
{
"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 and forward the acceptOwnership() call to the AZTEC Token [via: ProtocolTreasury the GATED_UNTIL timestamp has passed]\n* Can interact with Slasher\n * slash sequencers from the active set \n* Can interact with GSE\n * add a new rollup address, which automatically triggers all sequencers staked in the bonus address to be migrated to the new rollup \n* Can interact with Rollup\n * change the escape hatch address and disable the escape hatch, change the slasher address which can slash arbitrary sequencers, change the sequencer queue config and disallow new sequencers joining, set the ejection threshold that exits sequencers from the active set, change various critical fee and reward configurations ",
"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 ",
"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": "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 ",
"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:0xb31e6d9661720A93d54AF7D1815d9bb399280629",
"address": "eth:0x8138c46A572D989E54837d5e5dEB506889edFb5D",
"type": "EOA",
"isVerified": true,
"name": "0xb31e…0629",
"url": "https://etherscan.io/address/0xb31e6d9661720A93d54AF7D1815d9bb399280629"
"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": "EOA-1",
"name": "EOA 1",
"accounts": [
{
"address": "eth:0x92Ba0FD39658105FaC4dF2B9BADE998B5816b350",
"type": "EOA",
"isVerified": true,
"name": "0x92Ba…b350",
"url": "https://etherscan.io/address/0x92Ba0FD39658105FaC4dF2B9BADE998B5816b350"
}
],
"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 ",
"discoveryDrivenData": true
}
]
}
}
{
"creator": "Succinct",
"projectsForTvs": [
{
"projectId": "celo",
"sinceTimestamp": 1771445567
},
{
"projectId": "vector",
"sinceTimestamp": 1771445567
},
{
"projectId": "sophon",
"sinceTimestamp": 1771445567
},
{
"projectId": "lens",
"sinceTimestamp": 1771445567
},
{
"projectId": "galxegravity",
"sinceTimestamp": 1771445567,
"untilTimestamp": 1763420400
},
{
"projectId": "rari",
"sinceTimestamp": 1771445567
},
{
"projectId": "blobstream",
"sinceTimestamp": 1771445567
},
{
"projectId": "molten",
"sinceTimestamp": 1771445567
},
{
"projectId": "winr",
"sinceTimestamp": 1771445567
},
{
"projectId": "phala",
"sinceTimestamp": 1771445567
},
{
"projectId": "kroma",
"sinceTimestamp": 1771445567
},
{
"projectId": "taiko",
"sinceTimestamp": 1774964687
}
],
"proofSystemInfo": "\n## Description\n\nSP1 Hypercube is the latest Succint's RISC-V zkVM using the [Plonky3](https://github.com/Plonky3/Plonky3) stack. The zkVM execution is proven recursively and is wrapped into a SNARK for final verification. It provides tools to generate onchain Groth16 or Plonk verifiers. SP1 Hypercube provides 98 bits of proven security, as per [Ethereum Foundation’s soundcalc evaluation](https://github.com/ethereum/soundcalc/blob/main/reports/sp1.md).\n\n## Proof system\n\nSP1 Hypercube is an iteration of the previous zkVM version, SP1 Turbo, introducing architectural changes that improve prover performance and memory efficiency.\n\nHypercube proves execution of a 64-bit RISC-V VM using several ZK circuits, or chips, connected by lookup arguments ([LogUp based on GKR protocol](https://docs.succinct.xyz/docs/sp1/hypercube/logupgkr)). VM execution trace is split into several shards of size approximately 2^22, that could be proven in parallel with a STARK proving system. Additional arguments prove memory consistency across shards. \n\nThe parallelized proofs are recursively checked by the next layer of STARK circuits. The correctness of the final STARK proof is verified with the final wrap SNARK program, the wrap SNARK proof is verified onchain.\n\n### Hypercube vs. Turbo\n\nProving time and memory optimizations of SP1 Hypercube are based on several design improvements compared to SP1 Turbo.\n\nHypercube implements a [multilinear polynomial](https://github.com/succinctlabs/sp1/tree/v6.0.0/slop/crates/multilinear) STARK compared to univariate polynomials in Turbo. Multilinear polynomial based proving systems are more efficient than univariate because manipulating them reduces usage of log-linear FFT algorithm.\n\nMultilinear polynomials also allow Hypercube to innovate on a polynomial commitment scheme, implementing [Jagged PCS](https://docs.succinct.xyz/docs/sp1/hypercube/jagged) (defined in [this preprint](https://eprint.iacr.org/2025/917)). Jagged PCS allows efficient packing of computation traces of zkVM chips with different lengths, optimizing the prover memory requirement. More efficient LogUp based on GKR is also made possible because of multilinear polynomials.\n\n### Recursion circuits\n\nSP1 Hypercube provides tools for recursive proof generation by [verifying proofs in a zkVM](https://docs.succinct.xyz/docs/sp1/writing-programs/proof-aggregation#verifying-proofs-inside-the-zkvm). This uses the same toolkit as top-level proof system, but proves the correct verification of all proofs generated on the previous step.\n\nFirst, proofs for correctness of separate shards are generated. These shards may have different trace shape, so in the next step they are normalized. Finally, normalized shard proofs are recursively compressed in batches of 3-4 to a single zkVM proof. For further details see [this page](https://docs.succinct.xyz/docs/sp1/hypercube/recursion).\n\n### Final wrap\n\nSP1 Hypercube supports Plonk (with KZG polynomial commitments) or Groth16 final SNARK wrap of the STARK proof for performant onchain proof verification ([link](https://docs.succinct.xyz/docs/sp1/generating-proofs/proof-types#compressed)). The implementation of these proof systems over BN254 curve is used. For Plonk, Aztec Ignition trusted setup ceremony is used, for Groth16 Succinct run internal circuit-dependent phase 2 trusted setup (todo: link to trusted setups section).\n \n ",
"techStack": {
"zkVM": [
{
"id": "Plonky3",
"type": "STARK",
"name": "Plonky3",
"description": "Toolkit that implements a set of primitives for STARK-based zkVMs developed by Polygon Zero team."
},
{
"id": "RISCV64",
"type": "ISA",
"name": "RISC-V 64bit",
"description": "Free and open-source universal 64-bit ISA used across a variety of hardware and software."
},
{
"id": "BabyBear",
"type": "Field",
"name": "Baby Bear",
"description": "Prime field of order p = 15 * 2**27 + 1."
},
{
"id": "KoalaBear",
"type": "Field",
"name": "Koala Bear",
"description": "Prime field of order p = 2**31 - 2**24 + 1."
}
],
"finalWrap": [
{
"id": "Gnark",
"type": "Plonk",
"name": "Gnark",
"description": "Consensys implementation of Plonk proving system written in Go."
},
{
"id": "Gnark",
"type": "Groth16",
"name": "Gnark",
"description": "Consensys implementation of Groth16 proving system written in Go."
},
{
"id": "BN254",
"type": "curve",
"name": "BN254",
"description": "BN254, aka BN256, aka alt_bn128 pairing-friendly 254-bit prime field Weierstrass elliptic curve."
}
]
},
"trustedSetups": [
{
"proofSystem": {
"id": "Gnark",
"type": "Plonk",
"name": "Gnark",
"description": "Consensys implementation of Plonk proving system written in Go."
},
"id": "AztecIgnition",
"name": "Aztec Ignition",
"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": " \n 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. \n It 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).\n "
},
{
"proofSystem": {
"id": "Gnark",
"type": "Groth16",
"name": "Gnark",
"description": "Consensys implementation of Groth16 proving system written in Go."
},
"id": "SP1HypercubeGroth16",
"name": "SP1 Hypercube Groth16 circuit-specific setup",
"risk": "red",
"shortDescription": "Trusted setup ceremony for SP1 Hypercube (release v6.0.0) Groth16 final wrap circuits. Ceremony was organized by Succinct and includes 12 participants from 7 different organizations, without public calls to participate.",
"longDescription": "\nCeremony was run among 12 participants affiliated with Across Protocol, OP Labs, Offchain Labs, Succinct Labs, Conduit, Ethrealize and 1 independent participant. It generated circuit-specific setup parameters for Groth16 wrapper of SP1 Hypercube zkVM.\n\n- Ceremony info on Succinct docs page: .\n- Ceremony instructions and verification instructions: [https://github.com/succinctlabs/semaphore-gnark-11/tree/main](https://github.com/succinctlabs/semaphore-gnark-11/tree/main).\n- Link to transcript and other artifacts (Note: will immediately start downloading .tar.gz file): .\n "
}
],
"verifierHashes": [
{
"hash": "0xbb1a6f2930e94bfe8b35e794faf43133214534a17d2ad8e51358cad437b3c317",
"name": "SP1 Hypercube Plonk v6.0.0",
"sourceLink": "https://github.com/succinctlabs/sp1/tree/v6.0.0/crates/prover",
"proofSystem": {
"id": "Gnark",
"type": "Plonk",
"name": "Gnark",
"description": "Consensys implementation of Plonk proving system written in Go."
},
"knownDeployments": [
{
"address": "eth:0x8a0fd5e825D14368d90Fe68F31fceAe3E17AFc5C"
},
{
"address": "arb1:0x8a0fd5e825D14368d90Fe68F31fceAe3E17AFc5C"
}
],
"verificationStatus": "successful",
"attesters": [
{
"id": "l2beat",
"name": "L2BEAT",
"link": "https://l2beat.com"
}
],
"verificationSteps": "\n The regeneration process consumed around 70 GiB of memory on the peak.\n \n 1. Install necessary dependencies: rust, docker, sp1 toolkit, go.\n \n ```\n sudo apt update\n sudo apt install build-essential golang-go protobuf-compiler\n \n curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh\n . .cargo/env\n cargo install --debug --locked cargo-make\n \n curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -\n sudo add-apt-repository \"deb [arch=amd64] https://download.docker.com/linux/ubuntu focal stable\"\n sudo apt install -y docker-ce\n sudo usermod -aG docker ${USER}\n \n curl -L https://sp1up.succinct.xyz/ | bash\n source ~/.bashrc\n sp1up\n ```\n \n 2. Clone [sp1 repo](https://github.com/succinctlabs/sp1), set `SP1_ALLOW_DEPRECATED_HOOKS` for correct compilation and run the script to regenerate verifiers.\n \n ```\n git clone https://github.com/succinctlabs/sp1.git\n cd sp1/crates/prover\n git checkout v6.0.0 # commit should be f87f8d6ff005d542db22e241928319f5e96a4609\n export SP1_ALLOW_DEPRECATED_HOOKS=true # fixes compilation errors\n \n make build-circuits\n ```\n \n The script will generate Plonk verifier smart contract with verification keys and the verifier hash in `build/plonk` dir.\n "
},
{
"hash": "0x0e78f4db7a6771a3a6a7d9c3b0de6fe73d58781368967a7fe84d87aefffec896",
"name": "SP1 Hypercube Groth16 v6.0.0",
"sourceLink": "https://github.com/succinctlabs/sp1/tree/v6.0.0/crates/prover",
"proofSystem": {
"id": "Gnark",
"type": "Groth16",
"name": "Gnark",
"description": "Consensys implementation of Groth16 proving system written in Go."
},
"knownDeployments": [
{
"address": "eth:0x99A74A05a0FaBEB217C1A329b0dac59a1FA52508"
}
],
"verificationStatus": "successful",
"attesters": [
{
"id": "l2beat",
"name": "L2BEAT",
"link": "https://l2beat.com"
}
],
"verificationSteps": "\n The regeneration process consumed around 70 GiB of memory on the peak.\n \n 1. Install necessary dependencies: rust, docker, sp1 toolkit, go.\n \n ```\n sudo apt update\n sudo apt install build-essential golang-go protobuf-compiler\n \n curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh\n . .cargo/env\n cargo install --debug --locked cargo-make\n \n curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -\n sudo add-apt-repository \"deb [arch=amd64] https://download.docker.com/linux/ubuntu focal stable\"\n sudo apt install -y docker-ce\n sudo usermod -aG docker ${USER}\n \n curl -L https://sp1up.succinct.xyz/ | bash\n source ~/.bashrc\n sp1up\n ```\n \n 2. Clone [sp1 repo](https://github.com/succinctlabs/sp1), set `SP1_ALLOW_DEPRECATED_HOOKS` for correct compilation and run the script to build groth16 circuit file.\n \n ```\n git clone https://github.com/succinctlabs/sp1.git\n cd sp1/crates/prover\n git checkout v6.0.0 # commit should be f87f8d6ff005d542db22e241928319f5e96a4609\n export SP1_ALLOW_DEPRECATED_HOOKS=true # fixes compilation errors\n \n make build-circuits\n ```\n \n This script will generate `groth16_circuit.bin` file in the `prover/build/groth16` directory, however it will not generate correct prover and verifier keys.\n \n 3. Generate correct pk and vk using the correct SP1 trusted setup. This will require [semaphore-gnark-11](https://github.com/succinctlabs/semaphore-gnark-11/tree/main) repo.\n \n ```\n cd\n git clone https://github.com/succinctlabs/semaphore-gnark-11.git # tested on commit hash 6d6ebc3608e609ec879e9ba99abee6b6b97d937d\n cd semaphore-gnark-11\n # Download the trusted setup transcript\n curl \"https://sp1-circuits.s3-us-east-2.amazonaws.com/v6.0.0-trusted-setup.tar.gz\" -o trusted-setup.tar.gz\n \n # Extract trusted setup transcript.\n tar -xzf trusted-setup.tar.gz\n \n # Build the binary.\n go build\n \n # Generate keys. They are outputted to the files pk and vk in the root directory.\n ./semaphore-gnark-11 key trusted-setup/phase1 trusted-setup/phase2-11 trusted-setup/evals /path/to/sp1/crates/prover/build/groth16/groth16_circuit.bin\n ```\n The last step will take several hours to complete.\n \n 4. Compute the hash of generated `vk` file: `shasum vk -a 256`.\n "
}
]
}
taiko+517-1047
scalingRisks+9-8
{
"self": {
"stateValidation": {
"description": "A multi-proof system is used. There are four verifiers available: SGX (Geth), SGX (Reth), SP1 and RISC0. Two of them must be used to prove a batch, and SGX (Geth) is mandatory. The state root is supplied during the permissionless proveBatches call and is checked against the accompanying SGX/zkVM proof. A batch can be proven without providing a ZK proof as SGX (Geth) + SGX (Reth) is a valid combination.",
"description": "A multi-proof system is used. There are four verifiers available: SGX (Geth), SGX (Reth), SP1 and RISC0. Two of them must be used to prove a proposal range, and SGX (Geth) is mandatory. The end state root is supplied during the `prove` call and is checked against the accompanying SGX/zkVM proof. Proving is currently gated by ProverWhitelist, which has 1 whitelisted prover in discovery, and becomes permissionless only after an unproven proposal is > 5d old.",
"sentiment": "bad",
"value": "Multi-proofs",
"executionDelay": 7200,
"secondLine": "2h execution delay"
"executionDelay": 0,
"secondLine": "No execution delay"
},
"dataAvailability": {
"value": "Onchain",
"description": "All of the data needed for proof construction is published on Ethereum L1.",
"sentiment": "good",
"orderHint": null
},
"exitWindow": {
"description": "There is no window for users to exit in case of an unwanted upgrade since contracts are instantly upgradable.",
"sentiment": "bad",
"value": "None"
},
"sequencerFailure": {
"value": "Enqueue via L1",
"description": "Users can submit transactions to an L1 queue, but can't force them. The sequencers cannot selectively skip transactions but can stop processing the queue entirely. In other words, if the sequencers censor or are down, they are so for everyone.",
"sentiment": "warning"
"value": "Self sequence",
"description": "In the event of a sequencer failure, users can force transactions to be included in the project's chain by sending them to L1. There can be up to a 1d 1h delay on this operation.",
"sentiment": "good",
"orderHint": 92160
},
"proposerFailure": {
"value": "Self propose",
"description": "Anyone can be a Proposer and propose new roots to the L1 bridge. The initial whitelisted batch sequencer has a 2h proving window in which they must propose a state root and prove their own batch. After that, they forfeit half of their liveness bond and the other half can be claimed permissionlessly by any proposer who can supply proofs.",
"description": "Anyone can propose after 1d 1h if forced inclusions are ignored, and proving becomes permissionless after 5d if a proposal remains unproven.",
"sentiment": "good",
"orderHint": 0
"orderHint": 432000
}
}
}
scalingTechnology+27-20
{
"dataAvailability": [
{
"name": "All data required for proofs is published on chain",
"description": "All the data that is used to construct the system state is published on chain in the form of blobs. This ensures that it will be available for enough time.",
"references": [],
"risks": []
}
],
"exitMechanisms": [
{
"name": "Regular exit",
"description": "The user initiates the withdrawal by submitting a regular transaction on this chain. When the block containing that transaction is finalized the funds become available for withdrawal on L1. Finally the user submits an L1 transaction to claim the funds. This transaction requires a merkle proof.",
"risks": [],
"references": []
}
],
"forceTransactions": {
"name": "Users can force any transaction via L1",
"description": "Users can submit a blob containing a standalone transaction by calling the `storeForcedInclusion()` function on the `ForcedInclusionStore` contract. \n This forced transaction mechanism allows users to submit a transaction without running a prover.\n This mechanism ensures that at least one forced transaction from the queue is processed every 255 batches. However, if many transactions (k) are added to the queue, an individual transaction could experience a worst-case delay of up to k * 255 batches while waiting for its turn. Also, right now there is no mechanism that forces L2 Sequencer to include transactions from the queue in an L2 block, since L1 batches submission is permissioned behind a whitelist.",
"description": "Users can submit a blob reference containing a standalone transaction by calling the `saveForcedInclusion()` function on the `MainnetInbox` contract.\n Once any forced inclusion has been queued for 9m 36s, whitelisted proposers cannot submit new proposals unless they process all due forced inclusions.\n If the oldest queued forced inclusion is still ignored for 1d 1h, proposing becomes permissionless and anyone can include it.",
"references": [
{
"title": "ForcedInclusionStore.sol - Etherscan source code, storeForcedInclusion function",
"url": "https://etherscan.io/address/0xcdb25e201ad3fdcfe16730a6ca2cc0b1ce2137a2#code"
}
],
"risks": [
"title": "MainnetInbox.sol - Etherscan source code, saveForcedInclusion function",
"url": "https://etherscan.io/address/0x6f21C543a4aF5189eBdb0723827577e1EF57ef1f#code"
},
{
"category": "Users can be censored if",
"text": "the operator refuses to include their transactions."
"title": "MainnetInbox.sol - Etherscan source code, propose function",
"url": "https://etherscan.io/address/0x6f21C543a4aF5189eBdb0723827577e1EF57ef1f#code"
}
]
],
"risks": []
},
"operator": {
"name": "The system uses whitelist-based rotating operators",
"description": "The system uses a whitelist-based sequencing mechanism to allow for fast preconfirmations on the L2. On the L1, whitelisted preconfirmers (or the fallback operator) can sequence Taiko L2 blocks by proposing them on the TaikoL1 contract.\n The whitelist is managed by the `PreconfWhitelist` contract, which currently has 1 active operators registered.\n The proposer of a block is assigned the designated prover role, and will be the only entity allowed to provide a proof for the block during the 2h proving window.\n Currently, proving a block requires the block proposer to run a SGX instance with Geth, plus either SGX (Reth), SP1, or RISC0 to prove the block.\n Unless the block proposer proves the block within the proving window, it will forfeit half of its liveness bond to the TaikoL1 smart contract.",
"name": "The system uses whitelist-based sequencing and proving",
"description": "The system uses a whitelist-based sequencing mechanism to allow for fast preconfirmations on the L2. On the L1, whitelisted preconfirmers can propose Taiko L2 data to the MainnetInbox contract.\n The whitelist is managed by the `PreconfWhitelist` contract, which currently has 2 active operators registered.\n Forced inclusions become mandatory after 9m 36s and proposing becomes permissionless after 1d 1h if the queue is still ignored.\n Proving is controlled separately by `ProverWhitelist`, which currently has 1 whitelisted prover.\n Non-whitelisted actors must wait 5d after an unproven proposal before the whitelist is dropped. MainnetInbox currently sets minBond=0 and livenessBond=0.\n Currently, proving a proposal requires SGX (Geth), plus either SGX (Reth), SP1, or RISC0.",
"references": [
{
"title": "TaikoL1.sol - Etherscan source code, proposeBatch function",
"url": "https://etherscan.io/address/0x38Dd73fed93F8051E7A0dDd6FB3b9E7C25668187#code"
"title": "MainnetInbox.sol - Etherscan source code, propose function",
"url": "https://etherscan.io/address/0x6f21C543a4aF5189eBdb0723827577e1EF57ef1f#code"
},
{
"title": "TaikoL1.sol - Etherscan source code, proveBatches function",
"url": "https://etherscan.io/address/0x38Dd73fed93F8051E7A0dDd6FB3b9E7C25668187#code"
"title": "MainnetInbox.sol - Etherscan source code, prove function",
"url": "https://etherscan.io/address/0x6f21C543a4aF5189eBdb0723827577e1EF57ef1f#code"
},
{
"title": "PreconfWhitelist.sol - Etherscan source code",
"url": "https://etherscan.io/address/0xDBae46E35C18719E6c78aaBF9c8869c4eC84c149#code"
},
{
"title": "ProverWhitelist.sol - Etherscan source code",
"url": "https://etherscan.io/address/0xEa798547d97e345395dA071a0D7ED8144CD612Ae#code"
}
],
"risks": [
{
"category": "MEV can be extracted if",
"text": "the operator exploits their centralized position and frontruns user transactions."
}
]
},
"stateValidation": {
"categories": [
{
"title": "Validity proofs",
"description": "Taiko uses a multi-proof system to validate state transitions. The system requires two proofs among four available verifiers: SGX (Geth), SGX (Reth), SP1, and RISC0. The use of SGX (Geth) is mandatory, while the other three can be used interchangeably. This means that a block can be proven without providing a ZK proof if SGX (Geth) and SGX (Reth) are used together. Batch proposers are required to stake a liveness bond of 25.0 TAIKO, half of which is forfeited if they fail to prove the block within the proving window of 2h. The multi-proof system allows to detect bugs in the verifiers if they produce different results for the same block. If such a bug is detected, the system gets automatically paused.",
"description": "Taiko uses a multi-proof system to validate state transitions. The system requires two proofs among four available verifiers: SGX (Geth), SGX (Reth), SP1, and RISC0. The use of SGX (Geth) is mandatory, while the other three can be used interchangeably. This means that a proposal range can be proven without providing a ZK proof if SGX (Geth) and SGX (Reth) are used together. New proposals target a proof submission cadence of 4h. Proving is currently centralized behind ProverWhitelist with 1 whitelisted prover. Non-whitelisted actors must wait 5d before the whitelist is dropped, and MainnetInbox currently sets minBond=0 and livenessBond=0. The multi-proof system allows detecting bugs in the verifiers if they produce different results for the same proposal range. If such a bug is detected, the system gets automatically paused.",
"references": [
{
"title": "TaikoL1.sol - Etherscan source code, liveness bond",
"url": "https://etherscan.io/address/0x38Dd73fed93F8051E7A0dDd6FB3b9E7C25668187#code"
"title": "MainnetInbox.sol - Etherscan source code, getConfig function",
"url": "https://etherscan.io/address/0x6f21C543a4aF5189eBdb0723827577e1EF57ef1f#code"
},
{
"title": "TaikoL1.sol - Etherscan source code, proveBatches function",
"url": "https://etherscan.io/address/0x38Dd73fed93F8051E7A0dDd6FB3b9E7C25668187#code"
"title": "MainnetInbox.sol - Etherscan source code, prove function",
"url": "https://etherscan.io/address/0x6f21C543a4aF5189eBdb0723827577e1EF57ef1f#code"
},
{
"title": "ProverWhitelist.sol - Etherscan source code",
"url": "https://etherscan.io/address/0xEa798547d97e345395dA071a0D7ED8144CD612Ae#code"
}
],
"risks": [
{
"category": "Funds can be stolen if",
"text": "a malicious block is proven by compromised SGX instances."
}
]
}
]
}
}
livenessInfo+1-1
{
"explanation": "Taiko posts blocks of L2 transaction data directly to the L1. For a transaction to be considered final, both a block and its parent block have to be proven on the L1. State updates are a three step process: first blocks are proposed to L1, then they are proved, and lastly settled after a cooldown period."
"explanation": "Taiko posts proposals containing one or more L2 blocks to Ethereum using blobs. For a transaction to be considered final, the proposal containing it has to be proven on L1. State updates happen in two steps: proposals are submitted to MainnetInbox and later proven on L1."
}