The ZK Data Coprocessor is the core component within Brevis that enables smart contracts to securely and reliably access historical and cross-chain data. It retrieves authentic on-chain data and performs computations off-chain, then returns the results along with a zero-knowledge proof (ZK) for on-chain validation. As the most application-oriented layer of Brevis (BREV), it transforms the issue of “contracts being unable to compute or read historical data” into “compute off-chain, verify on-chain.”
Blockchain consensus mechanisms require every validator to repeat identical computations, making direct on-chain access to large volumes of historical transactions extremely costly. As a result, smart contracts are nearly blind to historical data.
Building on Brevis’s philosophy of “proving work instead of repeating it,” the ZK Data Coprocessor moves intensive data reading and computation off-chain, while on-chain validation is reduced to a millisecond-level process. This enables contracts to make decisions based on long-term on-chain behavior without relying on centralized intermediaries.
What Is the ZK Data Coprocessor?
The ZK Data Coprocessor is a specialized off-chain computation engine designed to access blockchain historical states and cross-chain data, execute computations that contracts cannot efficiently perform on-chain, and attach a cryptographic proof to each computation. It produces verifiable credentials—“result + proof that the result is derived from authentic data and is computed correctly.”
Within the Brevis technology stack, the ZK Data Coprocessor serves as a primary example of the Pico zkVM “application-level coprocessor.” Pico zkVM acts as a “glue” layer routing data between the general core and specialized modules, while the Data Coprocessor focuses on “reading history, performing analytics, and attaching proofs,” allowing contracts to trust mathematics rather than centralized operators.
Why Can’t Smart Contracts “Read” Historical Data?
By design, smart contracts can efficiently access only the current block state and are nearly blind to earlier block data. While networks such as Ethereum retain the full history, contracts accessing past block storage or transactions on-chain require expensive additional proofs and often lack native interfaces.
The fundamental reason is cost and consensus: replaying, for example, an address’s transaction volume over the past six months on-chain would require every validator to process massive state data, rapidly exceeding per-transaction gas limits. As a result, historical data “exists” but is “unavailable.” Features like tiered trading fees or loyalty rewards based on historical behavior have traditionally relied on off-chain computation and reintegration, reintroducing trust in centralized intermediaries.
How Does the ZK Data Coprocessor Access On-Chain Data Off-Chain?
The ZK Data Coprocessor accesses complete historical states through blockchain archive nodes. Archive nodes store snapshots of every historical block, enabling the coprocessor to read balances, storage slots, and transaction records at any point in time—covering both single-chain and multi-chain states—without requiring contracts to replay data on-chain.
After retrieving raw data, the coprocessor executes user-defined computation logic off-chain, such as aggregation, filtering, weighting, or conditional evaluation. Unlike standard off-chain computation, every data point accessed is included in the subsequent proof, ensuring both “data existence” and “computation correctness.”
From Request to Verification: How Does the Complete Data Flow Work?
The ZK Data Coprocessor’s data flow consists of four steps that form a closed loop from application request to on-chain smart contract adoption. In the pure-ZK workflow, proof generation at each step relies on the general zkVM execution layer. The following table breaks down each step:
| Step |
Stage |
What Happens |
Output |
| ① |
Application Request |
The dApp defines computation logic and data scope, then submits the request |
Computation Task |
| ② |
Off-Chain Data Access and Computation |
The coprocessor reads authentic data via archive nodes and performs the computation |
Raw Result |
| ③ |
ZK Proof Generation |
Generates a ZK proof that the computation was correctly executed on real data |
Result + Proof |
| ④ |
On-Chain Verification |
The smart contract verifies the proof in milliseconds and accepts the result |
Trusted Conclusion |
These four steps create an “off-chain compute, on-chain verify” pipeline: heavy data reading and computation are handled off-chain, while on-chain only verifies a succinct proof at minimal cost, with no need to move raw data on-chain.
Figure 1. ZK Data Coprocessor four-step data flow: application request → off-chain data access (archive node) → computation → ZK proof generation (data exists and computation is correct) → on-chain verifier → result returned.
Why Are the Generated Proofs Trustworthy?
The trustworthiness of the ZK Data Coprocessor’s proofs lies in their threefold guarantee: the result itself, the authenticity of the data, and the correctness of the computation. Any tampering at any layer will cause on-chain verification to fail.
Zero-knowledge proofs decouple verification cost from computational scale: regardless of how many historical blocks are processed off-chain, on-chain verification only requires checking a fixed-size succinct proof, typically within milliseconds. The table below details the three types of facts secured by the proof.
| Guarantee Type |
Fact Secured by Proof |
Prevents Cheating |
| Result |
The returned value is the true output of the computation |
Tampering with the final result |
| Data Existence |
Inputs are sourced from the target chain’s authentic historical state |
Forging or replacing input data |
| Computation Correctness |
Computation strictly follows the declared logic |
Skipping steps, simplifying, or altering logic |
This structure explains why contracts can “not trust, only verify”: the result, input, and process are all included in the proof, preventing the coprocessor from tampering at any stage. This trust-minimized property fundamentally distinguishes it from solutions that rely on trusted parties to reintegrate data.
Figure 2. ZK Data Coprocessor proof structure: a single proof simultaneously secures result, data existence, and computation correctness, verified by an on-chain smart contract in milliseconds.
What Scenarios Are Suitable for the ZK Data Coprocessor?
The ZK Data Coprocessor is ideal for any on-chain scenario requiring “trustworthy results based on historical or cross-chain data.” Use cases that previously depended on off-chain computation and reintegration can now leverage verifiable computation. The table below highlights several common scenarios:
| Scenario |
Required Capability |
Description |
| Data-Driven Incentives |
Aggregation of historical trading volume/behavior |
Rewards issued based on real activity; results are tamper-proof |
| Loyalty and Tiering |
Position duration/historical snapshots |
Tiered benefits based on holding or trading records |
| On-Chain Risk Control |
Address historical profiling |
Assess risk based on historical behavior before executing contract logic |
| Cross-Chain State Reading |
Multi-chain archive data |
Adopt historical state from another chain |
The common thread in these scenarios is that decisions are based on “past events,” and this data cannot be efficiently replayed on-chain. Unlike oracles that simply import off-chain data, the difference between Brevis and oracles is that the coprocessor not only provides data but also delivers “computation based on the data and its correctness proof,” shifting trust from the data source to mathematical verification.
What Are the Advantages and Limitations of Using the ZK Data Coprocessor?
The ZK Data Coprocessor’s core strengths are trust minimization and scalability. Off-chain execution removes computational constraints imposed by block gas limits, and zero-knowledge proofs allow results to be verified without reliance on third parties. This enables contracts to make secure decisions based on long-term on-chain activity.
The primary limitations stem from ZK computation itself: generating zero-knowledge proofs requires specialized hardware and hashrate, and proofs for complex logic incur higher overhead and latency than native execution, making it less suitable for ultra-low-latency scenarios. The reliability of results also depends on data source integrity—missing or incorrect archive node data directly impacts input authenticity.
Therefore, the ZK Data Coprocessor is most suitable for scenarios where “result correctness is more important than immediacy,” making large-scale historical computations reliable and usable, though not without cost. For use cases more sensitive to latency and proof costs, the BREV token and coChain optimistic model provides an alternative. All the above are objective, mechanism-level constraints and do not constitute investment advice.
Summary
As the application-facing layer of Brevis, the ZK Data Coprocessor addresses the challenges of smart contracts’ limited access to historical data and the high cost of on-chain replay. It accesses authentic historical and cross-chain data via archive nodes off-chain, performs computations, and returns a zero-knowledge proof—“result + data existence and computation correctness”—for millisecond-level contract verification. The four-step process—request, off-chain computation, proof generation, and on-chain verification—moves trust from centralized intermediaries to cryptography, enabling trusted data-driven incentives, loyalty programs, risk controls, and cross-chain state reading.
FAQ
What Is the ZK Data Coprocessor?
As an off-chain computation engine, the ZK Data Coprocessor accesses blockchain historical and cross-chain data, executes computations that contracts cannot perform on-chain, and attaches a zero-knowledge proof to the result. Contracts only need to verify a succinct proof on-chain to accept the result, eliminating the need to replay raw data.
Where Does the ZK Data Coprocessor’s Data Come From?
Data is sourced from blockchain archive nodes, which store complete state snapshots of every historical block. The coprocessor uses these snapshots to read balances, storage, and transaction records at any point, covering historical states across multiple chains. Every data point is included in the subsequent proof.
Why Are the ZK Data Coprocessor’s Results Trustworthy?
The returned zero-knowledge proof simultaneously secures three facts: the result itself, that the input data genuinely exists on the target chain, and that the computation strictly follows the declared logic. Any tampering will cause the proof to fail on-chain verification, enabling contracts to “not trust, only verify.”
How Is the ZK Data Coprocessor Different from Oracles?
Oracles primarily import off-chain data onto the blockchain and still require trust in the data source. By contrast, the ZK Data Coprocessor performs computations off-chain based on authentic on-chain or historical data and attaches a zero-knowledge proof of correctness, shifting trust from the data source to mathematical verification.
