The following reflects the views of L2BEAT’s governance team, composed of @kaereste, @Sinkas, and @Manugotsuka, and it’s based on their combined research, fact-checking, and ideation.
We are voting FOR the proposal.
As this was a technical and not a trivial upgrade, we requested L2BEAT’s research team to review both the proposal’s outline and its calldata.
As we understand, the new ZK chain ‘Gateway’ (chainID 9075) is whitelisted as a settlement layer, allowing it to host other ZK chains, which is part of the broader ZK stack scaling/interop roadmap. In turn, it will also enable ZKsync to migrate there as an L3. Since after the proposal is executed, the chain owners could start a migration at any instant, we’d like to ask whether we could have clarity on the plans for when this should occur.
Other than that, we do not see any issue with the proposal on a high level, and we are supportive of it as it is in line with the ZKsync priorities set forward by GAP-1.
Our research team successfully verified the proposal’s calldata using cyfrin’s zkgov-check, l2beat decoder, l2b zkgovproposal and l2b fetchzkstack, finding transactions that:
- Register chainid 9075 as a settlement layer,
- Set up the ChainTypeManager contract on the new settlement layer,
- Prepare chain migration via BridgeHub and CTMDeploymentTracker
With all the above info in mind, we decided to vote in favor of the proposal, and we’re looking forward to when ZKsync also migrates to Gateway as an L3.