Frequently Asked Questions

This section addresses common questions about ZKsync Gateway, its usage, and its implications for ZKsync chains.

Can chain operators move in and out of ZKsync Gateway?

Yes. Migration to ZKsync Gateway as a shared proof aggregation layer is optional and can be reversed if needed. Chains can configure their proof submission path to switch between Ethereum and ZKsync Gateway.

Is there any impact on application developers building on a ZKsync chain that migrates to ZKsync Gateway?

In most cases, no. Application developers continue to deploy their contracts on the ZKsync chain itself. Migration to ZKsync Gateway does not affect application-layer interactions. Bridging behavior and finality guarantees may differ slightly depending on the proof aggregation setup.

How does ZKsync Gateway affect finality?

ZKsync Gateway introduces an additional aggregation step before proofs are submitted to Ethereum for final verification. As a result, finality may take slightly longer compared to submitting proofs directly to Ethereum. However, for interactions between chains that use Gateway, interoperability finality may be faster since finalization through Gateway is sufficient.

Are ZKsync Gateway-connected chains still Layer 2s?

Yes. Chains that use ZKsync Gateway for proof submission remain Layer 2s. ZKsync Gateway functions as a middleware layer for proof aggregation, while Ethereum remains the final verifier for all proofs. Assets remain locked in Ethereum-based contracts, and L1–L2 interactions such as deposits originate from Ethereum, not from Gateway.

Additionally, chains must initially launch with Ethereum as their proof submission origin. Migration to Gateway is only possible after the chain has been registered and operating through Ethereum.

How are deposits and withdrawals from Ethereum to chains on ZKsync Gateway handled?

Deposits and withdrawals function the same way as for chains directly submitting proofs to Ethereum. ZKsync Gateway does not replace Ethereum as the origin for L1–L2 messaging or asset custody. APIs and helper methods for deposit and withdraw in the ZKsync SDKs are fully compatible with Gateway-connected chains.

How can I check if a chain is using Ethereum or ZKsync Gateway for proof submission?

You can call the settlementLayer(chainId) method on the BridgeHub contract. This method returns the aggregation layer chain ID used by the specified chain:

• 1 for Ethereum Mainnet
• 9075 for ZKsync Gateway

What fees are required to submit proofs to ZKsync Gateway?

Chains using ZKsync Gateway must pay aggregation fees in $ZK tokens. These fees cover the cost of proof submission and aggregation. Operators should plan for $ZK token availability based on their expected proof submission frequency.

Can chains use custom data availability solutions with ZKsync Gateway?

Yes. Chains using custom data availability mechanisms must ensure that their validation logic is compatible with Gateway and can be deployed on the aggregation layer. ZKsync Gateway performs verification middleware-level validation, so the data availability strategy must be enforceable within that context.

Where can I find more information about migrating a chain to ZKsync Gateway?

Detailed instructions are available in the ZKsync Stack migration guide.