ZKsync Era
Badges
About
ZKsync Era is a general-purpose ZK Rollup with full EVM compatibility.
Badges
About
ZKsync Era is a general-purpose ZK Rollup with full EVM compatibility.
2024 May 03 — 2025 May 03
2024 May 03 — 2025 May 02
The section shows the operating costs that L2s pay to Ethereum.
2024 May 03 — 2025 May 02
ZK token minter key compromised
2025 Apr 13th
1/1 signer key of a ZK airdrop admin multisig is compromised. ZKsync deploys TransactionFilterer.
Onchain Governance Launch
2024 Sep 12th
An onchain Governance system is introduced, including a Security Council and Guardians.
Funds can be stolen if
Funds can be lost if
Users can be censored if
MEV can be extracted if
Users can submit transactions to an L1 queue, but can’t force them. The sequencers cannot selectively skip transactions but can stop processing the queue entirely. In other words, if the sequencers censor or are down, they are so for everyone.
STARKs and SNARKs are zero knowledge proofs that ensure state correctness. STARKs proofs are wrapped in SNARKs proofs for efficiency. SNARKs require a trusted setup.
All of the data (SD = state diffs) needed for proof construction is published onchain.
There is no window for users to exit in case of an unwanted standard upgrade because the central operator can censor withdrawal transactions by implementing a TransactionFilterer with no delay. The standard upgrade delay is 4d 3h.
Only the whitelisted proposers can publish state roots on L1, so in the event of failure the withdrawals are frozen. There is a decentralized Governance system that can attempt changing Proposers with an upgrade.
ZKsync Era is a All data required for proofs is published on chain
All the data that is used to construct the system state is published on chain in the form of cheap blobs or calldata. This ensures that it will be available for enough time.
EthereumThe node software is open-source, and its source code can be found here. The main node software does not rely on Layer 1 (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.
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 system Boojum can be found here and contains essential tools like the Prover, the Verifier, and other backend components. The specs of the system can be found here.
The system has a centralized operator
The operator is the only entity that can propose blocks. A live and trustworthy operator is vital to the health of the system.
MEV can be extracted if the operator exploits their centralized position and frontruns user transactions.
Users can force any transaction via L1
If a user is censored by the L2 Sequencer, they can try to force their transaction via an L1 queue. Right now there is no mechanism that forces L2 Sequencer to include transactions from the queue in an L2 block. The operator 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.
Regular messaging
Forced messaging
If the user experiences censorship from the operator with regular L2->L1 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.
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 6 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.
Standard path
On ZKsync Era
Delegates can start new proposals by reaching a threshold of 21M ZK tokens on the ZKsync Era 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 proposer 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 to Ethereum as an L2->L1 log.
On Ethereum
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 30d, from which it can be immediately approved (cancelling the delay) by 6 participants of the SecurityCouncil. For the unlikely case that the SC 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.
Other governance tracks
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.
Emergency path
SecurityCouncil (9/12), Guardians (5/8) and ZkFoundationMultisig (3/5) 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.
Upgrade Delays
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 34d 3h for the path in which the SecurityCouncil is not approving the proposal.
Freezing
The SecurityCouncil can freeze (pause withdrawals and settlement) 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.
ZK cluster Admin and Chain Admin
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 that 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 Validators in the ValidatorTimelock. For rollups, data availability on Ethereum is validated by a RollupL1DAValidator contract. Each rollup can become a permanent rollup (through their Chain Admin) which disallows any DA change to a non-whitelisted source 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.
Ethereum
Roles:
Permissioned to call the functions to commit, prove, execute and revert L2 batches through the ValidatorTimelock in the main Diamond contract.
Actors:
- A custom contract allowing a 3/3 of SecurityCouncil, ZK Foundation Multisig and Guardians to
executeEmergencyUpgrade()via the ProtocolUpgradeHandler. - Can act on behalf of ProtocolUpgradeHandler.
- Is allowed to interact with BridgeHub - set critical system contract addresses, register settlement layers, pause and unpause and manage zk chain registration - acting via ProtocolUpgradeHandler.
- Is allowed to interact with ChainTypeManager - manage the shared ValidatorTimelock contract address and the admin role, register and execute upgrades (and set their deadlines), freeze, revert batches and set permissioned validators and fee params for all connected chains - acting via ProtocolUpgradeHandler.
- Is allowed to interact with L1Nullifier - pause, unpause and set critical escrow address references - acting via ProtocolUpgradeHandler.
- Is allowed to interact with RollupDAManager - manage allowed rollup DA pairs (allowed to be used by rollups in permanent rollup mode) - acting via ProtocolUpgradeHandler.
- Can upgrade the implementation of BridgeHub, MessageRoot, CTMDeploymentTracker, L1AssetRouter, L1NativeTokenVault, ChainTypeManager, L1Nullifier, ProtocolUpgradeHandler - acting via ProxyAdmin, ProtocolUpgradeHandler.
Used in:
- A Multisig with 5/8 threshold.
- Can act on behalf of EraAdminProxy.
- Is allowed to interact with BridgeHub - create new zk chains (based on the current version), register tokens (ZK cluster Admin role) - acting via EraAdminProxy.
- Is allowed to interact with ChainTypeManager - revert batches for any connected chain (ZK cluster Admin role) - acting via EraAdminProxy.
Participants (8):
0x4A33…C9290x3F00…c4810x8A23…D6740x3068…d2Bc0x702c…78b70xFAdb…79AE0xfd03…aEd20x700D…F1dfUsed in:
- 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.
- Is allowed to interact with ProtocolUpgradeHandler - extend the legal veto period, approve a protocol upgrade.
- Is allowed to interact with EmergencyUpgradeBoard - one of its 3/3 signers.
Used in:
- A Multisig with 9/12 threshold.
- Custom Multisig implementation that has a general threshold of 9 but also specific thresholds for upgrade approvals (6) or soft freezes (3).
- Is allowed to interact with ProtocolUpgradeHandler - soft freeze, hard freeze, approve a protocol upgrade.
- Is allowed to interact with EmergencyUpgradeBoard - one of its 3/3 signers.
Participants (12):
GnosisSafeGnosisSafeGnosisSafeGnosisSafeGnosisSafeGnosisSafeGnosisSafeGnosisSafeGnosisSafeGnosisSafeGnosisSafeGnosisSafeUsed in:
- Intermediary contract between the Validators and the central diamond contract that delays block execution (ie withdrawals and other L2 --> L1 messages) by 3h.
- Is allowed to interact with ZKsync - commit, prove, execute, revert batches directly in the main Diamond contract. This role is typically held by a proxying ValidatorTimelock.
Used in:
- Intermediary contract between the Validators and the central diamond contract that delays block execution (ie withdrawals and other L2 --> L1 messages) by 3h.
- Is allowed to interact with ZKsync - commit, prove, execute, revert batches directly in the main Diamond contract. This role is typically held by a proxying ValidatorTimelock.
Used in:
- A Multisig with 3/5 threshold.
- Is allowed to interact with EmergencyUpgradeBoard - one of its 3/3 signers.
Used in:
- Old Governance contract for ZKsync Era allowing for proposals in form of transactions. The minimum delay is 0s.
- Is allowed to interact with ValidatorTimelock3 - set addresses (validators) that can commit, prove, execute, revert batches through this contract.
Is allowed to interact with ProtocolUpgradeHandler - start (queue) upgrades.
Used in:
ZKsync Era
Actors:
- A token governance contract that allows token holders to create and vote on proposals. At least 21M tokens are necessary to start a proposal and a 630M quorum of voted tokens must be met to succeed. The accepted token is ZkToken.
- Can act on behalf of ZkTokenTimelockController with 3d delay.
- Is allowed to interact with ZkToken - grant the MINTER_ROLE to arbitrary addresses, thus controlling the minting of the ZK token - acting via ZkTokenTimelockController with 3d delay.
- Is allowed to interact with ZkTokenTimelockController - manage all access control roles and change the minimum delay with 3d delay - acting via ZkTokenTimelockController with 3d delay.
- Is allowed to interact with ZkTokenTimelockController - cancel queued transactions.
- Is allowed to interact with ZkTokenTimelockController - execute transactions that are ready.
- Is allowed to interact with ZkTokenTimelockController - propose transactions.
Used in:
- A token governance contract that allows token holders to create and vote on proposals. At least 21M tokens are necessary to start a proposal and a 630M quorum of voted tokens must be met to succeed. The accepted token is ZkToken.
- Can act on behalf of GovOpsTimelockController with 3d delay.
- Is allowed to interact with GovOpsTimelockController - manage all access control roles and change the minimum delay with 3d delay - acting via GovOpsTimelockController with 3d delay.
- Is allowed to interact with GovOpsTimelockController - cancel queued transactions.
- Is allowed to interact with GovOpsTimelockController - execute transactions that are ready.
- Is allowed to interact with GovOpsTimelockController - propose transactions.
Used in:
- A token governance contract that allows token holders to create and vote on proposals. At least 21M tokens are necessary to start a proposal and a 630M quorum of voted tokens must be met to succeed. The accepted token is ZkToken.
- Can act on behalf of TokenTimelockController_deprecated with 3d delay.
- Is allowed to interact with TokenTimelockController_deprecated - manage all access control roles and change the minimum delay with 3d delay - acting via TokenTimelockController_deprecated with 3d delay.
- Is allowed to interact with TokenTimelockController_deprecated - cancel queued transactions.
- Is allowed to interact with TokenTimelockController_deprecated - execute transactions that are ready.
- Is allowed to interact with TokenTimelockController_deprecated - propose transactions.
Used in:
- A token governance contract that allows token holders to create and vote on proposals. At least 21M tokens are necessary to start a proposal and a 630M quorum of voted tokens must be met to succeed. The accepted token is ZkToken.
- Can act on behalf of GovOpsTimelockController_deprecated with 3d delay.
- Is allowed to interact with GovOpsTimelockController_deprecated - manage all access control roles and change the minimum delay with 3d delay - acting via GovOpsTimelockController_deprecated with 3d delay.
- Is allowed to interact with GovOpsTimelockController_deprecated - cancel queued transactions.
- Is allowed to interact with GovOpsTimelockController_deprecated - execute transactions that are ready.
- Is allowed to interact with GovOpsTimelockController_deprecated - propose transactions.
Used in:
- A token governance contract that allows token holders to create and vote on proposals. At least 21M tokens are necessary to start a proposal and a 630M quorum of voted tokens must be met to succeed. The accepted token is ZkToken.
- Can act on behalf of ProtocolTimelockController, ProtocolTimelockController_deprecated.
- Is allowed to interact with ProtocolTimelockController, ProtocolTimelockController_deprecated - cancel queued transactions.
- Is allowed to interact with ProtocolTimelockController, ProtocolTimelockController_deprecated - execute transactions that are ready.
- Is allowed to interact with ProtocolTimelockController - manage all access control roles and change the minimum delay - acting via ProtocolTimelockController.
- Is allowed to interact with ProtocolTimelockController, ProtocolTimelockController_deprecated - propose transactions.
- Is allowed to interact with ProtocolTimelockController_deprecated - manage all access control roles and change the minimum delay - acting via ProtocolTimelockController_deprecated.
Used in:
Is allowed to interact with ZkTokenGovernor, ZkGovOpsGovernor - cancel proposals while they are pending (after having been proposed) or active (during the voting period).
Used in:
Is allowed to interact with ZkTokenGovernor - make direct proposals without owning ZK tokens. In propose-guarded mode, this address is the ONLY allowed proposer. Propose-guarded mode is currently set to false.
Used in:
Can upgrade the implementation of ZkToken - acting via ZkTokenProxyAdmin.
Used in:
Is allowed to interact with ZkToken - control all roles in the ZkToken access control, including the minter roles.
Used in:
Ethereum
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. This contract stores the following tokens: ETH.
Implementation used in:
The main registry (hub) for all the contracts in the ZK stack cluster and central entrypoint for 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 L2 chain, but this clone is only used on settlement layers.
Proxy used in:
Aggregates remote bridge message roots from all ZK stack chains. To be used with the Gateway when deployed.
Proxy used in:
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 settlement layer, for example the Gateway.
Proxy used in:
Contract that verifies the data availability of ethereum calldata and blobs. Can be used by ZK stack rollups as the L1 part of a DAValidator pair.
Proxy used in:
Defines L2 diamond contract versions, creation and upgrade data and the 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,27,0.
Proxy used in:
Contract responsible for bookkeeping L1 bridging transactions. Used to finalize withdrawals and reclaim failed deposits. Does not escrow funds.
Proxy used in:
- The central upgrade contract and Governance proxy for all ZK stack contracts. Accepts successful DAO proposals from L2 and emergency proposals from the EmergencyUpgradeBoard. The three members of the EmergencyUpgradeBoard also have special roles and permissions in this contract.
- Can act on behalf of ProxyAdmin, ProxyAdmin.
- Can be used to interact with BridgeHub - set critical system contract addresses, register settlement layers, pause and unpause and manage zk chain registration.
- Can be used to interact with ChainTypeManager - manage the shared ValidatorTimelock contract address and the admin role, register and execute upgrades (and set their deadlines), freeze, revert batches and set permissioned validators and fee params for all connected chains.
- Can be used to interact with L1Nullifier - pause, unpause and set critical escrow address references.
- Can be used to interact with RollupDAManager - manage allowed rollup DA pairs (allowed to be used by rollups in permanent rollup mode).
Proxy used in:
Simple registry for allowed DA address pairs for the ‘rollup’ data availability mode (can be permanently enforced with isPermanentRollup=true). Rollup DA address pairs (especially the L1 part) usually point to contracts that validate if data was made available on Ethereum.
Proxy used in:
- Can be used to interact with BridgeHub - create new zk chains (based on the current version), register tokens (ZK cluster Admin role).
- Can be used to interact with ChainTypeManager - revert batches for any connected chain (ZK cluster Admin role).
Proxy used in:
Legacy bridge for depositing ERC20 tokens to ZKsync Era. Forwards deposits and withdrawals to the BridgeHub. This contract can store any token.
Can be used to upgrade implementation of ProtocolUpgradeHandler.
Proxy used in:
Can be used to upgrade implementation of BridgeHub, MessageRoot, CTMDeploymentTracker, L1AssetRouter, L1NativeTokenVault, ChainTypeManager, L1Nullifier.
Proxy used in:
ZKsync Era
- Timelock contract allowing the queueing of transactions with a minimum delay of 0s.
- Can be used to interact with ProtocolTimelockController - manage all access control roles and change the minimum delay.
Proxy used in:
The ZK token contract on ZKsync Era. Mintable through access control roles. Used for voting in the ZK stack governance system.
Proxy used in:
- Timelock contract allowing the queueing of transactions with a minimum delay of 3d.
- Can be used to interact with GovOpsTimelockController - manage all access control roles and change the minimum delay with 3d delay.
Proxy used in:
- Timelock contract allowing the queueing of transactions with a minimum delay of 3d.
- Can be used to interact with ZkToken - grant the MINTER_ROLE to arbitrary addresses, thus controlling the minting of the ZK token.
- Can be used to interact with ZkTokenTimelockController - manage all access control roles and change the minimum delay with 3d delay.
Proxy used in:
Value Secured is calculated based on these smart contracts and tokens:
Shared bridge for depositing tokens to ZKsync Era and other ZK stack chains.
Legacy bridge for depositing ERC20 tokens to ZKsync Era. Forwards deposits and withdrawals to the BridgeHub.
Bridge for depositing wrapped stETH (Lido) to ZKsync Era. These deposits and withdrawals do not go through the new shared BridgeHub.
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.