Ownership Model
An overview of the most important contracts and roles in the ZKsync Stack ecosystem.
This section covers L1 and L2 contracts, their relationships, and the roles that manage them.
Contracts overview
| Contract | Description | Owned by | Shared within ecosystem | Source code |
|---|---|---|---|---|
| CTM (ChainTypeManager) | Trust zone that ensures unified state transition process across chains | ProtocolUpgradeHandler | Yes, but might have multiple instances with different ownership | Source |
| Bridgehub | Primary ecosystem entry point for L1↔L2 messaging, CTM management, chain registration | ProtocolUpgradeHandler | Yes | Source |
| L1 SharedBridge (legacy) | Bridges assets between L1 and all ZKsync chains | ProtocolUpgradeHandler | Yes | Source |
| DiamondProxy | Main contract of a specific chain, responsible for state transition | CTM (Admin can control some processes) | No | Facets |
| ValidatorTimelock | Trustlessly sets a batch execution delay | ProtocolUpgradeHandler | Yes, enforced within CTM | Source |
| Verifier | Verifies ZK proofs | - | Yes, within CTM | Source |
| L1/L2 NativeTokenVault | Holds L1 native ETH and ERC20 tokens bridged into ZKsync chains | ProtocolUpgradeHandler | Yes | NTV |
| L1/L2 AssetRouter | Bridges assets between L1 and ZKsync chains, supporting both ETH and ERC20 tokens | ProtocolUpgradeHandler | Yes | Asset Router |
| L1/L2 DA Validators | Ensure that pubdata is committed properly | - | L1: optionally shared, L2: no | Default L1 3rd Party L1 L2 |
Roles overview
| Name | Purpose | Owned by | Shared | Source code |
|---|---|---|---|---|
| DecentralizedGovernance (set of contracts) | Owns ProtocolUpgradeHandler, controls all ecosystem contracts, accepts/vetoes proposals. | - | Yes | Repository |
| ChainAdmin | - Change fee parameters - Set validator for a chain - Set transaction filterer - Set base token multiplier - Set pubdata pricing mode - Set the timestamp when the protocol upgrade will be applied | Chain operator’s Multisig | No | Source |
| ProtocolUpgradeHandler | Ownership of CTM, Bridgehub, L1 and L2 bridges, AssetRouters, NTVs | DecentralizedGovernance | Yes | Source |
| EcosystemAdmin | - Revert batches within CTM - Set validator to any chain (will be removed in gateway upgrade) - Create new chain in Bridgehub - Add a base token in Bridgehub - Allow bridging to some L2SharedBridge | ML Multisig | Yes | Source |
| ChainAdmin | - Change fee parameters - Set validator for a chain - Set transaction filterer - Set base token multiplier - Set pubdata pricing mode - Set the timestamp when the protocol upgrade will be applied | Chain operator’s Multisig | No | Source |
| BlobOperator | EOA that sends CommitBatches transactions | Chain operator | No | EOA |
| Operator | EOA that sends ProveBatches and ExecuteBatches transactions | Chain operator | No | EOA |
| FeeCollector | An address that receives the funds from fees paid by user transactions on L2 | Chain operator | No | Not enforced |
| TokenMultiplierSetter | An address nominated by the ChainAdmin that can set the ETH↔BaseToken price ratio | Chain operator | No | EOA |
FAQ
What powers does the governance have?
You can verify all of these by looking through the ChainTypeManager.sol & Bridgehub.sol contracts.
- Add/remove a CTM to/from the bridgehub
- Register a new chain to the bridgehub
- For any ZKsync chain deployed on the bridgehub:
- Upgrade the new protocol version and deadlines for upgrades
- Freeze and unfreeze a chain
- Change fee params
- Set Validator
What powers does the chain admin have?
These are deducible from the Admin facet, the main ones are:
- change fee params
- set DA validators
- set TransactionFilterer contract on L1
- ETH ↔ CustomBaseToken ratio for L1->L2 transactions
- set pubdata pricing mode (Rollup/Validium)
- set the timestamp when the protocol upgrade will be applied
Why do these limitations exist? What are the benefits of being on the shared CTM?
By being on the shared CTM, chain operators get the below benefits:
- Higher level of trust between chains that allows for proof-based interoperability and theoretically for commit- or TEE-based with additional limitations.
- Security handling in case of critical bugs.
- Upgrades managed by the CTM owner, (L1 contract upgrades done by owner, server+prover upgrades by the operator)
Are there other limitations to being on the shared CTM?
Yes. You cannot modify the L2 system contracts and the bootloader, the VM and the circuits. If there is a protocol-level feature you would want added, it would have to be added to the main repo and included in a protocol release.
What are the other options and what are their tradeoffs?
- Launching off the shared bridge as a completely separate fork of the fully open source ZKsync era
- Launching on the shared bridge using a different CTM (with permission by the governance)
If I start on the shared CTM, can I permissionlessly opt out?
Currently, no. This feature is on our roadmap
How do upgrades work in the shared CTMs and in external CTMs?
- In the shared CTM, the upgrades are proposed by the Governance. This also means that their deadlines are enforced by the governance.
- In the separate CTM scenario, the entity controlling the CTM can propose any upgrades they need and enforce any deadlines on them.
Can the chain be started on a different CTM and join the shared CTM?
Using the standard process - no, because the historical state transitions are not validated, thus there are no guarantees of their correctness.
But it is possible to do via governance voting, which is not a standard procedure and takes some time to do.