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:

1. Fetch the Merkle path

2. Submit the path to its own smart contract

3. 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 :)

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:

1. Fetch the Merkle path

2. Submit the path to its own smart contract

3. 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 :)