The ZKM June Update

A month of system-level upgrades, design-level clarity, and a coordinated signal toward the next big release.

ZKM spent June laying technical groundwork across the full stack - proving architecture, VM instruction encoding, developer workflows, and protocol integrations. Beneath each update was a common thread: we’re preparing for a significant upgrade that transitions zkMIPS from a performant zkVM to a truly scalable execution layer for real-world applications.

We didn’t disclose everything. But the direction is clear:

• The current stack is hitting measurable performance ceilings.
  
• We’ve isolated bottlenecks - prover latency, constraint scaling, toolchain compatibility.
  
• Solutions are already shipping incrementally: GPU acceleration, distributed proving, native ECDSA, and a more composable toolchain.
  
• The next release will resolve these in a single deployment - rewiring zkMIPS for real-world latency, developer scale, and multi-chain deployment without architectural compromise.‍

Proving System Deep Dive: STARKs, SNARKs, and Memory Abstractions

We released a series of technical posts detailing the internal composition of the ZKM prover stack. The system is structured as follows:

• Memory STARK: Enforces time-ordered memory access for read/write correctness in the VM trace, decoupling address resolution from arithmetic constraints.
  
• Logic STARK: Verifies Boolean operations and program logic with low constraint overhead.

Together, these enable modular verification chips that compose efficiently. Proofs are generated using transparent STARKs and then wrapped via recursive SNARKs (Groth16 and Plonky3) for cross-chain compatibility. This hybrid design balances fast proof construction with compact L1 verification.

We also explored offline memory checking, which abstracts memory operations into commitment layers, allowing parallel execution and reducing constraint system size - essential for throughput scaling.

→ STARK-SNARK hybrid

→ Memory + Logic STARKs

→ Offline memory checking

Why ZKM and the Journey so far

In parallel with the deep technical content, we published two vision-focused pieces:

• The ZKM Journey outlines our trajectory—from internal Ethereum L2 research in 2022, to whitepapers on hybrid and entangled rollups, to the full-stack zkVM powering Bitcoin-native infrastructure today.
  → Read: The Journey So Far
  
• Why ZKM articulates our architecture choices and long-term commitments: using MIPS for constraint efficiency, prioritizing developer ergonomics (Rust-native), and building the entire proving pipeline in-house. It includes performance benchmarks vs SP1 and R0VM, and points to the roadmap ahead.
  → Read: Choosing the Right zkVM

These pieces reflect ZKM’s stance not only on how zkVMs should be built, but why.‍

Why MIPS Still Outperforms RISC-V for zkVMs

ZKM published a technical comparison campaign explaining why MIPS remains the most efficient general-purpose ISA for zkVM use:

• Instruction Density: MIPS opcodes encode more logic per instruction, reducing trace length and constraint counts
  
• ISA Stability: MIPS32r2 has remained unchanged for decades, avoiding re-audits and re-implementation overheads
  
• Special Register and Opcode Support: Conditional moves, MAC operations, and branching logic are natively supported, reducing custom constraint logic

In constraint-based systems, fewer instructions mean fewer gates. MIPS continues to outperform because zk efficiency is about constraint minimization, not instruction simplicity.

→ Full comparative article‍

BitVM3: Reusable Garbled Circuits with ZKM as the Backend

ZKM’s collaboration with GOAT Network now extends to BitVM3, introducing a reusable circuit garbling approach. The work reduces proof-of-consistency overhead by compressing adaptor data (from terabytes to megabytes), while minimizing on-chain modular exponentiation.

This makes the fraud proof economically viable and deployable. Our zkVM functions as the proving backend for BitVM2 and BitVM3, enabling developers to write Rust or C, compile to MIPS32r2, and generate validity proofs with zero-knowledge guarantees.

Key architectural traits:

• zkMIPS is tightly embedded into GOAT’s prover pipeline (not a plug-in)
  
• Recursive proof generation supports real-time BTC rollup finality
  
• No trusted setup, no MPC, no centralized verification dependencies

→ BitVM2 Thread
→ BitVM3 Garbled Circuit Post‍

EthProofs Summit: System Design and zkVM Futures

At House of ZK’s hugely popular EthProofs Summit, ZKM participated across three sessions, covering proving architecture, virtual machine design, and long-term zkVM coordination.

Keynote - Stephen Duan, CTO‍

Stephen offered a deep-dive keynote into zkMIPS, focusing on:

• Why MIPS32r2: Dense opcode format, special registers, and stable ISA reduce constraint complexity and compilation overhead.
  
• zkMIPS architecture: Programs are decomposed into chips, proven with Plonky3 recursion using KoalaBear Prime Field for fast commitment.
  
• Integration example: zkMIPS underpins GOAT Network’s Bitcoin-native ZK rollup, supporting recursive Groth16 proofs for compact BTC finality.
  
• Prover performance: 2.6M cycles/sec on a single RTX 4090 GPU.

zkVM Design Panel - Stephen Duan

Participants included researchers and engineers from Ethereum Foundation, Linea, StarkWare, and zkSync, discussing topics like:

• Proving systems: STARKs vs SNARKs, Plonky2→Plonky3 transition, lattice vs hash-based commitments.
  
• VM choices: Custom ISAs vs standard ISAs (MIPS, RISC-V); tradeoffs between performance and devex.
  
• Security: Bugs stem from engineering missteps more than cryptographic breaks; formal verification is still rare.
  
• Ecosystem fragmentation: Different toolchains, recursion stacks, and verification layers create real-world deployment friction.

zkVM Interoperability Panel - Ming Guo, Co-founder

Ming joined panelists from zkCloud, Lita, and Miden to discuss the role of zkVMs in cross-chain infrastructure, focusing on:

• zkVMs as bridge replacements: Native proof verification across L1s could eliminate brittle bridging logic.
  
• Prover coordination: Discussion focused on the absence of standardized proof formats or market mechanisms for cross-chain proving services.
  
• Ecosystem fragmentation: Diverging zkVM architectures are likely to persist, driven by different economic models and chain constraints.
  
• Opportunities: zkVMs will unlock new models for privacy-preserving identity, decentralized proving markets, and permissionless zk computation.

‍

These sessions collectively illustrated ZKM’s approach: not just building a zkVM, but engineering a vertically integrated, architecture-stable execution environment designed to support recursive proofs, runtime portability, and long-term interoperability across chains.

While others optimize around specific ecosystems or languages, ZKM is targeting the coordination layer itself - where proof formats, verifier constraints, and execution models need to align across fragmented systems. The goal is not just compatibility, but standardization through performance.

Looking Ahead

June was not about announcements - it was about alignment. Every update, from BitVM3 developments to proof system architecture, pointed toward one thing: huge things are coming for both ZKM and GOAT Network.

In July, we’ll begin rolling out the most important upgrade for builders to date. GPU acceleration, networked proving, full toolchain support, and Ethereum-native compatibility will no longer be roadmap items - they’ll be live. This upgrade marks the point where our zkVM transitions from performant to truly scalable and production-grade: deployable in latency-sensitive, verifiability-critical environments across Bitcoin, Ethereum, and beyond.

If you're building serious ZK infrastructure, now is the time to get involved:

→ Explore the docs
→ Start Building