A family of chains, not one uniform configuration

ZKsync documentation describes a modular protocol supporting rollups and validiums built using ZK Stack. Both can use cryptographic proofs of execution, but a validium's data-availability arrangement differs from a rollup that publishes the required data to Ethereum. This distinction matters if operators stop serving information: a proof of a correct state transition is not a substitute for the data needed to reconstruct state. An ecosystem name therefore cannot establish a particular chain's recovery or settlement guarantees on its own.

Blocks, batches, and proof settlement

In the documented EraVM transaction lifecycle, the sequencer executes transactions and gives an early confirmation. Several blocks are grouped into a batch for proving, and state-difference data is published before the proof is submitted. The settlement contract verifies the proof and the required data submission before accepting the update. These stages explain why a transaction can already appear in an application while its batch has not completed settlement. They also make batch status and proof transactions useful evidence when investigating a delayed withdrawal.

Programmable accounts require their own review

ZKsync's native account-abstraction design allows smart accounts to define authorization logic, such as multiple signatures or spending constraints. Paymasters can sponsor fees or support payment through another token under their own rules. These are capabilities that an application can implement, not promises that every wallet provides recovery or free transactions. A developer must verify the targeted execution environment and account interface rather than assume every Ethereum account convention applies unchanged.

Users still depend on the account contract's validation code and any authority able to change it.