Search

Search for projects by name or address

SummaryActivityOnchain costsData postedLivenessMilestones & IncidentsRisk summaryRisk analysisStageData availabilityState validationUpgrades & GovernanceUpdatesOperatorWithdrawalsPermissionsSmart contracts

Treasure logo
Treasure

This project is archived and no longer maintained.

The project had a planned shutdown after a governance vote.

Badges

About

Treasure is a gaming-specific L2 built on ZKsync, the Elastic Network. Treasure offers an end-to-end tech stack for developers and consumer apps to build the next generation of gaming.

  • Total Value SecuredTVS
    No data
  • Past day UOPSDaily UOPS
    No data
  • Gas token
    ETH
  • Type
    Other
  • Purposes
    Universal, Gaming

    • Tokens breakdown

    Value secured breakdown

    View TVS breakdown
    Sequencer failureState validationData availabilityExit windowProposer failure
    Explore more in Discovery UI

    Badges

    About

    Treasure is a gaming-specific L2 built on ZKsync, the Elastic Network. Treasure offers an end-to-end tech stack for developers and consumer apps to build the next generation of gaming.

    Why is the project listed in others?

    There is no data availability bridge

    Consequence: projects without a data availability bridge fully rely on single entities (the sequencer) to honestly rely available data roots on Ethereum. A malicious sequencer can collude with the proposer to finalize an unavailable state, which can cause loss of funds.

    Learn more about the recategorisation here.

    Activity

    Past Day UOPS
    Past Day Ops count
    Max. UOPS
    Past day UOPS/TPS Ratio

    Onchain costs

    The section shows the operating costs that L2s pay to Ethereum.

    Total cost
    Avg cost per L2 UOP
    Avg cost per day

    Data posted

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

    Data posted
    Avg size per day
    Avg size per L2 UOP

    Liveness

    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.

    Avg. proof subs. interval
    Avg. state updates interval

    Milestones & Incidents

    Mainnet Launch

    2024 Dec 11th

    Treasure mainnet launches for all users.

    Learn more

    Risk summary

    Funds can be stolen if

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

    Funds can be lost if

    1. the external data becomes unavailable (CRITICAL),
    2. the proof system is implemented incorrectly.

    Users can be censored if

    1. the operator refuses to include their transactions,
    2. the operator implements a TransactionFilterer, which is possible without delay.

    MEV can be extracted if

    1. the operator exploits their centralized position and frontruns user transactions.

    Risk analysis

    Sequencer failureState validationData availabilityExit windowProposer failure
    Sequencer failure
    Enqueue via L1

    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.

    State validation
    Validity 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 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..

    Data availability
    External

    Proof construction and state derivation rely fully on data that is NOT published onchain.

    Exit window
    None (emergency upgrade path)
    4d 3h (regular upgrade path)

    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.

    Proposer failure
    Replace proposer

    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.

    Stage

    Treasure
    Treasure is not even a
    Stage 0
    project.
    Learn more about Stages
    Please keep in mind that these stages do not reflect project security, this is an opinionated assessment of project 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.

    Data availability

    Data is not stored on chain

    The transaction data is not recorded on the Ethereum main chain. Transaction data is stored off-chain and only the hashes are posted onchain by the centralized 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..

    • Funds can be lost if the external data becomes unavailable (CRITICAL).

    1. ExecutorFacet - _commitOneBatch() function

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

    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

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

    Program Hashes

    Name
    Hash
    Repository
    Verification
    Used in
    0x0100...2a81
    Github
    Treasure logo

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

    Standard path

    On ZKsync Era

    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.

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

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

    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 1mo 4d for the path in which the SecurityCouncil is not approving the proposal.

    Freezing

    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.

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

    Past upgrades

    The metrics include upgrades on the currently used proxy contracts. Historical proxy contracts and changes of such are not included.

    Count of upgrades
    34
    Last upgrade
    2mo 9d ago
    Avg upgrade interval
    5mo 18d

    Updates

    2025 July 14, 12:47 UTC
    7changes

    Discovery rerun on the same block number with only config-related changes.

    Discovery rerun on the same block number with only config-related changes.

    New and verified contracts

    + Status: CREATED
    contract TreasureChainAdminMultisig (0x282370D1e925ee897CB29Cb3beC13aAe0743067C)
    +++ description: None
    + Status: CREATED
    contract ValidatorTimelock2 (0x5D8ba173Dc6C3c90C8f7C04C9288BeF5FDbAd06E)
    +++ description: Intermediary contract between the *Validators* and the central diamond contract that delays block execution (ie withdrawals and other L2 --> L1 messages) by 3h.
    + Status: CREATED
    contract TreasureZkEvm (0x5e64D248Eab336AB3Fd0BeC0CFe31D4AAE32E879)
    +++ 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.
    + Status: CREATED
    contract ValidatorTimelock (0x8c0Bfc04AdA21fd496c55B8C50331f904306F564)
    +++ description: Intermediary contract between the *Validators* and the central diamond contract that delays block execution (ie withdrawals and other L2 --> L1 messages) by 3h.
    + Status: CREATED
    contract ValidiumL1DAValidator (0x907b30407249949521Bf0c89A43558dae200146A)
    +++ description: Contract that 'verifies' the data availability for validiums. This implementation only checks the correct formatting and does not serve as a DA oracle. Can be used by ZK stack validiums as the L1 part of a DAValidator pair.
    + Status: CREATED
    contract TreasureZkEvmAdmin (0x97440Bf040f0dfA402cf5D4F1e0f574309Ace871)
    +++ description: None
    + Status: CREATED
    contract Verifier (0xdb3300726556AFA413A11aF474a8cFDa4D7fc5a5)
    +++ description: Implements the ZK proof verification logic.
    2025 April 02, 15:08 UTC
    1change

    shared zk stack contracts upgraded to v26: config related changes for all children chains.

    shared zk stack contracts upgraded to v26: config related changes for all children chains.

    New and verified contracts

    + Status: CREATED
    contract ValidiumL1DAValidator (0x907b30407249949521Bf0c89A43558dae200146A)
    +++ description: Contract that 'verifies' the data availability for validiums. This implementation only checks the correct formatting and does not serve as a DA oracle. Can be used by ZK stack validiums as the L1 part of a DAValidator pair.
    2025 March 31, 11:37 UTC
    4changes

    MS signer change.

    MS signer change.

    contract TreasureChainAdminMultisig (0x282370D1e925ee897CB29Cb3beC13aAe0743067C) {
    +++ description: None
    values.$members.5:
    - "0x18c16E72CAa10D2Ce13E4b61bfC51AB93B7e92f0"
    values.$members.4:
    - "0x1ee4324F7BD44A4c7c335C2D4e758639B60E8726"
    + "0x18c16E72CAa10D2Ce13E4b61bfC51AB93B7e92f0"
    values.$members.3:
    - "0xe25AdA29FA5873A24afEe1342422BD14e5809e03"
    + "0x1ee4324F7BD44A4c7c335C2D4e758639B60E8726"
    values.multisigThreshold:
    - "4 of 6 (67%)"
    + "4 of 5 (80%)"
    }
    2025 March 28, 10:52 UTC
    High severity
    61changes

    v26 upgrade.

    v26 upgrade.

    - Status: DELETED
    contract Verifier (0x06aa7a7B07108F7C5539645e32DD5c21cBF9EB66)
    +++ description: Implements the ZK proof verification logic.
    contract undefined (0x2572835e02b59078711aa0800490e80975e4169d) {
    +++ description: None
    receivedPermissions.1:
    + {"permission":"validateZkStack","from":"0x8c0Bfc04AdA21fd496c55B8C50331f904306F564"}
    }
    contract undefined (0x4131719fb0FA1CB3e3A052A4A309ea7575d8c283) {
    +++ description: None
    receivedPermissions.1:
    + {"permission":"validateZkStack","from":"0x8c0Bfc04AdA21fd496c55B8C50331f904306F564"}
    }
    contract TreasureZkEvm (0x5e64D248Eab336AB3Fd0BeC0CFe31D4AAE32E879) {
    +++ 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.
    template:
    - "shared-zk-stack/Diamond"
    + "shared-zk-stack/Diamond_v26"
    sourceHashes.4:
    - "0xdf47c6cd4fcffcfa4a670e1544e2391acc365cd7fd9b8e7583d58b28dff50c40"
    + "0xf3a1cb3dd9315b2dfa9e9aca6d6b09e987a1eb463588f115e2eb142eaa2a4ac6"
    sourceHashes.3:
    - "0x91db58e4059dfed7357e56dac17d2963c6f9cfb540f527988ed25172251a2584"
    + "0xcd2dee9d49d75aa37138514c1f32d29c60222002963e0c0a7e1a815dff00444f"
    sourceHashes.2:
    - "0xcd2dee9d49d75aa37138514c1f32d29c60222002963e0c0a7e1a815dff00444f"
    + "0x28719e86c8042765405cbb88205d1fb130f39f3bb0923afe7fef6dd5ef798c31"
    sourceHashes.1:
    - "0x981d4f2ae5949ab33c6ba83f6446595d3b853bf6f7157884304445d70b185374"
    + "0x396f0e8e4bc223f186f87b7eabf2f4b537ce84f8515aa16c86400c4f10af79b1"
    sourceHashes.0:
    - "0x081a1805983e86cd6a80ed48c012c26bf9a39473c0f1e69b357afff240f027a0"
    + "0x8337740067b4f9278182a83ca83d62ca2611966b8beca6e0a49394204c8f74da"
    description:
    - "The main contract defining the Layer 2. The operator commits blocks and provides a ZK proof which is validated by the Verifier contract and then processes transactions. During batch execution it processes L1 --> L2 and L2 --> L1 transactions."
    + "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."
    issuedPermissions.2:
    + {"permission":"interact","to":"0x282370D1e925ee897CB29Cb3beC13aAe0743067C","description":"manage fees, apply predefined upgrades and manage censorship through a TransactionFilterer (ChainAdmin role).","via":[{"address":"0x97440Bf040f0dfA402cf5D4F1e0f574309Ace871"}]}
    issuedPermissions.1.to:
    - "0x282370D1e925ee897CB29Cb3beC13aAe0743067C"
    + "0x8c0Bfc04AdA21fd496c55B8C50331f904306F564"
    issuedPermissions.1.description:
    - "manage fees, apply predefined upgrades and manage censorship through a TransactionFilterer (ChainAdmin role)."
    + "commit, prove, execute, revert batches directly in the main Diamond contract. This role is typically held by a proxying ValidatorTimelock."
    issuedPermissions.1.via.0:
    - {"address":"0x97440Bf040f0dfA402cf5D4F1e0f574309Ace871"}
    values.$implementation.3:
    - "0x90C0A0a63d7ff47BfAA1e9F8fa554dabc986504a"
    + "0x53d0b421BB3e522632ABEB06BB2c4eB15eaD9800"
    values.$implementation.2:
    - "0xBB13642F795014E0EAC2b0d52ECD5162ECb66712"
    + "0x36b026c39125964D99596CE302866B5A59E4dE27"
    values.$implementation.1:
    - "0x5575218cECd370E1d630d1AdB03c254B0B376821"
    + "0x95C45F931946C97D10D9d6e859Fe8D62785ed3C1"
    values.$implementation.0:
    - "0x81754d2E48e3e553ba6Dfd193FC72B3A0c6076d9"
    + "0xEaedCF01c0B01C1a10b74cB0A2cDeF78a9540cdb"
    values.$pastUpgrades.3:
    + ["2025-03-25T20:10:23.000Z","0x0d39b66c0a194ce268eba8ea2883828caacbc62cb41ff972cea629bcb7ccd696",["0xEaedCF01c0B01C1a10b74cB0A2cDeF78a9540cdb","0x95C45F931946C97D10D9d6e859Fe8D62785ed3C1","0x36b026c39125964D99596CE302866B5A59E4dE27","0x53d0b421BB3e522632ABEB06BB2c4eB15eaD9800"]]
    values.$upgradeCount:
    - 3
    + 4
    values.daMode:
    - 1
    values.facetAddresses.3:
    - "0x90C0A0a63d7ff47BfAA1e9F8fa554dabc986504a"
    + "0x53d0b421BB3e522632ABEB06BB2c4eB15eaD9800"
    values.facetAddresses.2:
    - "0xBB13642F795014E0EAC2b0d52ECD5162ECb66712"
    + "0x36b026c39125964D99596CE302866B5A59E4dE27"
    values.facetAddresses.1:
    - "0x5575218cECd370E1d630d1AdB03c254B0B376821"
    + "0x95C45F931946C97D10D9d6e859Fe8D62785ed3C1"
    values.facetAddresses.0:
    - "0x81754d2E48e3e553ba6Dfd193FC72B3A0c6076d9"
    + "0xEaedCF01c0B01C1a10b74cB0A2cDeF78a9540cdb"
    values.facets.0x90C0A0a63d7ff47BfAA1e9F8fa554dabc986504a:
    - ["acceptAdmin()","changeFeeParams((uint8,uint32,uint32,uint32,uint32,uint64))","executeUpgrade(((address,uint8,bool,bytes4[])[],address,bytes))","freezeDiamond()","setPendingAdmin(address)","setPorterAvailability(bool)","setPriorityTxMaxGasLimit(uint256)","setPubdataPricingMode(uint8)","setTokenMultiplier(uint128,uint128)","setTransactionFilterer(address)","setValidator(address,bool)","unfreezeDiamond()","upgradeChainFromVersion(uint256,((address,uint8,bool,bytes4[])[],address,bytes))"]
    values.facets.0x81754d2E48e3e553ba6Dfd193FC72B3A0c6076d9:
    - ["baseTokenGasPriceMultiplierDenominator()","baseTokenGasPriceMultiplierNominator()","facetAddress(bytes4)","facetAddresses()","facetFunctionSelectors(address)","facets()","getAdmin()","getBaseToken()","getBaseTokenBridge()","getBridgehub()","getFirstUnprocessedPriorityTx()","getL2BootloaderBytecodeHash()","getL2DefaultAccountBytecodeHash()","getL2SystemContractsUpgradeBatchNumber()","getL2SystemContractsUpgradeBlockNumber()","getL2SystemContractsUpgradeTxHash()","getPendingAdmin()","getPriorityQueueSize()","getPriorityTxMaxGasLimit()","getProtocolVersion()","getPubdataPricingMode()","getSemverProtocolVersion()","getStateTransitionManager()","getTotalBatchesCommitted()","getTotalBatchesExecuted()","getTotalBatchesVerified()","getTotalBlocksCommitted()","getTotalBlocksExecuted()","getTotalBlocksVerified()","getTotalPriorityTxs()","getVerifier()","getVerifierParams()","isDiamondStorageFrozen()","isEthWithdrawalFinalized(uint256,uint256)","isFacetFreezable(address)","isFunctionFreezable(bytes4)","isValidator(address)","l2LogsRootHash(uint256)","priorityQueueFrontOperation()","storedBatchHash(uint256)","storedBlockHash(uint256)"]
    values.facets.0x5575218cECd370E1d630d1AdB03c254B0B376821:
    - ["bridgehubRequestL2Transaction((address,address,uint256,uint256,bytes,uint256,uint256,bytes[],address))","finalizeEthWithdrawal(uint256,uint256,uint16,bytes,bytes32[])","l2TransactionBaseCost(uint256,uint256,uint256)","proveL1ToL2TransactionStatus(bytes32,uint256,uint256,uint16,bytes32[],uint8)","proveL2LogInclusion(uint256,uint256,(uint8,bool,uint16,address,bytes32,bytes32),bytes32[])","proveL2MessageInclusion(uint256,uint256,(uint16,address,bytes),bytes32[])","requestL2Transaction(address,uint256,bytes,uint256,uint256,bytes[],address)","transferEthToSharedBridge()"]
    values.facets.0xBB13642F795014E0EAC2b0d52ECD5162ECb66712:
    - ["commitBatches((uint64,bytes32,uint64,uint256,bytes32,bytes32,uint256,bytes32),(uint64,uint64,uint64,bytes32,uint256,bytes32,bytes32,bytes32,bytes,bytes)[])","commitBatchesSharedBridge(uint256,(uint64,bytes32,uint64,uint256,bytes32,bytes32,uint256,bytes32),(uint64,uint64,uint64,bytes32,uint256,bytes32,bytes32,bytes32,bytes,bytes)[])","executeBatches((uint64,bytes32,uint64,uint256,bytes32,bytes32,uint256,bytes32)[])","executeBatchesSharedBridge(uint256,(uint64,bytes32,uint64,uint256,bytes32,bytes32,uint256,bytes32)[])","proveBatches((uint64,bytes32,uint64,uint256,bytes32,bytes32,uint256,bytes32),(uint64,bytes32,uint64,uint256,bytes32,bytes32,uint256,bytes32)[],(uint256[],uint256[]))","proveBatchesSharedBridge(uint256,(uint64,bytes32,uint64,uint256,bytes32,bytes32,uint256,bytes32),(uint64,bytes32,uint64,uint256,bytes32,bytes32,uint256,bytes32)[],(uint256[],uint256[]))","revertBatches(uint256)","revertBatchesSharedBridge(uint256,uint256)"]
    values.facets.0xEaedCF01c0B01C1a10b74cB0A2cDeF78a9540cdb:
    + ["acceptAdmin()","unfreezeDiamond()","upgradeChainFromVersion(uint256,((address,uint8,bool,bytes4[])[],address,bytes))","setPorterAvailability(bool)","setTransactionFilterer(address)","setTokenMultiplier(uint128,uint128)","freezeDiamond()","genesisUpgrade(address,address,bytes,bytes[])","forwardedBridgeMint(bytes,bool)","prepareChainCommitment()","setValidator(address,bool)","setPendingAdmin(address)","setDAValidatorPair(address,address)","forwardedBridgeBurn(address,address,bytes)","changeFeeParams((uint8,uint32,uint32,uint32,uint32,uint64))","makePermanentRollup()","executeUpgrade(((address,uint8,bool,bytes4[])[],address,bytes))","forwardedBridgeRecoverFailedTransfer(uint256,bytes32,address,bytes)","setPriorityTxMaxGasLimit(uint256)","setPubdataPricingMode(uint8)"]
    values.facets.0x95C45F931946C97D10D9d6e859Fe8D62785ed3C1:
    + ["getPubdataPricingMode()","getPriorityTxMaxGasLimit()","getTotalBlocksCommitted()","getVerifierParams()","baseTokenGasPriceMultiplierDenominator()","getTransactionFilterer()","isDiamondStorageFrozen()","getProtocolVersion()","getChainId()","getBridgehub()","getTotalBlocksExecuted()","getPriorityTreeRoot()","getVerifier()","facetAddresses()","getDAValidatorPair()","getPriorityQueueSize()","getSettlementLayer()","getAdmin()","storedBlockHash(uint256)","getFirstUnprocessedPriorityTx()","facets()","getL2SystemContractsUpgradeTxHash()","isPriorityQueueActive()","getChainTypeManager()","getBaseTokenAssetId()","getBaseToken()","l2LogsRootHash(uint256)","getL2SystemContractsUpgradeBlockNumber()","getTotalPriorityTxs()","facetFunctionSelectors(address)","getTotalBlocksVerified()","storedBatchHash(uint256)","getTotalBatchesExecuted()","isEthWithdrawalFinalized(uint256,uint256)","isFacetFreezable(address)","facetAddress(bytes4)","getPendingAdmin()","getL2BootloaderBytecodeHash()","getTotalBatchesCommitted()","getL2SystemContractsUpgradeBatchNumber()","isFunctionFreezable(bytes4)","baseTokenGasPriceMultiplierNominator()","getTotalBatchesVerified()","getPriorityTreeStartIndex()","getSemverProtocolVersion()","isValidator(address)","getL2DefaultAccountBytecodeHash()"]
    values.facets.0x36b026c39125964D99596CE302866B5A59E4dE27:
    + ["proveL1ToL2TransactionStatus(bytes32,uint256,uint256,uint16,bytes32[],uint8)","bridgehubRequestL2Transaction((address,address,uint256,uint256,bytes,uint256,uint256,bytes[],address))","requestL2Transaction(address,uint256,bytes,uint256,uint256,bytes[],address)","proveL2LogInclusion(uint256,uint256,(uint8,bool,uint16,address,bytes32,bytes32),bytes32[])","finalizeEthWithdrawal(uint256,uint256,uint16,bytes,bytes32[])","proveL2LeafInclusion(uint256,uint256,bytes32,bytes32[])","l2TransactionBaseCost(uint256,uint256,uint256)","requestL2TransactionToGatewayMailbox(uint256,bytes32,uint64)","bridgehubRequestL2TransactionOnGateway(bytes32,uint64)","proveL2MessageInclusion(uint256,uint256,(uint16,address,bytes),bytes32[])"]
    values.facets.0x53d0b421BB3e522632ABEB06BB2c4eB15eaD9800:
    + ["revertBatchesSharedBridge(uint256,uint256)","proveBatchesSharedBridge(uint256,uint256,uint256,bytes)","commitBatchesSharedBridge(uint256,uint256,uint256,bytes)","executeBatchesSharedBridge(uint256,uint256,uint256,bytes)"]
    values.getBaseTokenBridge:
    - "0xD7f9f54194C633F36CCD5F3da84ad4a1c38cB2cB"
    values.getL2BootloaderBytecodeHash:
    - "0x010008c3be57ae5800e077b6c2056d9d75ad1a7b4f0ce583407961cc6fe0b678"
    + "0x0100088580465d88420e6369230ee94a32ff356dbcdd407a4be49fc8009b2a81"
    values.getL2DefaultAccountBytecodeHash:
    - "0x0100055dba11508480be023137563caec69debc85f826cb3a4b68246a7cabe30"
    + "0x010004dbf8be36c421254d005352f8245146906919be0099e8a50d0e78df85e0"
    +++ description: Protocol version, increments with each protocol upgrade.
    +++ severity: HIGH
    values.getProtocolVersion:
    - 107374182400
    + 111669149696
    values.getSemverProtocolVersion.0:
    - 25
    + 26
    values.getStateTransitionManager:
    - "0xc2eE6b6af7d616f6e27ce7F4A451Aedc2b0F5f5C"
    values.getVerifier:
    - "0x06aa7a7B07108F7C5539645e32DD5c21cBF9EB66"
    + "0xdb3300726556AFA413A11aF474a8cFDa4D7fc5a5"
    values.txFilterer:
    - []
    values.validators.1:
    + "0x8c0Bfc04AdA21fd496c55B8C50331f904306F564"
    values.getBaseTokenAssetId:
    + "0x550294b5414f0e3416c764c5efc683ead2dd861c5a5bb23fb53f5aac8797882d"
    values.getChainId:
    + 61166
    values.getChainTypeManager:
    + "0xc2eE6b6af7d616f6e27ce7F4A451Aedc2b0F5f5C"
    +++ severity: HIGH
    values.getDAValidatorPair:
    + ["0x907b30407249949521Bf0c89A43558dae200146A","0xFa30EAe30351A83809657299F6Cad9557c232e8C"]
    values.getSettlementLayer:
    + "0x0000000000000000000000000000000000000000"
    +++ description: This contract must expose the ITransactionFilterer interface (see Mailbox facet) and is used for censoring transactions pushed from L1 to L2.
    +++ severity: HIGH
    values.getTransactionFilterer:
    + "0x0000000000000000000000000000000000000000"
    values.isPriorityQueueActive:
    + false
    fieldMeta.txFilterer:
    - {"severity":"HIGH","description":"This contract must expose the ITransactionFilterer interface (see Mailbox facet) and is used for censoring transactions pushed from L1 to L2."}
    fieldMeta.getProtocolVersion.severity:
    - "MEDIUM"
    + "HIGH"
    fieldMeta.getAdmin:
    + {"severity":"HIGH"}
    fieldMeta.getTransactionFilterer:
    + {"severity":"HIGH","description":"This contract must expose the ITransactionFilterer interface (see Mailbox facet) and is used for censoring transactions pushed from L1 to L2."}
    fieldMeta.getDAValidatorPair:
    + {"severity":"HIGH"}
    fieldMeta.getPendingAdmin:
    + {"severity":"HIGH"}
    fieldMeta.getPubdataPricingMode:
    + {"severity":"HIGH","description":"0 - Rollup, 1 - Validium"}
    }
    contract TreasureZkEvmAdmin (0x97440Bf040f0dfA402cf5D4F1e0f574309Ace871) {
    +++ description: None
    +++ description: Timestamps for new protocol version upgrades can be registered here (NOT enforced)
    values.upgradeTimestamps.1:
    + {"_protocolVersion":107374182400,"_upgradeTimestamp":1738591200}
    values.upgradeTimestamps.0._protocolVersion:
    - 107374182400
    + 111669149696
    values.upgradeTimestamps.0._upgradeTimestamp:
    - 1738591200
    + 1742454000
    }
    + Status: CREATED
    contract ValidatorTimelock (0x8c0Bfc04AdA21fd496c55B8C50331f904306F564)
    +++ description: Intermediary contract between the *Validators* and the central diamond contract that delays block execution (ie withdrawals and other L2 --> L1 messages) by 3h.
    + Status: CREATED
    contract Verifier (0xdb3300726556AFA413A11aF474a8cFDa4D7fc5a5)
    +++ description: Implements the ZK proof verification logic.
    2025 March 11, 08:00 UTC
    11changes

    ValidatorTimelock governance transfer for ZIP 5.

    ValidatorTimelock governance transfer for ZIP 5.

    - Status: DELETED
    contract undefined (0x3701fB675bCd4A85eb11A2467628BBe193F6e6A8)
    +++ description: None
    contract ValidatorTimelock (0x5D8ba173Dc6C3c90C8f7C04C9288BeF5FDbAd06E) {
    +++ description: Intermediary contract between the *Validators* and the central diamond contract that delays block execution (ie withdrawals and other L2 --> L1 messages) by 3h.
    values.owner:
    - "0x8f7a9912416e8AdC4D9c21FAe1415D3318A11897"
    + "0xE30Dca3047B37dc7d88849dE4A4Dc07937ad5Ab3"
    }
    - Status: DELETED
    contract ProtocolUpgradeHandler (0x8f7a9912416e8AdC4D9c21FAe1415D3318A11897)
    +++ description: The central upgrade contract and Governance proxy for all ZK stack contracts. Accepts successful DAO proposals from L2, emergency proposals from the EmergencyUpgradeBoard. The three members of the EmergencyUpgradeBoard also have special roles and permissions in this contract.
    - Status: DELETED
    contract SecurityCouncil (0xBDFfCC71FE84020238F2990a6D2954e87355De0D)
    +++ description: Custom Multisig implementation that has a general threshold of 9 but also specific thresholds for upgrade approvals (6) or soft freezes (3).
    - Status: DELETED
    contract Guardians (0xD677e09324F8Bb3cC64F009973693f751c33A888)
    +++ description: Custom Multisig implementation that has a general threshold of 5 and a specific threshold for extending the legal voting period of 2.
    - Status: DELETED
    contract EmergencyUpgradeBoard (0xdEFd1eDEE3E8c5965216bd59C866f7f5307C9b29)
    +++ description: A custom contract allowing a 3/3 of 0xBDFfCC71FE84020238F2990a6D2954e87355De0D, 0xbC1653bd3829dfEc575AfC3816D4899cd103B51c and 0xD677e09324F8Bb3cC64F009973693f751c33A888 to `executeEmergencyUpgrade()` via the 0x8f7a9912416e8AdC4D9c21FAe1415D3318A11897.

    New and verified contracts

    + Status: CREATED
    contract undefined (0x3701fB675bCd4A85eb11A2467628BBe193F6e6A8)
    +++ description: None
    + Status: CREATED
    contract ProtocolUpgradeHandler (0x8f7a9912416e8AdC4D9c21FAe1415D3318A11897)
    +++ description: The central upgrade contract and Governance proxy for all ZK stack contracts. Accepts successful DAO proposals from L2, emergency proposals from the EmergencyUpgradeBoard. The three members of the EmergencyUpgradeBoard also have special roles and permissions in this contract.
    + Status: CREATED
    contract SecurityCouncil (0xBDFfCC71FE84020238F2990a6D2954e87355De0D)
    +++ description: Custom Multisig implementation that has a general threshold of 9 but also specific thresholds for upgrade approvals (6) or soft freezes (3).
    + Status: CREATED
    contract Guardians (0xD677e09324F8Bb3cC64F009973693f751c33A888)
    +++ description: Custom Multisig implementation that has a general threshold of 5 and a specific threshold for extending the legal voting period of 2.
    + Status: CREATED
    contract EmergencyUpgradeBoard (0xdEFd1eDEE3E8c5965216bd59C866f7f5307C9b29)
    +++ description: A custom contract allowing a 3/3 of 0xBDFfCC71FE84020238F2990a6D2954e87355De0D, 0xbC1653bd3829dfEc575AfC3816D4899cd103B51c and 0xD677e09324F8Bb3cC64F009973693f751c33A888 to `executeEmergencyUpgrade()` via the 0x8f7a9912416e8AdC4D9c21FAe1415D3318A11897.

    Operator

    The system has a centralized operator

    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.

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

    1. L1 - L2 interoperability - Developer's documentation

    Withdrawals

    Regular messaging

    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.

    1. Withdrawing funds - ZKsync documentation

    Forced messaging

    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.

    Permissions

    A dashboard to explore contracts and permissions
    Go to Disco
    Disco UI Banner
    Disco UI BannerExplore in Disco

    Ethereum

    Actors:

    EmergencyUpgradeBoard0xF73a…a111

    A custom contract allowing a 3/3 of SecurityCouncil, ZK Foundation Multisig and Guardians to executeEmergencyUpgrade() via the ProtocolUpgradeHandler.

    • Can upgrade with no delay
      • BridgeHub
      • MessageRoot
      • CTMDeploymentTracker
      • L1AssetRouter
      • L1NativeTokenVault
      • ChainTypeManager
      • L1Nullifier
      • ChainAssetHandler
      • ProtocolUpgradeHandler
    • Can interact with BridgeHub
      • set critical contract addresses for the shared cluster, register 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, pause and unpause migrations and the 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. and manage zk chain registration
    • Can interact with L1NativeTokenVault
      • pause / unpause the bridge
    • Can 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 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 fee params for all connected chains
    • Can interact with L1Nullifier
      • pause, unpause and set critical escrow address references
    • Can interact with ChainAssetHandler
      • pause, resume chain migrations
    Used in:
    Matter Labs Multisig0x4e49…7828

    A Multisig with 4/7 threshold.

    • Can upgrade with no delay
      • ServerNotifier
    • Can interact with BridgeHub
      • create new zk chains (based on the current version), register tokens (ZK cluster Admin role)
    • Can interact with ChainTypeManager
      • set the pending admin of this contract and the ServerNotifier contract address (ZK cluster Admin role)

    Participants (7):

    0xEE7d…dE460x3F00…c4810xC9A8…3D830x3068…d2Bc0xFAdb…79AE0xAf0B…9B280x7408…70C7
    Used in:
    SecurityCouncil0x5919…9035

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

    • Can interact with ProtocolUpgradeHandler
      • soft freeze, hard freeze, approve a protocol upgrade
    • Can interact with EmergencyUpgradeBoard
      • one of its 3/3 signers

    Participants (8):

    GnosisSafeGnosisSafeGnosisSafeGnosisSafeGnosisSafeGnosisSafeGnosisSafeGnosisSafe
    Used in:
    1. Security Council members - ZK Nation docs
    Guardians0x600d…86b8

    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.

    • Can interact with ProtocolUpgradeHandler
      • extend the legal veto period, approve a protocol upgrade
    • Can interact with EmergencyUpgradeBoard
      • one of its 3/3 signers

    Participants (8):

    GnosisSafeGnosisSafeGnosisSafeGnosisSafeGnosisSafeGnosisSafeGnosisSafeGnosisSafe
    Used in:
    1. Guardians - ZK Nation docs
    TreasureChainAdminMultisig0x2823…067C

    A Multisig with 4/5 threshold.

    • Can interact with Diamond
      • administrate 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. roles for this chain in the ValidatorTimelock, manage fees, apply predefined upgrades, manage censorship through a TransactionFilterer, set DA mode, migrate the chain to whitelisted 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 (Chain Admin role)

    Participants (5):

    0x1c68…7f170xBAe6…23Ae0x1ee4…87260x5824…88940x18c1…92f0
    ValidatorTimelock0x8c0B…F564

    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.

    • Can interact with Diamond
      • commit, prove, execute, revert batches directly in the main Diamond contract. This role is typically held by a proxying ValidatorTimelock
    ZK Foundation Multisig0xbC16…B51c

    A Multisig with 3/6 threshold.

    • Can interact with EmergencyUpgradeBoard
      • one of its 3/3 signers

    Participants (6):

    0x64FE…52930xA10f…bE520x56B3…22220x441e…c2d10x0B2E…47090x610e…b991
    Used in:
    2 EOAs
    EOA 1EOA 2
    • Can interact with ValidatorTimelock2
      • Permissioned to call the functions to commit, prove, execute and revert 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. batches through the ValidatorTimelock in the main Diamond contract
    • Can interact with ValidatorTimelock
      • Permissioned to call the functions to commit, prove, execute and revert L2 batches through the ValidatorTimelock in the main Diamond contract
    EOA 30xdd2B…3216
    • Can interact with TreasureZkEvmAdmin
      • set the conversion factor for gasA virtual fuel used to execute smart contracts on a rollup. The EVM (or other VM within the rollup) uses an accounting mechanism to correspond the consumption of gas to the consumption of computing resources, and to limit the consumption of computing resources. token deposits

    ZKsync Era

    Actors:

    ZkProtocolGovernor0x7670…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 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.

    • Can interact with ProtocolUpgradeHandler
      • start (queue) upgrades
    • Can interact with ProtocolTimelockController
      • cancel queued transactions
      • execute transactions that are ready
      • manage all access control roles and change the minimum delay
      • propose transactions
    Used in:
    ZkTokenGovernor0xb83F…5746

    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.

    • Can interact with ZkToken
      • grant the MINTER_ROLE to arbitrary addresses, thus controlling the minting of the ZK token with 3d delay
    • Can interact with ZkTokenTimelockController
      • manage all access control roles and change the minimum delay with 6d delay
      • cancel queued transactions
      • execute transactions that are ready
      • propose transactions
    Used in:
    Guardians_l2Alias0x711e…97c9
    • Can interact with ZkTokenGovernor
      • cancel proposals while they are pending (after having been proposed) or active (during the voting period)
    Used in:
    ZKFoundationMultisig_l2Alias0xcd27…C62D
    • Can interact with ZkTokenGovernor
      • make direct proposals without owning ZK tokens. In propose-guarded mode, this address is the ONLY allowed 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.. Propose-guarded mode is currently set to false
    Used in:
    ProtocolUpgradeHandler_l2Alias0xF41E…6bc4
    • Can upgrade with no delay
      • ZkToken
    • Can interact with ZkToken
      • control all roles in the ZkToken access control, including the minter roles
    Used in:

    Smart contracts

    A dashboard to explore contracts and permissions
    Go to Disco
    Disco UI Banner
    Disco UI BannerExplore in Disco
    A diagram of the smart contract architecture
    A diagram of the smart contract architecture

    Ethereum

    Diamond0x5e64…E879Implementation #1 (Upgradable)Implementation #2 (Upgradable)Implementation #3 (Upgradable)Implementation #4 (Upgradable)

    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.

    • Roles:
      • getAdmin: TreasureZkEvmAdmin; ultimately TreasureChainAdminMultisig
      • 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: ValidatorTimelock, ValidatorTimelock2
    Verifier0xdb33…c5a5

    Implements the ZK proof verification logic.

    ValidiumL1DAValidator0x907b…146A

    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. for validiums. This implementation only checks the correct formatting and does not serve as a DA oracle. Can be used by ZK stack validiums 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.

    Implementation used in:
    BridgeHub0x303a…5213Implementation (Upgradable)Admin

    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.

    • Roles:
      • admin: EraChainAdminProxy, ProxyAdmin; ultimately EmergencyUpgradeBoard, Matter Labs Multisig
      • owner: ProtocolUpgradeHandler; ultimately EmergencyUpgradeBoard
    Can be upgraded by:
    EmergencyUpgradeBoard with no delay
    Proxy used in:
    MessageRoot0x5Ce9…B4aDImplementation (Upgradable)Admin

    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.

    • Roles:
      • admin: ProxyAdmin; ultimately EmergencyUpgradeBoard
    Can be upgraded by:
    EmergencyUpgradeBoard with no delay
    Proxy used in:
    CTMDeploymentTracker0x6078…9860Implementation (Upgradable)Admin

    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.

    • Roles:
      • admin: ProxyAdmin; ultimately EmergencyUpgradeBoard
    Can be upgraded by:
    EmergencyUpgradeBoard with no delay
    Proxy used in:
    L1AssetRouter0x8829…cE56Implementation (Upgradable)Admin

    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.

    • Roles:
      • admin: ProxyAdmin; ultimately EmergencyUpgradeBoard
    Can be upgraded by:
    EmergencyUpgradeBoard with no delay
    Proxy used in:
    Used in:
    ChainTypeManager0xc2eE…5f5CImplementation (Upgradable)Admin

    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.

    • Roles:
      • admin: EraChainAdminProxy, ProxyAdmin; ultimately EmergencyUpgradeBoard, Matter Labs Multisig
      • owner: ProtocolUpgradeHandler; ultimately EmergencyUpgradeBoard
    Can be upgraded by:
    EmergencyUpgradeBoard with no delay
    Proxy used in:
    L1Nullifier0xD7f9…B2cBImplementation (Upgradable)Admin

    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.

    • Roles:
      • admin: ProxyAdmin; ultimately EmergencyUpgradeBoard
      • owner: ProtocolUpgradeHandler; ultimately EmergencyUpgradeBoard
    Can be upgraded by:
    EmergencyUpgradeBoard with no delay
    Proxy used in:
    Used in:
    ProtocolUpgradeHandler0xE30D…5Ab3Implementation (Upgradable)Admin

    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.

    • Roles:
      • admin: ProxyAdmin; ultimately EmergencyUpgradeBoard
      • emergencyUpgradeBoard: EmergencyUpgradeBoard
      • guardians: Guardians
      • l2_protocol_governor: ProtocolTimelockController; ultimately ZkProtocolGovernor
      • securityCouncil: SecurityCouncil
    Can be upgraded by:
    EmergencyUpgradeBoard with no delay
    Proxy used in:
    TreasureZkEvmAdmin0x9744…e871

    A governance proxy that lets TreasureChainAdminMultisig act through it.

    • Roles:
      • owner: TreasureChainAdminMultisig
      • tokenMultiplierSetter: EOA 3
    EraChainAdminProxy0x2cf3…5063

    A governance proxy that lets Matter Labs Multisig act through it.

    • Roles:
      • owner: Matter Labs Multisig
    Implementation used in:
    ProxyAdmin
    2 instances
    0x1e4c…bE3e0xC2a3…2cf1
    • Roles:
      • owner: ProtocolUpgradeHandler
    Implementation used in:
    ProxyAdmin0x257F…D29B
    • Roles:
      • owner: EraChainAdminProxy
    Implementation used in:
    L1NativeTokenVault
    Escrow
    0xbeD1…11f6Implementation (Upgradable)Admin

    Canonical central asset escrow for all ZK stack chains.

    • Roles:
      • admin: ProxyAdmin; ultimately EmergencyUpgradeBoard
      • owner: ProtocolUpgradeHandler; ultimately EmergencyUpgradeBoard
    The following tokens are included in the value secured calculation:
    MAGIC token logo
    Can be upgraded by:
    EmergencyUpgradeBoard with no delay
    Proxy used in:
    ChainAssetHandler0xDd5C…1076Implementation (Upgradable)Admin

    Specialized contract for managing chain assets, i.e. chain migrations.

    • Roles:
      • admin: ProxyAdmin; ultimately EmergencyUpgradeBoard
      • owner: ProtocolUpgradeHandler; ultimately EmergencyUpgradeBoard
    Can be upgraded by:
    EmergencyUpgradeBoard with no delay
    Proxy used in:
    ServerNotifier0xfca8…Ce31Implementation (Upgradable)Admin

    A simple contract that can be called by the ChainAdmin to emit notifications about chain migrations.

    • Roles:
      • admin: ProxyAdmin; ultimately Matter Labs Multisig
    Can be upgraded by:
    Matter Labs Multisig with no delay
    Proxy used in:

    ZKsync Era

    ProtocolTimelockController0x085b…c714

    Timelock contract allowing the queueing of transactions with a minimum delay of 0s.

    • Roles:
      • canceller: ZkProtocolGovernor
      • executor: ZkProtocolGovernor
      • 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.: ZkProtocolGovernor
      • timelockAdmin: ProtocolTimelockController; ultimately ZkProtocolGovernor
    Implementation used in:
    ZkToken0x5A7d…af3EImplementation (Upgradable)Admin

    The ZK token contract on ZKsync Era. Mintable through access control roles. Used for voting in the ZK stack governance system.

    • Roles:
      • admin: ZkTokenProxyAdmin; ultimately ProtocolUpgradeHandler_l2Alias
      • defaultAdmin: ProtocolUpgradeHandler_l2Alias
      • minterAdmin: ZkTokenTimelockController; ultimately ZkTokenGovernor
    Can be upgraded by:
    ProtocolUpgradeHandler_l2Alias with no delay
    Proxy used in:
    ZkTokenProxyAdmin0xdB1E…15CC
    • Roles:
      • owner: ProtocolUpgradeHandler_l2Alias
    Implementation used in:
    ZkTokenTimelockController0xe5d2…9c3d

    Timelock contract allowing the queueing of transactions with a minimum delay of 3d.

    • Roles:
      • canceller: ZkTokenGovernor
      • executor: ZkTokenGovernor
      • 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.: ZkTokenGovernor
      • timelockAdmin: ZkTokenTimelockController; ultimately ZkTokenGovernor
    Implementation 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 3h - 8d 3h delay on code upgrades unless upgrade is initiated by the EmergencyUpgradeBoard in which case there is no delay.

    Program Hashes

    Name
    Hash
    Repository
    Verification
    Used in
    0x0100...2a81
    Github
    Treasure logo