Zksync is an Ethereum Rollup Network Powered by the ZK Stack

Zksync is an Ethereum scaling system where rollups bundle transactions and zero-knowledge proofs verify correct execution without replaying every step. Its open-source ZK Stack supports interconnected rollup and validium chains, led by Zksync Era, for payments, swaps and applications that settle through Ethereum.

It is a network of Ethereum Layer 2 rollups and validiums that uses ZK proofs and the ZK Stack for scalable payments, swaps, and apps.

Faster Ethereum Actions for Wallet Users

On those terms, Zksync Era gives Ethereum wallet users faster inclusion and lower per-transaction overhead by batching activity before settling proofs and data to Ethereum. A payment, swap or contract call executes on EraVM, then shares batch-level proof and data costs with many other transactions. Users retain Ethereum-style addresses and wallets, while applications gain 1-second L2 block production and native account abstraction for programmable authorization. Frequent activity therefore consumes less L1 space per action while preserving settlement on Ethereum mainnet. The topic is examined in detail.

ZK Rollups, Optimistic Rollups and L1

Proof design separates Zksync from Arbitrum One, OP Mainnet and Starknet mainly through validation method, virtual-machine compatibility and withdrawal workflow for users and developers. Ethereum mainnet, chain ID 1, executes every transaction directly on L1. Era amortizes execution and data publication across a batch, adding a sequencer, prover and bridge contracts to the workflow.

Arbitrum One uses chain ID 42161 and OP Mainnet uses chain ID 10; both are optimistic rollups. They post transaction data and use challenge-based validation rather than proving every batch with a validity proof before settlement, a design that changes withdrawal timing and dispute dependencies even when the wallet workflow looks similar for the same transfer. Zksync uses a zero-knowledge proof path, so accepted proofs establish batch correctness cryptographically. Cost is driven by L1 data, L2 execution and congestion on each system, while every rollup retains distinct bridge, upgrade and sequencer assumptions.

Starknet also settles validity proofs to Ethereum, but its Cairo VM and contract tooling differ more sharply from EVM workflows. EraVM targets Solidity and Vyper compatibility, and the EVM Bytecode Interpreter accepts conventional EVM bytecode. Familiar Solidity or Vyper workflows point toward EraVM, while Cairo-native development points toward Starknet.

Moving ETH Into Zksync Era

Moving ETH into Zksync Era starts with selecting chain ID 324 in a compatible wallet and choosing an Ethereum-to-Era bridge route. The canonical path has 2 transactions: an L1 deposit and the resulting L2 execution, each with its own status and fee.

Network Selection

Era mainnet uses ETH as its native fee asset and 20-byte account addresses. MetaMask and Rabby can select Era as an EVM-compatible network.

The mainnet chain ID is 324, while Zksync Sepolia uses chain ID 300.

Deposit Route

The Portal Bridge uses a pair of contracts, 1 on Ethereum and 1 on Era, to lock the L1 asset and credit the corresponding L2 balance. Across and Layerswap provide alternative routes with different liquidity and settlement dependencies. ERC-20 representations have different contract addresses on L1 and L2, so a wallet balance must be read on the selected chain.

First Transaction

A first transfer establishes the route, L2 balance and explorer status before the wallet proceeds to swaps or contract calls. Retaining ETH on both layers preserves fee capacity for subsequent actions.

Worked example with hypothetical inputs: an Ethereum balance of 0.500 ETH, a bridge amount of 0.100 ETH and combined network fees of 0.002 ETH. After completion, 0.100 ETH appears on Era and 0.398 ETH remains on Ethereum because 0.500 − 0.100 − 0.002 = 0.398. These three changing inputs are hypothetical; the calculation isolates balance movement and reaches a concrete total without treating a market quote as fixed. Across both layers, the post-fee wallet total is 0.498 ETH.

What Can You Do on Zksync Era?

Everyday Ethereum-style activity on Zksync Era includes ETH transfers, ERC-20 swaps, lending positions, NFT operations and smart-contract deployment through compatible applications. Native account abstraction also lets smart accounts define signatures, spending rules and fee sponsorship at the protocol level.

• Payments: Send ETH or supported ERC-20 tokens between Era accounts.
• Trading: Swap assets or manage liquidity through Uniswap v3 pools.
• Lending: Supply collateral or borrow through an Era deployment such as Aave V3.
• Building: Deploy Solidity or Vyper contracts with Hardhat, Foundry, Ethers or Viem.

Asset behavior remains contract-specific even when the network feels familiar. ETH uses 18 decimal places, and 1 ETH equals 10^18 wei. ERC-20 defines fungible-token interfaces, ERC-721 assigns 1 owner to each token ID and ERC-1155 lets 1 contract manage multiple token classes. A Uniswap v3 swap adds pool liquidity and price impact to the network fee. An Aave V3 position adds collateral rules and liquidation thresholds defined by its market. Those application rules sit above Era settlement, and many applications use Chainlink Data Feeds.

Fees, Paymasters and the ZK Token

Fee calculation on Zksync Era combines L2 execution, proof-related overhead and Ethereum data publication, while paymasters add programmable sponsorship or ERC-20 payment flows. The quoted fee reflects computation, changed state, pubdata volume and the Ethereum cost of carrying that data.

Gas and Pubdata

Era uses 1 unified gasLimit for account validation, fee payment and execution. By comparison, EIP-4337 defines 3 separate limits: verificationGasLimit, callGasLimit and preVerificationGas. Zksync recommends maxPriorityFeePerGas of 0 because the chain does not use a priority-fee market. Its pubdata model binds maximum L2 gas per pubdata byte to 2^20. A complex contract call costs more when it writes additional state or publishes more data to Ethereum.

Paymasters and Governance

Paymasters are smart accounts able to sponsor fees or accept an ERC-20 under application-defined terms. Zksync standardizes 2 common input flows: general and approval-based. The latter requires an allowance large enough to cover the selected maximum fee. Separately, the ZK token has a 21,000,000,000 supply cap and carries governance power; ETH remains Era's default fee asset. Governance responsibilities are divided among 3 bodies: the Token Assembly, Security Council and Guardians.

Compatibility Limits and Operational Dependencies

The main trade-offs in Zksync come from bridge contracts, sequencer availability, proof infrastructure, application code and each ZK Stack chain's data-availability policy. Each dependency affects a different part of execution, finality or asset access.

EraVM is EVM-compatible, yet exact Ethereum behavior is not universal. Contract deployment, address derivation, gas accounting, system contracts and compiler output differ in places, even though the EVM Bytecode Interpreter reduces migration work and common tools such as Hardhat, Foundry, Ethers and Viem remain available for developers. A Solidity or Vyper project should run its complete tests on Zksync Sepolia before mainnet deployment. This distinction matters most for contracts relying on low-level opcodes, factory dependencies or assumptions carried over from Ethereum.

Bridge operations add a separate contract and timing path. A standard withdrawal burns the L2 representation, emits an L2-to-L1 message and waits a protocol-defined 3 hours before finalization on Ethereum. Default bridging covers ETH and standard ERC-20 behavior, while token designs with rebasing or custom transfer logic require a custom bridge. A validium chain adds an external data-availability dependency; unavailable data prevents independent state reconstruction until availability returns. Zksync Era instead publishes rollup data to Ethereum.

How Does a Zksync Transaction Reach Ethereum?

A Zksync transaction reaches Ethereum through three distinct layers: sequencer execution, batch proof generation and L1 contract acceptance of the state update. The wallet sees an early L2 result before the enclosing batch completes every Ethereum settlement stage.

Sequencer Inclusion

Era produces an L2 block every 1 second. The sequencer orders submitted transactions and gives a soft confirmation before Ethereum has accepted the enclosing batch.

Batch and Proof

An L1 batch groups multiple 1-second L2 blocks and closes when resource limits or timeout criteria require it. Era records state differences rather than publishing every executed instruction. State diffs, L2-to-L1 logs, messages and published bytecode form pubdata. Boojum generates validity proofs for Era batch execution, then Ethereum contracts verify the proof and update the accepted state. For JSON-RPC compatibility, an L2 block reports gasLimit as 2^32 − 1, a field value rather than a promise one transaction can consume the entire amount.

Settlement Statuses

The Zksync RPC exposes 3 relevant batch states. Committed means the state transition has been posted to L1; proven means Ethereum has accepted its validity proof; executed means the L1 state root has been updated. An L2-to-L1 withdrawal message becomes usable through an inclusion proof and a final L1 contract call. Applications requiring strong settlement assurance wait for proven or executed status.

ZK Stack Chains and Shared Settlement

The ZK Stack turns Zksync from one rollup into the Elastic Network, a configurable group of chains sharing Ethereum settlement, proof infrastructure, bridging and interoperability rules. A chain operator chooses execution settings and either rollup or validium data availability without replacing the shared validity-proof model.

Rollup mode publishes changed storage values to Ethereum through calldata or blobs, preserving Ethereum data availability. Validium mode moves pubdata to another availability system, reducing L1 data load while introducing a separate availability dependency. The specification describes 3 validium stages: Stage 0 stores pubdata only in operator nodes, Stage 1 sends it to a data layer without onchain inclusion verification and Stage 2 also verifies inclusion on L1. These stages classify availability guarantees rather than proof correctness.

The Shared Bridge and Chain Type Manager coordinate Ethereum contracts for chains using the same virtual machine and proof system. Validium inclusion checks use 2 roles, an L2 data-availability validator and an L1 data-availability validator. ZK Stack chains such as Abstract, Lens and Sophon choose their own applications and operating policies, while the shared architecture ties their accepted proofs back to Ethereum alongside Zksync Era.

Practical questions