zkSync Era Upgrade Activation Timelines & Epochs

introduction

UPGRADE ACTIVATION TIMELINES AND EPOCHS

Introduction

A canonical timeline of mandatory zkSync Era protocol upgrades keyed by L2 block number and epoch, serving as the primary resource for operators to plan maintenance and ensure client readiness.

The zkSync Era protocol advances through a series of mandatory network upgrades, each activated at a specific L2 block number or epoch. Unlike Ethereum's slot-based timing, zkSync Era's upgrade triggers are embedded in the L2 state transition function, making the block number the authoritative activation signal. This page provides the definitive historical and forward-looking timeline of these upgrades, including the Gateway Upgrade Protocol, system contract migrations, and bootloader changes. For exchanges, wallet teams, and node operators, this timeline is the single source of truth for scheduling maintenance windows, updating client software, and verifying that their infrastructure remains in consensus with the canonical chain.

Each upgrade entry details the activation block, the affected protocol components, and the minimum node and prover client versions required. A missed upgrade results in an immediate chain split for the operator, as their node will fail to process new blocks or produce valid proofs. The operational impact extends beyond node runners: wallet SDKs must support new transaction formats, bridges must verify state against updated system contract hashes, and indexers must parse modified block structures. The timeline therefore serves as a coordination point for the entire ecosystem, from core infrastructure providers to application developers.

Chainscore Labs helps teams build automated upgrade monitoring and alerting systems that track on-chain activation signals, governance proposal status, and client release compatibility. For operators managing multiple ZK Stack hyperchains, we provide cross-chain upgrade compatibility analysis to ensure that a zkSync Era upgrade does not break inter-chain messaging or shared prover assumptions. Our upgrade readiness reviews verify that your node configuration, prover setup, and integration logic are aligned with the activation requirements before the target block arrives.

UPGRADE ACTIVATION MODEL

Quick Facts

Key operational facts about how protocol upgrades are activated on zkSync Era and who must act.

Area	What changes	Who is affected	Action
Activation Trigger	Upgrades are activated by a specific L2 block number or epoch, not a timestamp.	Node operators, exchanges, wallets	Monitor canonical block height to ensure client readiness before the target block.
Gateway Upgrade	The L1 ValidatorTimelock contract is used to commit new bootloader and default account hashes.	Bridge operators, security auditors	Verify the timelock delay and new hashes before the upgrade execution on L1.
System Contract Migration	New system contract bytecode is published, and the ContractDeployer migrates dependent contracts.	dApp developers, wallet teams	Audit your contracts' interactions with system contracts and test against the new versions on testnet.
Client Compatibility	A mandatory node and prover release is required to remain in consensus after the activation block.	Main node, external node, prover operators	Upgrade to the specified minimum client version before the activation epoch to avoid falling out of sync.
Transaction Format	New EIP-2718-like transaction types may be introduced, altering the L2 block structure.	Block explorers, indexers, SDK maintainers	Update parsing logic to handle new transaction types and ensure backward compatibility.
Fee Model	Intrinsic gas costs or new pricing dimensions (e.g., storage, L2->L1 logs) can change.	Wallets, paymasters, dApps	Recalibrate fee estimation logic and test transaction cost predictions immediately after the upgrade.
State Tree	The L2 state tree or storage log format may be altered, requiring a re-index.	Archive node operators, data pipeline teams	Plan for a full historical state re-index and validate data integrity post-upgrade.
Proof System	Changes to ZK circuit logic or the Executor facet alter validity proof generation.	Prover operators, security auditors	Verify prover compatibility with the new circuits and audit the state transition function changes.

technical-context

PROTOCOL UPGRADE LIFECYCLE

Activation Mechanism and Epochs

How mandatory protocol upgrades are scheduled, staged, and activated on zkSync Era using an epoch-based mechanism.

On zkSync Era, protocol upgrades are not activated by a single L1 transaction height but are scheduled using an epoch-based mechanism governed by the ValidatorTimelock on Ethereum. An upgrade is proposed by the governance system and, after a mandatory timelock delay, becomes executable. The execution on L1 commits a new set of hashes for the bootloader and default account implementations, and specifies a target protocol version. This new version is not immediately active; the L2 system waits for the next epoch boundary to transition.

An epoch on zkSync Era is a contiguous range of L2 blocks. The protocol version is incremented only at the start of a new epoch. When the sequencer observes that the L1 gateway has authorized a new protocol version, it completes the current epoch and begins a new one with the upgraded system contracts. This mechanism ensures that all transactions within an epoch execute under a single, consistent set of protocol rules, preventing state transition inconsistencies. For operators, this means the cutover point is deterministic and predictable, based on the L2 block number that marks the epoch boundary, not an unpredictable L1 confirmation time.

The practical impact for exchanges, wallet teams, and node operators is that maintenance windows must be planned around the expected L2 block height of the epoch transition. After the L1 upgrade transaction confirms, there is a bounded window before the sequencer finalizes the current epoch. Teams must have their nodes updated to a version that supports the new protocol version before this boundary to avoid falling out of sync. Monitoring the NewProtocolVersion event from the L1 gateway and the BlockCommit event on L2 provides the precise signal for activation. Chainscore Labs can help infrastructure teams build automated monitoring and alerting systems that track this lifecycle, ensuring operational readiness for every mandatory upgrade.

UPGRADE ACTIVATION IMPACT

Affected Actors

Node Operators

Operators of the main node and external node must track the L2 block number or epoch at which a new protocol version activates. Failing to update the node binary before the activation height results in a state divergence and an inability to sync with the canonical chain.

Action items:

Monitor the canonical upgrade announcement for the exact protocol_version and activation block.
Validate the new binary against the published checksums and reproduce the upgrade on a testnet node first.
Schedule a maintenance window to restart the node with the new version before the activation epoch.
Verify post-upgrade that the node is producing blocks or syncing correctly and that no protocol_version mismatch errors appear in logs.

implementation-impact

UPGRADE ACTIVATION READINESS

Operational Impact Areas

Mandatory protocol upgrades on zkSync Era are keyed to specific L2 block numbers or epochs. The following areas require direct operational action from node operators, exchanges, and infrastructure teams to avoid service disruption or chain splits.

Node and Prover Client Updates

Every protocol upgrade mandates a minimum main node and external node version. Operators must apply updates before the activation epoch to remain in sync. Prover operators face additional urgency: new circuit logic or state transition function changes require a compatible prover binary to generate valid proofs. Failure to update results in dropped proofs and potential economic penalties. Chainscore can perform an upgrade procedure validation and operational readiness test for your infrastructure.

EXPLORE

Exchange and Wallet Maintenance Windows

Exchanges and wallet providers must schedule maintenance windows around activation epochs. Deposit and withdrawal services should be paused or monitored during the upgrade to prevent transaction submission against an outdated state view. Post-activation, teams must verify that transaction construction, gas estimation, and signature validation remain compatible with any new bootloader or default account hashes. Chainscore offers an integration verification service to validate compatibility before and after the upgrade.

Smart Contract and System Contract Compatibility

Upgrades may alter system contract addresses, modify the ContractDeployer logic, or introduce new precompiles. Smart contracts relying on hardcoded system contract addresses or specific gas metering behavior can break. Developers must review the upgrade's system contract migration guide and test against the new protocol version on testnet. Chainscore provides a migration impact assessment to identify and remediate breaking changes in your codebase before mainnet activation.

Indexer and Data Pipeline Re-synchronization

Changes to the L2 block structure, transaction format, or storage log schema can force indexers, block explorers, and data pipelines to re-index historical state. Archive node operators must plan for increased storage and processing time during state tree migrations. Teams should monitor upgrade announcements for data format changes and test their parsing logic against testnet blocks. Chainscore can assist with data infrastructure update planning and format compatibility testing.

Bridge and Cross-Chain Message Monitoring

Gateway upgrades on L1 alter the core bridge contract's execution flow and timelock behavior. Bridge operators and asset issuers must verify that cross-chain message relaying and finality tracking remain accurate after the ValidatorTimelock commitment of new hashes. Any mismatch in state reconstruction from L1 pubdata can halt withdrawals. Chainscore offers a bridge security review to validate your relayer logic against the upgraded protocol state.

Automated Upgrade Monitoring and Alerting

Relying on manual checks of governance forums or GitHub releases for activation timelines creates a risk of missing a mandatory update. Teams should implement automated monitoring that tracks on-chain epoch boundaries, L1 gateway contract events, and node version requirements. Chainscore can help you build a custom upgrade monitoring and alerting system that provides early warning of upcoming protocol changes, ensuring your team never misses a critical maintenance window.

UPGRADE ACTIVATION RISK ASSESSMENT

Risk Matrix

Operational risks introduced by protocol upgrade activation on zkSync Era, keyed by L2 block number or epoch. This matrix helps node operators, exchanges, and infrastructure teams identify failure modes and required actions during a network upgrade.

Risk Area	Failure Mode	Severity	Affected Actors	Mitigation
Client Version Mismatch	Node or prover running an incompatible version after the activation block, leading to a chain split or inability to produce valid proofs.	Critical	Node operators, Prover operators	Verify minimum client version against the canonical upgrade announcement before the activation epoch. Implement automated upgrade monitoring.
State Transition Incompatibility	A change in the bootloader, default account, or a precompile alters transaction validity rules, causing previously valid transactions to revert.	High	Wallet teams, dApp developers, Exchanges	Audit state transition function changes in the upgrade specification. Replay testnet transactions against the new execution environment.
API and SDK Breakage	A breaking change to the node's JSON-RPC API or associated SDKs causes integration failures for downstream services after activation.	High	Block explorers, Indexers, Data pipeline operators	Review the backward-compatibility policy for the specific upgrade. Update parsing logic and SDK dependencies during the testnet phase.
Fee Estimation Failure	Changes to intrinsic gas costs or new pricing dimensions break transaction cost estimation, causing transactions to stall or fail.	Medium	Wallets, Paymasters, dApps	Integrate updated fee estimation logic from the latest SDK release. Monitor gas usage on testnet for representative transaction types.
Bridge Finality Delay	An upgrade to the L1 gateway contracts or a change in proof submission logic extends the time for L2 finality on L1, delaying deposits or withdrawals.	Medium	Bridge operators, Liquidity providers, Asset issuers	Confirm the new ValidatorTimelock and proof submission parameters. Update monitoring alerts for bridge transaction finality.
Data Availability Format Change	A modification to the pubdata compression or posting format prevents external systems from reconstructing L2 state from L1 data.	High	DA providers, External provers, Bridges	Validate the new pubdata format against your state reconstruction logic. Ensure compatibility with blob usage strategies.
System Contract Migration Error	A dApp or wallet continues to interact with an old system contract address after a migration, leading to unexpected reverts or security issues.	High	dApp developers, Wallet teams	Verify the ContractDeployer migration logic. Update all hardcoded system contract addresses to the new canonical versions.
Prover Circuit Incompatibility	An upgrade to the ZK circuit logic invalidates existing proof generation pipelines, causing a halt in proof submission.	Critical	Prover operators	Perform a full proof generation test on the testnet with the upgraded circuits. Audit circuit upgrade impact before mainnet activation.

MANDATORY PROTOCOL UPGRADE READINESS

Pre-Upgrade Operator Checklist

A structured checklist for node operators, exchanges, and infrastructure teams to validate readiness before a zkSync Era protocol upgrade activates at a target L2 block number or epoch. Completing these steps reduces the risk of service disruption, chain splits, or state transition failures.

What to check: The exact L2 block number or epoch at which the protocol upgrade activates on mainnet.

Why it matters: The upgrade is enforced by the L1 gateway contract and the L2 state transition function. Missing the activation point means your node will fail to produce valid blocks or sync with the canonical chain.

Readiness signal: You have cross-referenced the activation block number against the canonical governance announcement and your node's current sync status. Set a monitoring alert for the target block height minus a safety margin (e.g., 1000 blocks).

resource-links

ZKSYNC ERA UPGRADE TIMELINE SOURCES

Canonical Resources

Use these sources to verify zkSync Era upgrade activation windows, protocol-version changes, node release requirements, and live network health. Teams should reconcile every planned maintenance window against the official release, governance, and on-chain evidence before treating an activation height as final.

ZKsync Era Core Repository

The ZKsync Era core repository is the primary source for node, bootloader, system contract, prover, and protocol implementation changes. Operators should review release notes, tags, migration notes, and pull requests that mention protocol version changes before any scheduled activation. For upgrade timeline work, use the repository to map a announced activation block or epoch to the exact code path your infrastructure will run, then validate whether external nodes, provers, indexers, and custom RPC services require rebuilds or configuration changes.

EXPLORE

Official ZKsync Documentation

The official documentation is the baseline reference for ZKsync Era architecture, ZK Stack components, account abstraction behavior, bridging assumptions, and node operation. For activation timelines, documentation should be used to distinguish protocol-layer changes from application or SDK changes. Engineering teams should check whether an upgrade changes system contracts, transaction validation, pubdata format, fee accounting, or node requirements, then convert those findings into internal test cases and deployment runbooks.

EXPLORE

ZKsync Era Releases

Release pages are the fastest way to identify whether an activation requires a mandatory binary update, database migration, configuration change, or coordinated restart. Node operators and infrastructure providers should subscribe to release notifications, compare currently deployed versions against the latest tagged release, and stage upgrades on test infrastructure before the activation block. Do not rely only on social announcements; verify whether the release notes include breaking changes for external nodes, API behavior, prover compatibility, or system contract hashes.

EXPLORE

ZKsync Network Status

The network status page is useful during and immediately after an upgrade activation because it reflects service degradation, RPC disruptions, sequencer issues, explorer availability, and bridge-related incidents. Exchanges, wallets, and dApps should monitor it alongside their own block-height, finality, deposit, withdrawal, and RPC latency alerts. Treat status updates as operational signals, not as a substitute for validating your own node synchronization and transaction acceptance after the activation epoch.

EXPLORE

ZKsync Era Explorer

The official explorer helps teams confirm live L2 block progression, transaction inclusion, contract activity, and observable behavior around an activation height. For upgrade timeline tracking, use explorer data to verify whether the network crossed the expected block number, whether critical bridge or system-contract transactions occurred, and whether application transactions continue to execute as expected. Indexer and wallet teams should compare explorer observations with their own RPC responses to detect parser, caching, or node-version drift.

EXPLORE

Chains We Build On

Looking to build on a specific blockchain?

We build smart contracts, DeFi applications, wallets, tokenization platforms, and blockchain infrastructure across the major ecosystems teams choose today. That includes Ethereum, Arbitrum, Optimism, Polygon, Avalanche, Solana, Sui, Aptos, Hedera, Stellar, and NEAR, with support for additional EVM and non-EVM networks based on your product requirements.

Learn More

EVM ecosystems

Ethereum
Arbitrum
Optimism
Polygon
Avalanche
Cronos

Non-EVM ecosystems

Solana
Sui
Aptos
Hedera
Stellar
NEAR

Additional ecosystems

Polkadot
Cosmos
TON
Cardano
Algorand
Tempo

Also available for Base, appchains, custom EVM networks, and cross-chain product architecture.

UPGRADE PLANNING FAQ

Frequently Asked Questions

Common operational and integration questions about zkSync Era upgrade activation timelines and epoch-based scheduling.

Upgrades are scheduled by L2 block number or epoch, not by timestamp. The canonical timeline is published through official ZKsync governance channels and developer documentation. An upgrade is considered mandatory when it changes the state transition function, system contracts, or bootloader in a way that is not backward-compatible. Operators must monitor the canonical upgrade announcement channel to identify the target block number and ensure their node, prover, and dependent services are updated before that block is reached. Missing a mandatory upgrade causes the node to diverge from the canonical chain, leading to a service outage.

Key signals to monitor:

The exact L2 block number or epoch boundary for activation.
The minimum main node, external node, and prover client versions required.
Any system contract, bootloader, or default account hash changes that require integration updates.

Trusted by Industry Leaders

Delivering blockchain solutions for 5+ years.

We have partnered with 50+ leading DeFi protocols, NFT ecosystems, and fintech innovators to build secure, scalable, and capital-efficient blockchain products.

Selected Partners & Clients

“I've been working with Chainscore Labs for last 3+ years, they've consistently delivered with strong ownership across multiple projects. The team is reliable and detail-oriented.”

Lee Erswell

CEO, Telos Foundation

how to get started

How to get started?

If you're looking for blockchain integration, ChainScore Labs has 5+ years of experience helping teams build and integrate exchanges, wallets, smart contracts, tokenization solutions, and protocol-connected products, we can help you choose the right path, integrate securely, and get to production faster. Our team consists of experienced blockchain developers and architects who can help you with your blockchain integration needs.

Exploration & Strategy

Define your product goals and choose the right blockchain architecture for your use case.

Architecture & Design

Design the smart contracts, tokenomics, and security parameters of your system.

Development & Integration

Build and integrate with wallets, oracles, and front-end dApps for a seamless experience.

Security & Launch

Comprehensive audits followed by a risk-managed mainnet deployment to protect your users.

Learn More

Explore More Solutions

Discover our
blockchain development services.

We build production-grade blockchain solutions for top-tier projects across DeFi and Web3.

Book a Call

DeFi Protocol Development

End-to-end development of custom DeFi protocols including core smart contracts and system architecture.

DEX & Exchange Development

Building high-performance decentralized exchanges with optimized liquidity and advanced trading logic.

Lending & Borrowing Platforms

Scalable credit markets and money protocols built for production-grade liquidity and security.

Upgrade Activation Timelines and Epochs

Introduction

Quick Facts

Activation Mechanism and Epochs

Affected Actors

Node Operators