okay so what is zkVerify?
a one-liner answer would be: it is a one-stop solution for all proof verification needs
Not running apps… not doing DeFi…
Just verifying proofs as fast and cheap as possible.
so… is zkVerify some helper chain or plugin?
Nope.
It’s an actual L1 blockchain, built solely for verification.
Meaning:
It has its own validators
It has its own consensus
It’s optimized only for verifying proofs
instead of asking another L1 to verify proofs on-chain, systems can offload proof-checking to zkVerify
and what kinds of proofs can it verify?
Pretty much all major proof systems, for example:
Groth16
EZKL
UltraHonk (Noir)
UltraPlonk (Noir)
Risc0 (STARK-proof)
SP1 (STARK-proof)
you name it, they have it ;)
let’s dive deep into the “how?”
from proof submission → verification → attestation → on-chain confirmation
1. Proof creation by a client
A zkApp, zkRollup, zkBridge, or any ZK-enabled system generates a proof.
Example: An Fflonk proof created by a zkApp.
2. Proof submission to zkVerify
The client sends its proof to zkVerify using the Proof Submission Interface.
This interface accepts:
The proof
The verification key (vk)
Public inputs
Each proving system (Groth16, Plonk, STARK, Halo2, etc.) has proof specific verification palettes
3. Native rust verification
Once received, zkVerify:
Selects the appropriate verifier module
Runs native Rust verification (faster, safer, and cheaper than Solidity-based verification)
If valid → the proof moves to the queue for inclusion.
If invalid → the system returns an error.
4. Proof queued for block inclusion
Both Validated and invalidated proofs are queued on-chain and made available for aggregation according to predefined policies
This batching:
Reduces cost
Allows aggregation of heterogeneous proof types
Leads to a uniform settlement structure
4.5 Permissionless Aggregation
Aggregation on zkVerify is permissionless.
Any network participant can act as an aggregation publisher by:
Selecting an aggregation domain
Building the Merkle tree off-chain
Calling the aggregate extrinsic on zkVerify
Publishers pay the computation cost upfront and are reimbursed using fees collected from proof submitters.
5. Merkle Tree Construction
zkVerify exposes a permissionless aggregation mechanism, where any participant (publisher) can aggregate queued proofs into a Merkle tree according to predefined aggregation domains and policies, where:
Each leaf represents a verified proof statement
Tree contains a mix of proof types (Groth16 + Plonk + STARK + Fflonk, etc.)
The root is a compact representation of all included proofs
This is called the zkVerify Merkle Tree.
6. Attestation generation
Once an aggregation is published, zkVerify finalizes it on-chain by emitting an aggregation receipt (Merkle root) and related events. This finalized receipt acts as an attestation - a cryptographic commitment by the zkVerify chain that:
These proofs were verified
This Merkle root is canonical
Each attestation includes:
The Merkle root of the proof tree
An attestation ID
A digital signature
It represents “proof that these proofs were verified and recorded.”
7. Relay to Destination Chain
A relayer sends the attestation to a smart contract called the zkVerify L1 Contract on the user’s chosen destination chain.
Users pay:
Base zkVerify fee
Relayer fee (for posting on their chain of choice)
8. Attestation Stored On-Chain
The zkVerify L1 Contract:
Stores the attestation
Validates its signature
Makes it available for public verification
This acts as the source of truth on that chain.
9. Client Verifies Proof Inclusion
The zkApp that originally sent the proof can now:
Fetch the Merkle path
Submit the path to its own smart contract
Confirm that:
The proof → is part of the Merkle tree
The Merkle tree → matches an attestation on-chain
If both match = the proof is successfully verified by zkVerify, yay !
Simple job. Done extremely well.
don’t trust, zkVerify ;))
Thanks for reading :)