[ZIP-16] ZKsync v31 Upgrade

[0xValera]

Proposal Type	ZIP
One Sentence Summary	ZIP-16 proposes the v31 upgrade for ZKsync.
Proposal Author	Matter Labs
Proposal Sponsor	Matter Labs
Date Created	July 2026
Version	v2
Summary of Action	Upgrade ZKsync to v31
Link to Contracts	draft-v31 branch

This is the current, rescoped v31 proposal. It supersedes the original ZIP-16 draft, which is deprecated and retained for reference: https://forum.zknation.io/t/zip-16-v31-interop-bundles-upgrade/979

Abstract

ZIP-16 proposes the v31 protocol upgrade for ZKsync. The release delivers:

• Priority Mode for ZKsync OS L1-settling chains, giving users a permissionless path to withdraw their funds even if the sequencer stops processing.
• Broad ZKsync OS compatibility work across the protocol’s contract layer.
• A direct Era upgrade path from v29 to v31.

Motivation

v31 advances two priorities for ZKsync.

It introduces Priority Mode for L1-settling ZKsync OS chains, a censorship-resistance escape hatch for chains that settle directly to L1. If priority transactions remain unprocessed for too long, anyone can activate a restricted settlement path, so users can withdraw their funds even if the sequencer stops processing.

It also consolidates ZKsync Era and ZKsync OS onto a shared codebase and reduces protocol surface area. Protocol version 30 was used for ZKsync OS chains and was not deployed to Era mainnet, so Era chains upgrade directly from v29 to v31, rolling the v30 compatibility work into the next Era-facing release rather than requiring a separate mainnet upgrade. This foundational alignment keeps Era and ZKsync OS in a single codebase and streamlines the path for future protocol upgrades.

Specification

The implementation of the new protocol version can be viewed on the release-v31 branch of matter-labs/era-contracts.

Priority Mode for ZKsync OS L1-settling chains

Priority Mode is introduced in era-contracts #1943 as a censorship-resistance mechanism for ZKsync OS chains that settle directly to L1. It guarantees that users can withdraw their funds even if the sequencer stops processing.

• This is an opt-in feature, and we do not force ZK Chains to use it in any way.
• Users can submit L1-to-L2 priority transactions the same way they did before.
• The current release-v31 code sets PRIORITY_EXPIRATION = 4 days. If the first unprocessed priority transaction remains outstanding for at least that long, anyone can call activatePriorityMode() on the chain’s L1 contract.
• Once activated, batches may contain only priority-queue transactions, and anyone can settle a batch through PermissionlessValidator, which atomically commits, proves, and executes the batch.
• A chain admin can permanently enable Priority Mode for a chain by calling permanentlyAllowPriorityMode.

ZKsync OS Compatibility

Because protocol version 30 was reserved for ZKsync OS and was not deployed to Era mainnet, v31 incorporates the v30 compatibility work. The release includes:

• L2 contract restructuring, adapting L2 system contracts to work without constructors or immutables and splitting contracts into L1, L2, and Base variants.
• Custom DA validator removal, moving DA validation to a fixed set of supported commitment options.
• L2 Verifier removal, so the same verifiers are used on both L1 and L2.

Note on Version Numbering

Protocol version 30 was assigned to ZKsync OS chains and was not deployed to Era mainnet. Era chains therefore upgrade directly from v29 to v31.

Rationale

Priority Mode for ZKsync OS L1-settling chains

Priority Mode creates a deterministic censorship fallback for eligible chains. Once the timeout for a queued priority transaction is reached, anyone can move the chain into a mode where only priority transactions are processed and settlement is permissionless, so users retain the ability to exit even if the sequencer is unavailable.

Limiting this mechanism to L1-settling chains reflects the fact that Gateway-settling chains require additional coordination that is not part of the current design.

ZKsync OS Compatibility

The ZKsync OS work removes contract patterns that might make the codebase incompatible with ZKsync OS, effectively keeping Era and ZKsync OS support in the same codebase. Removing custom DA validators and separate L2 verifiers also reduces protocol surface area and eliminates legacy distinctions that are no longer required.

Some smaller changes

• Added the ability for the server to execute the upgrade automatically.
• Removed L2 Verifiers to reuse L1 Verifiers, since they are now the same.
• Continuous improvement of documentation.

Implementation & Backwards Compatibility

The upgrade modifies bootloader logic, L2 system contracts, L1 settlement coordination, and the server-side protocol implementation. While backwards compatibility is maintained for existing ZKsync Chain operations, chains that wish to support the new version must update.

Breaking Changes

1. Era skips protocol version 30. Tooling that assumes sequential Era mainnet protocol numbers must handle a direct upgrade from v29 to v31.
2. Node software and external nodes must upgrade to a v31-compatible zksync-era. v31 batches use commitment-scheme-based pubdata parameters that older external nodes cannot fully deserialize.
3. Custom DA validators are removed from L2. Chains must migrate to the supported commitment-scheme-based DA options.
4. Legacy SystemContext batch methods now revert. Off-chain systems that still call getBatchHash, getBatchNumberAndTimestamp, currentBlockInfo, getBlockNumberAndTimestamp, or blockHash must be updated before the upgrade.
5. Separate L2 Verifier contracts are removed. Integrations that referenced the old split verifier layout must update.

Security Considerations

The v31 upgrade’s trust surface centers on the Priority Mode path, the protocol-version boundary, and the server-side release.

• The Priority Mode path introduces a permissionless activation and settlement mechanism for L1-settling ZKsync OS chains, as specified above. Activation is gated by the priority-transaction expiration window, and once active, batches are restricted to priority-queue transactions.
• Server-side support must remain aligned with the v31 contract set, because batch metadata and pubdata validation semantics change at protocol version 31.

Audit

The v31 contracts were audited by OpenZeppelin. The audit report is publicly accessible here:
https://github.com/matter-labs/era-contracts/blob/draft-v31/audits/v.31%20Interop%20Audit%20(OpenZeppelin).pdf

Any minor fixes applied after the audit are noted in this post.

Estimated time to reach ZKsync Era

Each chain can upgrade at its own pace. Submission and vote timing will be confirmed when voting opens. We will update this section with confirmed dates before the proposal is submitted onchain. As usual, the upgrade start will be primarily time-based and the blockheight is not known in advance.

Currently pending a successful governance vote, the tentative time to reach ZKsync Era is on August 4th, 2026 around 12 pm CET.

UPD: To give more time for internal testing (e.g. to upgrade Battlechain prior to upgrading the mainnet), the estimated release date has been postponed to the 24th of August.

[Anwar]

This is a pretty massive shift from the original ZIP-16 draft. The previous version was all about the Interop Bundles Upgrade, but now all mentions of interoperability fees and ZK token utility are completely gone.

Did the team just drop this entirely? The community has been waiting for real utility to be brought to the ZK token, and completely scraping it from this upgrade feels like a major step backward. We need direct clarification from the admins on why these economic features were cut and whether the community’s interests are being sidelined here. Were we actually lied to?

[KryptoRitter]

@0xValera @Alex-Gluchowski

The original V31 was about interoperability fees and giving the ZK token real utility. Now those are simply gone, replaced by a completely different proposal with barely any explanation.

The original deadline was missed. TPP-18 passed, giving Matter Labs 67 million ZK per month. We were told interoperability fees would come before the first minting. That didn’t happen.

Now we’re just expected to accept that the original proposal is “deprecated” and move on?

This is exactly how trust is destroyed. The community deserves a clear explanation for why the most important economic features disappeared and whether token utility is still happening at all.

Why should investors continue to trust this process when the roadmap changes so dramatically after key votes? If Matter Labs continues receiving large monthly token allocations while token holders are left with dilution and NO MORE promised utility features, why should the community believe our interests are being treated as a priority?

NO WONDER many are calling this project a SCAM!

[BE4_2_L8]

Unbelievable… You just deleted all interoperability features. (v31 previously supposed to be about interoperability implementation). Firstly you did a proposal to allocate 67m ZK every month. Now you not even mention about all the token utility that you promised A HALF YEAR AGO. Giving teasers about interoperability and v31, posting bait tweets, and for what? Even with this delay you delivered almost nothing that you promised in the past. You really hate your project and community as much? Seems like this team having fun doing destructive moves…

[Golem]

hello everyone, we see your questions on the v31 update, and I’ll answer them below.

Why the interop fees are not in this release:
The fees ran on Gateway-based public interop, and that is what was deferred. Over recent months the team worked directly with the institutions building on ZKsync. Their requirements were consistent: private execution, settlement direct to Ethereum, and atomic interop between their own environments, rather than public interop routed through Gateway. v31 was rescoped to the foundation that path depends on. The Gateway interop code, including the fee mechanics, is complete, audited, and remains in the codebase, inactive. It could be brought into production through a future governance proposal and any implementation steps required at that time. The full account of what changed and why is in the deprecation notice on the original post [deprecation notice].

On “dropped entirely” and whether the community is being sidelined:
Nothing here bypasses the community. The consultation is the governance vote, and it is still ahead. This rescoped proposal is live for review now, and nothing in v31 executes without passing that vote.

On the claim that fees were promised before the first TPP-18 minting:
That misrepresents what I wrote. My statement in the TPP-18 thread was that v31 was expected to ship ahead of the first minter activation. That was a timeline expectation as of that date. It contained no promise that fees would pass before minting and said nothing about dilution. The full exchange is on the record [TPP-18 thread reply]. Two things from that statement did not hold, and they are that: the timeline slipped, and the scope changed. Both are now documented in the rescoped proposal.

On token utility:
No decision to abandon anything has been made. ZK is the network’s native and governance asset. The fee mechanics exist in the codebase and are inactive. Whether any fee mechanism activates is a governance decision, not a team announcement.

On trust in the process:
TPP-18 went through the standard governance process: a public proposal, feedback from ZKsync delegates, open discussion, and an onchain vote, with the allocation visible to every voter. v31 goes through the same process. When the scope changed, it was published as a new proposal with a deprecation notice explaining the change, precisely so the record stays intact and delegates vote on what will actually ship.

[Anwar]

@Golem , this response is a masterclass in rewriting history through semantics. Let’s strip away the corporate damage control and look at the actual facts, timelines, and the exact commitments made to this community.

1. The “v31 Means Interop Fees” Fact
   You claim it “misrepresents” your words to say fees were expected before the TPP-18 minting. Let’s be entirely real: In June, when you were pushing to allocate 67 million ZK to Matter Labs, v31 was literally named “Interop Bundles.” The entire core value proposition of v31 presented to the community at that time was the introduction of the interop fee mechanics.

By assuring the community in the TPP-18 thread that v31 would ship ahead of the first minter activation, you were directly using the promise of upcoming token utility (fees) to soften the blow of a massive token dilution. Now that the scope has been completely gutted, you are trying to separate the two as if v31 was always just a random version number detached from its actual features. It wasn’t.

2. Paid “Community Activation” Hyping the Interop Narrative
   If the team was secretly shifting directions “over recent months,” why were your official, treasury-funded arms under the so called “Community Activation ProgramS” (ZKnomist, Madmaxx, Zaksan, walker and associated content campaigns) aggressively pushing the interop narrative on social media until the very last moment?

While the team was behind closed doors completely changing the architecture for private institutions, paid contributors were out on X and Discord hyping up how “trillions of institutional bank dollars” would route through the token via interop fees. If a pivot was happening, why was public treasury funding being spent to actively mislead the community with bait narratives about token utility that you knew you were removing?

3. The Months-Long Silence vs. The “Sudden” Rescoping
   You admit in your own post that “over recent months the team worked directly with the institutions” to pivot away from public interop routed through the Gateway. If this institutional pivot has been happening for months, why was the community kept completely in the dark until the eleventh hour?

You had months to notify the community that the promised token utility was being stripped from the upcoming release. Instead, you let the community get fed hype tweets, only to hit them with a “deprecation notice” at the finish line.

4. “Inactive Code” is Not Token Utility
   Claiming that the fee mechanics are “complete, audited, and remain in the codebase, inactive” is a blatant twisting of words. Inactive code sitting dead in a repository does absolutely nothing for the ZK token or its holders. Presenting a gutted v31 with no roadmap, no timeline, and no promise of when or if these fee mechanisms will ever be activated is, for all practical purposes, canceling them for the foreseeable future.

5. Shifting the Blame to Governance
   Hiding behind the shield of “governance” to excuse a fundamental failure in product delivery is a recurring, bad-faith pattern. Yes, the community votes on what ships. But the team controls the pipeline, the timelines, the institutional pivots, and the narrative. When the team secretly spends months redesigning the protocol’s architecture for private institutions at the expense of public token utility, and then dumps a stripped-down proposal on the forum, that isn’t “respecting governance”—that is cornering the community into voting on a compromised product because the timeline slipped.

Stop hiding behind semantic technicalities. The community supported TPP-18 on the explicit premise of the network value and utility that June’s version of v31 represented. Delivering a gutted version months late, while institutional pivots were hidden from public view and counter-hyped by paid campaigns, is a total breach of trust.
This isn’t a minor slip in a timeline; it is a fundamental breach of trust. If we let Matter Labs dilute our holdings based on promises they secretly spent months dismantling, we are complicit in the destruction of this network’s integrity. To every holder and delegate who cares about the future of this project: we must vote NO on this rescoped proposal. Let’s show the team that governance isn’t a corporate theater where they get to hide their failures and institutional pivots behind a rubber-stamp vote.

[KryptoRitter]

Golem, your response completely sidesteps the real issue.

You say nobody was told fees would come before the first 67M minting. But in June, v31 was literally the Interop Bundles upgrade. That was the release centered on interoperability and its fee mechanics. When you assured everyone v31 would land before the first mint, the obvious implication was that the promised utility would arrive before dilution. Pretending today that v31 was just an arbitrary version number divorced from its contents is an attempt to twist words.

What’s even harder to reconcile is your own timeline, and it points to a much more troubling reality.

You now admit this strategic pivot happened over recent months. If that’s true, it means Matter Labs deliberately chose to operate in the dark, orchestrating this shift behind closed doors while keeping token holders completely blind to their real intentions. Why did token holders only find out at the absolute last minute? And as @Anwar said, why were treasury-funded Community Activation “contributors” kept on the hook, actively promoting the interoperability and fee narrative to paint a rosy picture, while the team had already killed that direction internally?

And please stop using deceptive word games to cover this up by saying the fees aren’t “cancelled.” An inactive feature with no timeline, no commitment, and no proposal to activate it has zero value to token holders today. Whether you call it “inactive” or “deferred” doesn’t change the reality of the rug pull. Let’s be real: if a months-long roadmap promise can be wiped out behind closed doors, then your vague “deferred” label translates to “never.” It’s nothing more than a blatant attempt to insult the community’s intelligence.

This isn’t about governance. Governance votes on what the team chooses to propose. The issue is that the community was actively misled—allowed to believe one thing for months to keep everyone quiet, while a completely different plan was being executed behind the scenes.

That’s why people are angry. Not just because the roadmap changed—but because the secrecy and bad faith surrounding it completely destroyed what’s left of the community’s trust.

[Anwar]

More and more, I find weird signs here, and things just aren’t adding up.

Isn’t it highly suspicious, @theshelb , that the delegate call on June 24th—where ZIP-16 was one of the two main discussion topics—accidentally failed to be recorded?

Out of all the previous delegate calls that have been successfully uploaded, this specific one has a technical glitch. But what makes it even more bizarre is that ONLY the presentation of the capped minter dashboard was re-recorded and shared.

ZIP-16 details major shifts, a delayed timeline, and structural scope changes from Matter Labs. Leaving the community entirely in the dark about the actual discussion, Q&A, and delegate pushback on this specific topic—while conveniently saving the dashboard presentation—looks incredibly weird.

Can the governance team explain exactly what happened to the rest of the call, and why an update of this magnitude is being handled with so little transparency?

[Golem]

Hi everyone, a few points, and then this can stand on its own.

On what was claimed:

The original claim was that I “explicitly promised” interop fees would pass before the first minting. I quoted directly what I said in the previous thread, which did not say that, and now the argument has moved to what those words implied. The words are linked above. People can weigh implications for themselves.

On the timeline and “months of silence”:

A protocol upgrade like this is a hard fork. It changes the engine of the entire protocol, where one mistake can affect every chain and all the value + users they secure. It is not easy nor is it simple, which is why these releases take time, multiple audits, and why dates can move.

The sequence here has been posted publicly on the forums this entire time: the original post carried an explicit note that the date could shift. When it shifted, an update was posted on the thread. The decision to rescope was finalized in late June, and the rescoped proposal and deprecation notice were published within days of the scope being settled. Discovery with institutional partners ran over months. The decision did not. Nothing sat hidden.

On “inactive code is not utility”:

Correct, and nobody has claimed otherwise. Inactive code is inactive code. The point of stating it is to point out that the work is not discarded, and bringing it into production remains available to governance through a future proposal.

What v31 does instead is reallocate finite engineering from a path without current partner demand toward the paths the institutional partners building on ZKsync are actively asking for. That is a prioritization argument, and it is the one this proposal makes openly.

On the call to vote no:

That is what the vote is for. Delegates should scrutinize this proposal as hard as any other, and if the community votes it down, it does not ship. The vote is the mechanism, that is how decentralized governance works, and it is ahead of us.

I’ll continue answering any new questions about the v31 release in this thread.

[Anwar]

Golem, let’s stop playing corporate word games. Your entire defense hinges on a blatant revision of history, pretending that “v31” was just some empty, flexible version number.

When you stated that v31 would land before the first token minting of the massive 67 Million monthly tokens to Matter labs, you weren’t talking about an abstract placeholder. At that exact time, ZIP-16 was literally titled the "V31 Interop Bundles Upgrade." Matter Labs’ own official deliverables, public roadmaps, and previous forum threads explicitly defined v31 as the milestone that would introduce native cross-chain interoperability and its associated interop fee mechanics.

The fee system wasn’t an implication of v31—the fee system WAS v31.

Trying to argue today that you “only promised v31, not interop fees” is a deceptive, bad-faith technicality. Stripping out the entire core economic engine of an upgrade, keeping the name “v31” for a gutted release, and then claiming you technically kept your word is an insult to the community’s intelligence. If someone promises to deliver a car before a specific deadline, and they show up with just an empty chassis and say, “Well, I never explicitly promised an engine, I just promised the model name,” everyone would call it a scam. That is exactly what you are doing here.

Furthermore, it is incredibly telling that in your list of clean little bullet points, you completely and conveniently dodged the most critical question from my previous post: What happened to the June 24th delegate call recording?

Before you try to excuse this as an unavoidable “technical glitch” and claim it was just a nice gesture to have the presenter manually re-record the dashboard presentation afterward: let’s look at the selective transparency here. It is deeply convenient that the promotional dashboard material was pushed out to the public, while the actual live Q&A, the delegate pushback, and the critical discussions regarding the destruction of the v31 roadmap completely vanished.

No one expects you to magically recreate a live call with dozens of delegates. We expect an explanation as to why the one crucial meeting where Matter Labs’ massive structural shifts and roadmap pivots were being challenged happens to be the only record that failed. If everything was done in good faith, publish the comprehensive written meeting minutes, chat logs, or internal notes from that Q&A immediately.

To your other points:

• The “Institutional Partner” Contradiction: You openly admit that finite engineering was reallocated away from interoperability fees because there was “no current partner demand” from institutional players. Interoperability fees directly benefit the ZK token holders and validators who secure this network. Private enterprise chains obviously don’t “demand” fees—but token holders do. You are openly admitting that core token utility was sacrificed behind closed doors to appease a few off-chain entities. Who does Matter Labs actually answer to: the ZK Nation community or private enterprises?

• The “Inactive Code” Gaslight: Claiming the work is “inactive but available for a future proposal” is technical gaslighting. You just fundamentally changed the architectural engine of the protocol in this rescoped v31. Code built for the original Interop design cannot just be “switched on” later by governance without massive re-auditing and heavy engineering cycles—the very cycles you claim you don’t have. Leaving dead, unusable code in the repository is not utility; it’s a graveyard.

• The “Just Vote No” Shield: Hiding behind the voting mechanism to absolve yourselves of bad planning is a total cop-out. You didn’t give governance a legitimate choice between the ‘Interop v31’ we were promised and this ‘Rescoped v31.’ You spent months secretly building only the version that suits your private partners, presenting the community with an ultimatum: swallow this hollowed-out upgrade, or vote ‘No’ and accept that months of ecosystem development time were completely wasted. That isn’t decentralized governance; it’s an illusion of choice.

We don’t want your semantic deflections, Golem. Every single bullet point in your reply was a calculated distraction to avoid answering for the missing June 24th delegate record. Stop dodging. Since the community has been denied the unedited video record of that Q&A, the burden of transparency now falls on the delegates who were present. We need the delegates to step into this thread and publicly clarify what was discussed regarding the destruction of the v31 roadmap. Token holders deserve to know exactly who approved of this shift behind closed doors and why it was kept quiet until the absolute last minute.
Stop trying to convince us nothing sat hidden when the entire public record of the discussion is the only thing missing.

[KryptoRitter]

Golem, your entire reply relies on separating “v31” from what v31 actually was at the time.

Let’s stop arguing over semantics and answer a few straightforward questions.

1. When you told the community that v31 would arrive before the first mint, was v31 publicly defined as the Interop Bundles upgrade INCLUDING FEES ? Yes or no?

At that point, v31 wasn’t an empty version number. Matter Labs had already presented it as the Interop Bundles upgrade, with interoperability and interop fees as its defining purpose. Those weren’t optional extras—they were the reason the release mattered to token holders.

So saying today, “I only promised v31,” is trying to redefine the promise after the fact by changing what v31 contains while keeping the same label.

2. You keep saying the decision was “finalized” in late June. That’s not what people are asking.

When did Matter Labs first begin internally discussing removing interop fees from v31?

Those are two completely different dates. If those discussions had already started while the community was still being told v31 was the Interop Bundles upgrade, then the community was making decisions based on information that Matter Labs already knew might no longer be true.

3. Your explanation creates another contradiction.

You say engineering priorities changed because institutional partners wanted something different.

That’s exactly why people are concerned.

Interop fees were consistently presented as part of the protocol’s economic direction for token holders. If private institutional feedback became more important than the roadmap communicated to the community, when did that happen? Was the protocol roadmap being driven by governance, or by discussions with enterprise partners that token holders knew nothing about?

Finally, you’ve once again ignored the June 24 delegate call.

The most important discussion about this strategic pivot is also the only one the community can’t review. The dashboard presentation was preserved, but the actual debate, delegate questions, and Matter Labs’ responses are gone.

If the recording truly cannot be recovered, then publish comprehensive written minutes. Publish the questions delegates asked. Publish Matter Labs’ answers. Publish the concerns that were raised.

Transparency isn’t asking the community to trust your version of events. Transparency is giving the community enough information to verify it independently.

Until these questions are answered, your response doesn’t resolve the issue—it simply tries to redefine what “v31” meant after its defining feature was removed.

[Anwar]

@theshelb — I noticed you completely ignored my message from two days ago. Let’s bring it right back to the top of this thread because your refusal to answer speaks volumes.

Isn’t it funny how out of all the delegate calls successfully recorded and uploaded to this forum, the June 24th call—the literal turning point where the original ZIP-16 was gutted and the v31 roadmap was destroyed—is the only one that suffered a convenient “technical glitch”?

But what makes it downright sinister is that the recording didn’t fully fail. Your team magically managed to save and re-record the promotional, capped minter dashboard presentation to push to the public. Meanwhile, the actual live Q&A, the heavy delegate pushback, and Matter Labs’ justifications for abandoning the Gateway fee mechanics were completely erased.

You are intentionally leaving the community in the dark. You are ignoring my questions because you don’t have a legitimate answer that doesn’t expose the truth: Matter Labs used our votes to secure 67 million tokens monthly for the Prividium vision, and the exact moment the ink dried, they quietly altered the codebase to ensure those enterprise partners bypass the $ZK token entirely.

Your silence is a confession. If everything was done in good faith, you wouldn’t be hiding behind @Golem 's technical semantics, and you wouldn’t be ignoring direct community questions.

To the ZK Nation community: They are ignoring us because they think we are passive exit liquidity. They think if they stay silent for a few more days, they will push ZIP-16 through and go own with abusing us.

Do not let them. Take this silence straight to X and every social media channel. Wake up the delegates. If your delegate is staying silent or planning to blindly vote “Yes” on this hollowed-out upgrade, revoke your power immediately or delegate to yourself.

We must organize and reject ZIP-16. Vote NO on v31!

[theshelb]

Hey folks - apologies for the slow reply. I was on on leave last week.

The call agenda from July 24th can be found here where it shared the only update for v31 that was available from the engineering team at that time, and linked to the forum post that the update was referencing for people to review directly. There was a technical malfunction with the recording from that day, but a recording of the guest presentation was re-recorded and shared on YouTube.

Proposal Review Discussion Process Recap:

All Proposal Review Calls, which happen every few weeks, are open for anyone to join. This is the core meeting where the ZKsync Association discusses improvements with Delegates, the ZKsync Foundation, operators such as Matter Labs, and ZKsync Chains. The next one is scheduled for Wednesday, June 22nd.

You can subscribe to the Delegate Call Calendar here, and join the ZKsync Delegate Announcements Telegram channel here for Delegate call & other important updates relevant for Delegates.

Proposal Approval Process Recap:

Proposal drafts are posted on the forum under the corresponding draft categories (i.e. Draft ZIPs, Draft TPPs, Draft GAPs). Posting drafts of proposals on the forum is meant to provide visibility for governance stakeholders prior to a proposal being submitted onchain. During this period, partners, security research, community members, and ZKsync Chains are welcome to share comments, insights, and suggestions to the author.

Posting a draft upgrade in the “Draft ZIP” category:

• does not bind a proposal author in any way — a proposal author is free to edit or update a draft proposal in any way they see fit, over any time period;
• carries no obligation or timeline requirement to progress the draft proposal to an onchain vote, and
• is not finalized until it is submitted onchain and formally approved by the Token Assembly, Guardians and then executed by Security Council.

All proposal updates - including new proposal drafts posted on the forum, when they are submitted onchain, start of voting period, voting extension updates, and final voting results - are shared on the ZK Nation X account, as well as the ZKsync Delegate Announcements Telegram channel

You can review the formal ZIP approval process on the ZK Nation docs. You can also visit the docs for detailed information on all ZKsync Governance Procedures, proposal design guidance, and relevant onchain contracts.

[Anwar]

Everyone following the ZIP-16 discussion needs to read @Golem ‘s response to @junkui.eth in this thread before voting. I’m linking it here because, in my view, it reveals more about Matter Labs’ priorities than any official announcement has.

After reading it carefully, I think the picture is clear.

For years, holders were told that the ZK token was on a path toward meaningful economic utility through protocol fees, burns and value accrual, LONG AGO through the paid propaganda on X, even before @gluk64 made his promise/draft in November 2025. That vision was repeatedly used to justify patience while the ecosystem matured.

Now Matter Labs is effectively telling us something very different.

Matter Labs’ commercial business earns revenue in FIAT through enterprise customers, managed services, licensing and Prividium.

Matter Labs also receives additional 67 million ZK every month from the token treasury to fund development and operations.

Meanwhile, the mechanisms that were expected to return economic value to token holders remain deferred, with no firm timeline or commitment beyond “future governance.”

Read those three points again.

Matter Labs earns FIAT.

Matter Labs receives ZK from the treasury.

Token holders continue waiting.

Based on Golem’s own explanation, Matter Labs currently receives both fiat revenue from enterprise customers and ongoing token funding from the treasury, while the mechanisms intended to create economic value for token holders remain without a concrete timeline. That is an asymmetry that deserves serious scrutiny.

If the original expectation was that token holders would eventually share in the network’s economic success through protocol utility and value accrual, Golem’s response raises the question of whether that expectation is still reflected in Matter Labs’ priorities.

The asymmetry is impossible to ignore..

The part that benefits Matter Labs has dates, contracts and monthly transfers.

The part that benefits token holders has ZERO promises and NO GURANTEE.

One side receives certainty.

The other side receives NOTHING but uncertainity and fake hope.

Golem argues that funding is aligned because TPP-18 is denominated in ZK rather than dollars.

But that misses the central concern.

A company cannot pay salaries, infrastructure, taxes and operating expenses with good intentions. Whether tokens are sold directly by Matter Labs or distributed as compensation and later sold, they ultimately become fiat to fund the business. At the same time, by Matter Labs’ own explanation, its enterprise business increasingly generates fiat revenue independently of the token’s market price.

That naturally raises an important question:

If enterprise customers are already paying Matter Labs in fiat, why does the company also require continued monthly funding from the token treasury while the value-accrual mechanisms for holders remain delayed?

Another question:

Why is the treasury transfer to Matter Labs guaranteed, while the transfer of value back to token holders has no comparable commitment or timeline?

And perhaps the most important one:

If interoperability fees and token utility were presented as central to the original vision for v31, why were those elements deprioritized while treasury funding continued unchanged?

This is no longer just a debate about engineering priorities.

It is a debate about incentives.

Good governance aligns incentives.

Today, the incentive structure appears uneven: the company’s funding is concrete and recurring, while the token’s economic roadmap remains uncertain.

That is why confidence has deteriorated.

That is why so many holders are asking harder questions.

If the original Interop Bundles vision—including the token utility that many holders expected—was an important part of the proposal, then ask yourself one question before you vote:

What leverage will token holders have to secure those commitments after this rescoped version has already been approved?

Voting No does not necessarily mean rejecting progress. It can also mean asking Matter Labs to return with a proposal that restores the missing economic components or provides clear, concrete commitments about when and how they will be delivered.

If those mechanisms are truly important to the long-term value of the network, then they should be important enough to define before, not after, governance approves a fundamentally rescoped v31.

[Manugotsuka]

The following reflects the views of L2BEAT’s governance team, composed of @kaereste and @Manugotsuka, and is based on their combined research, fact-checking, and discussion.

We voted FOR.

We support ZIP-16 and the ZKsync v31 protocol upgrade. The Priority Mode feature is a meaningful improvement for ZKsync OS chains that settle directly on L1, since it gives users a fallback path to withdraw if the sequencer stops processing transactions or censors priority transactions for too long.

We also like the direction of bringing ZKsync Era and ZKsync OS closer to a shared protocol codebase. Reducing divergence between the two systems should make future upgrades easier to manage and reason about, and this upgrade also seems like an important step toward broader improvements in the ZKsync stack.

Before voting, we asked our Research Team to review the proposal. They could not fully verify the upgrade transaction calldata because it was too large for our decoder, but the parts they were able to decode looked good. They also reviewed the v31 contract sources and the OpenZeppelin audit, and did not find anything that would change our view.