[ZIP-13] Adding a ZKsync OS CTM

Proposal Type	ZIP
One Sentence Summary	ZIP-13 proposes to add a ZKsync OS–based ChainTypeManager (CTM).
Proposal Author	Matter Labs
Proposal Sponsor	Cyfrin
Date Created	2025-09-26
Version	v1
Summary of Action	Adding a ZKsync OS–based CTM inside the Bridgehub.
Link to contracts	matter-labs/era-contracts (draft-v29)
Link to forum	https://forum.zknation.io/t/zip-13-adding-a-zksync-os-ctm/776

Abstract

ZIP-13 proposes to add a new ZKsync OS based ChainTypeManager (CTM) to our ecosystem. This will serve as the first milestone toward adoption of the ZKsync OS, which enables chains to have full EVM equivalence, while enjoying much cheaper and faster proofs.

Motivation

ZKsync OS introduces a new Airbender prover for ZKsync Chains that can prove arbitrary RISC-V execution.

The above not only opens the door to easier system upgrades (as we only need to amend the Rust code), but also much quicker and cheaper proof generation.

Due to the large difference in the internal structure between the currently existing ZKsync chains and the new ZKsync OS architecture, we want to release ZKsync OS chains on a separate CTM first, controlled by a temporary development multisig to ensure the ability to quickly patch any fixes if necessary. Once ZKsync OS is considered mature enough, the ownership will be transferred to the decentralized governance in a subsequent ZIP.

Specification

Matter Labs will deploy the CTM for ZKsync OS chains, while the ZKsync Governance will conduct a single operation to register the CTM inside the Bridgehub.

Rationale

The approach above makes it possible to get early feedback on the new ZKsync OS architecture on mainnet, while allowing quick upgrades to ensure prompt bug fixes during the initial phase of the system.

Due to the existing architecture, ZKsync Chains’ balances and messages are separated from each other, so even if the ZKsync OS based chains became completely malicious, they would not be able to affect other ZKsync Chains.

Implementation & Backwards Compatibility

The implementation does not involve any breaking changes for the existing chains.

For the new ZKsync OS chains, one limitation will apply: they will not be able to connect to ZKsync Gateway. This is done for security reasons to ensure maximal isolation between the existing chains and the ZKsync OS ones.

Security Considerations

Our current architecture already allows for the addition of untrusted chains without those chains being able to affect the existing chains in any way. Starting from v29, there will be two mechanisms that ensure that:

• In v29 an assertion was added that ensures that chains can only connect to ZKsync Gateway, only if they belong to the same CTM as ZKsync Gateway.
• The chainBalance mapping that has been present in our system for quite some time already ensures that a chain can never withdraw more than it had deposited into the shared bridge (L1NativeTokenVault contract).
• The CTM has been deployed but will be updated shortly to reflect new chain creation parameters. This change will not affect the security of this proposal.
• Verifier will be updated as well.

https://tally.xyz/gov/zksync/proposal/22471812359223094779541460804735287481991027375586193607912523407322605938475