Off-Chain Computing Revolution: A Deep Dive into ZK Coprocessors and Their Application Prospects in DeFi and DAO
TechFlow Selected TechFlow Selected
Off-Chain Computing Revolution: A Deep Dive into ZK Coprocessors and Their Application Prospects in DeFi and DAO
This article mainly discusses the implementation methods of coprocessors, various applications, and future development directions.
Navigating Web3 tides with focused insightsAuthor: Kernel Ventures Turbo Guo
Review: Kernel Ventures Mandy, Kernel Ventures Joshua
TL;DR
ZK coprocessors are a solution enabling dApps to leverage off-chain computing resources. This article discusses implementation methods, various applications, and future directions of coprocessors, including:
-
RISC Zero's zkVM is a ZK coprocessor solution that allows on-chain contracts to invoke specific Rust code execution in an off-chain zkVM and return results to the chain, while providing zero-knowledge proofs (zkp) for the contract to verify the correctness of computation.
-
There are different implementations of ZK coprocessors. Besides zkVMs, users can write custom ZK circuits for their programs or use pre-built frameworks to design circuits, allowing contracts to utilize off-chain computational resources.
-
ZK coprocessors can play a role in DeFi—for example, moving AMM computations off-chain to enable protocols to capture MEV-like value, or allowing AMMs to implement complex and computationally intensive logic. Coprocessors also allow lending protocols to calculate interest rates in real time and make margin calculations transparent. There are two approaches to implementing zkAMM: one using zkVM and another using zkOracle.
-
Other potential uses include wallets performing identity verification off-chain via ZK coprocessors, enabling more complex computations in on-chain games, and reducing gas costs for DAO governance.
-
The landscape of ZK coprocessors remains unsettled. While it is more developer-friendly to use a project as an interface to access off-chain resources rather than writing circuits manually, the question of which computing service provider (traditional cloud providers, decentralized resource sharing) lies behind such "interface" projects is another important topic for discussion.
1. Meaning and Applications of ZK Coprocessors
The core idea of a ZK coprocessor is to move on-chain computation off-chain, using zero-knowledge proofs to ensure the reliability of off-chain computation, enabling smart contracts to easily handle large-scale computations while verifying their correctness. This resembles the concept of zkRollups, but whereas rollups involve protocol-layer utilization of off-chain resources, ZK coprocessors enable dApps to do so.
RISC Zero is used here to explain one implementation method of ZK coprocessors, though multiple approaches exist, which will be discussed later. RISC Zero developed the Bonsai ZK coprocessor architecture, centered around its zkVM, allowing developers to generate zero-knowledge proofs (zkp) attesting to the correct execution of specific Rust code within the zkVM. With zkVM in place, the concrete workflow for implementing a ZK coprocessor is as follows:
-
Developers send a request to Bonsai’s relay contract to execute a specified program within the zkVM
-
The relay contract forwards the request to an off-chain request pool
-
Bonsai executes the requested program off-chain within the zkVM, performs large-scale computation, and generates a receipt (proof)
-
These proofs, called receipts, are published back on-chain by Bonsai through the relay contract
In Bonsai, the program being proven is referred to as a Guest Program. The receipt proves that the guest program was executed correctly. A receipt consists of a journal and a seal. Specifically, the journal carries public outputs from the zkVM application, while the seal verifies the validity of the receipt—i.e., that the guest program was correctly executed—with the seal itself being a zkSTARK generated by the prover. Verifying the receipt ensures that the journal was constructed using the correct circuitry.
Bonsai simplifies the entire process—from compiling Rust code into zkVM bytecode, uploading programs, executing them in the VM, to returning proof feedback—allowing developers to focus more on program logic design. Not only parts of contract logic, but even entire contract logic can be moved off-chain. RISC Zero also employs continuations, breaking down a large proof generation task into smaller chunks, each proven separately. This enables proving large programs without consuming excessive memory. Besides RISC Zero, other projects like IronMill, =nil; Foundation, and Marlin offer similar general-purpose solutions.
2. Applications of ZK Coprocessors in DeFi
2.1 AMM – Using Bonsai as Coprocessor
zkUniswap is an AMM that leverages off-chain computing resources, with its core mechanism involving moving part of swap computation off-chain, using Bonsai. Users initiate a swap request on-chain. Bonsai’s relay contract receives the request and triggers off-chain computation. After completing the computation, Bonsai returns the result and proof to a callback function in the EVM. If the proof is successfully verified, the swap is executed.
However, swaps are not completed in one transaction—the request and execution occur in separate transactions, introducing some risk: the pool state may change between submitting the request and completing the swap. Verification is based on the pool state at the time of request submission. If the pool state changes while a request is pending, verification will fail.
To address this issue, developers implemented a pool lock. When a user submits a request, all operations except finalizing the swap are locked until the on-chain swap is triggered off-chain or the request times out (with a preset timeout duration). Having a time limit ensures that even if the relay or zkp fails, the pool won’t remain locked indefinitely—typically for a few minutes.
zkUniswap has a unique design regarding MEV: the goal is for the protocol to capture MEV value. In theory, zkAMMs still have MEV because whoever submits first gets priority, leading to gas competition, and builders can still reorder transactions. However, zkUniswap captures MEV revenue internally using Variable Rate Gradual Dutch Auctions (VRGDA).
zkUniswap auctions off the lock at a decreasing price. If locks sell quickly, the protocol infers high demand and automatically raises prices; if sales slow down, it lowers prices. This becomes a new revenue stream. Essentially, the protocol introduces a new mechanism to determine transaction order, and the money paid to compete for priority goes directly to the project team—an imaginative approach.
2.2 AMM – Using zkOracle as Coprocessor
Besides zkVMs, some propose using zkOracles to leverage off-chain computing resources, where zkOracle acts as an oracle handling both input and output. Generally, there are two types of oracles: input oracles bring off-chain data (after processing/computation) onto the chain, while output oracles provide processed on-chain data to off-chain systems. An I/O (input-output) oracle (zkOracle) first performs output, then input, enabling on-chain applications to leverage off-chain computation.
zkOracle uses on-chain data as a data source and uses ZK proofs to ensure oracle nodes perform honest computation, thereby fulfilling the role of a coprocessor. Thus, core AMM computations can be placed within zkOracle, enabling traditional AMM functionality while supporting more complex, computation-heavy operations.
2.3 Other Applications: Lending Rate Calculation, Margin Computation, etc.
Setting aside implementation details, many functionalities become feasible with ZK coprocessors. For instance, lending protocols no longer need fixed parameters—they can adjust interest rates dynamically based on real-time borrowing and lending activity. For example, raising rates when borrowing demand is high to attract supply, and lowering them when demand drops. This requires the protocol to access real-time on-chain data and perform extensive computations to derive appropriate parameters—something requiring off-chain computation (unless on-chain costs drop significantly).
Complex calculations such as margin balance, unrealized PnL, and liquidation amounts can also be offloaded to a coprocessor. The advantage is increased transparency and verifiability—margin engines no longer operate as opaque black boxes. Although computation happens off-chain, users can fully trust its correctness. This approach also applies to options pricing.
3. Other Applications of ZK Coprocessors
3.1 Wallets – Using Bonsai as Coprocessor
Bonfire Wallet uses zkVM to move identity verification computation off-chain. The wallet aims to let users create burner wallets using biometric data (e.g., fingerprints) or hardware security keys like YubiKey.
Specifically, Bonfire Wallet leverages WebAuthn, a widely adopted web authentication standard, allowing passwordless login via devices. In Bonfire Wallet, users generate a public key (not blockchain-related, but for WebAuthn) through WebAuthn and use it to create a wallet.
Each Burner Wallet has a corresponding on-chain contract containing the WebAuthn public key. The contract must verify the user’s WebAuthn signature. However, this verification is computationally expensive, so Bonsai is used to move the computation off-chain. A zkVM guest program verifies the signature off-chain and produces a zkp for on-chain verification.
3.2 On-Chain Data Querying – User-Written ZK Circuits
Axiom is an application that does not use zkVM but adopts another coprocessor solution. First, what does Axiom aim to achieve? It seeks to leverage ZK coprocessors to allow contracts to query historical on-chain information. In fact, letting contracts read historical data is difficult—smart contracts typically access only real-time on-chain data, and accessing valuable historical data such as past account balances or transaction records is expensive and impractical.
Axiom nodes access required on-chain data and perform specified computations off-chain, then generate a zero-knowledge proof showing the result was correctly computed from valid on-chain data. This proof is verified on-chain, ensuring the contract can trust the outcome.
To generate zkps for off-chain computations, programs must be compiled into ZK circuits. As mentioned earlier, zkVMs can be used for this purpose. However, Axiom notes that multiple approaches exist, each involving trade-offs between performance, flexibility, and developer experience:
-
Custom Circuits: Developers build bespoke circuits for maximum performance, though development time is longer;
-
eDSL/DSL: Developers still write circuits but use available frameworks to abstract away ZK complexities, balancing performance and developer experience;
-
zkVM: Developers run ZK computations directly in a ready-made virtual machine—very convenient, though Axiom considers this inefficient.
Therefore, Axiom chose the second approach and provides users with optimized ZK modules for custom circuit design.
Projects similar to Axiom include Herodotus, aiming to serve as middleware for cross-chain information transfer. Since data processing occurs off-chain, distributing processed data across chains makes sense. Another project, Space and Time, implements a similar architecture for data indexing.
3.3 Other Applications: On-Chain Gaming, DAO Governance, etc.
Beyond the above, ZK coprocessors can support on-chain gaming and DAO governance. RISC Zero suggests that any computation requiring over 250k gas would be cheaper using a ZK coprocessor, though the exact basis for this claim requires further validation. DAO governance can benefit from ZK coprocessors due to multi-party involvement and interaction across multiple contracts, which are computationally intensive. RISC Zero claims Bonsai can reduce gas fees by 50%.ZKML essentially follows the same philosophy as ZK coprocessors, making Modulus Labs and Giza players in this space—though the concept of ZK coprocessors is broader.
Additionally, there are auxiliary projects in the ZK coprocessor ecosystem, such as ezkl, which provides compilers for building ZK circuits, toolkits for deploying ZK proofs, and tools for moving on-chain computation off-chain.
4. Future Outlook
Coprocessors give on-chain applications access to external computing resources akin to “cloud” computing, offering abundant and relatively inexpensive computation, while reserving on-chain space for essential operations. In practice, zkVMs themselves can run on cloud infrastructure. Fundamentally, a ZK coprocessor is an architectural paradigm—a way to move on-chain computation off-chain—and the source of off-chain computing resources is not restricted.
In essence, off-chain computing resources could come from traditional large vendors, decentralized shared computing networks, or even local user devices. Each direction has distinct characteristics: traditional large vendors offer mature off-chain computing solutions; decentralized computing may offer greater robustness in the future; and local device computation presents exciting possibilities. Currently, many ZK coprocessor projects operate in closed-source service mode because the ecosystem’s supply chain isn’t yet mature enough to modularize services across different projects. Two possible futures exist:
-
Numerous competing projects emerge at every stage of the ZK coprocessor pipeline
-
A single user-friendly service dominates most of the market
From a developer perspective, they might only interact with a single "interface" project when using a ZK coprocessor—similar to how AWS dominates cloud adoption, as developers tend to stick with familiar deployment models. However, the choice of underlying computing service provider (traditional cloud, decentralized sharing) behind such an "interface" project remains an open and critical discussion point for the ecosystem.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
Kernel Ventures
