Zksync is an Ethereum Layer 2 with an ETH Bridge Lifecycle from Deposit to Finalized L1 Exit

Network and Recipient Mismatch

Two chain identifiers define the route: Ethereum mainnet uses 1 and Zksync Era uses 324, so the wallet network must match the transaction leg.

An externally owned account controlled by one key has the same 20-byte address on both networks. A smart contract requires closer attention because code and state live separately on each chain; an address active on Ethereum does not establish an equivalent Era deployment. MetaMask and Rabby Wallet display the active network before signing, while a WalletConnect session passes that network choice to the connected interface. Chain ID, recipient and direction should agree before the request leaves the wallet.

A deposit to an externally owned account credits the familiar hexadecimal address after its L2 execution. Contract recipients need confirmed deployment and ETH-receiving behavior on Era first. A wallet confirmation showing chain 324 establishes the network, not recipient compatibility; those remain separate facts throughout the round trip. For an EOA recipient, the same checksum address should appear in both wallet views before the workflow continues. That check prevents a valid bridge transaction from delivering value to an address with no usable withdrawal path.

Prepare the Two-Network Route

Three items should be recorded before signing: the source network, the 20-byte recipient address and enough ETH on each network to pay its transaction.

An Ethereum address renders those 20 bytes as 40 hexadecimal characters after the 0x prefix. Select Ethereum for the deposit, record the intended Era recipient and add Zksync Era with chain ID 324 if the wallet has not stored it. The same wallet should also expose an Era balance view, since an Ethereum balance cannot confirm L2 execution. Keep a separate record of the amount, recipient and transaction hash rather than treating the wallet's combined portfolio value as settlement evidence.

Gas comes from the network executing each step. Ethereum ETH pays for the deposit and later L1 finalization; Era ETH pays for the internal transfer and withdrawal initiation. The deposit amount should exclude ETH reserved for L1 gas because the same units cannot fund both principal and execution. Quotes move with base fees, gas used and pubdata, so the useful preparation is a positive balance on both networks. After deposit, switching to Era reveals an independent base-token balance.

Deposit ETH From Ethereum

One Ethereum transaction starts an ETH deposit through BridgeHub, with the value and estimated L2 execution cost carried in the signed request.

BridgeHub selects chain 324, routes the base token through SharedBridge and creates an L1-to-L2 request for the chosen recipient. Native ETH needs no ERC-20 allowance, so the user signs one deposit transaction rather than an approval followed by a deposit. The transaction value funds the requested L2 value and the quoted execution requirement. SharedBridge holds the corresponding ETH on Layer 1, preserving 1:1 backing for the amount represented as native ETH on Era. Because ETH is the base token, the confirmation does not require a separate ERC-20 token address.

The request enters the priority queue and reaches Era as an L1-originated priority transaction, represented internally by type 255 or 0xff. Its Ethereum receipt proves the request was accepted on L1; the related L2 receipt proves execution. If the priority operation returns Failed, no spendable balance appears. The proof-bearing failure record supports the SharedBridge failed-deposit claim after the batch data reaches Ethereum. That recovery follows the deposit path because no ETH was credited on Era. For a successful request, both hashes belong in the lifecycle record.

Read the L2 Balance and Status

Four transaction states organize the receipt lifecycle - Pending, Included, Verified and Failed - while the balance changes only after the L2 execution succeeds on Era. Pending awaits a block, Included records execution before full L1 settlement and Verified follows batch commitment, proof and execution on Ethereum. Failed means the requested state change did not complete. Zksync Explorer and compatible wallet RPC views expose the L2 hash, status and resulting balance, separating a submitted deposit from spendable ETH.

Transfer ETH Inside Era

Eighteen decimal places define ETH accounting on Era, so one ETH equals 10^18 wei before any internal transfer is signed by the connected wallet.

Era treats ETH as its native base token, not as a default-bridge ERC-20 balance. A routine adjustment therefore uses one L2 transaction and consumes one account nonce. Standard external accounts support Ethereum-style type 2 EIP-1559 transactions, while custom accounts use Zksync's type 113 EIP-712 format for account-abstraction fields. Era has no priority-fee market, and the recommended maxPriorityFeePerGas value is 0.

The sender balance falls by the transferred value plus the Era execution fee; the recipient balance rises by the value after successful execution. That fee follows gas used, the batch base fee and published state differences rather than the amount moved. The eth_getBalance RPC call on chain 324 returns wei, which wallets format to 18 decimal places. A one-wei difference remains visible at the raw RPC level even when a wallet rounds its displayed balance. Read the confirmed balance before initiating an exit, especially when another transfer or application interaction has changed the nonce and available ETH.

A Worked Balance Adjustment

Four hypothetical changing inputs drive this worked example: a 0.500 ETH deposit, a 0.200 ETH transfer, a 0.050 ETH receipt and a 0.010 ETH reserve.

Start from the confirmed 0.500 ETH Era balance. Sending 0.200 ETH leaves 0.300 ETH before transaction charges, then receiving 0.050 ETH raises the tracked amount to 0.350 ETH. Holding back 0.010 ETH produces a concrete planned withdrawal of 0.340 ETH: 0.500 − 0.200 + 0.050 − 0.010 = 0.340. The 0.340 ETH is the principal placed in the withdrawal request, not the recipient's net wallet change if that recipient also pays finalization gas. The live withdrawal quote accounts for its L2 execution charge, while Ethereum gas comes from a separate L1 balance. Recalculate from receipts before signing.

Initiating the L2 Withdrawal

Two user-signed transactions complete the canonical exit: one withdrawal on Era and one finalization on Ethereum after the batch becomes executable on L1.

For native ETH, L2BaseToken.withdraw removes the specified amount from Era and sends an L2-to-L1 message through L1Messenger. The recipient is encoded into that message, while the released ETH remains locked on Ethereum until proof-backed finalization. Preserve the 32-byte L2 transaction hash, displayed as 64 hexadecimal characters after 0x, because proof tools use it as the primary lookup key. After successful L2 execution, the amount and recipient are fixed in the message; another transfer changes only the remaining balance. If one transaction contains several withdrawals, a zero-based index distinguishes them and index 0 is the default.

What Makes a Withdrawal Ready to Finalize?

Three hours is the enforced minimum execution delay for supported Zksync chains, but proof generation and batch scheduling determine the longer observed wait.

Readiness means the withdrawal's batch has reached executeBatches on Ethereum and its L2-to-L1 log proof is available. A commit records batch data, and a successful proof establishes the state transition, yet neither alone releases the recipient's ETH. The delay applies before the batch becomes final on L1; it is not a countdown promising completion at exactly three hours. An ethExecuteTxHash or an executed batch state gives stronger evidence than elapsed wall-clock time. Once proof becomes available, the remaining wait is ordinary Ethereum inclusion time for the user's L1 finalization transaction.

The Proof-Bearing L1 Finalization

One 32-byte L2 transaction hash anchors finalization, and an optional zero-based log index identifies a specific withdrawal when several share that transaction.

The Zksync SDK can derive finalization parameters containing the L1 batch number, L2 message index, L2 transaction position and Merkle proof. Each proof element is 32 bytes, matching the fixed-size hashes used in the log tree. The zks_getL2ToL1LogProof RPC method accepts the withdrawal hash plus an optional index, allowing software to retrieve the proof without reconstructing the full batch. The log proof becomes available only after the corresponding L2 transaction has been executed on Ethereum.

L1SharedBridge.finalizeWithdrawal verifies the message and releases the locked ETH to its encoded recipient. Anyone can submit the finalization call once the proof exists, so the submitting account and recipient need not match; the submitter pays Ethereum gas. The proof fixes the amount and recipient, while the finalizer chooses only the sending account and Ethereum gas settings. The isWithdrawalFinalized check uses the same withdrawal hash and defaults to index 0. After mining, the bridge records the message as spent and the recipient receives the L1 funds.

The Three Rollup Stages Behind the Wait

Three distinct Ethereum settlement operations - commitBatches, proveBatches and executeBatches - move an L2 batch from posted data to verified proof and finally an executable withdrawal message.

ExecutorFacet manages those stages in the rollup contracts. The commit operation records state differences and L2-to-L1 logs, the prove operation validates the Boojum proof and the execute operation finalizes the state transition. A detailed receipt can expose three corresponding L1 references: ethCommitTxHash, ethProveTxHash and ethExecuteTxHash. L1Messenger contributes the withdrawal message to a Merkle tree, which lets a compact branch prove inclusion without replaying every transaction in the batch. Included identifies L2 execution, while Verified reflects the later L1-settled state. Execution turns the branch into usable finalization data.

Close the Loop on Ethereum

One successful Ethereum receipt closes the lifecycle, and the recipient's L1 ETH balance should rise by the withdrawn amount while the finalizer pays gas.

A canonical round trip containing one internal transfer produces five useful references: the L1 deposit, derived L2 deposit, L2 transfer, L2 withdrawal and L1 finalization hashes. Match the final receipt's recipient and value to the withdrawal message, then retain the hashes until isWithdrawalFinalized returns true and the Ethereum balance reflects the release. Those receipts separate protocol completion from wallet display and preserve every cross-network balance change in one transaction trail.