{
"missing": {
"nextStage": "Stage 2",
"requirements": [
"Upgrades unrelated to onchain provable bugs provide less than 30d to exit."
]
},
"stage": "Stage 1",
"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)"
}
]
},
{
"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": false,
"description": "Upgrades unrelated to onchain provable bugs provide less than 30d to exit."
}
]
}
]
}
scalingRisks+33-0
{
"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,
"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.",
"sentiment": "good",
"orderHint": null
},
"exitWindow": {
"value": "10d",
"sentiment": "warning",
"description": "Users have 10d to exit funds in case of an unwanted regular upgrade. There is a 1mo delay before a regular upgrade is applied, and withdrawal inclusion via the decentralized sequencer set is probabilistic and simulated to take up to 20d to be processed. Although 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, counting as an upgrade for the exit window."
},
"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."
}
}
}
scalingDa+20-0
[
{
"layer": {
"value": "Ethereum",
"secondLine": "Blobs",
"sentiment": "good",
"description": "The data is posted to Ethereum as blobs.",
"projectId": "ethereum"
},
"bridge": {
"value": "Enshrined",
"sentiment": "good",
"description": "The validating bridge has access to all the data, as it is posted onchain.",
"projectId": "ethereum"
},
"mode": {
"value": "State diffs"
}
}
]
scalingTechnology+160-0
{
"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 4038 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."
}
{
"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."
}
}
{
"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",
"type": "EOA",
"isVerified": true,
"name": "0xb31e…0629",
"url": "https://etherscan.io/address/0xb31e6d9661720A93d54AF7D1815d9bb399280629"
},
{
"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
}
]
}
}
contracts+271-0
{
"addresses": {
"ethereum": [
{
"name": "HonkVerifier",
"isVerified": true,
"address": "eth:0x70aEDda427f26480D240bc0f4308ceDec8d31348",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "ZK proof verification contract.\n",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0x70aEDda427f26480D240bc0f4308ceDec8d31348#code"
},
{
"name": "EscapeHatch",
"isVerified": true,
"address": "eth:0x8c189ead28D5987A48e522162f9225124D50AD1B",
"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",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0x8c189ead28D5987A48e522162f9225124D50AD1B#code"
},
{
"name": "Rollup",
"isVerified": true,
"address": "eth:0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962",
"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 * **owner**: Governance",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962#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",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0x35b22e09Ee0390539439E24f06Da43D83f90e298#code"
},
{
"name": "GSE",
"isVerified": true,
"address": "eth:0xa92ecFD0E70c9cd5E5cd76c50Af0F7Da93567a4f",
"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",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0xa92ecFD0E70c9cd5E5cd76c50Af0F7Da93567a4f#code"
},
{
"name": "FeeJuicePortal",
"isVerified": true,
"address": "eth:0x2891F8b941067F8B5a3F34545A30Cf71E3E23617",
"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",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0x2891F8b941067F8B5a3F34545A30Cf71E3E23617#code"
},
{
"name": "Inbox",
"isVerified": true,
"address": "eth:0x8Dbf0b6ed495baAb6062f5D5365aF3C1B2ed4578",
"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",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0x8Dbf0b6ed495baAb6062f5D5365aF3C1B2ed4578#code"
},
{
"name": "Outbox",
"isVerified": true,
"address": "eth:0xc9698B7AdEf9ee63F3Bf5cFF38086e4E836579f0",
"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",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0xc9698B7AdEf9ee63F3Bf5cFF38086e4E836579f0#code"
},
{
"name": "RewardBooster",
"isVerified": true,
"address": "eth:0x1CbB707Bd7b4Fd2BcED6D96d84372fb428e93D80",
"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",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0x1CbB707Bd7b4Fd2BcED6D96d84372fb428e93D80#code"
},
{
"name": "RewardDistributor",
"isVerified": true,
"address": "eth:0x3D6A1B00C830C5f278FC5dFb3f6Ff0b74Db6dfe0",
"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) calls this to distribute payments to sequencers and provers.\n",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0x3D6A1B00C830C5f278FC5dFb3f6Ff0b74Db6dfe0#code"
},
{
"name": "Slasher",
"isVerified": true,
"address": "eth:0x64E6e9Bb9f1E33D319578B9f8a9C719Ca6D46eBb",
"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 * **vetoer**: SlashVeto Council",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0x64E6e9Bb9f1E33D319578B9f8a9C719Ca6D46eBb#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",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0x662De311f94bdbB571D95B5909e9cC6A25a6802a#code"
},
{
"name": "AZTEC Token",
"isVerified": true,
"address": "eth:0xA27EC0006e59f245217Ff08CD52A7E8b169E62D2",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "AZTEC token contract\n* Roles:\n * **owner**: CoinIssuer",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0xA27EC0006e59f245217Ff08CD52A7E8b169E62D2#code"
},
{
"name": "TallySlashingProposer",
"isVerified": true,
"address": "eth:0xa4a38fD0108C00983E75616b638Ff3321FD26958",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"description": "Allows the validator committee to vote on slashing a specific peer. Once a quorum is reached, it proposes a slash action to the Slasher.\n",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0xa4a38fD0108C00983E75616b638Ff3321FD26958#code"
},
{
"name": "SlashPayloadCloneable",
"isVerified": true,
"address": "eth:0xAA43220b7eb7c8Ffe75bc9C483f3C07b0a55B445",
"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",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0xAA43220b7eb7c8Ffe75bc9C483f3C07b0a55B445#code"
},
{
"name": "AztecTokenPositionRegistry_ProtocolTreasury",
"isVerified": true,
"address": "eth:0xD938bE4A2cB41105Bc2FbE707dca124A2e5d0c80",
"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.\n* Roles:\n * **owner**: EOA 1",
"discoveryDrivenData": true,
"url": "https://etherscan.io/address/0xD938bE4A2cB41105Bc2FbE707dca124A2e5d0c80#code"
}
]
},
"escrows": [
{
"address": "0x2891F8b941067F8B5a3F34545A30Cf71E3E23617",
"sinceTimestamp": 1772654159,
"tokens": [
"AZTEC"
],
"contract": {
"isVerified": true,
"address": "eth:0x2891F8b941067F8B5a3F34545A30Cf71E3E23617",
"upgradeability": {
"proxyType": "immutable",
"admins": [],
"implementations": [],
"immutable": true
},
"chain": "ethereum",
"url": "https://etherscan.io/address/0x2891F8b941067F8B5a3F34545A30Cf71E3E23617#code"
},
"chain": "ethereum",
"includeInTotal": true,
"chainId": 1
}
],
"risks": []
}
{
"badges": [],
"description": "Barretenberg includes several zk-SNARK proof systems built by Aztec, including UltraHonk and CHONK.",
"links": {
"websites": [
"https://aztec.network"
],
"documentation": [
"https://barretenberg.aztec.network/docs/",
"https://eprint.iacr.org/2022/1355"
],
"repositories": [
"https://github.com/AztecProtocol/aztec-packages/tree/next/barretenberg"
],
"socialMedia": [
"https://x.com/aztecnetwork"
]
}
}
colors+1-0
null
ecosystemColors+1-0
null
milestones+1-0
null
chainConfig+1-0
null
escrows+1-0
null
bridgeInfo+1-0
null
bridgeRisks+1-0
null
bridgeTechnology+1-0
null
scalingInfo+1-0
null
scalingStage+1-0
null
scalingRisks+1-0
null
scalingDa+1-0
null
scalingTechnology+1-0
null
daLayer+1-0
null
daBridge+1-0
null
customDa+1-0
null
zkCatalogInfo+86-0
{
"creator": "Aztec",
"projectsForTvs": [
{
"projectId": "aztecnetwork",
"sinceTimestamp": 1774821600
}
],
"proofSystemInfo": "\n## 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.\n ",
"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",
"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 "
}
],
"verifierHashes": [
{
"hash": "0x059ad02b037fcfd4df2b9db771777d067a400f06fc55cf45fa601511e58e2c3e",
"name": "Barretenberg Aztec verifier v4",
"sourceLink": "https://github.com/AztecProtocol/aztec-packages/tree/v4/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"
}
],
"verificationStatus": "successful",
"attesters": [
{
"id": "l2beat",
"name": "L2BEAT",
"link": "https://l2beat.com"
}
],
"verificationSteps": "\nThe 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`.\n "
}
]
}
interopConfig+1-0
null
tvsInfo+1-0
null
tvsConfig+1-0
null
activityConfig+1-0
null
livenessInfo+1-0
null
livenessConfig+1-0
null
costsInfo+1-0
null
trackedTxsConfig+1-0
null
daTrackingConfig+1-0
null
ecosystemInfo+1-0
null
ecosystemConfig+1-0
null
permissions+1-0
null
contracts+1-0
null
discoveryInfo+1-0
null
isScaling+1-0
null
isDaLayer+1-0
null
isInteropProtocol+1-0
null
isUpcoming+1-0
null
archivedAt+1-0
null
hasTestnet+1-0
null
ethereum+5-0
daBridge+5-0
{
"daLayer": "ethereum",
"name": "Enshrined Bridge",
"risks": {
"daBridge": {
"value": "Enshrined",
"sentiment": "good",
"description": "Rollup users have access to all the data, as it is posted onchain on the consensus layer. On the execution layer, the rollup relies on blob data commitment (versioned hashes), which are accessible through the BLOBHASH opcode. \nThe rollup smart contracts can use these blob commitments during state transition validation to reference blobs during proof verification, without requiring direct access to the raw blob data.\n "
},
"callout": "Unlike non-enshrined DA bridges, it does not place any honesty\n assumption on an external committee that provides data availability\n attestations to the DA bridge. From the rollup perspective,\n Ethereum's canonical chain cannot contain unavailable data\n commitments as full nodes self-verify the data availability of each\n block, discarding blocks with unavailable data. The rollup state\n validating bridge has access to all the data, as it is posted on chain."
},
"technology": {
"description": "\n ## Enshrined Bridge\n The DA bridge on Ethereum is enshrined, meaning that blob data is directly accessible on the consensus layer, with data availability guaranteed by the network's inherent consensus rules. \n If a block contains unavailable data, full nodes will reject it, causing the chain to fork away from that block. This ensures data availability without requiring additional trust assumptions. \n In contrast, external DA providers must rely on data availability attestations from the external validator set, introducing an extra layer of trust on the majority of validators.\n "
},
"usedIn": [
{
"id": "abstract",
"name": "Abstract",
"slug": "abstract"
},
{
"id": "adi",
"name": "ADI Chain",
"slug": "adi"
},
{
"id": "arbitrum",
"name": "Arbitrum One",
"slug": "arbitrum"
},
{
"id": "arenaz",
"name": "Arena-Z",
"slug": "arenaz"
},
{
"id": "aztecnetwork",
"name": "Aztec Network",
"slug": "aztecnetwork"
},
{
"id": "base",
"name": "Base Chain",
"slug": "base"
},
{
"id": "blast",
"name": "Blast",
"slug": "blast"
},
{
"id": "bob",
"name": "BOB",
"slug": "bob"
},
{
"id": "bobanetwork",
"name": "Boba Network",
"slug": "bobanetwork"
},
{
"id": "cartesi-prt-honeypot-v2",
"name": "Cartesi PRT Honeypot v2",
"slug": "cartesi-prt-honeypot-v2"
},
{
"id": "dbk",
"name": "DeBank Chain",
"slug": "dbk"
},
{
"id": "deri",
"name": "Deri",
"slug": "deri"
},
{
"id": "ethernity",
"name": "Epic Chain",
"slug": "epicchain"
},
{
"id": "ethscriptions",
"name": "Ethscriptions",
"slug": "ethscriptions"
},
{
"id": "facet",
"name": "Facet v1",
"slug": "facet"
},
{
"id": "forknet",
"name": "Forknet",
"slug": "forknet"
},
{
"id": "hashkey",
"name": "HashKey Chain",
"slug": "hashkey"
},
{
"id": "hemi",
"name": "Hemi",
"slug": "hemi"
},
{
"id": "ink",
"name": "Ink",
"slug": "ink"
},
{
"id": "jovay",
"name": "Jovay",
"slug": "jovay"
},
{
"id": "katana",
"name": "Katana",
"slug": "katana"
},
{
"id": "lighter",
"name": "Lighter",
"slug": "lighter"
},
{
"id": "linea",
"name": "Linea",
"slug": "linea"
},
{
"id": "lisk",
"name": "Lisk",
"slug": "lisk"
},
{
"id": "loopring",
"name": "Loopring",
"slug": "loopring"
},
{
"id": "metal",
"name": "Metal",
"slug": "metal"
},
{
"id": "metis",
"name": "Metis Andromeda",
"slug": "metis"
},
{
"id": "mint",
"name": "Mint",
"slug": "mint"
},
{
"id": "mode",
"name": "Mode Network",
"slug": "mode"
},
{
"id": "morph",
"name": "Morph",
"slug": "morph"
},
{
"id": "optimism",
"name": "OP Mainnet",
"slug": "op-mainnet"
},
{
"id": "phala",
"name": "Phala",
"slug": "phala"
},
{
"id": "polynomial",
"name": "Polynomial",
"slug": "polynomial"
},
{
"id": "r0ar",
"name": "R0ar",
"slug": "r0ar"
},
{
"id": "race",
"name": "Race Network",
"slug": "race"
},
{
"id": "scroll",
"name": "Scroll",
"slug": "scroll"
},
{
"id": "shape",
"name": "Shape",
"slug": "shape"
},
{
"id": "soneium",
"name": "Soneium",
"slug": "soneium"
},
{
"id": "starknet",
"name": "Starknet",
"slug": "starknet"
},
{
"id": "superseed",
"name": "Superseed",
"slug": "superseed"
},
{
"id": "swan",
"name": "Swan Chain",
"slug": "swan"
},
{
"id": "swell",
"name": "Swellchain",
"slug": "swell"
},
{
"id": "sxnetwork",
"name": "SX Network",
"slug": "sxnetwork"
},
{
"id": "syndicate",
"name": "Syndicate Chain",
"slug": "syndicate"
},
{
"id": "taiko",
"name": "Taiko Alethia",
"slug": "taiko"
},
{
"id": "unichain",
"name": "Unichain",
"slug": "unichain"
},
{
"id": "worldchain",
"name": "World Chain",
"slug": "world"
},
{
"id": "xlayer",
"name": "X Layer",
"slug": "xlayer"
},
{
"id": "zeronetwork",
"name": "ZERO Network",
"slug": "zeronetwork"
},
{
"id": "zircuit",
"name": "Zircuit",
"slug": "zircuit"
},
{
"id": "aztec",
"name": "Zk.Money v1 (Aztec v1)",
"slug": "aztecv1"
},
{
"id": "zksync2",
"name": "ZKsync Era",
"slug": "zksync-era"
},
{
"id": "zksync",
"name": "ZKsync Lite",
"slug": "zksync-lite"
},
{
"id": "zora",
"name": "Zora",
"slug": "zora"
}
]
}