Report Summary
Summary
zkVerify is a dedicated ZK proof verification layer purpose-built to address Ethereum’s inability to scale ZK proof verification. As ZK becomes foundational to Ethereum’s roadmap — from zkRollups to zkVMs and privacy-preserving apps — the bottleneck is no longer proof generation, but proof verification: it’s slow, expensive, and operationally complex.
zkVerify eliminates these issues by offering a modular, system-agnostic, and low-cost L1 for ZK proof verification, enabling fast finality, cost efficiency, and seamless integration for both zkApps and ZK rollups.
Key Takeaways
1. Verification Costs Are the Bottleneck
-
Verifying ZK proofs on Ethereum is prohibitively expensive and gas-intensive:
-
Groth16: ~200–300k gas ($20–60 per proof).
-
STARKs: up to 5M gas ($200+ per proof).
-
-
Ethereum blockspace limits verification throughput (e.g., only ~6 STARKs per block).
2. Why EVM Can’t Scale ZK Natively
-
The EVM lacks universal precompiles for common ZK systems.
-
Developers must deploy and maintain custom verifier contracts for each circuit.
-
Ethereum governance makes precompile updates slow and future-incompatible.
3. zkVerify’s Core Innovation
-
zkVerify is a universal verifier layer with:
-
Support for multiple proof systems (SNARKs, STARKs, Halo2, etc.).
-
Dedicated blockspace for verification — no congestion from unrelated apps.
-
Seamless API for devs: “send proof → get attestation.”
-
4. Cost Reduction & Developer Experience
-
zkVerify cuts Groth16 costs from 200k gas → 18k gas (11× reduction).
-
Starknet could save ~88% on verification fees ($168k/year → ~$20k/year).
-
Simplifies workflows: no need to maintain Solidity verifiers or rewrite contracts per circuit.
5. Impact on the ZK Ecosystem
-
Over 43M users and 178M addresses interact with ZK protocols.
-
More than $55M in gas already burned on Ethereum for ZK verification.
-
zkVerify improves withdrawal times, lowers L2 fees, and supports faster state updates.
6. Amortization vs Frequency Tradeoff
-
Rollups like Starknet batch proofs to amortize costs — but this delays user withdrawals.
-
zkVerify enables frequent, low-cost submissions, improving UX and liquidity flow.
7. Ethereum Alignment
-
Ethereum’s roadmap now hinges on zkEVMs, recursive proofs, and client diversity.
-
zkVerify complements this by offering:
-
Modularity: Avoids lock-in to single proof systems.
-
Abstraction: No need for Solidity verifiers or governance delays.
-
Future-proofing: Supports rapid evolution in proving systems.
-
Conclusion
zkVerify fills a critical gap in Ethereum’s modular future by abstracting and optimizing ZK proof verification. As ZK protocols scale and diversify, Ethereum’s monolithic structure can’t keep up with verification demands.
zkVerify solves this by:
-
Cutting costs,
-
Removing dev complexity,
-
And unlocking scalable verification across chains, circuits, and apps.
It positions itself as the “shared ZK verification layer” that every rollup, zkApp, and protocol will need — not just for savings, but for survival.
-
Introduction
ZK is eating infra, but verifying proofs on Ethereum is still broken: it’s slow, expensive, and a pain to integrate for devs. The EVM wasn’t built for this. It lacks universal precompiles, and its fee market treats every ZK proof like a luxury item. And yet ZK rollups (ZKR) and zkApps are forced to play along while burning millions in gas.
We’ve been tracking zkVerify from day one. The first deep dive report laid out the architecture: a purpose-built L1 for proof verification. The Q1 memo walked through the integration flow. This piece zooms in on a real pain point that’s been ignored: verification costs. Here, zkVerify is among the few projects that tackle this issue at the protocol level.
Yet cost reduction is just a downstream effect, not the main unlock. Under the hood, zkVerify strips away entire layers of complexity from the ZK stack. Devs are no longer required to deploy a verifier or maintain circuit-specific contracts. With zkVerify, praying in vain for the L1 to add precompiles for your proof system is over.
Meanwhile, Ethereum is going all-in on ZK. One thing is clear from the Foundation’s roadmap: ZK is no longer optional. Proofs will underpin every layer of the stack, from consensus to client privacy, building the foundation of Ethereum’s L1 zkEVM pivot.
But none of that works at scale without rethinking how we verify proofs…
It’s clear by now that the ecosystem needs a universal ZK verifier layer. zkVerify delivers just that, allowing you to prove once and verify anywhere. The DevEx improves by an order of magnitude, and the overhead burden disappears.
Previously, we looked at zkVerify’s architecture and integration flow. In this memo, we’ll focus on what’s broken in the proving landscape, how zkVerify addresses it, and why that changes the game for every ZKR, zkApp, and any protocol betting on ZK.
Proof Verification: A Cost-Prohibitive Integration Nightmare
ZK proofs are becoming core infra. And verification, once assumed to be cheap and negligible, is proving to be a major bottleneck. Both technically and economically. Every protocol that integrates ZK proofs needs to plan for this cost, or risk bleeding capital just to prove correctness.
Any app thinking about ZK native features must understand the economics around it. Because if you’re not paying now, your users soon will. To put it practically, multiple reports now project the proving market to grow into a multi-billion dollar economy:
- Aligned projects 87B ZK proofs by 2030, with a market-clearing price of $0.12 per proof, resulting in a $10.2B market size from ZK proving alone.
- Chorus One presents a more conservative estimate of $1.34B by 2030, based on real-world batch costs (~$0.001/proof).
- Horizen Labs (zkVerify) estimates $1.5B+ spent by 2028, driven by ZKR and zkApp security costs alone.
But here’s the catch: none of this scales on Ethereum. Ethereum, for all its dominance, is a terrible place to verify ZK proofs. The absence of a universal verification system and the lack of support for multiple precompiles make proving cost-prohibitive and a nightmare to integrate.
Almost every ZK system in production today pays high gas costs to run complex on-chain operations verifying ZK proofs on Ethereum. This isn’t going to improve anytime soon. And precompile contracts are crucial because they help optimize resource-intensive operations, such as those involving elliptic curves (like SNARK proofs).
Why is this the state of things? Because the EVM wasn’t built for ZK, it lacks precompiles for most ZK proofs. That means devs have to manually deploy custom verifier contracts each time, for every circuit.
Suppose Ethereum added a precompile for Groth16. It would only benefit Groth16 users, but leave everyone else out. Plonk, STARK, and Halo2 would remain unsupported. And expecting Ethereum to support every proof system is unrealistic.
Even if Ethereum wanted to keep up, adding precompiles is a slow, governance-heavy process. By the time one gets added, the ecosystem may have already moved on to newer proving systems. The bottleneck becomes Ethereum itself.
So verification remains costly. Groth16 proofs cost around 200k-300k gas (roughly $20 at 30 gwei and $3k ETH). STARKs can cost up to 5M gas, that’s ~$200 per proof.
To make matters worse, Ethereum has another bottleneck. The block limit is 30M gas (recently increased to 36M). A block can only fit ~100 Groth16 proofs, or just six STARKs, given no other apps are using blockspace. But Ethereum’s blockspace is never reserved for just ZK proofs, every app and user is competing to be part of the 30m gas. Every time.
As more ZK apps come online, demand for verification grows. But Ethereum’s architecture can’t keep up. It’s a shared chain with limited room and no native support for most proofs.
A dedicated verification layer with uncontested blockspace isn’t just useful, it’s a glaring necessity. One that supports multiple proof systems, maintains new verifiers, evolves with them, and provides uncontested blockspace just for proving. Enter zkVerify.
Having a dedicated verification layer seems like the natural conclusion to the modular stack thesis. Since this layer only verifies proofs, its blockspace is not shared with unrelated apps or activities. Offloading proof verification from L1s serves to both lower nominal costs and stabilize costs over time by segregating fees from gas volatility.
Over the past couple of years, ZK protocols (mostly rollups) have burned over $55M in gas just to verify and post proofs on Ethereum. And that number keeps climbing. As more protocols go live and adoption picks up, it becomes obvious there is a glaring need for a scalable way to bring those costs down. Otherwise, the economics fall apart, barriers to entry stay high, and costs remain prohibitive.
There are now over 43M unique users across ZK protocols, with cumulative addresses surpassing 178M by June 2025. Active users peaked at 7.6M in March last year, up from just ~2.5M in April 2023.
It’s worth noting that this is not a full list. It’s measured by analyzing the main leaders in the ZK field and identifying which apps are using which proof system:
- SNARK: ZKSync Era, Polygon ZKEVM, Aztec, Linea, Tornado Cash, Loopring, Worldcoin (mostly settling proofs on Optimism), Railgun, Sismo.
- STARK: StarkNet, ImmutableX, dYdX, Rhino.
ZK-Identity applications, such as Worldcoin, verify ZK proofs to ensure the user’s uniqueness without revealing personal data. Each proof can consume upwards of 200k to 300k gas units.
In times of network congestion, gas prices have reached over 100 Gwei. This means that verifying a single proof could cost between $20 and $60, or even more. To alleviate costs, Worldcoin launched an L2 based on Optimism’s OP stack. While this may mitigate the issue in the near term, it does not address the fact that billions of dollars of users’ liquidity and assets still live on Ethereum and not its L2s.
ZK-Apps vs ZK-Infra
ZK protocols can be divided into two categories:
(1) Infrastructure (Infra) providing the foundational technology and tools that use zero-knowledge, and
(2) Applications (Apps) or protocols building on top of the infrastructure.
The main roadblock preventing builders from launching ZK protocols today is the prover and verification cost. Thanks to the recent developments in ZK tech by teams like Succinct and RISC Zero (among many others), proving costs have decreased significantly. However, verification costs still remain a high barrier to launching ZK protocols. As mentioned, verification on the EVM is limited by precompiles, gas costs, and gas limits per block. That’s where zkVerify taps in.
In 2023, the number of total ZK app users was just below 63k. Since then, the user base has grown significantly. On the ZK infra level, there have been more than 20M addresses that have triggered transactions – primarily users of ZKRs. At the application level, more than 23 million addresses have interacted with ZK-powered apps like Tornado Cash or Railgun.
ZK Apps in 2024:
ZK Apps in 2023:
Infra protocols are currently the dominant users of ZK tech. Although fees are substantially lower at the infra level, the majority of settlement fees (>70%) are paid by ZK-infra protocols like ZKRs. Most activity and economic value in the ZK ecosystem is centered around building and maintaining the infrastructure, rather than specific zkApps.
Rollup Settlement Costs and the Dichotomy of Amortization
In production, a verification layer like zkVerify will be able to increase bandwidth and cut the cost of ZK proofs on-chain. In the initial benchmarks of zkVerify, the Groth16 proof cost could be reduced from ~200k gas to ~18k gas, a reduction of 11x.
Verification costs are constant in gas but high in complexity. The EVM lacks a universal verifier, doesn’t support multiple proof systems, and requires expensive on-chain operations for every circuit. So devs end up in a maintenance nightmare: deploying, updating, and testing custom verifier contracts for every new circuit or protocol iteration.
As a dedicated L1 for ZK verification, zkVerify offloads both the cost burden and the operational overhead. Proofs are submitted off-Ethereum and verified in a purpose-built environment with native support for multiple proving systems, and attestations can be relayed back to Ethereum or any other chain as needed.
Instead of wrestling with circuit-specific verifier contracts on Ethereum, devs just send their proof to zkVerify. No need to re-encode, re-deploy, or re-audit. Proofs are verified once and attested globally, opening the design space for both ZK apps and ZK infra.
ZKRs face two primary costs when posting proofs to Ethereum: (1) on-chain proof verification and (2) data availability (DA). DA costs are variable and being addressed by various Ethereum upgrades, such as Proto-Danksharding, which improves the efficiency of data storage and access on-chain, not ZK proof verification directly. The proving costs can be reduced by outsourcing proof verification to a specialized layer like zkVerify.
ZKRs are still spending more on proof verification than on blob submissions. May was the only month when both costs came close, and even then, verification remained higher. The real spike happened in December: $250k spent on ZKP verification vs just $137k on blobs.
And despite Ethereum rolling out blobs to reduce DA costs, verification costs haven’t gone anywhere. If anything, they’ve become the dominant expense. June shows the trend continuing: blob spend down, ZKP still stubborn. This is one of the core problems zkVerify is trying to solve.
Zooming out, the share of gas spent on verifying ZK proofs has remained relatively low. While there was an ATH at around 12% of total blockspace at the beginning of 2024, it quickly retraced. Since then, the gas spent on ZK proof verification has stabilized at a low level. Currently, the share accounts for around 0.5% of the total blockspace.
The decline to a steady 0.5% suggests that while ZK protocols are actively used, they occupy only a small portion of the gas consumption on Ethereum. This implies that ZK proofs are currently not a major driver of network congestion – or that adoption and usage remain constrained by high costs and technical barriers.
A dedicated verification layer makes the economics of ZKRs much more favorable. Let’s take Starknet as an example. They only verify their state on Ethereum 3 times/day using this verifier address on mainnet. Starknet shares a common solidity verifier with other StarkWare ZKRs. By doing this, computational integrity claims are combined in one proof checked by the same verifier.
Why? Because gas costs of the verification process are too high. If a new system like Starknet had its own verifier, it would have to bear all verification gas costs alone. This would result in unfeasibly high costs per transaction. Instead, Starknet and StarkWare ZKRs rely on the shared contract’s verifier to amortize the cost.
Since costs are so high, amortization is a key theme. The more transactions a ZKR includes in a single proof, the smaller the cost per transaction becomes. As a result, ZKRs are incentivized to process as many transactions in a batch as possible to drive down verification costs per transaction.
Amortizing costs that way sounds great in theory, and works in practice, but comes with a tradeoff. The frequency of proof submissions increases to batch more transactions. To the detriment of users.
The frequency of proof submissions directly impacts withdrawal time for end users since no assets can be withdrawn until the new state is verified and committed to the L1. With an 8 hour gap between each proof verification, users’ funds remain locked until verification is finalized.
How zkVerify Benefits ZK Protocols
zkVerify directly tackles the most painful bottlenecks for ZK-based systems: cost, latency, integration, and scalability. For rollups and zkApps burning millions on L1 gas to prove correctness, zkVerify offers an immediate performance upgrade.
As we see it, zkVerify could benefit ZK protocols (Apps/Infra) in two practical ways:
- Submitting proofs on Ethereum would be much cheaper and faster, allowing more frequent submissions. This means withdrawals can also be processed much faster, allowing for fast finality. Users wouldn’t have to wait several hours for proofs to be submitted to advance the state.
- The reduced verification costs for L2 on L1 result in lower transaction fees for L2 users. Similarly, the decreased verification costs for ZK Apps lead to lower fees for users of the underlying applications.
Currently, Starknet pays $154 (4 Gwei / $2.6k ETH price) in fees to submit and verify a single proof on the Ethereum mainnet. A single proof submission consumes 12M gas in one block. Starknet submits 3 STARK proofs per day, consuming 36M in total. Annually, this suggests they spend about ~$168k in fees verifying proofs. Keep in mind, this is the best-case scenario assuming Ethereum maintains 4 Gwei all year, which isn’t very realistic.
STARK proof verification tx on Ethereum
If Starknet were to use zkVerify to submit proofs instead, they would be spending ~$20k per year. A reduction of ~88% that could flow back to their users by reducing L2 fees. But the real savings go deeper than just dollars, as the hidden cost for devs is always time.
For zkApp developers, writing and maintaining verifier contracts is an ongoing nightmare, especially when juggling multiple proving systems or migrating across base layers. zkVerify eliminates that complexity as devs simply need to send their proofs (and keys) via API, and zkVerify handles the rest: attestation, Merkle inclusion, and relay to a settlement contract. This means no more rewriting, redeploying, or debugging verifiers for every circuit, chain, or upgrade.
Since no SNARK conversion is needed, devs can also natively verify STARK proofs. Today, many STARK-based protocols resort to STARK-to-SNARK conversion just to get proofs accepted on Ethereum, adding latency and overhead. zkVerify accepts STARK proofs as-is.
Verification logic evolves, proving systems upgrade, curves change, and recursion becomes standard. Instead of forcing every protocol to adapt in isolation, zkVerify modularizes the problem. Its forkless architecture means new pallets and proving formats can be added without breaking apps. Devs plug into zkVerify once and gain future-proof access to the full ZK stack.
zkVerify unlocks better UX, faster finality, and simpler dev workflows. For zkApps and rollups looking to scale without bleeding out on verification costs or fighting infra complexity, integrating zkVerify should be a no-brainer.
There’s also a case to be made that zkVerify is the perfect fit for Ethereum’s endgame. As we quoted in the intro, Ethereum’s recent post laid out a new roadmap. It puts ZK at the core of Ethereum’s long-term future, at all levels of the stack. From L1 zkEVMs and real-time proving to signature aggregation, client-side privacy, and home staking with zkVMs, the direction is clear.
However, verifying those proofs still doesn’t scale on Ethereum. The EF acknowledges that while proof generation is improving fast, verification (especially zkVMs) remains unoptimized. To unlock this client diversity, Ethereum needs a flexible verification layer.
zkVerify is the obvious counterpart to this vision, as it provides the modular, system-agnostic verification layer Ethereum needs to realize its ZK-native future. It lets validators, rollups, and apps verify any proof system without waiting on precompiles, hard forks, or custom verifiers. It complements the EF’s roadmap in two key ways:
- Modularity. By offloading proof verification to a purpose-built layer, zkVerify allows Ethereum to scale ZK throughput without inflating L1 gas costs or locking into a single proof system. Different zkVMs can plug into zkVerify without waiting on protocol upgrades.
- Abstraction. zkVerify abstracts away verifier deployment entirely, as there is no need to write Solidity verifier contracts or audits for each new circuit. Devs can iterate faster, integrate quicker, and avoid overhead. Cost savings are a huge downstream benefit of better design choices.
EF is betting big on zkVMs and client diversity. zkVerify is the layer that makes that bet scalable.
Looking Ahead
It’s clear that proof verification on Ethereum cannot scale alone. Every new proving system forces developers to reinvent the wheel. Rollups are rationing proof submissions and zkApps are bogged down by circuit-specific integration debt.
zkVerify breaks this loop.
It cuts cost, lowers latency, and kills system complexity – without locking protocols into one proving system or base layer. zkVerify fills a crucial design gap in the modular stack: a shared verification layer that works regardless of ZK primitive or underlying chain.
By abstracting verification from monolithic chains and rollup-specific tooling, zkVerify enables faster withdrawals, lower L2 fees, and dev workflows that don’t collapse every time a circuit changes.
As more protocols turn to recursive proofs and adopt multi-proof systems, ZkVerify presents a scalable path forward. ZK is going modular, and zkVerify is well-positioned to capture a moat by becoming the connective tissue that enables scalable, efficient verification for a plethora of use cases.
0 Comments