zkSync shipped Airbender SNARK proofs. Multi-prover security is officially a benchmark, not a roadmap.
Two Airbender releases in six days, and the second one adds the cryptographic layer that actually verifies execution. L2 teams are being held to shipping proof systems now, not describing them.
CryptoVibe Desk · zksync · zkrollup · snark
- →zkSync Era core-v29.19.0 shipped today with SNARK proofs for Airbender and a fix for a debug API bug that was dropping call traces.
- →Two Airbender releases in six days shows Matter Labs converting roadmap language into code, and raises the bar for L2 prover credibility.
- →Whether a second independent prover ships alongside Airbender before Q3 2026 is the real test of multi-prover security, not this release.
- SNARK proof → A type of cryptographic proof that lets one computer verify another ran a computation correctly, without re-running the full computation itself.
- Airbender → Matter Labs' in-house proof system for zkSync, responsible for generating the cryptographic proofs that confirm transactions on the network are valid.
- Multi-prover security → A model where multiple independent proof systems must all agree before a transaction is final, so a bug in one prover cannot compromise the whole chain.
- Call trace → A step-by-step log of every operation a smart contract ran during a transaction, used by developers to debug and audit what actually happened on-chain.
Matter Labs shipped core-v29.19.0 for zkSync Era today. The main addition, per the GitHub release, is SNARK proofs for Airbender, their in-house prover.
That's two Airbender releases in six days. Core-v29.17.0 on May 20 included earlier Airbender groundwork alongside v31 execute changes and a migration path from Era v29 to v31. This release adds the SNARK layer.
At the contract level, this distinction matters. A SNARK proof is a cryptographic guarantee that the prover ran the computation correctly. You're not trusting the prover team's word. You're verifying math. Adding SNARKs to Airbender moves the prover from an internal execution engine to something the rest of the stack can verify independently.
The debug fix is also in v29.19.0. A bug in `debug_traceBlockByNumber` was quietly dropping call traces from API responses. If you've been using that endpoint to audit transaction execution, you were getting incomplete data. The fix is narrow, but silent data loss erodes trust in a debugging stack.
The angle here is the pressure, not just the release. Multi-prover security has moved from roadmap language to an expected checkpoint across the L2 field. No one gets credit for describing a second prover anymore. The question is what ships. Every Airbender release is partial evidence of where Matter Labs actually is, not where the blog says they're going.
If you're building on zkSync, the prover stack is what most L2 marketing skips past. ZK finality is only as strong as the prover. SNARKs let anyone verify the prover is correct, not just trust that it is. This release moves the stack closer to that distinction mattering in production.
The single-source caveat: this brief has one source family, the official matter-labs/zksync-era GitHub releases, so the brief depends on a single primary source. Read the release notes, not the thread.
Matter Labs is calling this multi-prover progress, but shipping SNARK proofs for one prover with no independent benchmarks is velocity, not validation.
A second independent prover shipping alongside Airbender before Q3 2026 ends would confirm multi-prover security as a concrete commitment, not just roadmap language.
Primary links and supporting reads used by the desk for this story.
Forward this.
