# zksync (matter-labs/zksync): ZK Rollup for Ethereum, and the Exit Tool That Outlived It

> The repository is the original ZKsync Lite codebase, now in deprecation. Its most useful surviving artifact is the Exit Tree Generator, a Rust binary that builds a Merkle proof so a Lite account holder can withdraw funds directly from the mainnet withdrawal contract.

**matter-labs/zksync** — zkSync: trustless scaling and privacy engine for Ethereum

- Repository: https://github.com/matter-labs/zksync
- Website: https://zksync.io
- Stars: 4,923 · Forks: 2,650
- Language: Rust
- License: Apache-2.0
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/matter-labs-zksync

## What the zksync repository actually contains today

The README opens with a deprecation notice: ZKsync Lite is being deprecated, and users are pointed at lite.zksync.io to withdraw funds. That single paragraph reframes the whole repository. What remains is a Rust workspace of roughly forty crates, a Solidity contracts directory, two SDKs (sdk/zksync.js and sdk/zksync-rs), an explorer under infrastructure/, and a set of operational binaries under core/bin. The stated scope of Lite was narrow from the start: the README describes it as a scaling and privacy engine whose "current functionality scope includes low gas transfers of ETH and ERC20 tokens in the Ethereum network." No general-purpose smart contracts, no arbitrary computation. If you arrived expecting a zkEVM, this is not it. The last push to the repository was on 2026-05-08, which is recent enough that the code is not frozen, but the release list stops at contracts-7 (Security upgrade) on 2021-11-12. Those two facts together describe a repository kept alive for one purpose: letting people get their money out.

## How ZK Rollup works in this codebase

The README gives a compact account of the mechanism. All funds sit in a smart contract on Ethereum mainnet. Computation and storage happen off-chain. For every Rollup block, a state transition zero-knowledge proof (SNARK) is generated and verified by the mainchain contract, and that SNARK covers the validity of every transaction in the block. The public data update for each block is published to mainnet as calldata, which is the cheap part.

Three guarantees follow, and the README spells them out. A validator can never corrupt state or steal funds, unlike a sidechain. Users can always retrieve funds even if validators stop cooperating, because the data is available, unlike Plasma. And because the proofs are validity proofs, nobody has to stay online watching blocks to prevent fraud. The repository layout mirrors that split. core/bin/zksync_eth_sender talks to L1, core/bin/zksync_witness_generator and core/bin/prover handle proof production, core/bin/zksync_api serves clients, and core/lib/circuit holds the constraint system. The trade-off is inherent: proof generation is expensive and the circuit is fixed, which is exactly why Lite could only move ETH and ERC20 tokens.

## Withdrawing from ZKsync Lite with the Exit Tree Generator

This is the one workflow the README documents in full, and the only reason most people will clone the repository. The Exit Tree Generator is a Rust binary at core/bin/exit_tree_generator. The flow is three steps.

First, download the snapshot of the ZKsync Lite state at the last verified block. The README gives a URL and an IPFS CID, and states the archive contains accounts.csv, balances.csv and tokens.csv.

Second, build the leaves for the Keccak tree. The README gives this command:

```bash
cargo run --release --bin zksync_exit_tree_generator -- create-new-leaves \
    --accounts accounts.csv \
    --balances balances.csv \
    --tokens tokens.csv \
    [--output new_leaves.csv]
```

The output flag is optional; without it the tool writes new_leaves.csv by default. Expect this step to be the slow one, since it hashes every account and balance entry.

Third, produce the proof for your own account and tokens:

```bash
cargo run --release --bin zksync_exit_tree_generator -- create-proof \
    --account <YOUR_ACCOUNT_ADDRESS> \
    --tokens <TOKEN_ADDRESS_1> [<TOKEN_ADDRESS_2> ...] \
    [new_leaves.csv]
```

The binary prints a proof. Submit that proof to the mainnet withdrawal contract at 0x0a14b696350546110a0d8acdb86226983af9d2a0. The contract exposes two methods. claim sends the funds to msg.sender, which is what you want when the submitting wallet is the address that held the Lite account. claimTo sends them to a recipient you specify, for a cold wallet or a different EOA. Both take the account address, the token addresses and the proof. The README notes you can call them from Etherscan's Write Contract tab or from any wallet that can encode a contract call. The generator README additionally describes verifying the Keccak Merkle root, restoring the original ZKsync Merkle root (which the documentation calls a heavy computational task, around six hours) and restoring the tree from a database.

## Where the repository is thin, and where it is the wrong tool

The README does not document rollback, and it does not describe what happens if the snapshot at the last verified block is incomplete or if your account is missing from accounts.csv. There is no troubleshooting section for a proof that the withdrawal contract rejects. The documentation also does not state which block the snapshot corresponds to beyond the phrase "last verified block," so you cannot independently confirm you have the right archive without checking the IPFS CID yourself.

The bigger limitation is architectural. ZKsync Lite is not a general computation environment. If your project needs arbitrary Solidity contracts on L2, this repository cannot provide them, and the deprecation notice makes clear that the Lite line is not where new work is going. The repository also carries the operational weight of a full rollup: docker-compose.yml brings up postgres on 5432 and a geth image on 8545 and 8546, and docs/launch.md is a separate document because standing the stack up locally is not a one-command affair. If you only want to move tokens cheaply today, the exit tooling is the wrong entry point; it exists to leave, not to use.

## The alternative: build on a general-purpose zkEVM instead

The natural alternative is a general-purpose zkEVM, where the circuit supports arbitrary EVM bytecode rather than a fixed set of token-transfer operations. The difference in approach is the constraint system. Here, core/lib/circuit encodes a small, fixed instruction set, which keeps proving costs manageable and is why Lite could only do ETH and ERC20 transfers. A zkEVM accepts the full EVM, which means a much larger circuit, higher proving overhead, and a different set of engineering problems around witness generation and memory layout. For a team that needs smart contracts on L2, that is the trade you have to make. For a team that needs to understand how a minimal ZK Rollup is assembled in Rust, with an eth_sender, a witness generator, a prover and a state crate, this repository is a more legible artifact than a full zkEVM, precisely because the scope is small.

## Building the workspace, licensing and upgrade cost

The repository is a Cargo workspace with a pinned rust-toolchain file, so the toolchain version comes from the repository rather than your machine. The JavaScript side is a Yarn workspace rooted at package.json, named zksync-root, with workspace scripts for zksync, crypto, contracts, zk and reading-tool. Building the SDKs means running yarn build:zksync-sdk, which chains yarn build:crypto and yarn zksync prepublish. The Rust binaries build through cargo, as the exit-tree commands above show.

On licensing, the README states ZKSync is distributed under the terms of both the MIT license and the Apache License (Version 2.0), with LICENSE-APACHE and LICENSE-MIT at the repository root. The package.json declares MIT. Dual licensing of this kind generally lets you choose either set of terms, but the details matter for redistribution and I am not in a position to give legal advice; read both files if you plan to ship derived code.

Upgrade cost is the honest problem. The changelog is split by component (contracts, core, infrastructure, js-sdk, rust-sdk), and the newest release in the list is contracts-7 from 2021-11-12. There is no evidence of ongoing feature development in the release history. Treat any dependency on these crates as a dependency on a frozen interface that you will maintain yourself.

## Conclusion

Adopt this repository only if you are a ZKsync Lite account holder who needs the Exit Tree Generator, or an engineer studying how a ZK Rollup's off-chain state, SNARK proofs and Ethereum settlement were wired together in Rust. Do not adopt it as a starting point for a new rollup: the README states Lite is being deprecated, and the changelogs have not moved since the 2021 contracts releases. Before running anything, verify the snapshot archive against the IPFS CID QmSqzPQNRcz3grznTMCYDDunDFGZCXFFjew7fgYpFcGYoh, confirm the withdrawal contract address 0x0a14b696350546110a0d8acdb86226983af9d2a0 on Etherscan, and read core/bin/exit_tree_generator/README.md for the root-verification workflow.

## FAQ

### What is ZKsync Lite in this repository?

The README describes ZKsync Lite as a scaling and privacy engine for Ethereum whose current functionality scope covers low gas transfers of ETH and ERC20 tokens. It is built on ZK Rollup architecture, with funds held by a mainchain smart contract and computation performed off-chain.

### How do I use zksync to withdraw my funds?

The README's flow is three steps: download the snapshot archive containing accounts.csv, balances.csv and tokens.csv, run the Exit Tree Generator's create-new-leaves command, then run create-proof for your account and token addresses. Submit the printed proof to the mainnet withdrawal contract at 0x0a14b696350546110a0d8acdb86226983af9d2a0 using either claim or claimTo.

### Is zksync dead?

The README carries a deprecation notice stating that ZKsync Lite is being deprecated and directing users to lite.zksync.io to withdraw funds. The repository itself is not archived and its last push was on 2026-05-08, but the newest release listed is contracts-7 from 2021-11-12.

### What are the benefits of zksync?

According to the README, the ZK Rollup architecture means validators can never corrupt state or steal funds, users can retrieve funds even if validators stop cooperating because the data is available, and validity proofs mean nobody needs to stay online monitoring blocks to prevent fraud.

### What is ZKsync in crypto?

In this repository, ZKsync is a ZK Rollup: all funds are held by a smart contract on the mainchain while computation and storage happen off-chain, and each Rollup block gets a state transition SNARK verified by the mainchain contract. The README states the architecture strictly inherits the security guarantees of the underlying L1.

## Sources

- [License: Apache-2.0](https://github.com/matter-labs/zksync/blob/master/LICENSE)
- [matter-labs/zksync on GitHub](https://github.com/matter-labs/zksync)
- [Project website](https://zksync.io)
- [README](https://github.com/matter-labs/zksync/blob/master/README.md)
- [Releases](https://github.com/matter-labs/zksync/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/matter-labs-zksync