zkSync Era Portfolio Tracking: Validity Finality and the Withdrawal Delay

The catch with zkSync Era is that its balance model looks like Ethereum's while its finality does not. A transaction is shown and usable on L2 almost immediately, but it is only final once a validity proof is verified on Ethereum, and a withdrawal back to L1 cannot execute until a further delay after that. So the distinct tracking problem on zkSync is timing, not state shape: an asset can be spendable on L2 while a bridged withdrawal of it is still in flight, and a tracker that conflates "visible on L2" with "settled on L1" double-counts funds. This article covers the commit-prove-execute pipeline and the withdrawal-in-progress state, plus the Type-4 zkEVM nuances. The sibling validity rollup is Starknet; both feed the non-EVM aggregation hub.

EVM balances, non-EVM finality

• zkSync Era is EVM-like in its balance model but not in its finality.
• A transaction is usable on L2 quickly; full finality comes only when a validity proof is verified on Ethereum, which takes longer.
• The pipeline is commit (no proof), then prove, then execute, and the state root is executable for L1 withdrawals only after a delay.
• L2-usable is not the same as L1-withdrawable, so bridged funds must not be double-counted while in transit.
• As a Type-4 zkEVM, some Solidity-level behaviour differs; the balance model is EVM-style, but the timing is the real change.
• Cost basis and tax are unchanged (jurisdiction method); L1 to L2 movements of your own funds are internal transfers.

Validity finality, not optimistic challenge

zkSync Era is a validity (ZK) rollup: finality is reached when a validity proof is verified on Ethereum, with no 7-day challenge window like an optimistic rollup. But "no challenge window" is not "instant L1 finality." A transaction is shown quickly and assets are usable for further L2 transactions almost immediately, while full finality aligns roughly with the corresponding L1 settlement and takes longer than the display. For tracking, visible and usable on L2 is not the same as L1-final.

The commit-prove-execute pipeline

zkSync posts state in stages:

1. Commit: the data is posted without a proof.
2. Prove: a validity proof is provided for it.
3. Execute: after a delay, the state root becomes available to execute, which is when L1 withdrawals can be processed.

So an L2 balance can be spendable on L2 well before the corresponding withdrawal to Ethereum is executable. A correct tracker distinguishes L2-usable from L1-withdrawable.

Step-by-step: how to track a zkSync Era portfolio

1. Import the wallet address using zkSync Era's EVM-compatible endpoint. The balance model mirrors Ethereum: use eth_getBalance for ETH and balanceOf on ERC-20 contracts. zkSync Era exposes a standard JSON-RPC endpoint, so EVM-compatible libraries work.
2. Pull transaction history via the zkSync Era block explorer API (or the native zks_getTransactionDetails RPC). Retrieve all L2 transactions for the address, sorting by block number. Each transaction includes the L2 status (Pending, Included, Verified, Failed).
3. Map each transaction to its finality stage. A transaction with status Included is on L2 but not yet proved. Verified means the batch containing it has been proved and executed on L1. Use this status to distinguish L2-usable from L1-final in the portfolio view.
4. Identify deposit (L1→L2) and withdrawal (L2→L1) bridge transactions. Deposits are submitted on Ethereum's Mailbox contract; after L2 inclusion the funds are credited on L2. Withdrawals are requested on L2, proved, and then executed on L1. Track both legs and hold them in an in-transit state until execution is confirmed.
5. Classify L1↔L2 movements between your own addresses as internal transfers. Do not book them as a sale on L2 and a purchase on L1; cost basis and acquisition date must carry across.
6. Deduct L2 gas fees. Gas on zkSync Era is paid in ETH and consists of an L2 execution component plus an L1 data-availability cost. The total fee is visible in each transaction's fee field and must be deducted from the ETH cost basis pool.
7. Apply the jurisdiction cost-basis method to the unified L1+L2 history.

The withdrawal delay and double-counting

Funds bridged out of zkSync are not immediately on L1: there is an execution delay after proving before a withdrawal completes. The tracking errors here are:

• showing the asset as already on L1 before execution;
• double-counting it on both layers during the in-flight period.

The asset is in a withdrawal-in-progress state until L1 execution, a distinct state that is neither "on L1" nor "still freely on L2." This is the internal-transfer pairing problem with a time gap.

Common errors and how to fix them

Error 1 — Treating L2 inclusion as L1 finality. A tracker that sets a balance as final on L2 inclusion may report assets as available on Ethereum before the batch is executed. Fix: set a "zkSync pending" sub-state for transactions until the corresponding batch is marked as executed on Ethereum's Executor contract.

Error 2 — Double-counting bridged ETH during withdrawal. If the tracker shows ETH as both credited on L2 (not yet withdrawn) and credited on L1 (withdrawal initiated but not executed), the portfolio is overstated. Fix: when a withdrawal request is detected on L2, mark that amount as "withdrawal-in-progress" and remove it from the L2 balance; credit it to L1 only on confirmed L1 execution.

Error 3 — Ignoring L1 data cost in gas. The fee for an L2 transaction on zkSync Era includes an L1 data-posting component that varies with calldata size. Tracking only the execution cost understates the true ETH cost per transaction. Fix: use the full fee value returned by the transaction receipt, not an estimated base gas.

Error 4 — Assuming mainnet-identical contract behaviour (Type-4). Some Solidity precompile calls or assembly-level tricks valid on Ethereum may behave differently on zkSync Era (Type-4 zkEVM). A tracker that copies Ethereum ABI decoders verbatim may misparse certain contract interactions. Fix: test contract interaction decoding specifically on zkSync Era transactions rather than assuming Ethereum equivalence.

Type-4 nuance

zkSync Era is broadly EVM-like but a Type-4 zkEVM: some Solidity-level behaviour differs, and contracts may compile and behave with changes versus mainnet. For portfolio tracking the account and balance model is EVM-style, so the main practical differences are finality timing and the withdrawal pipeline, not the balance model. Contract-level edge cases, though, should not be assumed identical to mainnet.

Tax unchanged; timing is the work

zkSync does not change the cost-basis method; the jurisdiction-mandated one applies. The tracking work is to:

• handle L2-usable versus L1-final correctly;
• avoid double-counting bridged assets in transit;
• classify L1 to L2 movements of your own funds as internal transfers, not disposals (see internal transfer vs disposal and cross-chain reconciliation).

Practical guidance

1. Distinguish L2-usable from L1-final: don't treat instant display as finality.
2. Model the withdrawal-in-progress state, which is neither "on L1" nor freely "on L2".
3. Never double-count bridged funds across layers during the delay.
4. Treat the balance model as EVM-style but don't assume mainnet-identical contract behaviour (Type-4).
5. Apply the jurisdiction cost-basis method; L1↔L2 own moves are internal transfers.
6. Reconcile to the chain including the proving/execution stage, with an audit trail.

Choosing a tool for a validity rollup

Koinly and CoinTracker both ingest zkSync Era as an EVM-style chain, but the timing-specific points to verify are:

• it distinguishes an L2-included transaction from an L1-verified one, rather than treating L2 inclusion as final settlement;
• it holds a bridged withdrawal in an in-progress state and credits L1 only on confirmed execution, so the same funds never appear on both layers at once;
• it uses the full fee value (L2 execution plus L1 data cost) returned by the transaction, not an estimated base gas;
• it does not assume mainnet-identical contract decoding, given the Type-4 differences;
• it treats L1 to L2 movements of your own funds as internal transfers.

The timing model, not the balance model, is where zkSync trips a naive tracker.

How Wag3s handles zkSync Era

Wag3s Folio reads zkSync Era with an EVM-style balance model while modelling the commit-prove-execute timing: it distinguishes L2-usable from L1-final, holds bridged funds in a withdrawal-in-progress state without double-counting, uses the full L2-plus-L1 fee, and classifies L1 to L2 own-fund moves as internal transfers under your jurisdiction's cost-basis method. See the Folio product page.

Further reading

• StarkNet Portfolio Tracking
• L2 Accounting: Arbitrum, Optimism, Base
• Cross-Chain Transfer Reconciliation (CCTP & Bridges)
• Multi-Chain Portfolio Aggregation Beyond EVM
• Crypto Cost Basis Methods 2026
• Internal Transfer vs Disposal in Crypto

Sources

• ZKsync — Finality: finality ties to Ethereum via a verified validity proof, with batch commitment, proof generation, submission, and a security delay before finalization.
• ZKsync — Withdrawal delay: the block-execution time lock before a committed batch is finalized on L1, delaying an L2-to-L1 withdrawal.
• IRS — Digital assets for the US cost-basis and disposal framework applied to the unified L1+L2 data, not the chain.