What Is a ZK Coprocessor? How Off-Chain Compute Is Proven

A ZK coprocessor runs computation that a smart contract cannot afford to run itself. It does the work off-chain, then returns the result together with a Zero-Knowledge Proof (a short cryptographic proof that a statement is true, which reveals nothing beyond that) that the contract checks on-chain. The contract gets the answer without redoing the work and without trusting whoever did it. The name comes from hardware, where a coprocessor is a separate chip that takes specialized work off the main CPU.

The idea exists because smart contracts are expensive to run and can see very little of their own chain. A ZK coprocessor lifts both limits for one kind of job: heavy computation over data that is already on a blockchain.

Every operation a contract performs is metered in gas, so complex logic gets expensive fast. Lagrange, which builds a ZK coprocessor, works through one example in its September 2024 post "Cracking ZK Coprocessors": computing the average ETH price on Uniswap V3 over the last 10,000 blocks directly on-chain would cost roughly $500 to $2,000 in gas, assuming gas at about 20 gwei and 20,000 gas per block.

The second limit is memory. A contract can read the current state of its own chain, and even that costs gas. Past balances, old transaction receipts and earlier storage values are not available to it natively, as Axiom's explainer "What Is a ZK Coprocessor?" points out. A rule like "reward wallets that held this token for the last six months" needs data the contract cannot see.

Axiom describes the outcome as proving off-chain computation "over existing on-chain data" without asking users to trust anyone new. The application also keeps its data and balances where they are: the coprocessor works next to contracts on the base chain (L1) or scaling network (L2) where they already live.

A ZK coprocessor proves that a computation over blockchain data was done correctly. It does not make the underlying data true in any real-world sense: if a price on-chain was wrong, a correct average of that price is still built on it. It also cannot reach data that never touched a chain.

Proofs take time to generate. In the same 2024 post, Lagrange estimates that a query over the 8,888 NFTs of the Pudgy Penguins collection across the last 100 blocks would take about two minutes to query, prove and submit on-chain. That suits jobs where a short delay is fine, such as rewards, eligibility checks and analytics over long windows, rather than logic that must react within the same block.

An oracle network brings outside data onto a chain, a ZK coprocessor computes over data already on a chain, a ZK rollup moves a whole application's execution off-chain, and a zkVM is the proving engine underneath.

These pieces work together. A protocol can take a price from one of the types of blockchain oracles and use a coprocessor to compute a long-window average of that price. The proving engine under both is often a zkVM, which our post on zkVM scaling with zkMemory explains, and how a zero-knowledge proof works covers the basics. Bridges between chains use the same pattern: the Polkadot wiki page on Hyperbridge describes running heavy verification off-chain and checking the results with proofs on-chain.

A ZK coprocessor starts from the chain's history. Much of the data institutions care about is kept off-chain on purpose: reserve balances, fund net asset value (NAV) inputs, collateral positions, identity checks. Publishing it would expose clients and trading positions, so it never becomes chain history for a coprocessor to read.

zkDatabase, built by Orochi Network, applies the same proof pattern to that off-chain data. It keeps the data in an off-chain database, generates a Zero-Knowledge Proof for every update, and proves that a query result matches a Merkle root (a single hash that commits to the whole dataset) published on-chain. The proofs use Groth16, a proof system with small proofs that are cheap to check, so a counterparty, an auditor or a smart contract on an EVM-compatible chain can verify the answer without seeing the data behind it. A stablecoin issuer, for example, can let holders check that its published reserve total was computed from the reserve data it committed, without showing individual account balances. As with a coprocessor, the proof shows the data was stored and processed as claimed. It does not show that a reserve balance or a price is correct in the real world. A coprocessor proves work over what the chain already knows; a verifiable database proves work over what the chain is not allowed to see. Our guide to verifiable database solutions compares the approaches, and verifiable data explains how proofs follow data through a pipeline.

See how proofs work on off-chain data. The zkDatabase site walks through the use cases and how verification fits into an existing stack.