The conversion from STARK to SNARK begins with the construction of recursive circuits. These recursive circuits are designed to compress the original large STARK proof into a smaller SNARK proof. The process involves several key components: the root circuit, the aggregation circuit, and the block circuit. Below is an introduction to the roles of each of these circuits:

1. Root Circuit

The root circuit is the core component for compressing STARK proofs. It aggregates recursive proofs from multiple tables and ultimately generates a SNARK proof. The root circuit collects recursive proofs from all tables and ensures that their public inputs meet the required conditions.

Code implementation:

The key to the root circuit is how it compresses each table’s recursive proof into a final proof and checks their consistency. In this structure, proof_with_pis stores each table’s recursive proof, while index_verifier_data and public_values are used to verify these proofs.

2. Aggregation Circuit

The purpose of the aggregation circuit is to compress two proofs into one. During the STARK-to-SNARK conversion, the aggregation circuit is typically used to merge the root circuit proof with other intermediate proofs into the final proof. By aggregating multiple recursive proofs, it reduces the overall proof size.

Code implementation:

The aggregation circuit compresses two proofs into a single final proof using lhs and rhs sub-circuits. Each sub-circuit can either be a ZKVM root proof or another aggregated proof. In implementation, lhs and rhs represent the left and right sides of the aggregation, respectively.

3. Block Circuit

The block circuit is similar in function to the aggregation circuit, but it not only compresses proofs — it also verifies the consistency between two proofs (e.g., an aggregation proof and a parent block proof). This circuit ensures blockchain validity and consistency.

When processing proofs, the block circuit verifies both the parent block proof and the aggregation root proof. If there is no parent block proof available, a dummy parent proof is used instead.

Next, we focus on the process of compressing each STARK proof into a single SNARK proof. This includes determining the recursive circuit chain (i.e., the order in which recursive proofs are performed), handling the challenge sets and public inputs, and finally executing the conversion from a STARK proof to a SNARK proof, as follows:

3.1 Step-by-Step Compression of the Recursive Circuit Chain

The key to the recursive circuit chain is the step-by-step compression of each table’s recursive proof. Each table’s recursive circuit contains multiple sub-circuits, with the degree of each decreasing progressively until it reaches a preset threshold THRESHOLD_DEGREE_BITS.

RecursiveCircuitsForTable constructs a recursive circuit chain for each table, where each circuit in the chain has a different size. The recursion ends once the size of the circuit falls below the preset threshold THRESHOLD_DEGREE_BITS. This chain is implemented through RecursiveCircuitsForTableSize.

3.2 Handling of Challenge Sets and Public Inputs

In each recursive step, the challenge set and public inputs are used to ensure the validity of the proof. The public inputs provide verification data for each proof, while the challenge set is used to verify the challenge values of each proof. With the help of RecursiveChallenger, we can observe and verify these challenge values.

During each recursive step, RecursiveChallenger is used to observe the challenge values in the public inputs and ensure their consistency. This guarantees that each proof is valid and eligible for further compression.

3.3 Final Conversion from STARK to SNARK

Once all recursive steps are completed, the final conversion from STARK to SNARK is achieved by progressively compressing the STARK proof into a smaller SNARK proof through multiple recursive circuit chains. The proof for each table is gradually reduced and eventually merged into a single root proof.

In the final conversion, prove_root processes each table’s proof one by one, compresses them using the shrink method, and generates the final SNARK proof by setting the public inputs.

The core function of shrink is to compress a large STARK proof into a smaller one suitable for recursive verification, while preserving the original proof’s integrity and soundness. This not only reduces proof complexity but also improves the efficiency of subsequent recursive circuits. The process involves the following steps:

1. First, shrink calls the proving function within the initial_wrapper to perform an initial compression of the STARK proof. This crucial step maps the original large proof into a smaller circuit.
2. Then, it iteratively calls each recursive circuit in the shrinking_wrappers to further compress the initially shrunk proof, until the proof’s size fits the target circuit constraints (e.g., the recursive gate size defined by THRESHOLD_DEGREE_BITS).
3. Finally, it returns a compressed ProofWithPublicInputs structure that contains the public inputs and the compressed proof, which can be directly consumed by smaller recursive circuits.

‍

Subscribe to the ZKM Blog to stay updated with the latest research by ZKM. If you have any questions about the article, you can contact the ZKM team on discord: discord.com/zkm

Originally published at https://www.zkm.io.

ZKM began as an internal research-driven effort to integrate zero-knowledge proofs into blockchain infrastructure. In 2022, as discussions around Ethereum scaling intensified, the idea of hybrid rollups began to take shape. Rather than abandoning the Optimistic Rollup model, the proposal was to combine it with zk-proofs to create a hybrid architecture that could deliver both developer flexibility and cryptographic finality. This would later evolve into the vision behind our MIPS-based zkVM.

The decision to adopt the MIPS instruction set was deliberate: while less in-trend than RISC-V, MIPS offered denser opcodes, smaller circuit footprints, and predictable performance characteristics. On the other hand, the opcode complexity made MIPS the more difficult development choice, but the payoff became evident in later benchmarks.

In early 2024, the vision expanded. Rather than stop at hybrid rollups, ZKM committed to solving the deeper issue of liquidity fragmentation. The Entangled Rollup paper outlined how our zkVM could serve as the foundation for a new kind of rollup, acting as a verification layer across chains and enabling unified liquidity without centralized bridges. That vision became the core strategic roadmap: build real infrastructure that connects fragmented chains through ZK validity.

The focus shifted to Bitcoin as the first integration target. With BTC holding the largest idle liquidity in the ecosystem, it was the natural place to begin the Entangled Rollup journey. GOAT Network was born as a Bitcoin-native rollup bringing BTC assets on-chain in a sustainable, yield-enabled framework — utilizing ZKM as its proving backend.

This infrastructure-driven approach contrasts sharply with the surface-level integrations pursued by many zkVM teams. ZKM didn’t prioritize optics or rapid integrations. Instead, we prioritized depth, performance, and full-stack ownership.

Recently, the 1.0 version of our zkVM launched with leading CPU-based benchmarks, outperforming other zkVMs like SP1 and R0VM in standard workloads. But that was just the beginning. The next major update unlocks GPU acceleration and distributed proving. For the first time, ZKM becomes performant enough for latency-sensitive, high-throughput applications. Developers no longer need to choose between general-purpose flexibility and practical cost.

We’re building for a future where zero-knowledge infrastructure isn’t a marketing layer — it’s the very core of cross-chain computation. MIPS was the harder path, but it’s proving to be the right one.

In a nutshell, this is the ZKM journey so far. And there’s much more to come.

Originally published at https://www.zkm.io.

At ZKM, we’ve taken a different approach: rather than targeting as many integrations as possible, our focus is on a few truly high-quality applications that can scale across architectures, chains, and domains.

This piece is all about why ZKM may also be the right foundation for what you’re building.

MIPS ISA: A Stable, Portable Target

Unlike RISC-V or custom bytecodes, MIPS is a mature, stable instruction set architecture that is easy to compile to and reason about. It’s been used in production hardware and software systems for decades.

• Toolchain Maturity: You can use standard Rust without needing to learn custom compilers or bytecode environments.
• Low Abstraction Overhead: The instruction set is simple, predictable, and has a clear mapping to constraints — making performance optimization easier.
• Smaller circuit footprint: Denser opcodes result in fewer instructions and simpler decoding logic.
• Hardware-Aware: MIPS is compatible with emulation and co-processor integrations, which is critical for our next phase of GPU acceleration.

The choice of the MIPS instruction set isn’t aesthetic. It reflects a deliberate tradeoff: MIPS enables clean constraint systems, highly parallelizable logic, and predictable performance on real workloads. It also aligns well with upcoming acceleration targets such as GPU-based proving. ‍

Now Prover-Optimized

• Fibonacci, SHA2, SHA3, and memory-intensive benchmarks show ZKM outperforming SP1 and RISC Zero (v2.0.1) on AWS r6a.8xlarge.
• Our upcoming GPU-enabled prover will further improve proof generation times and enable real-world usage for apps with latency sensitivity.

With its recent pipeline upgrades, our 1.0 version is optimized for fast, scalable proof generation, outperforming many general-purpose zkVMs across standard workloads:

For a benchmarking vs other leading zkVMs across CPU, see https://www.zkm.io/blog/zkmips-1-0-benchmarking-the-fastest-zkvm-on-cpu

Our next major release will include GPU acceleration for proof generation, enabling the capability to power high-throughput applications.

This update addresses one of the biggest bottlenecks for developers today: proof generation costs. GPU proving slashes runtime and compute overhead, enabling support of latency-sensitive use cases like real-time settlement, high-frequency trading, and composable applications.

Designed for Modularity and Developer-Centric Simplicity

• Chain Agnostic: Can be deployed to Ethereum, Bitcoin (via BitVM2), modular L2s, and support coming for more L1s.
• Co-Processor Friendly: Engineered for recursive composition and TEE/MPC delegation.
• Proof System Flexibility: Though initially based on STARKs, the architecture is modular enough to support Groth16 or Plonk-style backends.

Our zkVM provides a general-purpose computation layer that can integrate with any chain, proof system, or co-processor.

• Write standard Rust code.
• Compile directly to MIPS.
• Use our zkMIPS SDK to generate proofs or deploy smart contracts with verifiers.

It has also been designed to minimize friction for developers:

There’s no need to learn a new domain-specific language or deal with complex bytecode structures — everything is deterministic, debuggable, and inspectable.

​​Depth Over Hype

While other zkVMs seek rapid integrations for visibility, ZKM prioritizes depth. We focus on a small number of high-impact deployments where we can integrate tightly and support fully.

GOAT Network exemplifies this. It’s not another generic Bitcoin L2 — it introduces a decentralized sequencer model with sustainable, native BTC yield. Our zkVM isn’t just plugged in; it’s co-engineered.

• Architectural integration: ZKM sits at the protocol core.
• Full-stack support: We collaborate on provers, verification, and optimization.
• Performance alignment: Block time, cost, and latency tuned from day one.

This approach enables:

Fewer integrations. Higher fidelity. Real usage, not surface-level support.

As developers shift from asking “Can I integrate this?” to “Is this built to last?”, we think the answer will increasingly favor focused, production-grade zkVM deployments like ours.

Proof Markets Will Decide — We’re Ready for That

We’re not claiming our zkVM is better in every way. Each has its own strengths. But as proof markets mature and systems begin choosing zkVMs dynamically based on workload, cost, and latency, we believe ZKM will prove to be one of the most cost-efficient, high-throughput options available.

• A clear and stable instruction set architecture
• Proof generation at practical cost and latency
• Deep integration with real protocols solving hard problems in a uniquely optimal way
• Transparent engineering focus on scale, not optics

Very few other zkVMs can offer:

The goal isn’t to win in every category — but to be the best choice for the high-quality applications that demand real performance, deeper integration, and closer support.

If you’re just experimenting with proofs, any zkVM will do. But if you’re building production-grade, cross-domain, performance-sensitive ZK applications — ZKM is ready to go.

Get started with ZKM: ZKM Docs

Build with ZKM: ZKM Github

Originally published at https://www.zkm.io.

Memory checking in a zkVM is used to allow a prover to demonstrate to a verifier that read/write memory operations are performed correctly. In such a memory system, a value v can be written to an address a, and later retrieved from address a by the program. This technique enables the verifier to efficiently confirm that the prover has followed memory access rules-specifically, that any read returns the latest value written to that memory address.

The term offline memory checking refers to a technique in zkVM proofs where the correctness of all read operations is checked at once, after all read values have been committed. Offline checking does not immediately determine whether each read is correct at the moment it happens. Instead, it verifies the correctness of all reads in a single batch after all operations are done. This contrasts with online memory checking techniques, such as Merkle hashing, which confirm read correctness immediately by requiring an authentication path for every read. Merkle hashing imposes higher proof costs on the prover for each read operation, whereas offline memory checking is more suitable for zkVM scenarios.

We construct two sets, the read set RS and the write set WS, where each element is a tuple Esto es un ejemplo: \( (a, v, c) \) representing the address, value, and instruction count. They are constructed as follows:

Initialization:

• \(RS = WS = \emptyset ;\)
• If the memory \(a_i\) is to be initialized with value \(v_i\), then the initial tuple is added to the write set: \(WS = WSU(a_i, v_i, 0)\).

Memory Read and Write Operations:

• When reading from address \(a\), find the last tuple \((a, v, c)\) in \(WS\) for that address (i.e., with the largest instruction count \(c\)). Update: \(RS = RSU(a, v, c)\) and \(WS = WSU(a, v, c_{\text{now}})\), where \(c_{\text{now}}\) is the current instruction count.
• When writing value \(v’\) to address \(a\), find the last tuple \((a, v, c)\) in \(WS\) for address \(a\). Update: \(RS = RSU(a, v, c)\) and \(WS = WSU(a, v’, c_{\text{now}})\).

Post-processing:

If the following conditions are met, then the prover has followed the memory rules and read the correct values from memory:

1. The read and write sets are correctly initialized;

2. For each address \(a_i\), the instruction counts added to \(WS\) strictly increase over time;

• For read operations, the tuples added to \(RS\) and \(WS\) must have the same value;
• For read-write operations, the tuple added to \(RS\) must have a lower instruction count than the one added to \(WS\);

3. After post-processing, \(RS = WS.\).

Brief Proof: Consider the first faulty memory read operation. Suppose a read operation is expected to return the tuple \((a, v, c)\) but instead erroneously returns \((a, v’ \neq v, c’)\), which is added to \(RS\). Note that all tuples in \(WS\) are unique. After adding \((a, v’, c_{\text{now}})\) to \(WS\), both \((a, v, c)\) and \((a, v’, c_{\text{now}})\) are not in \(RS\). According to condition 2, after each read/write operation, there are always at least two tuples in \(WS\) that are not in \(RS\), which means post-processing cannot make \(RS = WS\).

There are two methods for enforcing the final equality of \(WS\) and \(RS\): multiset hashing and lookup tables (e.g., LogUp).

Multiset hashing allows a (multi)set to be hashed into a short string such that it is computationally difficult to find two different sets with the same hash. The hash is computed incrementally-one element at a time. A key property is that the final hash value is independent of the order in which elements are hashed. This lets us compare sets constructed in different orders.

Let the group \(G\) be the set of points on an elliptic curve defined by \(y² = x³ + Ax + B\) (including the point at infinity). We can implement multiset hashing using group hashing. To hash a set element into a point on the elliptic curve, we first map the element to an \(x\)-coordinate. Since this may not yield a valid curve point, we add an 8-bit adjustment value \(t\) and use hash operations to avoid collisions. Additionally, we apply constraints (e.g., ensuring the \(y\)-coordinate is a quadratic residue or adding range checks) to prevent flipping the sign of the y-coordinate.

For example, during zkVM execution, we can construct the following columns and corresponding constraints:

Columns:

• \(a\): operation address;
• \(v_r, v_w\): values added to the read/write set;
• \(c_r, c_w\): program counters added to the read/write set;
• \(t_r, t_w\): 8-bit adjustments;
• \(x_r, x_w\): x-coordinates, satisfying \(x = \text{hash}(a | |v| | |c| | t);\)
• \(y_r, y_w\): y-coordinates;
• \(z_r, z_w\): satisfying \(y = z²\), used to ensure that \(y\) is a quadratic residue;
• \(h_r, h_w\): current hash values of the read/write sets.

Constraints:

1. Perform range checks on \(a, v, c, t\);
2. \(c_{\text{now}} = c_w > c_r\) (you can introduce \(d = c_w — c_r\) and range-check \(d\));
3. \(x = \text{hash}(a||v||c||t)\), \(y² = x³ + Ax + B\), \(y = z²\);
4. \(h = h_{\text{old}} + (x, y)\);
5. At the end, ensure \(h_r = h_w\).

To prove that two multisets \(A = a_i\) and \(B = b_i\) are equal, it is sufficient to prove that for a randomly chosen challenge \(\gamma\), the following holds:

\[\sum_{i} \frac{1}{a_i + \gamma} = \sum_{i} \frac{1}{b_i + \gamma}\]

We can construct the following columns and constraints:

Columns:

Originally published at https://www.zkm.io.

The MemoryStark proving process mainly includes Trace Generation, Constraints Evaluation, and ZK Circuit Evaluation. The core goal of the entire process is to ensure that memory access operations occur in order of time and address, and that the value read is consistent with the previously written value. Details are as follows:

1. Trace Generation

• Collect MemoryOp and convert to Trace rows (into_row)
• Sort (generate_trace_row_major)
• Generate First Change Flags and RANGE_CHECK (generate_first_change_flags_and_rc)
• Process data format (generate_trace_col_major)

2. Constraints Evaluation

• Constrain FILTER to only be 0 or 1
• Ensure address changes follow the rules
• Ensure timestamps are strictly increasing
• Ensure read data matches the most recent write

3. ZK Circuit Evaluation

• Perform the same checks in eval_ext_circuit
• Constrain all variables to boolean values
• Ensure range_check is computed correctly

4. Lookup Constraints

The memory operations MemoryOp record all read/write activities, including:

• Access address (context, segment, virtual address)
• Access timestamp timestamp
• Accessed data value
• Access type Read/Write
• Whether the operation is valid filter

Each MemoryOp represents one memory access and is converted into an array of length NUM_COLUMNS, where:

• FILTER indicates if the row is valid
• ADDR_CONTEXT, ADDR_SEGMENT, ADDR_VIRTUAL record the access address
• TIMESTAMP records when the operation occurred
• IS_READ indicates whether it is a read (1) or write (0)
• VALUE stores the accessed data

1.1.2 Processing and Sequencing MemoryOp

• Sort MemoryOp by (context, segment, virtual address, timestamp)
• Call fill_gaps to ensure timestamp and address changes stay within the range_check bounds
• Call generate_first_change_flags_and_rc to generate First Change Flags and RANGE_CHECK constraints

1.1.3 Generating First Change Flag

• CONTEXT_FIRST_CHANGE: Did the context change in this row?
• SEGMENT_FIRST_CHANGE: Did the segment change in this row?
• VIRTUAL_FIRST_CHANGE: Did the virtual address change in this row?
• RANGE_CHECK: Ensures differences between adjacent rows do not exceed the max limit

1.1.4 Processing Data Format

• Generate a COUNTER used for range checks
• Calculate FREQUENCIES, which store the occurrence count of RANGE_CHECK values

1.2 Constraint Evaluation

In STARK proofs, we must ensure:

• Access timestamps are increasing
• Access addresses change in order
• Values read must match the most recent write
• FILTER must be either 0 or 1

1.2.1 Constraint Evaluation

Constraint Logic

In STARK proofs, we not only need conventional constraints, but must also perform the same checks at the circuit level to be compatible with zk-SNARKs.

To efficiently handle RANGE_CHECK, Lookup Arguments are used.

LogicSNARK is a proof system for basic logical operations. The process includes trace generation, constraint construction, STARK proof generation, and recursive circuit verification, ultimately allowing for efficient proofs of correctness for logical operations. The STARK proof process typically consists of the following stages:

1. Trace Generation

• Compute all operations and store the computation path.
• Generate polynomial representations suitable for STARK proofs.

2. Constraint Construction

• Ensure correctness of logical operations and define constraints.
• Constraints ensure correctness of input → operation → result.

3. Polynomial Commitment (PCS) and FRI Proofs

4. Recursive Proofs (Optional)

In the STARK proof system, the trace is the core of the computation process. It records the inputs, computation steps, and outputs, and is ultimately used to generate polynomial representations.

The code first defines the four supported logical operations:

• The Op enum defines AND, OR, XOR, and NOR operations.
• The result() method computes the result of a logical operation on two u32 values.

The Operation struct stores a logical operation:

• Operation::new creates a new logical operation and computes its result.
• The struct stores input0, input1, and the computed result, which will be used in the STARK proof.

The trace is a 2D array where each row represents a logical operation:

• Trace rows are organized by input, computation, and result, with each row having NUM_COLUMNS fields.
• The trace is padded to a power of two size for FFT compatibility in STARK proofs.

Constraints are the core of STARK proofs, ensuring that logical operations follow the correct mathematical rules throughout computation.

During STARK evaluation, each logical operation must satisfy:

• INPUT0 and INPUT1 store bit decompositions of input values.
• RESULT stores the final result.

\[\text{result} = \text{sum\_coeff} \cdot (\text{input0} + \text{input1}) + \text{and\_coeff} \cdot (\text{input0} \& \text{input1}) + \text{not\_coeff} \cdot \text{MASK}\]

Where: sum_coeff, and_coeff, and not_coeff are determined by the values in IS_AND, IS_OR, etc.

• Calculates sum_coeff, and_coeff, and not_coeff.
• Computes the theoretical result x_op_y and constrains it against the actual result.

Constraint implementation:

This part follows from earlier documentation in this series.

• CircuitBuilder handles recursive SNARK constraints.
• Computes x_op_y and ensures that the result is computed correctly.

Recursive circuits are used to efficiently verify STARK proofs:

Originally published at https://www.zkm.io.

May was the biggest month in ZKM’s history to date. We launched zkMIPS 1.0 — the first production-ready MIPS-based zkVM — while deepening integrations across Ethereum and Bitcoin, advancing our work through live deployments, industry benchmarks, and research publications.

zkMIPS 1.0 Is Live

ZKM released zkMIPS 1.0, a complete re-architecture of our zkVM with production-grade performance. This version introduces support for MIPS32r2, Plonky3 integration over the Koala prime field, multiset hashing for memory consistency, and a modular chip-based circuit architecture. These upgrades deliver up to 20x speedup over v0.3.0 across standard CPU benchmarks. zkMIPS 1.0 is now actively proving Ethereum mainnet blocks as part of the Ethereum Foundation’s @Eth_Proofs program and powers @GOATRollup, the first Bitcoin Layer 2 using BitVM2. This dual deployment validates our design goal: a zkVM capable of servicing both Ethereum and Bitcoin at the infrastructure layer.

Full launch article: https://www.zkm.io/blog/zkmips-1-0-production-ready-performance-optimized-and-open-for-developers

Benchmarking the Fastest zkVM on CPU

We published detailed benchmarking results comparing zkMIPS 1.0 to zkMIPS 0.3.0, Succinct’s SP1, and Risc Zero’s R0VM. Across workloads such as SHA-2, Fibonacci, and Big-Memory, zkMIPS 1.0 consistently outperformed previous versions and most other zkVMs in its category. This confirmed not only raw performance gains but also the advantage of our system-level architectural improvements.

Benchmark article: https://www.zkm.io/blog/zkmips-1-0-benchmarking-the-fastest-zkvm-on-cpu

Community and Industry Response

ZKM’s May work sparked strong engagement from leaders across the ecosystem, particularly regarding our article comparing MIPS vs RISC-V: https://www.zkm.io/blog/why-zkm-chose-mips32r2-over-risc-v-for-zkmips.

@EliBenSasson, co-founder of @StarkWareLtd, weighed in on our MIPS decision, noting he had once considered building STARKs for MIPS himself. This led to further dialogue between ZKM, StarkWare, and other ecosystem figures such as @ClementWalter of @Kakarotzkevm. ZKM’s leadership — CEO @KevinLiub and CTO @sd_eigen — publicly responded, emphasizing our rationale grounded in hardware and trace optimization.

ZKM was also featured across key publications and Twitter ecosystems including U.Today, @AlignedLayer ‘s ZK-Newsflash, and various others. The broader ZK community has responded with high interest across Twitter, Discord, and GitHub.

Developer Activation

Following the launch of zkMIPS 1.0, we launched the final phase of our Early Contributor Program with the ZKM Developer Track — a call for developers to build with zkMIPS, contribute to the toolchain, and expand onboarding resources. This track is the gateway to building verifiable applications using zkMIPS and participating in the next wave of scalable, cross-chain infrastructure.

Program details: https://www.zkm.io/blog/zkm-developer-track-a-call-to-builders

Thought Leadership

ZKM CEO Kevin Liu published a five-part BTCFi series, outlining a foundational thesis for Bitcoin-native financial infrastructure:

1. BTCFi hasn’t begun — the opportunity is ahead.
2. GOAT Network’s vertical integration enables security.
3. BTCFi must serve real user demand.
4. Native yield comes from L2 gas.
5. Bitcoin L2s are economic amplifiers.

Full recap: https://x.com/ProjectZKM/status/1923339874985238848

We also published a breakdown of zkMIPS’s integration with BitVM2 in GOAT Network. The thread outlines our novel proving architecture (Root, Aggregation, SNARK), cryptoeconomic design (dual-layer slashing), and latency breakthrough (sub-1-day finality). This positions zkMIPS as the first zkVM deployed in a trust-minimized Bitcoin L2.

Thread: https://x.com/ProjectZKM/status/1922580611249684885

Finally, we contributed to defining the Bitcoin-native L2 standard. Alongside GOAT Network, we outlined core and optional principles for trustless Bitcoin L2s — from permissionless exits to proof-based bridges. This is a call to reclaim the integrity of the term “Layer 2”.

Proposal: https://x.com/kevinliub/status/1924948457443172731

GOAT Network Milestones

GOAT Network released the BitVM2 whitepaper, showcasing how zkMIPS enables faster finality and enforces security through recursive proofs and decentralized sequencers. Shortly after, they launched the first permissionless BitVM2 testnet, powered by zkMIPS 1.0. This marks a new era for BTCFi — delivering real Bitcoin-native security, finality, and yield.

Try the testnet: https://bitvm2.testnet3.goat.network/bridge/inWhitepaper: https://drive.google.com/file/d/1ewves_XtJnOmDiNgzSciyBIgrUXiouVE/view

Talks and Events

We participated in key technical spaces this month:

In parallel, House of ZK hosted a ZKM special covering zkMIPS 1.0’s architecture and role in powering GOAT Network. https://hozk.io/journal/zkm-report — https://x.com/HouseofZK/status/1927031440568451093

On the Road

ZKM made appearances at the Bitcoin Economy Conference, where Ming and Stephen explained the foundational design of both ZKM and GOAT. We’ll also be sponsoring and speaking at House of ZK’s upcoming Ethproofs Summit in Berlin, and hosting ZK Morning Coffee during EthCC alongside @Starknet, @Hyli_org, and @thzkcloud — a casual gathering for serious builders.

Register for ZK Morning Coffee: https://lu.ma/71jtlhzi

That wraps up May — a true milestone month for ZKM. We launched zkMIPS 1.0, expanded into real-world deployments, defined ecosystem standards, and began energizing the developer community. June will build on this momentum.

Follow us at @ProjectZKM to stay ahead of what’s next 🟠

Originally published at https://www.zkm.io.

Zero-knowledge systems are quickly moving from research to production, and the industry is converging around a core assumption: ZK is the cryptographic foundation for how trustless systems will operate at scale.

This past week, ZKM released zkMIPS 1.0 — the first production-ready zkVM built on the MIPS32r2 architecture. It delivers up to 19x faster proving over its prior version and outperforms other major zkVMs on CPU benchmarks across standard workloads. But beyond performance, what matters is where zkMIPS 1.0 is being deployed: Ethereum and Bitcoin. In both ecosystems, it’s being primed to enable trust-minimized execution with real-world stakes and real-time constraints.

ZK for Ethereum: Enshrining Proofs

@ethereumfndn has made it clear: zero-knowledge proofs will become a native part of its consensus in the long term. The @eth_proofs initiative is the testbed for that future, shaping up to be the most important benchmarking environment for zkVMs. With over 20 zkVMs now lining up to participate, @ethereum is about to become the proving ground for verifiable compute infrastructure.

ZKM is one of the few teams already submitting proofs of Ethereum mainnet blocks through EthProofs, and zkMIPS 1.0 is now fully integrated. The proving architecture supports Groth16, PLONK, and compressed STARKs, giving flexibility across verification cost, recursion compatibility, and hardware environments.

Upcoming GPU prover support and circuit improvements are expected to drive proof time and cost even lower — opening the door to real-time proving of Ethereum L1 execution.

ZK for Bitcoin: Native Security, Finally Possible

At the same time, zkMIPS 1.0 is live on @GOATRollup — a Bitcoin Layer 2 that uses BitVM2 and zkMIPS to provide sustainable, native BTC yield through a fully trust-minimized decentralized sequencer and execution architecture.

Bitcoin has long lacked credible L2 systems with native BTC security. BitVM2 changes this: enabling arbitrary computation on Bitcoin without L1 changes. But it’s only viable in practice when paired with a performant, stable zkVM. That’s where zkMIPS comes in.

GOAT BitVM2, introduced this week, solves key production challenges — double-spend risk, slow challenge resolution, and misaligned incentives — by combining zkMIPS proofs with a decentralized sequencer layer and a fully cryptoeconomically secure challenge protocol. The result: finality in under 24 hours and a real path to native Bitcoin execution.

Two Foundations, One Objective

While zkMIPS was built for generality, its supporting infrastructure has been engineered with two specific outcomes in mind.

Ethereum’s roadmap demands scale, modularity, and recursive efficiency. Bitcoin’s demands native settlement, minimal trust, and economic security. zkMIPS 1.0 is built to meet both.

The team has repeatedly chosen the more difficult path — opting for a mature fixed ISA (MIPS32r2) over the more popular but evolving RISC-V. That decision now shows its payoff: smaller programs, simpler constraint systems, and performance gains that translate directly into lower cost and higher speed.

More integrations are on the way — from Rollup upgrades to verifying AI systems — and the ZKM team shows no signs of slowing down.

Developer Track

If you’ve been waiting for the right moment to start building with zkMIPS, this is it.

We’re inviting developers to create zkMIPS-powered applications, contribute to the zkMIPS toolchain or example projects, and produce educational content to help onboard others.

This is your chance to help shape the zkVM ecosystem from the ground up.

‍

Originally published at https://www.zkm.io.

With the release of zkMIPS 1.0, ZKM has opened up a new paradigm. After months of intensive engineering, zkMIPS is now production-ready, performance-optimized, and actively proving Ethereum mainnet blocks and powering Bitcoin-native applications like GOAT Network. But this milestone isn’t the end — it’s the beginning. And we want YOU to be a part of it.

The ZKM Early Contributor Program now enters its third and final phase, focused entirely on builders. While previous phases invited users to generate proofs and contribute to the growing ZK ecosystem through community content, Phase 3 is aimed squarely at developers who want to explore and implement the benefits of verifiable computation into their applications.

Why Contribute Now?

Phase 3 coincides with the most technically mature point in ZKM’s journey to date. zkMIPS 1.0 delivers 6x to 19x improvements over the previous version across benchmarks, and for the first time, developers have access to a full SDK, patched libraries, and a working toolchain designed for real-world use.

But more importantly, ZKM is not just another zkVM. It’s the only production-ready VM based on MIPS — a fixed, stable instruction set chosen for its alignment with efficient proof generation, trace compactness, and long-term compatibility. This makes zkMIPS uniquely suited to developers who want to go beyond experimentation and build applications meant to last.

What Can Developers Do in Phase 3?

ZKM is calling on developers to engage in three core ways:

1. Build a Real zkMIPS App

• Use the provided ZKM SDK, compiler toolchain, and template to build a verifiable application (zkApp) running on zkMIPS.
• Focus areas include identity, AI-verification, Bitcoin L2s, or novel trust-minimized systems.
  ‍

1. Improve the Tooling

• Contribute to ZKM’s open-source repos by improving tooling, documentation, or templates.
• Star and fork the GitHub repo to show support and help raise visibility.
  ‍

1. Run and Optimize Proofs

• Deploy the ZKM Prover locally or via the Proof Network and experiment with custom circuits or verification logic.
• Submit benchmarks or optimization PRs to help shape the next proving iteration.

Why It Matters

This is more than just another ZK program. ZKM is building verifiable compute infrastructure that already works — on Ethereum, on Bitcoin, and soon across chains. By contributing now, developers get a chance to work with what is arguably the most performant zkVM stack currently available.

If you believe in the long-term impact of zero-knowledge infrastructure, and if you want to work with a team that’s been prioritizing the building of superior tech over hollow marketing campaigns, now is the time.

Ready to build? View our ECP task board here: Tasks & Submissions

Try it. Fork it. Prove it.

Originally published at https://www.zkm.io.

zkMIPS 1.0 is here — our most significant leap toward real-time proving, following months of careful engineering and system-level breakthroughs.

We’ve been heads-down refining every layer of the stack — now it’s ready: the first production-ready version of our MIPS-based zkVM. This upgrade delivers a 6x-19x performance improvement over zkMIPS 0.3.0 and is a major breakthrough in our attempt to build the most simple, stable, and scalable foundation for real-time verifiable computation.

zkMIPS 1.0 is the result of a full-stack overhaul: new architecture support, optimized proving systems, memory checking mechanisms, chip decomposition, and precompile strategy. Together, these updates make zkMIPS a highly performant proving infrastructure for the next generation of verifiable applications.

Key Upgrades in zkMIPS 1.0

Support for MIPS32r2
We’ve upgraded from MIPS2 to the MIPS32r2 ISA, unlocking access to a broader opcode set (e.g. MADDU) and compiler-level optimizations. This reduces program size, enabling more efficient execution and smaller trace matrices during proof generation.

Powered by Plonky3 and Koala Prime Field
zkMIPS now leverages Plonky3 — an advanced STARK backend using the FRI protocol — and adapts SP1’s circuit builder and recursion infrastructure. The KoalaBear 31-bit prime significantly accelerates arithmetic operations compared to the previous 64-bit Goldilocks setup.

Multiset Hashing for Memory Consistency
We’ve replaced Merkle trees with multiset hashing for memory consistency checks. This reduces witness size, minimizes communication overhead, and enables parallel verification.

Area-Minimized Chip Design
zkMIPS partitions circuits into modular ‘chips’ that minimize constraint layout area. This reduces proof generation costs while preserving completeness. Applied across CPU and memory subsystems.

Precompiles for Hot Paths
Heavy operations like Keccak and field arithmetic are abstracted into precompiles, reducing constraint payload and speeding up verification.

Benchmarking the Performance Gains

We benchmarked zkMIPS 1.0 against zkMIPS 0.3.0 using the zkVM-benchmarks suite ( https://github.com/zkMIPS/zkvm-benchmarks), running on AWS r6a.8xlarge.

Results below (lower is better):

Across a wide variety of workloads, zkMIPS v1.0 consistently delivers 6x-19x improvements in performance over v0.3.

For a performance comparison with other leading zkVM’s, see: https://docs.zkm.io/introduction/performance.html#performance-of-zkmips

A Developer Toolkit

zkMIPS 1.0 ships with a full toolchain and SDK, including:

• A compiler toolchain targeting mipsel-zkm-zkvm-elf
• A zkm_sdk Rust crate for local proof generation and verification
• Support for Core, Compressed, Groth16, and PLONK proofs
• A network prover integration with the ZKM Proof Network
• Guest patches and precompile support for common cryptographic libraries

Developers can get started in minutes with:

curl — proto ‘=https’ — tlsv1.2 -sSf https://raw.githubusercontent.com/zkMIPS/toolchain/refs/heads/main/setup.sh | sh

Ecosystem Readiness

zkMIPS 1.0 is already integrated into the ZKM Proof Network and is live-proving Ethereum mainnet blocks as part of the Ethereum Foundation’s EthProofs initiative.

It’s also in production with GOAT Network, a Bitcoin L2 powered by BitVM2 and built entirely on zkMIPS. This demonstrates the first real-world deployment of zkMIPS as a trust-minimized Bitcoin execution environment, with further integrations underway across AI, Optimistic Rollup upgrades, and more. ‍

Using zkMIPS 1.0 on the ZKM Proof Network

The same 6x-19x performance improvements achieved in local benchmarks now apply to network proving as well, enabling significantly faster proof generation for supported programs.

zkMIPS 1.0 introduces a new circuit architecture, so verifier keys must be regenerated. Proofs generated with zkMIPS 1.0 are not compatible with previous versions.

All proof types — Groth16, PLONK, and compressed STARKs — are supported with zkMIPS 1.0 on the ZKM Proof Network.

If you are already using the ZKM Project Template ( https://github.com/zkMIPS/zkm-project-template), you don’t have to change anything on the prover side to use zkMIPS 1.0. For verification, just regenerate the verification key.

If you’re using the local prover, zkMIPS 1.0 support is coming soon. In the meantime, follow thisguide to get started: https://docs.zkm.io/dev/prover.html#prover

Make sure to pull the latest zkm_sdk crate (from the main branch) to ensure compatibility with the zkMIPS 1.0 toolchain.

We also provide a set ofpatched crates to speed up proof generation: https://docs.zkm.io/dev/patched-crates.html

What Comes Next

zkMIPS will continue to evolve. More patches, better cost models, broader precompile support, and deeper integration into rollups and trustless bridges are underway.

We’re building toward a unified proving infrastructure — one that can support multiple chains, multiple proof types, and radically improved developer experience.

zkMIPS 1.0 is the milestone that makes that real, but there is much more to come.

Try it. Fork it. Prove it.

Developer Track

With the release of zkMIPS 1.0, we’re entering the final phase of the ZKM Early Contributor Program — focused on developers. If you’ve been waiting for the right moment to start building with zkMIPS, this is it.

Key tasks include building and publishing zkMIPS-powered applications, contributing to the zkMIPS toolchain or example projects, and producing educational content to help onboard others.

This is your chance to help shape the zkVM ecosystem from the ground up — earning ZKM POINTS in the process.

Get started with zkMIPS 1.0: ZKM Docs

Build with zkMIPS 1.0: ZKM Github

Originally published at https://www.zkm.io.

zkMIPS 1.0 is near.

This release will bring the most advanced performance and architecture upgrades to date:

• 6–20x increased prover performance compared to zkMIPS 0.3
• Integration of MIPS32r2, a fixed, efficient ISA that reduces circuit complexity and improves execution trace density
• Migration to Plonky3, our next-gen proving backend
• New optimizations: multiset hashing, chip decomposition, and high-efficiency precompiles
• Designed for real-world use: powering GOAT Network (Bitcoin L2), proving Ethereum blocks (via Ethproofs), and upcoming integrations with Metis, LazAI & more
• Unlike zkVMs based on RISC-V, zkMIPS uses a stable, 20+ year standardized ISA, purpose-built for verifiable computation

zkMIPS 1.0 is ZKM’s biggest step to-date toward real-time, trust-minimized execution across blockchain ecosystems — starting with Bitcoin and Ethereum.

This month, we continued delivering deep technical breakdowns of the ZKM Prover:

• Arithmetic Operations and CPU Operations: Explore how arithmetic and CPU operations work in the ZKM Prover, and what that means for developers optimizing for performance → Read the article
• Cross-Table Lookups: How the ZKM Prover uses CTLs to ensure consistency across execution layers — CPU, memory, arithmetic — enabling modular, scalable proofs → Read the article
• Poseidon in STARK: A deep dive on PoseidonStark, our custom Poseidon hash implementation for STARKs. It covers round computations, constraint design, and witness generation. A practical reference for developers optimizing hash functions in ZK circuits →Read the article
• Why MIPS?: In perhaps the standout piece of the month, this article explains why ZKM chose the road less traveled by building zkMIPS on MIPS32r2 instead of RISC-V. This deep dive explains how a richer, more mature instruction set leads to shorter traces, lower proof overhead, and a more performant zkVM → Read the article

An Architectural Comparison between MIPS32r2 and RISC-V

Global Events

• The ZK/AI Summit (Token2049, Dubai): ZKM Co-founder and Chief Scientist Ming Guo participated in multiple panels at House of ZK’s recent event in Dubai. The summit reached full capacity and received over 200k livestream views. Catch up on the action here →Watch now
• Web3 Festival, Hong Kong: ZKM Developer Lead Stephen Duan joined the panel “The ZK Road to Enshrinement”, where he shared how zkMIPS is expanding beyond EVM chains, unlocking cross-ecosystem verifiability and enabling trust-minimized computation →Watch now
• zkVM Meetup (Shanghai): Stephen also gave a deep-dive into zkMIPS’ modular STARK-to-SNARK pipeline and why a fixed ISA like MIPS offers unmatched ZK performance, during the Shanghai zkVM meetup.
• Zero-Knowledge & Bitcoin College Tour: Presenting to blockchain clubs from Yale, Princeton, Columbia, and NYU, Ming talked about ZKM’s Entangled Rollup Design and highlighted the role of zkMIPS in powering GOAT Network, the first Bitcoin Layer 2 to offer sustainable native yield. The recording will be available soon.

Will Corcoran of the Ethereum Foundation giving a ZKM shoutout at the College Tour

April saw ZKM’s core team participate in multiple ZK gatherings around the world:

Ethproofs

In the first ever Ethproofs builders call, ZKM Developer Lead Stephen Duan joined Justin Drake and the Ethproofs community to discuss the upcoming zkMIPS 1.0 upgrade, sharing how zkMIPS 1.0 delivers a 6–20x performance boost over v0.3, and outlining ZKM’s path toward real-time Ethereum block proving.

Justin expressed his excitement about the progress being made by ZKM, and rightfully so. The dark horse of the zkVM race is about to get much, much faster.

• Final performance benchmarks and public rollout of zkMIPS 1.0.
• Expanded dev tutorials and precompiles.
• Deeper integrations with Ethproofs — we’ll let the data do the talking.
• More IRL events and workshops.

Looking Ahead

As our big zkVM upgrade is prepared for launch, May is shaping up to be the most exciting month in ZKM’s history:

The future of verifiable computation is fast, flexible, and finally here.

Let’s build together.

🔗 Follow us on X

📚 Explore our research

💬 Join the community

Originally published at https://www.zkm.io.