# zkVerify


*The Blockchain that runs no dapps, instead, just Verify.*

By [knowLOG](https://paragraph.com/@knowlog) · 2025-12-21

zk, zkverify, proof, verification

---

* * *

**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_**  

![](https://storage.googleapis.com/papyrus_images/8ce976072bb2867f66b7c57eb71a53cff72ff5e1c4dac648eded8e1e937493d8.png)

**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 **z_kVerify 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 :)

---

*Originally published on [knowLOG](https://paragraph.com/@knowlog/zkverify)*