ZKsync Council Discloses Five Preventive Protocol Patches

On September 1, 2026, the ZKsync Security Council disclosed five fast-tracked protocol patches, including an August fix for a cryptographic weakness in the proof system. The council classified every upgrade as preventive rather than a response to exploitation, said users need take no action and reported no known material effect on transactions, deposits, withdrawals or finalization. The consolidated disclosure nevertheless exposes a consequential fact: flaws reached the circuits and cryptographic machinery that determine which ZKsync state transitions Ethereum will accept.

What did the five ZKsync patches change?

The upgrades corrected both security-sensitive constraint failures and bugs capable of blocking valid proofs. The disclosed record groups them as follows:

• Version 0.29.3, signed January 23, addressed three circuit vulnerabilities, including one soundness issue; version 0.29.4, signed February 5, repaired multiple over- and under-constraints.
• Version 0.29.5, signed July 24, removed an overconstraint that could stop valid batches from being proven.
• Version 0.30.0, signed August 8, prevented miscomputation in certain EraVM operations.
• Version 0.30.1, signed August 15, fixed a cryptographic proof-system weakness and made additional VM corrections.

An under-constrained circuit can leave a value or relationship insufficiently checked, potentially allowing an invalid execution witness to satisfy the circuit. An over-constrained circuit has the opposite operational failure: a legitimate execution may have no valid witness, halting batch proving. ZKsync has not said which cryptographic primitive failed in v0.30.1 or what attack it could have enabled, so claims about its severity would outrun the disclosure.

What does a ZKsync proof prove, and what remains private?

A ZKsync proof attests that a batch’s execution follows the protocol circuit and transforms the previous state commitment into the claimed new one. Ethereum verifies that compact proof instead of re-executing every EraVM instruction. The prover’s full execution witness is not revealed to the verifier, but that does not make ordinary ZKsync Era transactions private: transaction activity and the data needed to reconstruct rollup state remain available. Here, zero knowledge reduces verification work; it is not a transaction-confidentiality layer.

The remaining assumptions are substantial. Users rely on correct circuits, a sound proof implementation, Ethereum settlement and data availability. They also rely on upgrade governance: the instant-upgrade procedure bypasses a Token Assembly vote but requires approval thresholds within the Security Council, Guardians and ZKsync Foundation.

Do preventive instant upgrades improve ZKsync security?

They improve response capability, but trade advance scrutiny for speed. A standard proposal publicly exposes its code and purpose while passing through voting, risk review and a timelock. The instant route lets authorized signers deploy a confidential fix before disclosure warns potential attackers. Ethereum records show calls to the upgrade-board contract around the January and February actions, demonstrating that the governance mechanism was used, not that the underlying flaws were harmless.

The council’s no-exploitation and no-user-impact statements remain unverified claims because it is withholding technical reports on security grounds. Nor has it published benchmarks showing that the new versions change proving time or cost. The patches were the right immediate action, and the new preventive label is more informative than calling every rapid upgrade an emergency. But without eventual technical disclosure, outsiders cannot independently measure how close these bugs came to violating proof soundness—or whether the fixes cover the full failure class.