GRVT
Badges
About
Gravity (GRVT) is a hybrid crypto derivatives exchange, providing a centralized exchange-like experience while being based on the ZK stack Validium codebase with confidential data availability and transaction filtering enabled.
Badges
About
Gravity (GRVT) is a hybrid crypto derivatives exchange, providing a centralized exchange-like experience while being based on the ZK stack Validium codebase with confidential data availability and transaction filtering enabled.
Recategorisation
The project will be classified as "Other" due to its specific risks that set it apart from the standard classifications.
The project will move to Others because:
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.
Funds can be stolen if
Funds can be lost if
Users can be censored if
MEV can be extracted if
Sequencer failure
No mechanismState validation
ZK proofs (ST, SN)STARKs and SNARKs are zero knowledge proofs that ensure state correctness. STARKs proofs are wrapped in SNARKs proofs for efficiency. SNARKs require a trusted setup.
Data availability
ExternalProof construction and state derivation rely fully on data that is NOT published onchain.
Exit window
NoneThere is no window for users to exit in case of an unwanted standard upgrade because the central operator can censor withdrawal transactions by implementing a TransactionFilterer with no delay. The standard upgrade delay is 4d 3h.
Proposer failure
Cannot withdrawOnly the whitelisted proposers can publish state roots on L1, so in the event of failure the withdrawals are frozen. There is a decentralized Governance system that can attempt changing Proposers with an upgrade.
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 Sequencer.
Funds can be lost if the external data becomes unavailable (CRITICAL).
Each update to the system state must be accompanied by a ZK proof that ensures that the new state was derived by correctly applying a series of valid user transactions to the previous state. These proofs are then verified on Ethereum by a smart contract.
ZKsync Era proof system Boojum can be found here and contains essential tools like the Prover, the Verifier, and other backend components. The specs of the system can be found here.
The system has a centralized operator
The operator is the only entity that can propose blocks. A live and trustworthy operator is vital to the health of the system.
MEV can be extracted if the operator exploits their centralized position and frontruns user transactions.
Users can't force any transaction
If a user is censored by the L2 Sequencer, they cannot by default force their transaction via the L1 queue. An an active TransactionFilterer contract which allows only whitelisted accounts to enqueue, prevents it. Even if a user was specifically whitelisted, there is no mechanism that forces L2 Sequencer to include transactions from the queue in an L2 block.
Users can be censored if the operator refuses to include their transactions.
Users can be censored if the Operator does not specifically whitelist them in the TransactionFilterer.
Regular messaging
Forced messaging
If the user experiences censorship from the operator with regular L2->L1 messaging they can submit their messages directly on L1. The system is then obliged to service this request or halt all messages from L1, including all forced withdrawals and deposits. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.
There are two main paths for contract upgrades in the shared ZK stack ecosystem - standard and emergency - both converging on the shared upgrade proxy contract ProtocolUpgradeHandler. The standard path involves a governance proposal and voting through the DAO, multiple timelock delays and finally approval by the Guardians or 6 SecurityCouncil participants. The emergency path allows for contract upgrades without any delay by the EmergencyUpgradeBoard, which acts as a 3/3 Multisig between SecurityCouncil, Guardians and the FoundationMultisig.
Standard path
On ZKsync Era
Delegates can start new proposals by reaching a threshold of 21M ZK tokens on the ZKsync Era Rollup’s ZkProtocolGovernor contract. This launches a 7d ‘voting delay’ after which the 7d voting period starts. During these first two periods, the proposal can be canceled by the proposer or if it falls below the proposing threshold. A proposal is only successful if it reaches both quorum (630M ZK tokens) and simple majority. When it reaches quorum, the voting period is reset to 7d. In the successful case, it can be queued in the 0s timelock which forwards it to Ethereum as an L2->L1 log.
On Ethereum
After the execution of the proposal-containing batch (3h delay), the proposal is now picked up by the ProtocolUpgradeHandler and enters the 3d ‘legal veto period’. This serves as a window in which a veto could be coordinated offchain, to be then enforced by non-approval of Guardians and SecurityCouncil. A threshold of 2 Guardians can extend the veto period to 7d. After this a proposal enters a waiting state of 30d, from which it can be immediately approved (cancelling the delay) by 6 participants of the SecurityCouncil. For the unlikely case that the SC does not approve here, the Guardians can instead approve the proposal, or nobody. In the two latter cases, the waiting period is enforced in full. A proposal cannot be actively cancelled in the ProtocolUpgradeHandler, but will be expired if not approved within the waiting period. An approved proposal now enters the pendingExecution state for a final delay of 1d, and can then be executed.
Other governance tracks
There are two other tracks of Governance also starting with DAO Delegate proposals the ZKsync Era rollup: 1) Token Program Proposals that add new minters, allocations or upgrade the ZK token and 2) Governance Advisory Proposals that e.g. change the ZK Credo or other offchain Governance Procedures without onchain targets. The protocol for these two other tracks is similar to the first part of the standard path described above (albeit having different quorum and timelock values), and not passing over to the Ethereum L1. Further customizations are that the ZkFoundationMultisig can propose to the ZkTokenGovernor without a threshold and that the Guardians’ L2 alias can cancel proposals in the ZkTokenGovernor and the ZkGovOpsGovernor.
Emergency path
SecurityCouncil (9 / 12), Guardians (5 / 8) and ZkFoundationMultisig (3 / 5) form a de-facto 3/3 Multisig by pushing an immediate upgrade proposal through the EmergencyUpgradeBoard, which circumvents all delays and executes immediately via the ProtocolUpgradeHandler.
Upgrade Delays
The cumulative duration of the upgrade paths from the moment of a voted ‘successful’ proposal is 4d 3h or 8d 3h (depending on Guardians extending the LegalVetoPeriod) for Standard, 0 for Emergency and 34d 3h for the path in which the SecurityCouncil is not approving the proposal.
Freezing
The SecurityCouncil can freeze (pause withdrawals and settlement) all chains connected to the current StateTransitionManager. Either for a softFreeze of 12h or a hardFreeze of 7d. After a softFreeze and / or a hardFreeze, a proposal from the EmergencyUpgradeBoard has to be passed before subsequent freezes are possible. Only the SecurityCouncil can unfreeze an active freeze.
Elastic Chain Operator and ChainAdmin
Apart from the paths that can upgrade all shared implementations, the ZK stack governance system defines other roles that can modify the system: A single Elastic Chain operator role that governs parameters in the shared contracts and a ChainAdmin role (in the chain-specific diamond contract) for managing parameters of each individual Hyperchain that builds on the stack. These chain-specific actions include setting a transaction filterer that can censor L1 -> L2 messages, setting fee parameters and adding / removing Validators in the ValidatorTimelock. ZKsync Era’s ChainAdmin differs from the others as it also has the above Elastic Chain Operator role in the shared ZK stack contracts.
Ethereum
Roles:
Permissioned to call the functions to commit, prove, execute and revert L2 batches through the ValidatorTimelock in the main Diamond contract.
Actors:
- A Multisig with 2 / 3 threshold.
- Can act on behalf of GrvtZkEvmAdmin.
- Is allowed to interact with GrvtZkEvmAdmin - set the conversion factor for gas token deposits.
- Is allowed to interact with GrvtZkEvm - manage fees, apply predefined upgrades and manage censorship through a TransactionFilterer (ChainAdmin role) - acting via GrvtZkEvmAdmin.
- Can upgrade the implementation of GRVTTransactionFilterer, GRVTBridgeProxy.
- Intermediary contract between the Validators and the central diamond contract that delays block execution (ie withdrawals and other L2 --> L1 messages) by 3h.
- Is allowed to interact with GrvtZkEvm - commit, prove, execute, revert batches directly in the main Diamond contract. This role is typically held by a proxying ValidatorTimelock.
Used in:
- Checks the signature of the DepositApprover for each deposit and, on succeeding, forwards the user’s funds and bridging request to the L1SharedBridge contract to deposit to GRVT.
- Is allowed to interact with GRVTTransactionFilterer - address is part of the GRVTTransactionFilterer whitelist.
Is allowed to interact with GRVTTransactionFilterer - address is part of the GRVTTransactionFilterer whitelist.
- A Multisig with 4 / 7 threshold.
- Can act on behalf of EraAdminProxy.
- Is allowed to interact with BridgeHub - register new tokens in the BridgeHub and create new chains sharing the Elastic Chain contracts - acting via EraAdminProxy.
- Is allowed to interact with StateTransitionManager - manage the shared ValidatorTimelock contract address, revert batches and set permissioned validators for all chains connected to the StateTransitionManager - acting via EraAdminProxy.
- Is allowed to interact with L1SharedBridge - register new Elastic Chains in the shared bridge - acting via EraAdminProxy.
Used in:
- A Multisig with 9 / 12 threshold.
- Custom Multisig implementation that has a general threshold of 9 but also specific thresholds for upgrade approvals (6) or soft freezes (3).
- Is allowed to interact with ProtocolUpgradeHandler - soft freeze, hard freeze, approve a protocol upgrade.
Participants (12):
GnosisSafeGnosisSafeGnosisSafeGnosisSafeGnosisSafeGnosisSafeGnosisSafeGnosisSafeGnosisSafeGnosisSafeGnosisSafeGnosisSafeUsed in:
- A Multisig with 5 / 8 threshold.
- Custom Multisig implementation that has a general threshold of 5 and a specific threshold for extending the legal voting period of 2.
- Is allowed to interact with ProtocolUpgradeHandler - extend the legal veto period, approve a protocol upgrade.
Used in:
- A custom contract allowing a 3/3 of SecurityCouncil, ZkFoundationMultisig and Guardians to
executeEmergencyUpgrade()via the ProtocolUpgradeHandler. - Can act on behalf of ProtocolUpgradeHandler.
- Can upgrade the implementation of BridgeHub, StateTransitionManager, L1SharedBridge - acting via ProxyAdmin, ProtocolUpgradeHandler.
Used in:
Is allowed to interact with GRVTBridgeProxy - approve deposits to GRVT via the GRVTBridgeProxy.
- Member of GrvtChainAdminMultisig.
- Is allowed to interact with GRVTTransactionFilterer - address is part of the GRVTTransactionFilterer whitelist.
- Is allowed to interact with GRVTTransactionFilterer - manage the whitelist of addresses.
Is allowed to interact with ProtocolUpgradeHandler - start (queue) upgrades.
ZKsync Era
Actors:
- 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 act on behalf of TokenTimelockController with 3d delay.
- Is allowed to interact with TokenTimelockController - cancel queued transactions.
- Is allowed to interact with TokenTimelockController - execute transactions that are ready.
- Is allowed to interact with TokenTimelockController - propose transactions.
- Is allowed to interact with ZkToken - grant the MINTER_ROLE to arbitrary addresses, thus controlling the minting of the ZK token - acting via TokenTimelockController with 3d delay.
- Governance contract allowing for token voting (simple majority) with the ZK token through delegates. This contract is used for Governance Advisory Proposals (GAPs) that are not executable onchain. At least 21M ZK tokens are necessary to start a proposal and a 630M quorum of voted tokens must be met to succeed.
- Can act on behalf of GovOpsTimelockController with 3d delay.
- Is allowed to interact with GovOpsTimelockController - cancel queued transactions.
- Is allowed to interact with GovOpsTimelockController - execute transactions that are ready.
- Is allowed to interact with GovOpsTimelockController - propose transactions.
- 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 1 and can - from there - target all L1 and L2 contracts. At least 21M ZK tokens are necessary to start a proposal and a 630M quorum of voted tokens must be met to succeed.
- Can act on behalf of ProtocolTimelockController.
- Is allowed to interact with ProtocolTimelockController - cancel queued transactions.
- Is allowed to interact with ProtocolTimelockController - execute transactions that are ready.
- Is allowed to interact with ProtocolTimelockController - propose transactions.
- Is allowed to interact with ZkToken - control all roles in the ZkToken access control, including the minter roles.
- Can upgrade the implementation of ZkToken - acting via ZkTokenProxyAdmin.
Is allowed to interact with ZkTokenGovernor - make direct proposals without owning ZK tokens. In propose-guarded mode, this address is the ONLY allowed proposer. Propose-guarded mode is currently set to false.
Is allowed to interact with ZkTokenGovernor, ZkGovOpsGovernor - cancel proposals while they are pending (after having been proposed) or active (during the voting period).
Ethereum
Can be used to interact with GrvtZkEvm - manage fees, apply predefined upgrades and manage censorship through a TransactionFilterer (ChainAdmin role).
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.
Implementation used in:
- Can be used to interact with BridgeHub - register new tokens in the BridgeHub and create new chains sharing the Elastic Chain contracts.
- Can be used to interact with StateTransitionManager - manage the shared ValidatorTimelock contract address, revert batches and set permissioned validators for all chains connected to the StateTransitionManager.
- Can be used to interact with L1SharedBridge - register new Elastic Chains in the shared bridge.
Implementation used in:
Helper contract that defines diamondcut data to initialize a new diamond implementation for the chain-specific system contracts.
Implementation used in:
- 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.
- Can act on behalf of ProxyAdmin.
Implementation used in:
Can be used to upgrade implementation of BridgeHub, StateTransitionManager, L1SharedBridge.
Implementation used in:
Defines L2 diamond contract creation and upgrade data, the proof system for the ZKsync diamond contract connected to it (and other L2 diamond contracts that share the logic).
Proxy used in:
This bridge contract escrows all ERC-20s and ETH that are deposited to registered ZK stack chains like ZKsync Era.
Proxy used in:
ZKsync Era
- Timelock contract allowing the queueing of transactions with a minimum delay of 3d.
- Can be used to interact with ZkToken - grant the MINTER_ROLE to arbitrary addresses, thus controlling the minting of the ZK token.
The ZK token contract on ZKsync Era. Mintable through access control roles. Used for voting in the ZK stack governance system.
Timelock contract allowing the queueing of transactions with a minimum delay of 3d.
Can be used to upgrade implementation of ZkToken.
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.
