ZKsync Lite Stopped Producing Blocks. Its Exit Plan Yields a Rollup-Retirement Runbook

On May 4, 2026, ZKsync Lite stopped producing blocks. That sentence sounds like a chain disappeared. It did not mean that users' assets disappeared with it—or that their balances automatically moved to ZKsync Era.

That distinction is the useful part of the event. ZKsync Lite's public withdrawal page still describes the network as sunsetted and directs users to recover funds. Matter Labs' maintained repository also publishes a path for independently constructing a withdrawal proof and submitting a claim on Ethereum. A chain can stop executing new transactions while the machinery that proves and recovers its final state remains available. ZKsync's sunset announcement, Lite withdrawal page, and exit-tree documentation

That is a much better test for a retirement than whether a project has a successor brand. A successor may be useful. It is not the safety property. The safety property is simpler: after the operator stops the chain, can a user still recover what the chain says they own without asking that operator for permission?

The retirement contract: six guarantees before a chain can stop​

The following table is the core runbook. It is deliberately rollup-neutral: an optimistic rollup, a validity rollup, and another system will use different proofs and contracts, but a user needs the same outcomes. ZKsync Lite supplies a concrete case rather than a universal recipe.

Two details keep this table honest. First, a final-state snapshot is not the asset recovery itself; it is evidence used to make recovery possible. Second, “operator-independent” does not mean “dependency-free.” It means a sequencer or support desk is not the sole gatekeeper. The settlement chain, the withdrawal contract, public data, software, and a user's ability to sign an Ethereum transaction all remain part of the system.

That is still a meaningful improvement over a shutdown notice that says, in effect, “withdraw before Friday or contact support.” A rollup's security story begins with the ability to exit while it is live. A credible retirement proves that the property survives the end of live operations.

Lite's worked example: snapshot, proof, claim​

ZKsync Lite was a transfer-oriented ZK rollup. Its repository describes the shutdown recovery flow in three broad steps: obtain the account, balance, and token snapshot for the last verified state; build the necessary Merkle-tree material; then generate a proof for a particular account and token set. The resulting proof can be submitted to the Ethereum withdrawal contract. The documented contract methods distinguish claim, which sends assets to the caller, from claimTo, which sends them to a specified recipient. Matter Labs' recovery instructions

That sequence is worth unpacking because it separates convenience from the guarantee:

1. The hosted withdrawal form is the convenient route. It can guide a normal user through the claim path.
2. The snapshot is the recovery evidence. It records the terminal state from which a claimant's balance can be demonstrated.
3. The Exit Tree Generator is the fallback route. It lets a technically capable user reconstruct the claim proof from public artifacts rather than depend solely on the form staying online.
4. The Ethereum contract is the settlement route. It is where the recovered asset becomes available on L1.

The ordering matters. A web interface can fail, be blocked by a browser change, or become poorly maintained. If the only exit lives behind that interface, the chain has replaced a protocol guarantee with a customer-service dependency. Conversely, an opaque data dump without buildable proof tooling leaves users unable to turn data into a claim. Lite's design pairs both paths: a practical interface and a documented, local method.

This is also why “forced bridge-out” is an imprecise description of the event. The safety path settles assets to Ethereum. A user may subsequently bridge ETH or supported tokens to ZKsync Era, another network, or a self-custody address, but that next move is a new user decision. It is not a silent migration of one rollup state machine into another.

Turn the case study into an operator runbook​

For a team retiring a rollup, sidechain, appchain, or even a hosted execution service, the work should be organized as an evidence-producing sequence—not as a single decommissioning date.

1. Announce the freeze and define the terminal state​

Publish the date, time, and block or state boundary at which new execution ends. Explain which actions stop immediately, which operations remain available, and whether deposits are disabled earlier. The announcement should be machine-readable as well as human-readable: wallets, explorers, bridges, indexers, and custodians all need a reliable signal.

2. Commit the final state and publish the recovery inputs​

Make the final state commitment discoverable on the settlement layer where the system's security ultimately rests. Publish the state data, checksum it, mirror it across independent locations, and document how to verify that it corresponds to the commitment. For a ZK rollup, this may involve a final verified state root and Merkle proofs; another design may use a different withdrawal, fraud-proof, or exit construction. The test is not the name of the mechanism. It is whether an outside party can check the claim against the committed state.

3. Preserve a permissionless exit, not merely a help channel​

Users need a route that remains usable when the operator is unavailable, unresponsive, or no longer funded. That route should state the contract address, required calldata or proof format, supported token behavior, estimated L1 gas costs, and failure modes. If a service does not have an L1 settlement contract, it needs an equally clear custody and redemption guarantee; a support inbox is not one.

4. Archive the operational dependencies​

Save more than chain data. Publish source code, versioned binaries or reproducible builds, ABI files, contract verification links, the final configuration, and instructions for running recovery tooling without a vendor account. Archive explorer data and token metadata where possible. Lite's documented Exit Tree Generator is a useful pattern: it makes the recovery method inspectable rather than treating a hosted UI as the only source of truth.

5. Run a recovery drill before retiring​

This is the step teams are most likely to skip. Select representative balances: a plain ETH balance, an ERC-20 balance, a smart-contract wallet if supported, and an account that uses a different destination. Rebuild the proof in a clean environment, submit a claim on a test path where feasible, and record the result. Measure the full experience: artifact download, checksum verification, tool build, proof generation, gas estimation, transaction inclusion, and asset receipt.

The point is not to promise that every user has the same technical skill. It is to prove that the system does not rely on an untested operator escape hatch. If the independent route is too difficult for ordinary holders, the team can improve the UI and documentation—but it should not delete the independently verifiable route that makes the UI trustworthy.

Why Era is not the protocol-level destination​

Lite and Era share a name and a lineage, but they do not share an interchangeable application state. Contemporary reporting on the planned retirement described Lite as a lightweight network for transfers, NFT minting, and basic swaps, without smart-contract support; Era launched as a full-EVM-compatible environment. Decrypt's December 2025 report

That difference explains why the safe answer is “exit to Ethereum,” not “copy every Lite account to Era.” A balance claim is one thing. Porting contract storage, applications, token assumptions, transaction histories, and permissions between different execution environments is another. Even where a product can make the next step feel seamless, users and developers need to know which part is protocol-level recovery and which part is a new migration process with its own risks.

This distinction generalizes beyond ZKsync. A successor network can be commercially attractive, technically better, or easier to use. It should never be used to obscure whether the retiring system has an exit path that stands on its own.

What one sunset does—and does not—prove about L2 consolidation​

It is tempting to turn Lite's shutdown into a market forecast: a long tail of L2s exists, so a wave of forced consolidation must follow. The data does not justify that conclusion. L2BEAT's current catalog shows 22 rollups, six validiums/optimiums, and 77 other projects, while the value distribution is highly uneven. That is useful context for asking which systems have durable demand, but it does not reveal each team's runway, user commitments, upgrade plans, or exit design. L2BEAT's current Layer 2 catalog

Nor does Lite prove a universal migration pattern. Its withdrawal mechanism benefits from a design in which state commitments and recovery settle against Ethereum. Other systems may expose different guarantees, and some may not provide a comparably permissionless exit at all. The lesson is narrower and more actionable: before calling a network “finished,” ask to see the final-state evidence, the recovery contract, the independent tooling, and the drill record.

Retirement is complete when recovery no longer needs the operator​

ZKsync Lite's May shutdown is not just a story about a legacy product making room for a newer one. It is a useful demonstration of what software infrastructure owes its users when live operation ends: a final state they can inspect, a recovery path they can invoke, and enough durable material to use that path without trusting a remaining web service.

For rollup operators, that is the standard to build long before a sunset is on the roadmap. For users and integrators, it is the question to ask before trusting a chain with value: if block production stops, what exactly can I do next—and can I do it without asking you?

Sources​

• ZKsync: “Why and How We're Sunsetting ZKsync Lite”
• Matter Labs: ZKsync Lite recovery and Exit Tree Generator documentation
• ZKsync Lite withdrawal page
• L2BEAT: Layer 2 value and project catalog
• Decrypt: planned retirement context and Lite/Era distinction