Abstract
Smart contracts are computationally constrained by design: the EVM’s per-block gas limit makes on-chain execution of complex data queries, statistical aggregations, or historical lookups prohibitively expensive. ZK coprocessors address this by moving computation off-chain and returning a zero-knowledge proof that the computation was performed correctly over verified historical blockchain state. A contract can then consume the proof and act on the result without re-executing the computation itself. This model, developed and deployed by projects including Axiom, Brevis, and Risc Zero’s Bonsai network, has matured significantly through 2025 and is being integrated into production DeFi protocols. This post examines the architecture, trust assumptions, and practical constraints of ZK coprocessors as they stand in early 2026.
Architecture - Proof Over Committed State
The core idea is that Ethereum’s block hashes form a chain of commitments to historical state. EIP-4788 made the beacon chain block root accessible from the EVM, extending this commitment to consensus-layer data. A ZK coprocessor proves a computation over a slice of historical data by first proving, within the ZK circuit, that the data is consistent with a block hash or block root that the on-chain contract can verify independently. Axiom’s system, for example, uses a chain of KZG-based storage proofs that authenticate account and storage data at historical blocks, then runs arbitrary user-defined query logic on that authenticated data inside a PLONK circuit. The contract receives the proof and the query output; if the proof verifies, the output is trusted as correct over real historical state.
What Can and Cannot Be Proven Efficiently
ZK coprocessors are well-suited to computations that are naturally expressible as arithmetic circuits: aggregations like sums and weighted averages over historical token balances, Merkle path verifications for historical ownership proofs, and range checks over time-series data. They struggle with computations that are control-flow-heavy or that require access to a large and unpredictable set of storage slots, because each storage access inside the circuit requires a merkle or verkle path proof, and the circuit size grows with the number of accesses. Brevis and Lagrange both target specific DeFi use cases where the query shape is constrained: volume-weighted average prices, loyalty score accumulations over swap histories, and governance power calculations over historical snapshots. General-purpose computation over arbitrary historical state is possible with RISC-V based zkVMs like SP1 or Risc Zero, but prover time and cost at that generality are still barriers for latency-sensitive applications.
Trust Model and On-Chain Verification Cost
ZK coprocessors shift trust from on-chain recomputation to the correctness of the prover circuit and the soundness of the proof system. A bug in the circuit that allows the prover to generate a valid proof for a false computation result is silent: the contract verifies the proof successfully and acts on wrong data. This makes circuit auditing critical. On-chain verification cost varies by proof system. A Groth16 verification runs around 200,000 gas; PLONK-based verification is higher, typically 300,000-500,000 gas. For coprocessors that aggregate many queries into a single proof (Axiom’s query API batches multiple requests into one proof), the per-query on-chain cost becomes acceptable even at current gas prices.
Integration Patterns in DeFi
The most active integration pattern as of early 2026 is using ZK coprocessors for capital-efficient lending. Protocols that want to offer undercollateralized credit based on a borrower’s historical on-chain activity (average balance, trading volume, repayment history) cannot do this computation on-chain affordably. A coprocessor proves the historical score off-chain; the lending contract verifies the proof and adjusts collateral requirements accordingly. Morpho, Aave, and several newer lending protocols have explored or begun integrating coprocessor-based credit scoring. The key integration question is latency: generating a proof for a complex historical query can take minutes on current prover hardware, which does not fit synchronous transaction flows. Asynchronous credit score updates, where the proof is submitted in a prior transaction and cached in contract state, are the practical pattern for interactive lending.