IOG Develops ZK Wrapper for RISC Zero and SP1 Proof Verification on Cardano

Input Output Research is developing a zero-knowledge wrapper designed to connect Cardano applications with RISC Zero, SP1 and other systems that generate Groth16 proofs over the BN254 elliptic curve.

The prototype addresses a cryptographic compatibility gap that currently prevents Cardano smart contracts from efficiently verifying many proofs produced by established ZK tools. The work is still in the technical-feasibility stage, with selected components being prepared for potential engineering implementation in early 2027.

Groth16 Wrapper Converts BN254 Proofs for Cardano

A large share of blockchain zero-knowledge infrastructure uses Groth16 proofs over BN254. Ethereum’s support for the curve encouraged developer frameworks, applications and ZK virtual machines to adopt the same cryptographic standard.

Cardano instead supports BLS12-381 operations. Although Groth16 can be used with both curves, a proof created over BN254 cannot be verified efficiently on Cardano without new protocol functions or computationally expensive arithmetic inside a Plutus smart contract.

The prototype introduces a recursive wrapping layer between the two environments. It receives a valid Groth16 proof over BN254 and generates a second proof over BLS12-381, allowing Cardano to verify the result using cryptographic operations already supported by the network.

The conversion does not require users to trust the party performing it. The outer proof confirms that a valid original proof exists for the specified verification key and public inputs. Cardano checks that claim without repeating the computation behind the original result.

The current toolkit supports RISC Zero and SP1, two zero-knowledge virtual machines that allow developers to run general-purpose programs and generate compact proofs that those programs executed correctly.

Source-specific plugins convert their outputs into a common format. The wrapping engine then reproduces the claim over BLS12-381 and generates verifier code that can be integrated into a Cardano application.

Input Output Research tested Groth16 and Plonk as outer proving systems. Groth16 completed the wrapping process faster and produced smaller proofs, but requires a trusted setup for the wrapper circuit. Plonk avoids a circuit-specific setup while requiring substantially more off-chain proving time.

Both approaches produced final proofs capable of fitting within Cardano’s on-chain verification budget. The main trade-off therefore sits in proof generation and setup requirements rather than final verification through Plutus.

RISC Zero and SP1 Could Support Cross-Chain Verification

Compatibility with RISC Zero and SP1 would allow Cardano developers to use existing ZK programs and libraries without rebuilding every computation for Cardano’s cryptographic environment.

One example included in the research proves the ERC-20 balance of an Ethereum account. RISC Zero executes the required Ethereum logic, extracts the balance from committed network state and generates a proof. The wrapper then converts that output into a form that a Cardano validator can verify.

The same architecture could be used to confirm selected Ethereum or Bitcoin state, verify external program execution or provide cryptographic evidence that a computation occurred outside Cardano.

The workshop also discussed a potential SP1-based implementation of Helios, an Ethereum light client. Such a system could prove Ethereum consensus execution inside a zero-knowledge environment and submit a compact result for verification by a Cardano application.

These capabilities could support light clients, bridges, rollups and cross-chain protocols that depend on reliable information from another blockchain. The wrapper does not transfer assets or operate as a bridge by itself. It provides a verification layer that other applications could integrate into their own architecture.

The approach could also reduce duplicated development work. Instead of implementing every computation as a Cardano-native ZK circuit, teams could use supported software from the RISC Zero or SP1 ecosystems and translate the final proof before on-chain verification.

The toolkit remains a prototype for experimentation. Its examples cover proof generation, recursive wrapping and creation of the corresponding Cardano verifier, while production deployment would still require engineering work, security review and a final decision on the outer proving system.

Plonky3 and Halo2 Define the Remaining Verification Work

The workshop also presented a feasibility study for verifying Plonky3 proofs through Cardano smart contracts.

Plonky3 is a modular framework for STARK-based proving systems. It relies primarily on hash functions and finite-field arithmetic rather than the elliptic-curve operations used by many SNARK systems, making it relevant to Cardano’s post-quantum research.

One proposed application is post-quantum signature aggregation. These signatures can require tens of kilobytes each, while a ZK proof could combine multiple signatures into a single result and reduce the amount of data that must be stored or verified on-chain.

Another possible use concerns legacy UTXOs following a future migration away from current elliptic-curve signatures. A holder could potentially prove knowledge of the seed connected to an address without revealing the seed publicly.

The feasibility study found that direct Plonky3 verification still exceeds Cardano’s single-transaction limits. An optimized test proof measured approximately 186 kilobytes and required around 220 million memory units and 75 billion CPU units.

Because individual query proofs can be checked separately, the researchers estimated that the complete process could be divided across approximately 23 transactions. Hydra execution and an optimistic verification model, in which the full proof is checked only after a challenge, were also discussed as possible alternatives.

A separate Halo2 cost estimator addresses an earlier stage of the development process. The tool calculates expected proof size, verification-key size and the cryptographic operations required to verify a proposed circuit on Cardano.

Developers can model a circuit or test components such as SHA-256 before completing the full application. The estimates allow teams to identify expensive components and adjust the design before building the prover and Cardano validator.

The Groth16 wrapper is currently the most direct route from the research program to practical developer use. If it advances into engineering implementation, Cardano applications could verify outputs from established zkVM ecosystems without waiting for each external system to introduce native BLS12-381 support. Plonky3 would require a different architecture, with verification divided across transactions, moved into Hydra or activated through a challenge-based design.