Arbitrum’s ZK Test Is No Longer EVM-Only—it Must Prove Stylus

Arbitrum’s latest ZK settlement update changes the question developers should ask. The issue is no longer whether an EVM block can be proven; it is whether a production-oriented chain can prove every execution environment it supports.

In an August 20 announcement, Arbitrum said its prover can take a real Arbitrum One mainnet block and generate a zero-knowledge proof by running the actual Arbitrum state-transition function inside SP1, Succinct’s RISC-V zkVM. The claim matters because it describes proof generation over the same execution logic used by Arbitrum’s optimistic prover, rather than a separate approximation.

The sharper milestone is Stylus. Arbitrum’s WASM-based prover has been extended to prove Stylus contracts alongside Solidity contracts. Stylus allows developers to write contracts in Rust, C, C++, Move, and other languages that compile to WASM. That makes the proving boundary a systems problem: the verifier must cover both EVM behavior and WASM behavior, including the interface between them.

This is also why the validator redesign matters. Arbitrum says its validation machinery has been rebuilt as a standalone Rust service so standard validation and proof generation can share one path. In practical terms, that can reduce the risk that the optimistic and ZK modes silently implement different rules. SP1’s own repository describes the zkVM as able to prove arbitrary Rust or other LLVM-compiled programs, which fits the direction of proving a mixed execution stack.

The settlement design is deliberately additive. Arbitrum says BoLD can accept a valid ZK proof for an assertion and confirm it earlier, while its fraud-proof dispute game remains available if no proof arrives. That creates a multi-prover fallback: ZK can reduce the normal waiting period, but a proving outage does not automatically remove the existing settlement route.

The safety boundary is not finished. Arbitrum lists lower proving cost and latency, proving the L1 message inbox, and exposing ZK settlement as a node configuration step as future work. It also says an upgrade for Arbitrum One would require a DAO proposal. In other words, this is a verified engineering milestone, not a claim that ZK settlement is already the default production path.

For ICP developers watching the ZK infrastructure race, the lesson is concrete: compatibility should be measured across the whole runtime. A chain that proves only its headline VM may still leave its alternative language runtime, message inbox, or validator implementation outside the proof boundary. Stylus makes that gap visible—and gives the next generation of chain-integrated provers a more demanding definition of “ZK-compatible.”

This article is based on the Arbitrum engineering update, the SP1 repository, and the Ethereum Foundation’s current discussion of machine-checked SNARK soundness.