ZKsync Resubmits v31 Upgrade With Priority-Mode Exit Path

Matter Labs has resubmitted ZKsync’s v31 protocol upgrade after the July-approved version was not executed, restarting governance around a release that adds a permissionless withdrawal fallback for eligible ZKsync OS chains and aligns Era with a newer protocol build.

12 October 2026 · ZKsync governance · Protocol upgrade · Source-checked report

Why ZIP-18 was needed

The onchain ZIP-18 record, published by Matter Labs on 9 October, resubmits the v31 upgrade previously approved as ZIP-16. The earlier proposal passed the Token Assembly in July but was never executed.

The new filing gives two reasons. First, the Security Council was alerted to issues in the earlier calldata that needed correction before deployment. Second, ZKsync Era subsequently moved to protocol version v0.30.1, making calldata built for the earlier v0.29 state unusable. ZIP-18 regenerates the upgrade instructions against the current Ethereum mainnet state while keeping the substantive scope of ZIP-16.

Matter Labs says OpenZeppelin reviewed the regenerated calldata in September. The proposal also states that referenced contracts were deployed on 6 October, verified on Etherscan and tested through the full governance sequence on an Ethereum mainnet fork. Those checks reduce implementation uncertainty, but they do not substitute for the pending governance vote or for post-deployment verification.

What v31 changes

The most consequential user-facing component is Priority Mode for ZKsync OS chains that settle directly to Ethereum layer 1. If the first unprocessed priority transaction remains outstanding for four days, anyone can activate a restricted mode through the chain’s L1 contract. In that state, batches can contain only priority-queue transactions and a permissionless validator can commit, prove and execute a batch.

The design is intended as a censorship-resistance and liveness fallback: users retain a route to withdraw if a sequencer stops processing. It is opt-in rather than mandatory, and the present design does not extend to chains settling through ZKsync Gateway because those chains require additional coordination.

The release would also move ZKsync Era chains from protocol v0.30.1 directly to v0.33.0, while ZKsync OS chains would move from v0.30.1 to v0.31.2. ZKsync explains that the Era label skips v0.31 and v0.32 because testnet and staging used those numbers, while staging already runs the same bootloader and system contracts under v0.33.0.

Other changes consolidate Era and ZKsync OS around a shared contract codebase, remove separate L2 verifier contracts and retire custom data-availability validators in favour of supported commitment schemes. The proposal also changes the Protocol Upgrade Handler so the Security Council, Guardians and Emergency Upgrade Board contracts are updated in the same call as the handler.

Operator work is a real part of the upgrade

ZIP-18 preserves existing chain operations, but it is not frictionless for infrastructure providers. External nodes must support protocol v0.33 before the upgrade executes; the proposal identifies zksync-era release v32.0.0 as the minimum compatible software line. Older nodes cannot fully deserialize the pubdata parameters used by post-upgrade batches.

Integrations that depend on legacy SystemContext batch methods or the previous split-verifier layout must also update. Chains using custom DA validators must migrate to the supported commitment-based options. This makes operator readiness a practical confirmation point alongside the governance result.

NetNapz assessment

Fact: the earlier v31 authorization was not executed, the replacement calldata has been regenerated, and ZIP-18 remains pending. Inference: the resubmission is materially more important for protocol resilience than for near-term token economics. Priority Mode would improve the exit assurances of eligible chains, but it does not create an automatic revenue stream or direct demand mechanism for the ZK token.

The constructive case is that a successful vote, coordinated node upgrades and a clean Era rollout establish a credible censorship fallback while reducing code divergence between Era and ZKsync OS. The adverse case is operational: a failed vote, a delayed deployment, incompatible external nodes or a post-deployment address mismatch would push the benefit out and could expose coordination weaknesses.

Confirmation: a successful 12–19 October vote, proposal execution, public release of compatible node software and verified deployment at the expected mainnet addresses. Invalidation or delay: governance rejection, execution deferral, new security findings or insufficient operator readiness. The relevant horizon is the next two to four weeks, not an intraday token-price call.

What to watch

• The final Token Assembly vote and whether quorum and support thresholds are met.
• Queueing and execution after the vote rather than treating approval as deployment.
• Release notes for compatible ZKsync Era and external-node software.
• Evidence that major operators have upgraded before v0.33 batches begin.
• Post-deployment confirmation that contracts landed at their expected addresses.
• Future work needed to extend a comparable fallback to Gateway-settling chains.

Sources

• ZKsync governance — ZIP-18 onchain proposal and timetable, 9 October 2026
• ZK Nation Forum — ZIP-18 governance discussion, 9 October 2026
• Matter Labs — era-contracts v31-mainnet implementation
• ZKsync — official brand assets

Published 12 October 2026. Confirmed facts are drawn from the dated governance and technical sources above. The NetNapz assessment is analysis, not investment advice.