Search for projects by name or address
ZKsync Era is a general-purpose ZK Rollup with full EVM compatibility.
While the Security Council is properly set up and is able to recover from a misbehaving operator, the majority is required, meaning that a compromised quorum-blocking minority can prevent users from exiting. Recovery actions are not straightforward and require complex protocol upgrades.
ZKsync Era is a general-purpose ZK Rollup with full EVM compatibility.
The section shows the operating costs that L2s pay to Ethereum.
This section shows how much data the project publishes to its data-availability (DA) layer over time. The project currently posts data to; previously it posted to
Ethereum.
This section shows how "live" the project's operators are by displaying how frequently they submit transactions of the selected type. It also highlights anomalies - significant deviations from their typical schedule.
V29 Interop Messaging Upgrade
2025 Oct 6th
A protocol upgrade introducing native interop messaging between chains connected to ZKsync Gateway.
Proof system intervention
2025 Jul 30th
The proof systemThe infrastructure that allows projects to verify their state transitions. It is composed by onchain verifiers and offchain provers. The main two flavors are optimistic and ZK proof systems, but they can be combined in a hybrid model. In general though, if a system is able to accept state roots optimistically, even if it has a ZK component, it is considered an optimistic proof system. is manually paused due to a vulnerability, causing a partial livenessLiveness refers to the ability of a system to respond to requests and to process them in a timely manner. In the context of L2s, it refers to the ability of settling transactions, proofs and state roots to the base layer. failure.
Users can submit transactions to an L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. 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.
STARKs and SNARKs are zero knowledge proofs that ensure state correctness. STARKs proofs are wrapped in SNARKs proofs for efficiency. SNARKs require a trusted setupGeneration of a piece of data that must then be used for some cryptographic protocol to run. Generating this data requires some secret information. The "trust" comes from the fact the secret must be destroyed after the ceremony, otherwise cryptographic properties of the protocol could be broken. Once the data is generated, and the secrets are forgotten, no further participation from the creators of the ceremony is required. There are two types of trusted setups for SNARKs: (i) trusted setup per circuit where it is generated from scratch for each circuit, (ii) trusted universal setup per proving system where it can be used for several circuits..
All of the data (SD = state diffs) needed for proof construction is published onchain.
Non-emergency upgrades go through a 4d 3h delay, but the central operatorAn operator is the entity charged with managing a rollup and progressing its state. A rollup operator can be a centralized sequencer, proposer, prover, challenger, pauser of admin that is able to perform upgrades. can still censor withdrawal transactions by implementing a TransactionFilterer with no delay.
There is no window for users to exit in case of an unwanted upgrade since contracts are instantly upgradable.
Only the whitelisted proposers can publish state rootsA cryptographic hash succinctly representing a state using a Merkle tree. on L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development., so in the event of failure the withdrawals are frozen. There is a decentralized Governance system that can attempt changing Proposers with an upgrade.
All the data that is used to construct the system state is published on chain in the form of cheap blobsThe data that a rollup publishes to its L1/data availability (DA) layer. They consist of the L2 transactions that are rolled up, along with some metadata. Blobs are introduced as a new transaction type within Ethereum with EIP-4844, and has rollup scaling specifically in mind. Blobs persist on Ethereum’s Beacon Chain ephemerally. or calldata. This ensures that it will be available for enough time.
The nodeA software client that participates in the network. software is open-source, and its source code can be found here. The main node software does not rely on Layer 1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. (L1) to reconstruct the state, but you can use this tool for that purpose. Currently, there is no straightforward method to inject the state into the main node, but ZKsync is actively working on a solution for this.
Bytecodes undergo compression before deployment on Layer 1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. (L1). You can find additional information on this process here.
There have been neither genesis states nor regenesis.
Details on data format can be found here.
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.
ZKsync Era proof systemThe infrastructure that allows projects to verify their state transitions. It is composed by onchain verifiers and offchain provers. The main two flavors are optimistic and ZK proof systems, but they can be combined in a hybrid model. In general though, if a system is able to accept state roots optimistically, even if it has a ZK component, it is considered an optimistic proof system. Boojum can be found here and contains essential tools like the ProverAn entity that generates the cryptographic proof to convince the verifier that the statement is true. In a ZK-Rollup, the prover generates the ZK (validity) proof to submit to the verifier contract., the VerifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover., and other backend components. The specs of the system can be found here.
Funds can be lost if the proof system is implemented incorrectly.
SNARKShort for "succinct non-interactive argument of knowledge", a SNARK is a widely used type of zero-knowledge proof that is short and fast to verify. Different kinds of SNARKs are usually systematized by proof size, verification time, and type of setup. The most famous SNARKs are Groth16, PLONK/Marlin, Bulletproofs, and STARKs. verification keys can be generated and checked against the Ethereum verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. contract using this tool. The system requires a trusted setupGeneration of a piece of data that must then be used for some cryptographic protocol to run. Generating this data requires some secret information. The "trust" comes from the fact the secret must be destroyed after the ceremony, otherwise cryptographic properties of the protocol could be broken. Once the data is generated, and the secrets are forgotten, no further participation from the creators of the ceremony is required. There are two types of trusted setups for SNARKs: (i) trusted setup per circuit where it is generated from scratch for each circuit, (ii) trusted universal setup per proving system where it can be used for several circuits..
Onchain verifier
Onchain verifier
Onchain verifier | ||
Onchain verifier |
Name | Hash | Repository | Verification | Used in | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
0x0100...51e6 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||

There are two main paths for contract upgrades in the shared ZK stack ecosystem - standard and emergency - both converging on the shared upgrade management contract ProtocolUpgradeHandler. The standard path involves a governance proposal and voting through the DAO, multiple timelock delays and finally approval by the Guardians or 4 SecurityCouncil participants. The emergency path allows for contract upgrades without any delay by the EmergencyUpgradeBoard, which acts as a 3/3 Multisig between SecurityCouncil, Guardians and the FoundationMultisig.
Delegates can start new proposals by reaching a threshold of 21M ZK tokens on the ZKsync Era RollupA blockchain that inherits consensus and data availability from another blockchain called L1. Rollups enable trust minimized bridges with the base layer via proof systems, either optimistic or zero-knowledge. A rollup without a bridge, or without considering the bridge, is called a sovereign rollup.’s ZkProtocolGovernor contract. This launches a 3d ‘voting delay’ after which the 7d voting period starts. During these first two periods, the proposal can be canceled by the proposerIn the context of L2s, the actor that proposes a claimed state root on L1. The term is also used in the context of Ethereum to refer to the actor that proposes a new block. or if it falls below the proposing threshold. A proposal is only successful if it reaches both quorum (630M ZK tokens) and simple majority. When it reaches quorum, a remaining voting period of 3d is guaranteed by a potential late quorum vote extension. In the successful case, it can be queued in the 0s timelock which forwards it via the Gateway to Ethereum as an L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups.->L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. log.
After the execution of the proposal-containing batch (3h delay), the proposal is now picked up by the ProtocolUpgradeHandler and enters the 3d ‘legal veto period’. This serves as a window in which a veto could be coordinated offchain, to be then enforced by non-approval of Guardians and SecurityCouncil. A threshold of 2 Guardians can extend the veto period to 7d. After this a proposal enters a waiting state of 1mo, from which it can be immediately approved (cancelling the delay) by 4 participants of the SecurityCouncil. For the unlikely case that the Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups. does not approve here, the Guardians can instead approve the proposal, or nobody. In the two latter cases, the waiting period is enforced in full. A proposal cannot be actively cancelled in the ProtocolUpgradeHandler, but will expire if not approved within the waiting period. An approved proposal now enters the pendingExecution state for a final delay of 1d and can then be executed.
There are two other tracks of Governance also starting with DAO Delegate proposals the ZKsync Era rollup: 1) Token Program Proposals that add new minters, allocations or upgrade the ZK token and 2) Governance Advisory Proposals that e.g. change the ZK Credo or other offchain Governance Procedures without onchain targets. The protocol for these two other tracks is similar to the first part of the standard path described above (albeit having different quorum and timelock values), and not passing over to the Ethereum L1. Further customizations are that the ZkFoundationMultisig can propose to the ZkTokenGovernor without a threshold and that the Guardians’ L2 alias can cancel proposals in the ZkTokenGovernor and the ZkGovOpsGovernor.
SecurityCouncil (6/8), Guardians (5/8) and ZkFoundationMultisig (3/6) form a de-facto 3/3 Multisig by pushing an immediate upgrade proposal through the EmergencyUpgradeBoard, which circumvents all delays and executes immediately via the ProtocolUpgradeHandler.
The cumulative duration of the upgrade paths from the moment of a voted ‘successful’ proposal is 4d 3h or 8d 3h (depending on Guardians extending the LegalVetoPeriod) for Standard, 0 for Emergency and 1mo 4d for the path in which the SecurityCouncil is not approving the proposal.
The SecurityCouncil can freeze (pause withdrawals and settlementThe mechanism with which the execution of rollup blocks and the resultant state is verified and possible disputes are resolved. In the context of rollups or other modular blockchains, it often refers to the proof system used--validity (ZK) or fraud proofs, or a combination thereof. Sometimes it will refer to this mechanism along with where the mechanism's outputs are ultimately published and verified, as in Ethereum being a settlement layer by verifying the proofs and allowing for withdrawals.) all chains connected to the current ChainTypeManager. Either for a softFreeze of 12h or a hardFreeze of 7d. After a softFreeze and / or a hardFreeze, a proposal from the EmergencyUpgradeBoard has to be passed before subsequent freezes are possible. Only the SecurityCouncil can unfreeze an active freeze.
Apart from the paths that can upgrade all shared implementations, the ZK stack governance system defines other roles that can modify the system: A single ZK cluster Admin role who governs parameters in the shared contracts and a Chain Admin role (defined in each chain-specific diamond contract) for managing parameters of each individual ZK chain that builds on the stack. These chain-specific actions include critical operations like setting a transaction filterer that can censor L1 -> L2 messages, changing the DA mode, migrating the chain to a different settlement layer and standard operations like setting fee parameters and adding / removing ValidatorsIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier in the ValidatorTimelock. For rollups, data availabilityThe property of a rollup's data being reachable by any node retrieving the data that were rolled up and executed to reach the proposed state. Data availability (DA), specifically decoupling it from the rollup nodes themselves, is one of the preeminent factors which allows a rollup to scale securely. A rollup is faced with a decision of what to use as a DA layer to guarantee that any node can retrieve this data--permissionlessly under any circumstance. For this reason, using Ethereum for DA currently provides the strongest security guarantees. If data is stored somewhere other than a permissionless L1, then the project is not a rollup, but rather a validium or an optimium. on Ethereum is validated by a RollupL1DAValidator contract (or a RelayedSLDAValidator on the Gateway). Each rollup can become a permanent rollup (through their Chain Admin) which disallows DA changes to non-whitelisted sources or settlement layers in the future. The source of truth for rollup-compliant DA validator contracts is the RollupDAManager contract, which is administered via the ProtocolUpgradeHandler. ZKsync Era’s Chain Admin differs from the others as it also has the above ZK cluster Admin role in the shared ZK stack contracts.
| Composition | 4/8 to approve upgrades · 3/8 soft freeze · 6/8 hard freeze, unfreeze and emergency approval. No fixed terms: members serve until replaced via Protocol Governor proposal. |
|---|---|
| Members public | Mapped — 8 representatives of different orgs + signer addresses published in Schedule 3. |
| Charter | ZKsync Governance Procedures, Schedules 2–3 + bylaws of the ZKsync Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups. entity. |
| Can bypass DAO? | Freeze yes, upgrade no (alone) — can unilaterally and immideately freeze the protocol: 12h soft freeze (3/8) or 7d hard freeze (6/8). Upgrades require approvals from 5/8 Guardians and 3/6 ZK Foundation Multisig. |
| DAO can override SC? | Partially — the Token Assembly can pass a Protocol Governor proposal replacing SC members, but it needs SC approval (4/8) or 5/8 Guardians as fallback. No unconditional tokenholder path. |
| Composition | 5/8 for vetoes and approvals, no fixed terms. Addresses and names of individuals that take Guardian role are published in Schedule 4. |
|---|---|
| Powers | Veto + fallback approval + emergency co-sign. L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. Onchain veto (5/8) cancels Token/GovOps proposals during voting delay or vote. Offchain veto (5 signed statements to the SC Foundation) blocksAn ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over. Protocol proposals during the 3d legal veto period; 2/8 can extend it to 7d. 5/8 can approve a Protocol proposal in risk review if the SC won’t. The Guardian multisig is 1 of 3 emergency upgrade signers. Veto justification due on the forum within 48h. |
| Self-protection | Yes — Guardian membership is changed via Protocol Governor proposal, but Guardians may explicitly veto proposals affecting the Guardian body itself (Schedule 4 §5.2). Token holders have no unconditional onchain removal path. |
| Normal upgrade path | ZIP submission on L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. → 3d voting delay → 7d vote (late quorum +3d) → L2→L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. message to the ProtocolUpgradeHandler → 3d Guardian offchain-veto window (extendable to 7d by 2/8) → ≤1mo risk review, SC approval (4/8) short-circuits to → 1d timelock → permissionlessAnyone willing should be able to join and leave the network at any time, without causing significant disturbance to the network or being detrimental to the party in question. No single entity should have the power to allowlist or blocklist participants. execution on Ethereum. Fastest ≈ 14 days from submission; Guardian-fallback path ≈ 44 days. |
|---|---|
| Emergency upgrade path | 6/8 SC + 5/8 Guardians + 3/6 ZKsync Foundation, instant. |
| Exit window | ~4 days after the vote closes when the SC approves promptly (3d veto window + 1d timelock). 0 for emergency upgrades. |
| Token Program path | Grants or modifies capped ZK minting/burning rights. TPPs via Token Governor: 3d delay → 7d vote (late quorum +2d) → 3d timelock → permissionlessAnyone willing should be able to join and leave the network at any time, without causing significant disturbance to the network or being detrimental to the party in question. No single entity should have the power to allowlist or blocklist participants. execution on Era, ≈ 13 days. |
| GovOps path | GAPs via GovOps Governor: same 3d + 7d + 3d schedule, but advisory only, implementation is left to the proposerIn the context of L2s, the actor that proposes a claimed state root on L1. The term is also used in the context of Ethereum to refer to the actor that proposes a new block. or named parties. |
| Governance token |
|
|---|---|
| Voting venue | ZKsync Governance Portal powered by Cactus (formerly Tally). Three OpenZeppelin Governors on ZKsync Era: Protocol, Token, GovOps, each with its own timelock. |
| Proposal threshold | 21,000,000 ZK delegated (0.1% of the 21.00 B max mintable supply), identical for all three governors. |
| Quorum | 630,000,000 ZK (3% of max mintable supply) for all three governors. Simple majority of For vs Against; abstentions don’t count. Late-quorum extension: +3d (Protocol), +2d (Token/GovOps). |
| Execution model | On-chain payload · PermissionlessAnyone willing should be able to join and leave the network at any time, without causing significant disturbance to the network or being detrimental to the party in question. No single entity should have the power to allowlist or blocklist participants. execute. Protocol proposals travel via L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups.→L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. message and are permissionlessly executed on Ethereum after review + timelock; Token proposals execute permissionlessly on Era after their timelock. |
The metrics include upgrades on the currently used proxy contracts. Historical proxy contracts and changes of such are not included.
Matter Labs 4/7 multisig upgraded the boojum verifiers to version v0.30.1 (registered on the ChainTypeManager before). The new verifiers are not yet reproduced.
Matter Labs 4/7 multisig upgraded the boojum verifiers to version v0.30.1 (registered on the ChainTypeManager before). The new verifiers are not yet reproduced.
| contract Diamond (eth:0x32400084C286CF3E17e7B677ea9583e60a000324) [shared-zk-stack/Diamond] { | |
| +++ description: The main contract defining the Layer 2. Operator actions like commiting blocks, providing ZK proofs and executing batches ultimately target this contract which then processes transactions. During batch execution it processes L1 --> L2 and L2 --> L1 transactions. isPermanentRollup was set to true in this contract which prevents changing the DA mode to Validium in the future. | |
| values.$pastUpgrades.28: | |
| + | ["2026-08-16T09:36:47.000Z","0xa22268c77351fd1c1e3c632ad2323425cb1f2330b2ee34686c0a081f93bdd423",["eth:0x37CefD5b44c131FEf27e9Bc542e5B77A177A7253","eth:0x1666124221622eb6154306Ea9BA87043e8be88B2","eth:0x1e34aB39a9682149165ddeCc0583d238A5448B45","eth:0x0597CaA8A823A699d7CD9E62B5E5d4153FF82691"]] |
| values.$upgradeCount: | |
| - | 28 |
| + | 29 |
| +++ description: Protocol version, increments with each protocol upgrade. | |
| +++ severity: HIGH | |
| values.getProtocolVersion: | |
| - | 128849018880 |
| + | 128849018881 |
| values.getSemverProtocolVersion.2: | |
| - | 0 |
| + | 1 |
| values.getVerifier: | |
| - | "eth:0xC47D355402E78b886B628914B3b129F236fEe3cc" |
| + | "eth:0xCeF0218c0C6dB0768e48debeE26E41B8DAdE7081" |
| } | |
| - | Status: DELETED |
| contract L1VerifierPlonk (eth:0x35CD3865199F2D9c574f34DD72520B19842d440c) [shared-zk-stack/L1VerifierPlonk] | |
| +++ description: Verifies a zk-SNARK proof using an implementation of the PlonK proof system. | |
| - | Status: DELETED |
| contract L1VerifierFflonk (eth:0x4A34cE730052cb195d8a95e730623eEcc1CB8B66) [shared-zk-stack/L1VerifierFflonk] | |
| +++ description: Verifies a zk-SNARK proof using an implementation of the fflonk proof system. | |
| - | Status: DELETED |
| contract DualVerifier (eth:0xC47D355402E78b886B628914B3b129F236fEe3cc) [shared-zk-stack/DualVerifier] | |
| +++ description: A router contract for verifiers. Routes verification requests to eth:0x4A34cE730052cb195d8a95e730623eEcc1CB8B66 or eth:0x35CD3865199F2D9c574f34DD72520B19842d440c depending on the supplied proof type. | |
| + | Status: CREATED |
| contract EraVerifierPlonk (eth:0x0DAAB2B7b38ab48712996E760152c569FA356DbF) [shared-zk-stack/L1VerifierPlonk] | |
| +++ description: Verifies a zk-SNARK proof using an implementation of the PlonK proof system. | |
| + | Status: CREATED |
| contract EraVerifierFflonk (eth:0x8470d6B3fd71B5fE3906B4ea04498d18F721eDe9) [shared-zk-stack/L1VerifierFflonk] | |
| +++ description: Verifies a zk-SNARK proof using an implementation of the fflonk proof system. | |
| + | Status: CREATED |
| contract EraDualVerifier (eth:0xCeF0218c0C6dB0768e48debeE26E41B8DAdE7081) [shared-zk-stack/DualVerifier] | |
| +++ description: A router contract for verifiers. Routes verification requests to eth:0x8470d6B3fd71B5fE3906B4ea04498d18F721eDe9 or eth:0x0DAAB2B7b38ab48712996E760152c569FA356DbF depending on the supplied proof type. | |
Matter Labs 4/7 multisig upgraded boojum verifier to v29.5 (was registered on chain type manager before). Verifier is not yet reproduced. Config-related: added full batch lifecycle permissions to era multisig template, fixed incorrect permissions and descriptions.
Matter Labs 4/7 multisig upgraded boojum verifier to v29.5 (was registered on chain type manager before). Verifier is not yet reproduced.
Config-related: added full batch lifecycle permissions to era multisig template, fixed incorrect permissions and descriptions.
| contract Diamond (eth:0x32400084C286CF3E17e7B677ea9583e60a000324) [shared-zk-stack/Diamond] { | |
| +++ description: The main contract defining the Layer 2. Operator actions like commiting blocks, providing ZK proofs and executing batches ultimately target this contract which then processes transactions. During batch execution it processes L1 --> L2 and L2 --> L1 transactions. isPermanentRollup was set to true in this contract which prevents changing the DA mode to Validium in the future. | |
| values.$pastUpgrades.27: | |
| + | ["2026-08-08T17:03:47.000Z","0x1586dea0c7326b2ae060b222925e9c752481cd049f907634a114200ecaa7baab",["eth:0x37CefD5b44c131FEf27e9Bc542e5B77A177A7253","eth:0x1666124221622eb6154306Ea9BA87043e8be88B2","eth:0x1e34aB39a9682149165ddeCc0583d238A5448B45","eth:0x0597CaA8A823A699d7CD9E62B5E5d4153FF82691"]] |
| values.$upgradeCount: | |
| - | 27 |
| + | 28 |
| +++ description: Protocol version, increments with each protocol upgrade. | |
| +++ severity: HIGH | |
| values.getProtocolVersion: | |
| - | 124554051589 |
| + | 128849018880 |
| values.getSemverProtocolVersion.1: | |
| - | 29 |
| + | 30 |
| values.getSemverProtocolVersion.2: | |
| - | 5 |
| + | 0 |
| values.getVerifier: | |
| - | "eth:0x47fC5273145E053A18C0BBF6d88F8d6d573C3d0e" |
| + | "eth:0xC47D355402E78b886B628914B3b129F236fEe3cc" |
| } | |
| - | Status: DELETED |
| contract DualVerifier (eth:0x47fC5273145E053A18C0BBF6d88F8d6d573C3d0e) [shared-zk-stack/DualVerifier] | |
| +++ description: A router contract for verifiers. Routes verification requests to eth:0x9f5C39a2790f38542065E7854b90407371923375 or eth:0xd22cA89e8991FCE568456914c616d303e3142395 depending on the supplied proof type. | |
| - | Status: DELETED |
| contract L1VerifierFflonk (eth:0x9f5C39a2790f38542065E7854b90407371923375) [shared-zk-stack/L1VerifierFflonk] | |
| +++ description: Verifies a zk-SNARK proof using an implementation of the fflonk proof system. | |
| - | Status: DELETED |
| contract L1VerifierPlonk (eth:0xd22cA89e8991FCE568456914c616d303e3142395) [shared-zk-stack/L1VerifierPlonk] | |
| +++ description: Verifies a zk-SNARK proof using an implementation of the PlonK proof system. | |
| + | Status: CREATED |
| contract L1VerifierPlonk (eth:0x35CD3865199F2D9c574f34DD72520B19842d440c) [N/A] | |
| +++ description: None | |
| + | Status: CREATED |
| contract L1VerifierFflonk (eth:0x4A34cE730052cb195d8a95e730623eEcc1CB8B66) [N/A] | |
| +++ description: None | |
| + | Status: CREATED |
| contract DualVerifier (eth:0xC47D355402E78b886B628914B3b129F236fEe3cc) [shared-zk-stack/DualVerifier] | |
| +++ description: A router contract for verifiers. Routes verification requests to eth:0x4A34cE730052cb195d8a95e730623eEcc1CB8B66 or eth:0x35CD3865199F2D9c574f34DD72520B19842d440c depending on the supplied proof type. | |
Upgraded boojum verifiers to the next version. It is not yet verified.
Upgraded boojum verifiers to the next version. It is not yet verified.
| contract Diamond (eth:0x32400084C286CF3E17e7B677ea9583e60a000324) [shared-zk-stack/Diamond] { | |
| +++ description: The main contract defining the Layer 2. Operator actions like commiting blocks, providing ZK proofs and executing batches ultimately target this contract which then processes transactions. During batch execution it processes L1 --> L2 and L2 --> L1 transactions. isPermanentRollup was set to true in this contract which prevents changing the DA mode to Validium in the future. | |
| values.$pastUpgrades.26: | |
| + | ["2026-07-24T17:51:11.000Z","0x3230654aa6e3c7d63a7f6d8bfe6eccabc98a11f18409af0fcadd12f8b65f34b4",["eth:0x37CefD5b44c131FEf27e9Bc542e5B77A177A7253","eth:0x1666124221622eb6154306Ea9BA87043e8be88B2","eth:0x1e34aB39a9682149165ddeCc0583d238A5448B45","eth:0x0597CaA8A823A699d7CD9E62B5E5d4153FF82691"]] |
| values.$upgradeCount: | |
| - | 26 |
| + | 27 |
| +++ description: Protocol version, increments with each protocol upgrade. | |
| +++ severity: HIGH | |
| values.getProtocolVersion: | |
| - | 124554051588 |
| + | 124554051589 |
| values.getSemverProtocolVersion.2: | |
| - | 4 |
| + | 5 |
| values.getVerifier: | |
| - | "eth:0xCD279BD537c8e1A1acC46aC2205bebD8902F7A45" |
| + | "eth:0x47fC5273145E053A18C0BBF6d88F8d6d573C3d0e" |
| } | |
| - | Status: DELETED |
| contract L1VerifierPlonk (eth:0x7f33D100f482093182111d69a4a457289e99f4ec) [shared-zk-stack/L1VerifierPlonk] | |
| +++ description: Verifies a zk-SNARK proof using an implementation of the PlonK proof system. | |
| - | Status: DELETED |
| contract L1VerifierFflonk (eth:0xa38a0Df579F9eCA29fbA560b9885B1113b1Df442) [shared-zk-stack/L1VerifierFflonk] | |
| +++ description: Verifies a zk-SNARK proof using an implementation of the fflonk proof system. | |
| - | Status: DELETED |
| contract DualVerifier (eth:0xCD279BD537c8e1A1acC46aC2205bebD8902F7A45) [shared-zk-stack/DualVerifier] | |
| +++ description: A router contract for verifiers. Routes verification requests to eth:0xa38a0Df579F9eCA29fbA560b9885B1113b1Df442 or eth:0x7f33D100f482093182111d69a4a457289e99f4ec depending on the supplied proof type. | |
| + | Status: CREATED |
| contract DualVerifier (eth:0x47fC5273145E053A18C0BBF6d88F8d6d573C3d0e) [shared-zk-stack/DualVerifier] | |
| +++ description: A router contract for verifiers. Routes verification requests to eth:0x9f5C39a2790f38542065E7854b90407371923375 or eth:0xd22cA89e8991FCE568456914c616d303e3142395 depending on the supplied proof type. | |
| + | Status: CREATED |
| contract L1VerifierFflonk (eth:0x9f5C39a2790f38542065E7854b90407371923375) [shared-zk-stack/L1VerifierFflonk] | |
| +++ description: Verifies a zk-SNARK proof using an implementation of the fflonk proof system. | |
| + | Status: CREATED |
| contract L1VerifierPlonk (eth:0xd22cA89e8991FCE568456914c616d303e3142395) [shared-zk-stack/L1VerifierPlonk] | |
| +++ description: Verifies a zk-SNARK proof using an implementation of the PlonK proof system. | |
Rotated one validator.
Rotated one validator.
| contract EraMultisigValidator (eth:0xdC26B08F0335b68721F64001C38b05D0BC9B539d) [shared-zk-stack/ExecutionMultisigValidatorTimelock_Trackable] { | |
| +++ description: A multisig wrapper around `ValidatorTimelock` that requires a threshold of approvals before batch execution can proceed, provides additional security through 2FA. | |
| values.$members.3: | |
| - | "eth:0xd3cA2aDe062d453F410b5C5cfA1B2b89879AbE1b" |
| values.$members.7: | |
| + | "eth:0x2400D5d69043d9BE4fF32c6F8F28047d605ad976" |
| +++ severity: HIGH | |
| values.multisigMembers.3: | |
| - | "eth:0xd3cA2aDe062d453F410b5C5cfA1B2b89879AbE1b" |
| +++ severity: HIGH | |
| values.multisigMembers.7: | |
| + | "eth:0x2400D5d69043d9BE4fF32c6F8F28047d605ad976" |
| } | |
Rotated 4 validator multisig members.
Rotated 4 validator multisig members.
| contract EraMultisigValidator (eth:0xdC26B08F0335b68721F64001C38b05D0BC9B539d) [shared-zk-stack/ExecutionMultisigValidatorTimelock_Trackable] { | |
| +++ description: A multisig wrapper around `ValidatorTimelock` that requires a threshold of approvals before batch execution can proceed, provides additional security through 2FA. | |
| values.$members.2: | |
| - | "eth:0x8ffC957cba878cDdF446574e88Cf7e1004fc953F" |
| values.$members.3: | |
| - | "eth:0x548409daf1D6766929F3927D1Ca1df0A13129a6b" |
| values.$members.6: | |
| + | "eth:0xf6f32866b8De74683563fCCd07dE7e23431d0626" |
| values.$members.7: | |
| + | "eth:0x809bc2e1519641B482730330922950a4972a2227" |
| +++ severity: HIGH | |
| values.multisigMembers.2: | |
| - | "eth:0x8ffC957cba878cDdF446574e88Cf7e1004fc953F" |
| +++ severity: HIGH | |
| values.multisigMembers.3: | |
| - | "eth:0x548409daf1D6766929F3927D1Ca1df0A13129a6b" |
| +++ severity: HIGH | |
| values.multisigMembers.6: | |
| + | "eth:0xf6f32866b8De74683563fCCd07dE7e23431d0626" |
| +++ severity: HIGH | |
| values.multisigMembers.7: | |
| + | "eth:0x809bc2e1519641B482730330922950a4972a2227" |
| } | |
The operatorAn operator is the entity charged with managing a rollup and progressing its state. A rollup operator can be a centralized sequencer, proposer, prover, challenger, pauser of admin that is able to perform upgrades. is the only entity that can propose blocksAn ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over.. A live and trustworthy operator is vital to the health of the system.
Batch execution is initiated by permissioned executor EOAs, but each batch also requires approval from the sufficient number of EraMultisigValidator members before it can be executed on L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development..
MEV can be extracted if the operator exploits their centralized position and frontruns user transactions.
Users can be censored if the validator multisig does not approve batch execution.
If a user is censored by the L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. SequencerA party responsible for ordering and executing transactions on the rollup. The sequencer verifies transactions, compresses the data into a block, and submits the data related to it to enable state reconstruction to Ethereum L1 as a single transaction. The data can be either transaction data or state diffs., they can try to force their transaction via an L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. queue. Right now there is no mechanism that forces L2 Sequencer to include transactions from the queue in an L2 blockAn ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over.. The operatorAn operator is the entity charged with managing a rollup and progressing its state. A rollup operator can be a centralized sequencer, proposer, prover, challenger, pauser of admin that is able to perform upgrades. can implement a TransactionFilterer that censors forced transactions.
Users can be censored if the operator refuses to include their transactions.
Users can be censored if the operator implements a TransactionFilterer, which is possible without delay.
The user initiates L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups.->L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. messages by submitting a regular transaction on this chain. When the blockAn ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over. containing that transaction is settled, the message becomes available for processing on L1. ZK proofs are required to settle blocks.
If the user experiences censorship from the operatorAn operator is the entity charged with managing a rollup and progressing its state. A rollup operator can be a centralized sequencer, proposer, prover, challenger, pauser of admin that is able to perform upgrades. with regular L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups.->L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. messaging they can submit their messages directly on L1. The system is then obliged to service this request or halt all messages from L1, including all forced withdrawals and deposits. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.

A custom contract allowing a 3/3 of SecurityCouncil, ZK Foundation Multisig and Guardians to executeEmergencyUpgrade() via the ProtocolUpgradeHandler.
A Multisig with 4/7 threshold.
A Multisig with 6/8 threshold. Custom Multisig implementation that has a general threshold of 6 but also specific thresholds for upgrade approvals (4) or soft freezes (3).
A Multisig with 5/8 threshold. Custom Multisig implementation that has a general threshold of 5 and a specific threshold for extending the legal voting period of 2.
Intermediary contract between the ValidatorsIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier and the central diamond contract that delays blockAn ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over. execution (ie withdrawals and other L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. --> L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. messages) by 3h.
A Multisig with 3/8 threshold.
A multisig wrapper around ValidatorTimelock that requires a threshold of approvals before batch execution can proceed, provides additional security through 2FA.
A Multisig with 3/6 threshold.
Main Governance contract allowing for token voting (simple majority) with the ZK token through delegates. This contract is used for protocol upgrade proposals (ZIPs) that start on ZKsync Era, go through Ethereum Layer 1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. and can - from there - target all L1 and L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. contracts. At least 21M ZK tokens are necessary to start a proposal and a 630M quorum of voted tokens must be met to succeed.
Governance contract allowing for token voting (simple majority) with the ZK token through delegates. This contract is used for Token Program Proposals (TPPs) usually targeting the ZK token on ZKsync Era. At least 21M ZK tokens are necessary to start a proposal (for delegates) and a 630M quorum of voted tokens must be met to succeed.


The main contract defining the Layer 2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups.. OperatorAn operator is the entity charged with managing a rollup and progressing its state. A rollup operator can be a centralized sequencer, proposer, prover, challenger, pauser of admin that is able to perform upgrades. actions like commiting blocksAn ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over., providing ZK proofs and executing batches ultimately target this contract which then processes transactions. During batch execution it processes L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. --> L2 and L2 --> L1 transactions. isPermanentRollup was set to true in this contract which prevents changing the DA mode to ValidiumAn off-chain solution that uses validity proofs for settlement and publishes the data offchain, therefore requiring an additional trust assumption. in the future.
The main registry (hub) for all the contracts in the ZK stack cluster and central entrypoint for bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. transactions. Stores important mappings like from chainId to diamond address, from chainId to parent CTM, from chainId to base token etc. A clone of Bridgehub is also deployed on each L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. chain, but this clone is only used on settlementThe mechanism with which the execution of rollup blocks and the resultant state is verified and possible disputes are resolved. In the context of rollups or other modular blockchains, it often refers to the proof system used--validity (ZK) or fraud proofs, or a combination thereof. Sometimes it will refer to this mechanism along with where the mechanism's outputs are ultimately published and verified, as in Ethereum being a settlement layer by verifying the proofs and allowing for withdrawals. layers.
Aggregates remote bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. message roots from all ZK stack chains. To be used with the Gateway when deployed.
Asset deployment tracker where the ‘asset’ is a ChainTypeManager. The registering of asset IDs for ChainTypeManagers is necessary to be able to migrate them to a given settlementThe mechanism with which the execution of rollup blocks and the resultant state is verified and possible disputes are resolved. In the context of rollups or other modular blockchains, it often refers to the proof system used--validity (ZK) or fraud proofs, or a combination thereof. Sometimes it will refer to this mechanism along with where the mechanism's outputs are ultimately published and verified, as in Ethereum being a settlement layer by verifying the proofs and allowing for withdrawals. layer, for example the Gateway.
Contract that verifies the data availabilityThe property of a rollup's data being reachable by any node retrieving the data that were rolled up and executed to reach the proposed state. Data availability (DA), specifically decoupling it from the rollup nodes themselves, is one of the preeminent factors which allows a rollup to scale securely. A rollup is faced with a decision of what to use as a DA layer to guarantee that any node can retrieve this data--permissionlessly under any circumstance. For this reason, using Ethereum for DA currently provides the strongest security guarantees. If data is stored somewhere other than a permissionless L1, then the project is not a rollup, but rather a validium or an optimium. of ethereum calldata and blobsThe data that a rollup publishes to its L1/data availability (DA) layer. They consist of the L2 transactions that are rolled up, along with some metadata. Blobs are introduced as a new transaction type within Ethereum with EIP-4844, and has rollup scaling specifically in mind. Blobs persist on Ethereum’s Beacon Chain ephemerally.. Can be used by ZK stack rollups as the L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. part of a DAValidator pair.
Canonical central asset router for all ZK stack chains. Routes deposits and withdrawals to the respective asset handlers (like the L1NativeTokenVault); does not escrow funds itself.
Defines L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. diamond contract versions, creation and upgrade data and the proof systemThe infrastructure that allows projects to verify their state transitions. It is composed by onchain verifiers and offchain provers. The main two flavors are optimistic and ZK proof systems, but they can be combined in a hybrid model. In general though, if a system is able to accept state roots optimistically, even if it has a ZK component, it is considered an optimistic proof system. for all ZK stack chains connected to it. ZK chains are children of this central contract and can only upgrade to versions that were previously registered here. The current protocol version is 0,30,1.
Contract responsible for bookkeeping L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. bridging transactions. Used to finalize withdrawals and reclaim failed deposits. Does not escrow funds.
The central upgrade contract and Governance proxy for all ZK stack contracts. Accepts successful DAO proposals from L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. and emergency proposals from the EmergencyUpgradeBoard. The three members of the EmergencyUpgradeBoard also have special roles and permissions in this contract.
Simple registry for allowed DA address pairs for the ‘rollupA blockchain that inherits consensus and data availability from another blockchain called L1. Rollups enable trust minimized bridges with the base layer via proof systems, either optimistic or zero-knowledge. A rollup without a bridge, or without considering the bridge, is called a sovereign rollup.’ data availabilityThe property of a rollup's data being reachable by any node retrieving the data that were rolled up and executed to reach the proposed state. Data availability (DA), specifically decoupling it from the rollup nodes themselves, is one of the preeminent factors which allows a rollup to scale securely. A rollup is faced with a decision of what to use as a DA layer to guarantee that any node can retrieve this data--permissionlessly under any circumstance. For this reason, using Ethereum for DA currently provides the strongest security guarantees. If data is stored somewhere other than a permissionless L1, then the project is not a rollup, but rather a validium or an optimium. mode (can be permanently enforced with isPermanentRollup=true). Rollup DA address pairs (especially the L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. part) usually point to contracts that validate if data was made available on Ethereum.
A governance proxy that lets Matter Labs Multisig act through it.
Legacy bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. for depositing ERC20 tokens to ZKsync Era. Forwards deposits and withdrawals to the BridgeHub.
All supported tokens in this escrow are included in the value secured calculation.
BridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. for depositing wrapped stETH (Lido) to ZKsync Era. These deposits and withdrawals do not go through the shared Bridge.

Verifies a zk-SNARKShort for "succinct non-interactive argument of knowledge", a SNARK is a widely used type of zero-knowledge proof that is short and fast to verify. Different kinds of SNARKs are usually systematized by proof size, verification time, and type of setup. The most famous SNARKs are Groth16, PLONK/Marlin, Bulletproofs, and STARKs. proof using an implementation of the PlonKA zk-SNARK proving system introduced by Gabizon, Williamson and Ciobotaru in 2019 that allows proving custom circuits. Plonk is based on KZG polynomial commitments and thus requires a universal trusted setup. proof systemThe infrastructure that allows projects to verify their state transitions. It is composed by onchain verifiers and offchain provers. The main two flavors are optimistic and ZK proof systems, but they can be combined in a hybrid model. In general though, if a system is able to accept state roots optimistically, even if it has a ZK component, it is considered an optimistic proof system..
Verifies a zk-SNARKShort for "succinct non-interactive argument of knowledge", a SNARK is a widely used type of zero-knowledge proof that is short and fast to verify. Different kinds of SNARKs are usually systematized by proof size, verification time, and type of setup. The most famous SNARKs are Groth16, PLONK/Marlin, Bulletproofs, and STARKs. proof using an implementation of the fflonk proof systemThe infrastructure that allows projects to verify their state transitions. It is composed by onchain verifiers and offchain provers. The main two flavors are optimistic and ZK proof systems, but they can be combined in a hybrid model. In general though, if a system is able to accept state roots optimistically, even if it has a ZK component, it is considered an optimistic proof system..
A router contract for verifiers. Routes verification requests to EraVerifierFflonk or EraVerifierPlonk depending on the supplied proof type.
Canonical central asset escrow for all ZK stack chains.
All supported tokens in this escrow are included in the value secured calculation.
Specialized contract for managing chain assets, i.e. chain migrations.
A simple contract that can be called by the ChainAdmin to emit notifications about chain migrations.
Timelock contract allowing the queueing of transactions with a minimum delay of 0s.
The ZK token contract on ZKsync Era. Mintable through access control roles. Used for voting in the ZK stack governance system.
Timelock contract allowing the queueing of transactions with a minimum delay of 3d.
The current deployment carries some associated risks:
Funds can be stolen if a contract receives a malicious code upgrade. There is a 4d 3h - 8d 3h delay on code upgrades unless upgrade is initiated by the EmergencyUpgradeBoard in which case there is no delay.
Name | Hash | Repository | Verification | Used in | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
0x0100...51e6 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||