Matter Labs | Q3 2026 Deliverables Report

Protocol Development
1

Summary

In Q3 2026, work continued under TPP-18 across the three areas the allocation funds, with the changes in scope described in this report: Prividium for institutions, private interoperability between Prividium chains, and the ZKsync protocol and proving stack that both run on. The main results of the quarter are that the first release of atomic interoperability is deployed on the mainnets Matter Labs operates, the core of Prividium is open source, and v33, the new ZKsync OS release, is audited and live on our own mainnets. Moving customer mainnets to these releases continues in Q4.

The quarter also carried forward the change of focus made in June. We prioritized private interoperability ahead of public interoperability through Gateway and moved engineering capacity accordingly, because that is what the institutions building on Prividium are asking for. In September we announced that the EraVM execution environment will be retired, alongside new security measures for EraVM chains. Both changes are explained below, together with what they mean for the ecosystem.

Highlights included:

  • Atomic interoperability, which lets institutions on separate Prividium chains settle a trade in one all-or-nothing transaction, passed staging tests and is deployed on testnets and on the mainnets Matter Labs operates
  • Prividium Core became open source under the Apache 2.0 license on September 8, and Deutsche Bundesbank is the first institution to test it in its own infrastructure
  • Prividium Organizations, which lets several institutions share one Prividium chain while each manages its own users, roles and contracts, reached customer mainnets in September and is not yet enabled there
  • SOC 2 Type II audit of Prividium is underway: the observation period started on July 7 and the auditors began their review in September
  • v33, the new release for the ZKsync OS chains Matter Labs operates, is audited and live on those mainnets (see section 4 for how this relates to the governance-approved v31 upgrade)
  • A second, independent prover ran alongside Airbender on staging for a week without issues
  • BFT consensus for the ZKsync OS sequencer moved from design to implementation, using Commonware’s implementation of the Simplex consensus protocol
  • ZKsync Era’s execution delay increases to 24 hours on October 7, after token holders approved ZIP-17. The longer delay is one of five security measures announced for EraVM chains

As in previous quarters, this report is our update for the ZK Nation community. Its sections follow the workstreams of TPP-18, the 2026 ZKsync Protocol & Network Development Allocation, so that progress can be read against the plan the allocation funds.

1. Private Interoperability

At the start of 2026 the interoperability plan had two parts: public interoperability between ZKsync chains through Gateway, and private interoperability between Prividium chains. Working with the institutions building on Prividium, we found their requirements consistent: private execution, settlement directly on Ethereum, and atomic transfers between chains. Public routing through Gateway was not among them. In June we therefore prioritised private interoperability ahead of public interoperability through Gateway, and changed the scope of the v31 upgrade (ZIP-16) so that it no longer contains the Gateway-based features. Private interoperability does not deliver the original plan for public interoperability, but it continues the same goal for the use case institutions need now. The interop fees in the original v31 proposal were part of Gateway-based public interoperability and were removed with it (section 5 covers what this means for protocol fees).

  • Atomic transfers and swaps: The first release of private interoperability is atomic transfers and swaps between Prividium chains. In an atomic swap, both legs of a trade, for example a tokenized asset on one chain and its payment on another, settle together in one transaction, or neither does. This removes the risk that one party delivers and the other does not pay (how it works).
  • Deployment status: Atomic interoperability ships as part of v33 (see section 4). It passed staging tests in September and is deployed on testnets and on the mainnets Matter Labs operates. Next steps are moving customer mainnets to it and integrating it into the Prividium API.

2. Accelerating Prividium Adoption

An institution running Prividium in production needs more than the chain software: a supported service, evidence that the security controls work, and engineers who help with the deployment. TPP-18 covers this work under its managed services, SOC 2 attestation and forward-deployed engineering deliverables. Its purpose is getting Prividium chains launched and operated by institutions. Several parts were delivered in Q3, while the full set is still being built.

  • Prividium Organizations: Reached customer mainnets in September but is not yet enabled there. It is built for a Prividium chain that several institutions share: each manages its own users, roles, contracts, identity provider settings and machine-to-machine credentials. Before release we hardened the isolation between organizations and tested it for security.
  • SOC 2 Type II audit underway: The Type I examination completed in Q2 checked that our security controls are designed correctly at a point in time. Type II checks that they operated over a period of several months. The observation period started on July 7, we submitted evidence in September, and the auditors have started their review. The Type II report is not yet issued.
  • Prividium Core open source: Prividium Core, the permissioning engine that decides who can see and do what on a chain, became open source on September 8 under the Apache 2.0 license. Institutions asked for this because they need to inspect the code that runs their systems and to keep those systems running without depending on a single vendor. Deutsche Bundesbank is the first institution to test the open-source engine in its own infrastructure, and we continue to work with it on the design and testing of the platform (The Block). Prividium Core is open source; the enterprise administration and operational tooling built around it remain proprietary.
  • Forward-deployed engineering: The part of the team that works directly with institutions on their deployments and the features they need. In Q3 we defined the role and the hiring requirements and started hiring for the first positions. The function is not yet staffed, so it was not ready for deployments in Q3.

3. Off-Chain Integration Layer

Banks run their operations on systems they already have, such as ERP and treasury systems and payment messaging based on the ISO 20022 standard. The off-chain integration layer connects Prividium to these systems, so that an institution does not have to rebuild its processes around a blockchain.

  • Transaction-status API: Built in Q3. Lets an institution’s own systems follow the state of each transaction.
  • Policy engine: First version built in Q3. Checks transactions against rules the institution sets.
  • Tokenization features: Built in Q3.
  • ISO 20022 messaging: A proof of concept exists. It is not a production integration.
  • ERP and treasury system integrations: Not yet available.

4. Core Protocol Development

This section covers the ZKsync protocol and proving stack that both Prividium and the public ZKsync chains run on.

  • v33: The new protocol release for chains that run ZKsync OS, the execution environment on which all new ZKsync protocol development happens. It contains ZKsync OS 0.5.0 and the first release of atomic interoperability. v33 applies to the ZKsync OS chains that Matter Labs and its customers operate, which are upgraded on their own release schedule rather than through a Token Assembly vote; upgrades to ZKsync Era go through governance, most recently v31 under ZIP-16. v33 passed its audit and staging tests, and in September it reached the mainnets Matter Labs operates, where chains now produce and settle proofs with it. Moving customer chains to v33 continues in Q4.
  • Second prover for ZKsync OS: Every batch is proven with a zero-knowledge proof before it becomes final on Ethereum, so a bug in the only prover could in theory let an invalid batch through. A second prover built independently reduces this risk, because the same bug would have to exist in both. In Q2 we completed the proof of concept for using more than one prover. In Q3, ZisK, an independent zkVM, started shadow proving on staging: it proves the same batches as Airbender, but its proofs are not yet required for settlement. By September 29 it had run alongside Airbender for a week without issues.
  • Consensus for decentralized sequencing: To decentralize sequencing on ZKsync OS chains, several sequencer nodes have to agree on the order of transactions, even when some fail or behave incorrectly. A consensus protocol that gives this guarantee is Byzantine fault tolerant (BFT). Our Q2 design work was based on RAFT, which handles nodes that crash but not nodes that behave incorrectly, and it showed that a BFT protocol is needed for this goal. On July 2 we started integrating Commonware’s implementation of Simplex, a BFT consensus protocol, into the ZKsync OS server, reusing the lessons and parts of the code design from the RAFT work. During the quarter the integration went through fuzz testing and was deployed to a separate staging environment. Next steps are merging it into the main codebase, running it continuously on staging, and then a gradual rollout to production. This work covers consensus between sequencer nodes; it does not include validator rewards, staking or slashing.
  • EraVM chains: EraVM is the execution environment of ZKsync Era and the other early ZKsync chains. On September 4 we announced that it will be retired: within six months, EraVM chains will begin a transition, while all new protocol development happens on ZKsync OS. Funds in regular wallets (EOAs) need no action at this time. For funds held in smart contracts, the exact steps and dates will be published on the official ZKsync channels. Through the transition, EraVM chains keep receiving security work, and we announced five security measures for them, including a longer execution delay and a second proving system (Hardening EraVM). Both progressed in Q3. The execution delay is the minimum time before a batch becomes final on Ethereum, and a longer delay gives more time to detect and stop an attack. Token holders approved ZIP-17, which lets each EraVM chain set its own execution delay, and ZKsync Era moves from 3 to 24 hours on October 7 (what this means for users and integrators). The second proving system is EraBender, a prover for EraVM based on Airbender, the prover that ZKsync OS chains use. EraBender will run alongside Boojum, the current Era prover, so that an exploitable flaw would have to exist in both proving systems at the same time. In Q3 we completed the remaining sequencer changes for EraBender, and the audit of its smart contracts started at the end of September. End-to-end validation and the production rollout are still ahead.
  • Hyperledger Besu: Besu is an Ethereum client often used to run permissioned networks, and TPP-18 includes a migration path for such networks to Prividium and Ethereum L2s. Besu support for Prividium was announced in July. In Q3 we demonstrated a Prividium chain settling on a private Besu chain running QBFT, a BFT consensus protocol for permissioned networks, and added Besu to our local development environment and to our full-stack end-to-end tests. This lets institutions that run Besu networks deploy a Prividium chain on top of the infrastructure they already operate.
  • v31: Token holders approved v31 (ZIP-16) in July. It has not yet been executed: as announced in the ZIP-16 thread in August, the release went through an additional review before execution.

5. Protocol Fees, Governance & Ecosystem

  • Protocol fees: The Fee Flow contracts, through which governance can route protocol fees, were deployed on ZKsync Era in May and remain available for governance to activate. Work on the fee model for the private interoperability layer is ongoing (the interop fees in the original v31 proposal were specific to Gateway; see section 1), and we will include an update in the Q4 report.
  • Governance: Token holders approved two protocol upgrades in Q3, v31 (ZIP-16) and the EraVM execution delay increase (ZIP-17), both covered in section 4. Two governance advisory proposals also passed. GAP-5, passed August 24, introduces Instant Upgrade terminology and a classification for upgrades executed with Emergency Upgrade Board approval instead of the standard Token Assembly process. GAP-6, passed September 16, allocates the remaining TPP-8 tokens to ZKnomist to extend funding for ZKsync social media communications. Alongside GAP-5, the Security Council published a consolidated record of the Instant Upgrades executed in 2026 so far.
  • Ecosystem: In Q3, institutions began working with Prividium in their own environments and in new markets.
    1. Deutsche Bundesbank is testing Prividium Core in its own infrastructure: Following the open-source release in September, the Bundesbank became the first institution to test the Prividium Core engine in its own infrastructure (see section 2).
    2. Japan: Work through Q3 led to a memorandum of understanding with NexBridge, announced in October. NexBridge is the Tokyo-based company that runs regulated yen stablecoin infrastructure for licensed banks and trust banks. It intends to market and distribute Prividium to Japanese banks, trust banks and securities firms. Under the MOU, the two companies intend to work together on infrastructure for Japan’s institutional digital asset market, including trust-type stablecoins, tokenized deposits, cross-border settlement and tokenized securities, with Matter Labs providing the technology. Japan’s amended Payment Services Act came into full force in June, giving institutions a defined path to run digital asset businesses at commercial scale.
    3. Hyperledger Besu: In July, Prividium extended to Hyperledger Besu, which underpins about 35% of enterprise permissioned blockchain deployments worldwide. Institutions running Besu can add ZK-proven privacy and Ethereum connectivity in phases, on top of their existing networks and governance, without replacing their infrastructure. At launch, the capability was in testing with major financial institutions, including a central bank and a systemically important financial market infrastructure.
    4. Institutional research: ZKsync co-sponsored SODA’s 2026 “Tokenization at Investment Banks” report, based on 16 of the world’s largest sell-side institutions. Every respondent placed tokenized deposits in their top three priorities for cross-border payments and settlement. Interoperability with existing systems was the top platform-selection criterion, and privacy was rated essential.

After Q3, Prividium Core is being tested by a central bank, Prividium is available to the installed base of enterprise Besu chains, and it is entering the Japanese market through NexBridge. In the Q2 report we described the next step as connecting these institutions to one another through a shared coordination layer. That work begins in Q4.

What Comes Next

In Q4 the main focus is delivering the Q3 releases to customers and operating live chains reliably: moving customer mainnets to v33 and atomic interoperability, completing the SOC 2 Type II audit, merging and rolling out the new consensus, and completing the EraBender audit. For EraVM chains, the next public step is the guidance for funds held in smart contracts, which will be published on the official ZKsync channels.

1 Like