GRVT

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: GrvtZkEvmAdmin; ultimately GrvtChainAdminMultisig
  • getTransactionFilterer: GRVTTransactionFilterer
  • 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

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.

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 at least 0s. Duration could be configured individually for zk stack chains by chain admins. All delays are capped at 30 days. This version (MultisigCommitter) can additionally require batch commitments to be signed by a set of commit validators: by default the shared set of 3 validators with a threshold of 0 (0 means no signatures are required), or a custom per-chain set and threshold if enabled by the owner.

• Roles:
  • admin: ProxyAdmin; ultimately EmergencyUpgradeBoard
  • owner: ProtocolUpgradeHandler; ultimately EmergencyUpgradeBoard

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. Since v31 the verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. of each protocol version is registered here and written into a chain when it applies the upgrade. The current protocol version is 0,31,2.

• Roles:
  • admin: ChainAdminOwnable, ProxyAdmin; ultimately EmergencyUpgradeBoard, Matter Labs Multisig
  • owner: ProtocolUpgradeHandler; ultimately EmergencyUpgradeBoard

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 and from chainId to 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. Since v31 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.->L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. message and log inclusion proofs it offers are verified by the MessageRoot instead of each chain’s diamond.

• Roles:
  • admin: EraChainAdminProxy, ProxyAdmin; ultimately EmergencyUpgradeBoard, Matter Labs Multisig
  • owner: ProtocolUpgradeHandler; ultimately EmergencyUpgradeBoard

Service contract that registers one ZK stack chain on another for interop by sending 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.->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. service transaction through the Bridgehub. Only chains settling on the same 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 can be registered with each other.

• Roles:
  • admin: ProxyAdmin; ultimately EmergencyUpgradeBoard

A router contract for verifiers of ZKsync OS chains. Routes verification requests to the PLONKA zk-SNARK proving system introduced by Gabizon, Williamson and Ciobotaru in 2019 that allows proving custom circuits. Plonk is based on KZG polynomial commitments and thus requires a universal trusted setup. verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. of the version selected in the proof, currently ZKsyncOSVerifierPlonk_v31 (version 0). The owner can add and remove verifier versions without a chain upgrade.

• Roles:
  • owner: ProtocolUpgradeHandler; ultimately EmergencyUpgradeBoard

Stores the batch roots of all ZK stack chains and verifies 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.->L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. message, log and L1->L2 transaction status proofs used for withdrawals and failed deposit claims. Batch roots are appended by each chain while it settles on Ethereum; proofs of chains settling on a 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. layer are verified recursively through that layer’s roots. Batches produced before a chain’s v31 upgrade are still verified against the chain’s own diamond.

• Roles:
  • admin: ProxyAdmin; ultimately EmergencyUpgradeBoard

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

Contract that verifies the data availabilityThe property of a rollup's data being reachable by any node retrieving the data that were rolled up and executed to reach the proposed state. Data availability (DA), specifically decoupling it from the rollup nodes themselves, is one of the preeminent factors which allows a rollup to scale securely. A rollup is faced with a decision of what to use as a DA layer to guarantee that any node can retrieve this data--permissionlessly under any circumstance. For this reason, using Ethereum for DA currently provides the strongest security guarantees. If data is stored somewhere other than a permissionless L1, then the project is not a rollup, but rather a validium or an optimium. of ethereum calldata and blobsThe data that a rollup publishes to its L1/data availability (DA) layer. They consist of the L2 transactions that are rolled up, along with some metadata. Blobs are introduced as a new transaction type within Ethereum with EIP-4844, and has rollup scaling specifically in mind. Blobs persist on Ethereum’s Beacon Chain ephemerally.. Can be used by ZK stack rollups as the L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. part of a DAValidator pair.

Keeps the per-chain token balances of the L1NativeTokenVault escrow: every deposit increases and every withdrawal or failed deposit claim decreases the balance of the chain (or of its 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. layer), and a withdrawal that exceeds it reverts. Also migrates balances between a chain and its settlement layer on chain migrations. Legacy balances are moved here from the vault token by token through the permissionlessAnyone willing should be able to join and leave the network at any time, without causing significant disturbance to the network or being detrimental to the party in question. No single entity should have the power to allowlist or blocklist participants. registerLegacyToken().

• Roles:
  • admin: ProxyAdmin; ultimately EmergencyUpgradeBoard
  • owner: ProtocolUpgradeHandler; ultimately EmergencyUpgradeBoard

The only address allowed to commit, prove and execute batches of a chain while its Priority Mode (escape hatchThe facility for any user of a rollup to exit the system with their assets under any circumstance. Most relevant in rollups with a centralized proposer, wherein users do not have the ability to propose blocks, but can nonetheless exit the rollup by interacting with a smart contract on L1.) is active. Anyone can call it to settle batches of such a chain in one transaction, bypassing the ValidatorTimelock delay. In Priority Mode each batch can contain only priority (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) transactions. Anyone can activate Priority Mode once the first unprocessed priority transaction is older than 4 days. This requires a permanent 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. whose admin has permanently allowed Priority Mode.

• Roles:
  • admin: ProxyAdmin; ultimately EmergencyUpgradeBoard

Canonical central asset escrow for all ZK stack chains. Since v31 the per-chain balance accounting that caps what each chain can withdraw is enforced by the L1AssetTracker, which the vault calls on every deposit, withdrawal and failed deposit claim.

• Roles:
  • admin: ProxyAdmin; ultimately EmergencyUpgradeBoard
  • owner: ProtocolUpgradeHandler; ultimately EmergencyUpgradeBoard

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. Since v31 the verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. of each protocol version is registered here and written into a chain when it applies the upgrade. The current protocol version is 0,33,0.

• Roles:
  • admin: EraChainAdminProxy, ProxyAdmin; ultimately EmergencyUpgradeBoard, Matter Labs Multisig
  • owner: ProtocolUpgradeHandler; ultimately EmergencyUpgradeBoard

Specialized asset handler for chains as assets, i.e. chain migrations between Ethereum and 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. It records the migration number and the batch intervals of each chain per settlement layer, which the MessageRoot uses to validate proofs, and gates migrations on the chain being upgraded to v31 with its base token registered in the L1AssetTracker.

• Roles:
  • admin: ProxyAdmin; ultimately EmergencyUpgradeBoard
  • owner: ProtocolUpgradeHandler; ultimately EmergencyUpgradeBoard

The only address allowed to commit, prove and execute batches of a chain while its Priority Mode (escape hatchThe facility for any user of a rollup to exit the system with their assets under any circumstance. Most relevant in rollups with a centralized proposer, wherein users do not have the ability to propose blocks, but can nonetheless exit the rollup by interacting with a smart contract on L1.) is active. Anyone can call it to settle batches of such a chain in one transaction, bypassing the ValidatorTimelock delay. In Priority Mode each batch can contain only priority (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) transactions. Anyone can activate Priority Mode once the first unprocessed priority transaction is older than 4 days. This requires a permanent 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. whose admin has permanently allowed Priority Mode.

• Roles:
  • admin: ProxyAdmin; ultimately EmergencyUpgradeBoard

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

Simple registry for allowed DA address pairs for the ‘rollupA blockchain that inherits consensus and data availability from another blockchain called L1. Rollups enable trust minimized bridges with the base layer via proof systems, either optimistic or zero-knowledge. A rollup without a bridge, or without considering the bridge, is called a sovereign rollup.’ data availabilityThe property of a rollup's data being reachable by any node retrieving the data that were rolled up and executed to reach the proposed state. Data availability (DA), specifically decoupling it from the rollup nodes themselves, is one of the preeminent factors which allows a rollup to scale securely. A rollup is faced with a decision of what to use as a DA layer to guarantee that any node can retrieve this data--permissionlessly under any circumstance. For this reason, using Ethereum for DA currently provides the strongest security guarantees. If data is stored somewhere other than a permissionless L1, then the project is not a rollup, but rather a validium or an optimium. mode (can be permanently enforced with isPermanentRollup=true). Rollup DA address pairs (especially the L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. part) usually point to contracts that validate if data was made available on Ethereum.

• Roles:
  • owner: ProtocolUpgradeHandler; ultimately EmergencyUpgradeBoard

A governance proxy that lets GrvtChainAdminMultisig act through it.

• Roles:
  • owner: GrvtChainAdminMultisig
  • tokenMultiplierSetter: GrvtChainAdminMultisig

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

• Roles:
  • owner: Matter Labs Multisig

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

• Roles:
  • owner: Matter Labs Multisig

Verifies a zk-SNARKShort for "succinct non-interactive argument of knowledge", a SNARK is a widely used type of zero-knowledge proof that is short and fast to verify. Different kinds of SNARKs are usually systematized by proof size, verification time, and type of setup. The most famous SNARKs are Groth16, PLONK/Marlin, Bulletproofs, and STARKs. proof using an implementation of the PlonKA zk-SNARK proving system introduced by Gabizon, Williamson and Ciobotaru in 2019 that allows proving custom circuits. Plonk is based on KZG polynomial commitments and thus requires a universal trusted setup. proof systemThe infrastructure that allows projects to verify their state transitions. It is composed by onchain verifiers and offchain provers. The main two flavors are optimistic and ZK proof systems, but they can be combined in a hybrid model. In general though, if a system is able to accept state roots optimistically, even if it has a ZK component, it is considered an optimistic proof system..

Bridges ETH of the GRVTL1TreasuryVault to the exchange on GRVT and returns failed ETH deposits to the vault. Only the vault can 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. through it.

• Roles:
  • admin: ProxyAdmin; ultimately GrvtChainAdminMultisig

Yield strategy of the GRVTL1TreasuryVault for one vault token. Whitelisted operators swap registered receipt tokens (e.g. tokenized treasuries) with the strategy at the price of their price sources, within per-swap and per-token exposure caps. Only the vault can allocate to and withdraw from it.

• Roles:
  • admin: GrvtChainAdminMultisig
  • 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.: , EOA 6
  • owner: TimelockController; ultimately GrvtChainAdminMultisig

Yield strategy of the GRVTL1TreasuryVault that supplies the vault token to Aave V3. Only the vault can allocate to and withdraw from it.

• Roles:
  • admin: ProxyAdmin; ultimately GrvtChainAdminMultisig

• Roles:
  • owner: GrvtChainAdminMultisig

Receives the yield harvested from the strategies of the GRVTL1TreasuryVault and reimburses the vault for strategy entry and exit fees. The owner and authorized withdrawers can send its balance to the withdrawalRecipient.

• Roles:
  • authorizedWithdrawers: EOA 2

A timelock with access control. The current minimum delay is 2d.

• Roles:
  • canceller: GrvtChainAdminMultisig
  • defaultAdmin: GrvtChainAdminMultisig, TimelockController; ultimately EOA 1, EOA 2
  • executor: EOA 1, EOA 2
  • 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.: GrvtChainAdminMultisig

Registry of compartments: contracts on Ethereum that hold the capital of GRVT vaults withdrawn 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., deploy it into external yield venues and 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. it back to the vaults on GRVT. The registry also holds the roles and the global pause for all compartments.

• Roles:
  • admin: ProxyAdmin; ultimately UpgradeAuthority
  • compartmentCreator: GrvtChainAdminMultisig
  • configAdmin: GrvtChainAdminMultisig
  • defaultAdmin: GrvtChainAdminMultisig
  • pauser: GrvtChainAdminMultisig
  • registryAdmin: GrvtChainAdminMultisig
  • unpauser: GrvtChainAdminMultisig

Yield strategy of the GRVTL1TreasuryVault that supplies the vault token to Aave V3. Only the vault can allocate to and withdraw from it.

• Roles:
  • admin: GrvtChainAdminMultisig

Placeholder implementation that new compartment proxies are deployed with, so that their CREATE2 address does not depend on the real implementation. The CompartmentRegistry upgrades a compartment to its real implementation in the same transaction.

• Roles:
  • owner: UpgradeAuthority

Verifies a zk-SNARKShort for "succinct non-interactive argument of knowledge", a SNARK is a widely used type of zero-knowledge proof that is short and fast to verify. Different kinds of SNARKs are usually systematized by proof size, verification time, and type of setup. The most famous SNARKs are Groth16, PLONK/Marlin, Bulletproofs, and STARKs. proof using an implementation of the fflonk proof systemThe infrastructure that allows projects to verify their state transitions. It is composed by onchain verifiers and offchain provers. The main two flavors are optimistic and ZK proof systems, but they can be combined in a hybrid model. In general though, if a system is able to accept state roots optimistically, even if it has a ZK component, it is considered an optimistic proof system..

Yield strategy of the GRVTL1TreasuryVault that converts the vault token to GHO through the Aave GHO Stability Module and deposits it into sGHO. Only the vault can allocate to and withdraw from it.

• Roles:
  • admin: GrvtChainAdminMultisig

Holds most of the exchange reserves of GRVT on Ethereum, which the exchange withdraws from GRVT to this vault. The funds can be allocated to whitelisted yield strategies, bridged back to the exchange on GRVT, and yield above the allocated principal is harvested to the yieldRecipient. Strategies and their allocation caps are whitelisted by the VAULT_ADMIN_ROLE.

• Roles:
  • admin: ProxyAdmin; ultimately GrvtChainAdminMultisig
  • allocator: EOA 1, EOA 2, EOA 4
  • defaultAdmin: GrvtChainAdminMultisig
  • pauser: EOA 1, EOA 2, EOA 4
  • rebalancer: EOA 1, EOA 2, EOA 4
  • vaultAdmin: GrvtChainAdminMultisig
  • yieldHarvester: EOA 2

A timelock with access control. The current minimum delay is 3d.

• Roles:
  • canceller: GrvtChainAdminMultisig
  • defaultAdmin: TimelockController; ultimately GrvtChainAdminMultisig
  • executor: GrvtChainAdminMultisig
  • 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.: GrvtChainAdminMultisig

A router contract for verifiers. Routes verification requests to EraVerifierFflonk or EraVerifierPlonk depending on the supplied proof type.

Compartment of a GRVT vault. It holds vault capital withdrawn from GRVT and deploys it into listed Axcess loan vaults, Nest vaults and Wildcat V2 markets. Proceeds of venue exits always return to the compartment, and funds can only leave it to a listed venue or to the vault’s deposit proxy on GRVT through the GRVTBridgeProxy. Venues are listed by the REGISTRY_ADMIN_ROLE of the CompartmentRegistry.

• Roles:
  • admin: ProxyAdmin; ultimately UpgradeAuthority
  • 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.: EOA 5
  • rebalancer: EOA 5

Yield strategy of the GRVTL1TreasuryVault for one vault token. Whitelisted operators swap registered receipt tokens (e.g. tokenized treasuries) with the strategy at the price of their price sources, within per-swap and per-token exposure caps. Only the vault can allocate to and withdraw from it.

• Roles:
  • admin: GrvtChainAdminMultisig
  • 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.: , EOA 6
  • owner: TimelockController; ultimately GrvtChainAdminMultisig

• Roles:
  • owner: ProtocolUpgradeHandler

• Roles:
  • owner: EraChainAdminProxy

Verifies a zk-SNARKShort for "succinct non-interactive argument of knowledge", a SNARK is a widely used type of zero-knowledge proof that is short and fast to verify. Different kinds of SNARKs are usually systematized by proof size, verification time, and type of setup. The most famous SNARKs are Groth16, PLONK/Marlin, Bulletproofs, and STARKs. proof using an implementation of the PlonKA zk-SNARK proving system introduced by Gabizon, Williamson and Ciobotaru in 2019 that allows proving custom circuits. Plonk is based on KZG polynomial commitments and thus requires a universal trusted setup. proof systemThe infrastructure that allows projects to verify their state transitions. It is composed by onchain verifiers and offchain provers. The main two flavors are optimistic and ZK proof systems, but they can be combined in a hybrid model. In general though, if a system is able to accept state roots optimistically, even if it has a ZK component, it is considered an optimistic proof system..

A router contract for verifiers. Routes verification requests to EraVerifierFflonk_v33 or EraVerifierPlonk_v33 depending on the supplied proof type.

Verifies a zk-SNARKShort for "succinct non-interactive argument of knowledge", a SNARK is a widely used type of zero-knowledge proof that is short and fast to verify. Different kinds of SNARKs are usually systematized by proof size, verification time, and type of setup. The most famous SNARKs are Groth16, PLONK/Marlin, Bulletproofs, and STARKs. proof using an implementation of the PlonKA zk-SNARK proving system introduced by Gabizon, Williamson and Ciobotaru in 2019 that allows proving custom circuits. Plonk is based on KZG polynomial commitments and thus requires a universal trusted setup. proof systemThe infrastructure that allows projects to verify their state transitions. It is composed by onchain verifiers and offchain provers. The main two flavors are optimistic and ZK proof systems, but they can be combined in a hybrid model. In general though, if a system is able to accept state roots optimistically, even if it has a ZK component, it is considered an optimistic proof system..

Verifies a zk-SNARKShort for "succinct non-interactive argument of knowledge", a SNARK is a widely used type of zero-knowledge proof that is short and fast to verify. Different kinds of SNARKs are usually systematized by proof size, verification time, and type of setup. The most famous SNARKs are Groth16, PLONK/Marlin, Bulletproofs, and STARKs. proof using an implementation of the fflonk proof systemThe infrastructure that allows projects to verify their state transitions. It is composed by onchain verifiers and offchain provers. The main two flavors are optimistic and ZK proof systems, but they can be combined in a hybrid model. In general though, if a system is able to accept state roots optimistically, even if it has a ZK component, it is considered an optimistic proof system..

Verifies a zk-SNARKShort for "succinct non-interactive argument of knowledge", a SNARK is a widely used type of zero-knowledge proof that is short and fast to verify. Different kinds of SNARKs are usually systematized by proof size, verification time, and type of setup. The most famous SNARKs are Groth16, PLONK/Marlin, Bulletproofs, and STARKs. proof using an implementation of the fflonk proof systemThe infrastructure that allows projects to verify their state transitions. It is composed by onchain verifiers and offchain provers. The main two flavors are optimistic and ZK proof systems, but they can be combined in a hybrid model. In general though, if a system is able to accept state roots optimistically, even if it has a ZK component, it is considered an optimistic proof system..

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

• Roles:
  • admin: ProxyAdmin; ultimately Matter Labs Multisig

• Roles:
  • owner: ChainAdminOwnable

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

• Roles:
  • admin: ProxyAdmin; ultimately Matter Labs Multisig

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

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 EmergencyUpgradeBoard
  • defaultAdmin: ProtocolUpgradeHandler; ultimately EmergencyUpgradeBoard
  • minterAdmin: ZkTokenTimelockController; ultimately ZkTokenGovernor

• Roles:
  • owner: ProtocolUpgradeHandler

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