The price of not trusting: a working cost model for ZK light clients

Whether a ZK light client pays for itself is arithmetic, not ideology. The model fits in one line, the inputs are public, and the answer is lopsided: on Ethereum L1, on-chain verification — not proving — is where the money goes. Here is the working cost model, with our own published numbers as inputs.

The model

Everything a light client costs per verified header:

Cost/header = P·C_m  +  G·g·p_ETH  +  O/N

P    = prover wall-clock per proof (hours)
C_m  = machine cost per hour (owned: amortized; cloud: listed)
G    = on-chain verification gas per proof
g    = gas price (ETH per gas)
p_ETH= ETH price in your unit of account
O/N  = fixed ops (relayer, monitoring) amortized over N proofs

No term is exotic. What matters is which term dominates — and that is an empirical question the vendor marketing around “fast provers” consistently answers about the wrong term.

Our inputs

From the NEAR→Ethereum build (full account): a five-block finality window proves in ≈8 minutes on a 32-core machine, and the wrapped proof verifies on Ethereum for ≈310k gas. Price the machine at a round $1.60/hour — cloud list price for that class; owned hardware amortizes lower — and proving costs ≈$0.21 per finality proof. Those two numbers, prover-side, are the whole supply story.

Where the money actually goes

Gas price	Verify cost/proof (310k gas, ETH $3,500)	vs prover ($0.21)
1 gwei	≈$1.09	5×
5 gwei	≈$5.43	26×
20 gwei	≈$21.70	103×

Run hourly finality updates for a day at 5 gwei and the ledger reads: proving ≈$5, verification ≈$130. Every optimization dollar belongs on the right-hand column: batch multiple headers per proof, verify on an L2 and settle up, or prove on demand instead of on schedule. Recursion makes header batching nearly free on the prover side — which is precisely why proof aggregation research (including ours) is economics, not aesthetics. The published comparators sit in the same band: zkBridge reports batched Groth16 verification under 230k gas (arXiv:2210.00264), so nobody's wrapping stack escapes the verification-dominant regime on L1.

Against the optimistic baseline

The optimistic design pays almost nothing per header — post now, verify never, challenge if wrong. Its costs hide elsewhere: two or more independent watchdog operators as standing opex (infrastructure plus the organizational overhead of keeping them genuinely independent), challenge-window latency measured in hours, and the assumption that at least one honest watcher is awake for every window forever. Write it in the same form: fixed watchdog opex divided by transfer count, plus a latency cost users pay in time, plus a trust term no invoice captures. High frequency amortizes the watchdogs beautifully — which is why optimistic designs won the cheap-and-frequent regime — and does nothing about latency or the liveness assumption.

The decision rule

Buy proofs when value-at-risk × trust premium > per-proof cost at your frequency. Three regimes fall out. Institutional-size transfers on low-frequency corridors: $5–$22 per verified finality window is noise against the value moved — ZK, without discussion. High-frequency low-value flows between parties who already trust an operator set: the optimistic or committee design keeps winning on cost, and the honest conversation is about latency and censorship, not gas. And L2-verified light clients — verification gas at rollup prices turns the dominant term into cents, which moves the crossover point further toward ZK every year the rollup fee market matures.

Limits

The model's constants are volatile: prover markets reprice as zkVM tooling commoditizes, gas regimes shift with blob adoption, and the 310k-gas verify assumes today's wrapping stack rather than a future precompile. The structure of the answer is what holds — verification-side costs dominate on L1, and the engineering that matters is the engineering that amortizes them. Rerun the arithmetic with your corridor's numbers before believing anyone's conclusion, including this one.