Search

Search for projects by name

ZERO Network logoZERO Network

Badges

About

ZERO Network is an L2 by the Zerion wallet team, utilizing the ZK stack and native account abstraction, allowing Zerion wallet users gasless and prioritized transactions.


Value Locked
$4.77 M37.7%
Canonically Bridged
$4.77 M
Externally Bridged
$0.00
Natively Minted
$0.00

  • Tokens
  • Daily UOPS
    0.1923.3%
  • 30D tx count
    1.08 M

  • Stage
    Stage 0
  • Type
    ZK Rollup
  • Purpose
    Universal
  • Sequencer failureState validationData availabilityExit windowProposer failure

    Badges

    About

    ZERO Network is an L2 by the Zerion wallet team, utilizing the ZK stack and native account abstraction, allowing Zerion wallet users gasless and prioritized transactions.


    Value Locked
    Activity
    Milestones & Incidents

    Mainnet launch

    2024 Nov 12th

    ZERϴ launches their mainnet.

    Learn more
    Risk summary
    Risk analysis
    Sequencer failureState validationData availabilityExit windowProposer failure

    Sequencer failure

    Enqueue via L1

    Users can submit transactions to an L1 queue, but can’t force them. The sequencer cannot selectively skip transactions but can stop processing the queue entirely. In other words, if the sequencer censors or is down, it is so for everyone.

    State validation

    ZK proofs (ST, SN)

    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.

    Data availability

    Onchain (SD)

    All of the data (SD = state diffs) needed for proof construction is published onchain.

    Exit window

    None

    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 21h.

    Proposer failure

    Cannot withdraw

    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.

    Rollup stage
    ZERO NetworkZERO Network is a
    Stage 0
    ZK Rollup.

    Learn more about Rollup stages
    Please keep in mind that these stages do not reflect rollup security, this is an opinionated assessment of rollup maturity based on subjective criteria, created with a goal of incentivizing projects to push toward better decentralization. Each team may have taken different paths to achieve this goal.
    Technology

    Zero knowledge STARK and SNARK cryptography is used

    Despite their production use zkSTARKs and zkSNARKs proof systems are still relatively new, complex and they rely on the proper implementation of the polynomial constraints used to check validity of the Execution Trace. In addition zkSNARKs require a trusted setup to operate.

    • Funds can be lost if the proof system is implemented incorrectly.

    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.

    State derivation
    Node software

    The 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.

    Compression scheme

    Bytecodes undergo compression before deployment on Layer 1 (L1). You can find additional information on this process here.

    Genesis state

    There have been neither genesis states nor regenesis.

    Data format

    Details on data format can be found here.

    State validation

    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.


    Prover Architecture

    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.

    ZK Circuits

    ZKsync Era circuits are built from Boojum and are designed to replicate the behavior of the EVM. The source code can be found here. The circuits are checked against tests that can be found here.

    • Funds can be lost if the proof system is implemented incorrectly.

    Verification Keys Generation

    SNARK verification keys can be generated and checked against the Ethereum verifier contract using this tool. The system requires a trusted setup.

    Operator

    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.

    1. L1 - L2 interoperability - Developer's documentation
    Withdrawals

    Regular exit

    The user initiates the withdrawal by submitting a regular transaction on this chain. When the block containing that transaction is proven the funds become available for withdrawal on L1. Finally the user submits an L1 transaction to claim the funds. This transaction requires a merkle proof.

    1. Withdrawing funds - ZKsync documentation

    Forced exit

    If the user experiences censorship from the operator with regular exit they can submit their withdrawal requests 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 exit.

    Upgrades & Governance
    A diagram of the upgrades and governance
    A diagram of the upgrades and governance

    There are two main paths for contract upgrades in the shared ZK stack ecosystem - standard and emergency - both converging on the shared upgrade proxy 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 7d ‘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, the voting period is reset to 7d. 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 (21h 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 be expired 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 21h or 8d 21h (depending on Guardians extending the LegalVetoPeriod) for Standard, 0 for Emergency and 34d 21h 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 StateTransitionManager. 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.

    Elastic Chain Operator and ChainAdmin

    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 Elastic Chain operator role that governs parameters in the shared contracts and a ChainAdmin role (in the chain-specific diamond contract) for managing parameters of each individual Hyperchain that builds on the stack. These chain-specific actions include setting a transaction filterer that can censor L1 -> L2 messages, setting fee parameters and adding / removing Validators in the ValidatorTimelock. ZKsync Era’s ChainAdmin differs from the others as it also has the above Elastic Chain Operator role in the shared ZK stack contracts.

    Permissions

    The system uses the following set of permissioned addresses:

    SecurityCouncil 0xBDFf…De0D

    One of the three signers of the EmergencyUpgradeBoard. Can freeze all ZK stack chains. Can approve governance proposals in the ProtocolUpgradeHandler. The default threshold for the members of this contract is 9 / 12 but is customized for certain actions.

    Used in:

    Guardians 0xD677…A888

    Is one of the three signers of the EmergencyUpgradeBoard. Can extend the legal veto period and / or approve governance proposals in the ProtocolUpgradeHandler. Permissioned to cancel non-protocolUpgrade proposals on L2. The default threshold for the members of this contract is 5 / 8 but is customized for certain actions.

    Used in:

    Members of the Guardians contract, usually 1/1 Gnosis multisigs themselves.

    1. ZKsync Guardians - ZK Nation docs
    ZkFoundationMultisig 0xbC16…B51c

    A Gnosis Safe with 3 / 5 threshold. Is one of the three signers of the EmergencyUpgradeBoard.

    Used in:

    Those are the participants of the ZkFoundationMultisig.

    ProtocolUpgradeHandler 0x8f7a…1897

    Owner and upgrade Admin of all shared ZK stack contracts. Can also upgrade the individual Hyperchain diamond contracts.

    Used in:

    Matter Labs Multisig Elastic Chain Operator

    A Gnosis Safe with 4 / 7 threshold. Has the ChainAdmin role in the ZKsync Era diamond and the Elastic Chain Operator role in the shared contracts.

    Used in:

    Those are the participants of the Matter Labs Multisig.

    Elastic Chain Operator Matter Labs Multisig

    Can change the ValidatorTimelock in the StateTransitionManager, manage validators of the Hyperchain diamonds, revert batches and create new Hyperchains.

    Used in:

    ChainAdmin 0xCA8f…73b3

    Can manage fees, apply predefined upgrades and censor bridge transactions (ChainAdmin role).

    Diamond Contract Validators 0x5D8b…d06E

    Addresses permissioned to call the functions to propose, execute and revert L2 batches in the ZERO Network diamond. Usually these are addresses of proxying ValidatorTimelock contracts.

    Used in:

    ValidatorTimelock Validators (2) 0x0F9B…CB2F0x479B…73B9

    Actors that are allowed to propose, execute and revert L2 batches on L1 through the ValidatorTimelock.

    ZeroNetworkChainAdminMultisig 0x2e5B…D6a9

    A Gnosis Safe with 3 / 5 threshold. Inherits ChainAdmin permissions like adding/removing validators in the ValidatorTimelock, adding a TransactionFilterer that can censor transactions, upgrading the ZERϴ Diamond to a predeployed version of the ZK stack and settings its fee parameters.

    ZeroNetworkChainAdminMultisig participants (5) 0xA167…813E0xc858…fEC90xF322…52770x3Bc7…52550x3Ec9…70e1

    Those are the participants of the ZeroNetworkChainAdminMultisig.

    ZeroNetworkOracleEOA 0x0000…0000

    Can set the conversion factor for SOPH deposits to ZERϴ.

    The system consists of the following permissions on ZKsync Era:

    ZkFoundationMultisig L2 alias 0xcd27…C62D

    The Layer2 alias address through which the ZkFoundationMultisig can act.

    Guardians L2 alias 0xe788…b999

    The Layer2 alias address through which the Guardians contract can act.

    ProtocolUpgradeHandler L2 alias 0xA08b…29A8

    The Layer2 alias address through which the ProtocolUpgradeHandler contract can act.

    Veto Guardian TokenGovernor 0xe788…b999

    This address can cancel proposals in the ZkTokenGovernor while they are pending (after having been proposed) or active (during the voting period).

    Propose Guardian TokenGovernor 0xcd27…C62D

    This address can make direct proposals in the ZkTokenGovernor without owning ZK tokens.

    ZK Token upgrade Admin 0xA08b…29A8

    Can upgrade the ZK token contract, affecting all holders of the ZK token.

    ZK Token minter Admin 0x3E21…dDd6

    Can add and remove minters from the ZK token contract and mint unlimited amounts.

    Veto Guardian GovOpsGovernor 0xe788…b999

    This address can cancel proposals in the ZkGovOpsGovernor while they are pending (after having been proposed) or active (during the voting period).

    Smart contracts

    The system consists of the following smart contracts on the host chain (Ethereum):

    The main Rollup contract. The operator commits blocks and provides a ZK proof which is validated by the Verifier contract then processes transactions. During batch execution it processes L1 --> L2 and L2 --> L1 transactions.

    Can be upgraded by:

    Upgrade delay: 4d 21h via the standard upgrade path, but immediate through the EmergencyUpgradeBoard.

    Implementation used in:

    ZeroNetworkZkEvmAdmin 0xCA8f…73b3

    Intermediary governance contract that has the ChainAdmin role in the ZERϴ zkEVM diamond contract.

    ValidatorTimelock 0x5D8b…d06E

    Intermediary contract between the Validators and the ZKsync Era diamond that delays block execution (ie withdrawals and other L2 --> L1 messages) by 21h.

    Implementation used in:

    Verifier 0x70F3…9604

    Implements ZK proof verification logic.

    Implementation used in:

    SecurityCouncil 0xBDFf…De0D

    Custom contract acting as a Multisig. The default threshold for the members of this contract is 9 / 12 but is customized for certain actions.

    Implementation used in:

    Guardians 0xD677…A888

    Custom contract acting as a Multisig. The default threshold for the members of this contract is 5 / 8 but is customized for certain actions.

    Implementation used in:

    ProtocolUpgradeHandler 0x8f7a…1897

    The central upgrade contract and Governance proxy for all ZK stack contracts. Accepts successful DAO proposals from L2 and emergency proposals from the EmergencyUpgradeBoard.

    Implementation used in:

    This bridge contract escrows all ERC-20s and ETH that are deposited to registered ZK stack chains like ZKsync Era. This contract stores the following tokens: ETH, USDC.

    Can be upgraded by:

    Upgrade delay: 4d 21h via the standard upgrade path, but immediate through the EmergencyUpgradeBoard.

    Proxy used in:

    Sits between the single shared bridge and the StateTransitionManager(s) and relays L1 <-> L2 messages from the shared bridge or other ZK stack chains to their respective destinations.

    Can be upgraded by:

    Upgrade delay: 4d 21h via the standard upgrade path, but immediate through the EmergencyUpgradeBoard.

    Proxy used in:

    Defines L2 diamond contract creation and upgrade data, proof verification for the ZKsync diamond contract connected to it (and other L2 diamond contracts that share the logic).

    Can be upgraded by:

    Upgrade delay: 4d 21h via the standard upgrade path, but immediate through the EmergencyUpgradeBoard.

    Proxy used in:

    The system consists of the following smart contracts on ZKsync Era:

    ZkProtocolGovernor 0x7670…e34f

    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 go through Ethereum Layer 1 and can target all L1 and L2 contracts. At least 21M ZK tokens are necessary to start a proposal and a 630M quorum of voted tokens must be met to succeed. Can queue and execute proposals in the ProtocolTimelockController.

    ProtocolTimelockController 0x3701…e6A8

    Timelock contract that can send L2->L1 logs that start a proposal in the ProtocolUpgradeHandler on Ethereum. This timelock has no minimum delay

    ZkTokenGovernor 0x1056…6E89

    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. 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. Can queue and execute proposals in the TokenTimelockController.

    TokenTimelockController 0x3E21…dDd6

    This timelock contract has 3d minimum delay

    ZkGovOpsGovernor 0x4968…afAb

    Governance contract allowing for token voting (simple majority) with the ZK token through delegates. This contract is used for Governance Advisory Proposals (GAPs) that are not executable onchain. At least 21M ZK tokens are necessary to start a proposal and a 630M quorum of voted tokens must be met to succeed. Can queue and execute proposals in the GovOpsTimelockController.

    GovOpsTimelockController 0xC3e9…7a19

    This timelock contract has 3d minimum delay

    The ZK token contract on ZKsync Era. Used for voting in the ZK stack governance system.

    Can be upgraded by:

    Upgrade delay: 4d 21h via the standard upgrade path, but immediate through the EmergencyUpgradeBoard.

    Value Locked is calculated based on these smart contracts and tokens:

    Shared bridge for depositing tokens to ZERϴ and other ZK stack chains.

    Can be upgraded by:

    Upgrade delay: 4d 21h via the standard upgrade path, but immediate through the EmergencyUpgradeBoard.

    Proxy used in:

    The current deployment carries some associated risks:

    • Funds can be stolen if a contract receives a malicious code upgrade. There is a 4d 21h - 8d 21h delay on code upgrades unless upgrade is initiated by the EmergencyUpgradeBoard in which case there is no delay.

    Knowledge nuggets