Today we’re releasing the Brevis ProverNet whitepaper, detailing our vision for a decentralized marketplace where any application can access zero-knowledge proving capacity and any prover can compete to serve it.
The whitepaper is technical (formal auction mechanisms, mathematical proofs, implementation architecture) so we’ve written this post to highlight what matters most: why we’re building this, how it works, and what it means for the ZK ecosystem.
Where We Are Today
Brevis has become known for something pretty unique in the ZK space: we’re live in production across a genuinely diverse range of applications. Through our Pico zkVM (+ Pico Prism for Ethereum real-time proving) and ZK Data Coprocessor, we’ve powered everything from instant DEX personalization to massive-scale reward distributions.
The scope is genuinely vast when you take a close look at it:
Linea runs ecosystem-wide growth campaigns using our coprocessor.
PancakeSwap uses our hooks to offer VIP trading discounts based on token holdings and trading volume.
Euler distributed $100K in rewards every four hours using trustless computation without backend servers or trust assumptions, just cryptographic proofs verifying who earned what.
Uniswap v4 is about to implement gas rebates for routers integrating v4 pools, fully trustless, with Brevis proving which transactions qualify for rebates.
MetaMask offers 2.4% APR on Linea through Aave integration.
These are just a few examples of what developers built with Brevis, and each is entirely different. Ethereum real-time proving requires proving 99% blocks executions under a strict 10-second latency. A protocol distributing rewards to 100,000 addresses prioritizes throughput over latency and runs on multi-hour epochs. Off-chain privacy-preserving attestations require different cryptographic operations due to no need for on-chain verification. We’ve built infrastructure that handles this diversity, and it works. 130 million proofs for 110,000 users across radically different use cases proves that.
Why We’re Building a Brevis ProverNet
The diversity you see in our deployments isn’t accidental, it’s the direct result of Brevis’s “glue-and-coprocessor” architecture.
Pico acts as the glue layer, a minimal, high performance core that connects specialized coprocessors for different computational needs. We have the ZK Data Coprocessor for historical blockchain queries, the ZKML Coprocessor for machine learning inference, and various cryptographic accelerators optimized for specific operations. This modular design is what allowed us to handle everything from sub-second DEX matching engine proofs to multi-hour reward distributions.
However, this diversity also poses a unique challenge: these workloads cannot be handled by a single type of prover. Some applications require extremely high-performance GPUs with latency sensitive requirements and flexible cost constraints, while other workloads prioritize low-cost proving with more relaxed latency tolerance. Some need on-chain verification with compact proofs, while others only target in-browser verification with flexible proof sizes.
Even within the same application, we often need diverse prover types. For example, in an Ethereum block execution pipeline, we need extremely high-performance CPUs for emulation and high-performance GPUs for sub-block proving. The proving requirements change at each stage of the pipeline.
These diverse computational needs require a new kind of system, one that can match a wide range of prover resources to the highly heterogeneous demands from different applications.
Our glue-and-coprocessor architecture already demonstrated that this heterogeneity is the reality of production ZK workloads, not an edge case. Rather than building and scaling all this specialized capacity in-house, we see a superior path: the ZK ecosystem is filled with distinct projects with specialized optimizations that could serve specific workloads. Our solution is to bring them together under one framework.
ProverNet creates a marketplace where those specialized provers can contribute capacity for what they do best. Applications specify their exact requirements like latency targets, cost constraints, verification environments, proof size limits. Provers with the right setup compete for those jobs. Price discovery happens through open auctions, and service quality gets enforced through economic incentives rather than trust. The architecture we built to handle heterogeneous workloads becomes the framework for an open marketplace where specialized proving capacity can plug in wherever it’s needed most.
How Do You Make a Marketplace Actually Work?
This is where TODA (Truthful Online Double Auction) comes in.
Most people are familiar with one-sided auctions (you bid for something on eBay). A double auction is different: both buyers and sellers submit bids, and the mechanism matches them efficiently. “Online” just means jobs and capacity arrive continuously rather than all at once. “Truthful” means the optimal strategy for both sides is honest bidding rather than games where you’re trying to outsmart the mechanism.
Here’s why standard auction designs don’t work for proof generation:
Heterogeneous goods: Proving jobs aren’t identical. A zkVM execution trace isn’t the same as a ZKTLS attestation or an on-chain historical data proof for user profiling. They require different hardware setup, and different optimization approaches. Most auction theory assumes you’re selling identical items (like bushels of wheat or shares of stock). That doesn’t apply here.
Decomposable tasks: Complex proving jobs often break into sub-tasks that different provers can handle collaboratively. Generating an EVM-verifiable proof for a large zkVM program might involve chunk proofs on one prover, compression on another, aggregation on a third, and final wrapping on a fourth. The mechanism needs to be able to coordinate this without central planning.
Service level requirements: Applications have deadlines and quality thresholds (proof size limits, security parameters, coverage percentages). The mechanism must match jobs to provers who can actually meet those requirements, not just the cheapest bid.
Real-time clearing: Proofs often need to be generated quickly. The auction can’t take hours to compute allocations; it needs to clear efficiently enough to honor latency targets.
Our TODA mechanism solves these problems by treating different proof types as first-class citizens in the auction, using a mathematical framework that guarantees several key properties:
Truthfulness: Best strategy is honest bidding. Requesters report their true maximum willingness to pay; provers report their actual costs and capabilities. No strategic gaming.
Budget balance: The mechanism doesn’t require subsidies. Fees collected from requesters cover payments to provers plus operational costs.
Individual rationality: No participant is forced into a loss. Winning requesters pay at most their bid; winning provers receive at least their cost.
Computational efficiency: The auction computes allocations quickly enough to meet real-time proving deadlines, even with many participants.
Asymptotic optimality: As more provers join with diverse capabilities, the marketplace gets better at matching the right prover to the right job. With abundant supply, allocations approach the theoretical best outcome where jobs go to whoever can complete them most efficiently. Early inefficiencies (such as the perfect prover being available yet) disappear as the network grows.
The mechanism works through continuous auction rounds. Requesters submit jobs with maximum fees and requirements. Provers submit capacity offers with costs. The TODA solver computes the optimal allocation. It decides which jobs get assigned to which provers at what prices, considering all the different proof types simultaneously. Winners get matched, losers get refunded, and the next round begins.
The Role of BREV Token
With the marketplace mechanism designed and the coordination layer built, one critical piece remains: what keeps this whole system moving?
To power the entire ZK Proof economy, we introduce the BREV token with three essential functions in Brevis ProverNet.
Payment Medium for Verifiable Compute
All proving, settlement, and verification fees in Brevis ProverNet are paid in BREV. This includes proof generation for zkVM execution, ZK Data Coprocessor queries, ZKTLS proofs, and recursive aggregation. It also covers verification, settlement, and auxiliary services like result availability. When Brevis ProverNet deploys as a specialized rollup, BREV will also function as the gas token for all network transactions, creating additional utility directly tied to network usage.
Staking for Provers and Delegators
Provers stake BREV, or receive delegated stake from token holders, to participate in the network and earn proving jobs. Staking serves three key roles:
- Sybil resistance and access control
- Economic alignment through stake at risk for SLA violations
- Capacity signaling, where greater effective stake unlocks larger and more urgent workloads
Applications can set required stake levels for their proof jobs, reflecting the opportunity cost if deadlines or verification parameters are not met. Stake unlocks only after successful proof delivery. Token holders can delegate BREV to professional provers, enabling those provers to accept more workload while sharing a portion proving revenue with delegators. Delegated stake is also subject to slashing, so delegators must evaluate providers carefully.
Governance for Protocol Parameters
BREV serves as the governance token for managing key system parameters that shape network reliability and economic incentives. Initial parameters governed by BREV holders include:
- Maximum acceptable proof size
- Minimum cryptographic security level
- Slashing percentage for SLA violations
- Auction market fee charged by ProverNet
What This Means for the Ecosystem
Brevis ProverNet opens proving capacity as infrastructure and a public good that any application can access and any prover can contribute to.
For developers: You no longer choose between building custom proving infrastructure (expensive, time-consuming) or depending on centralized services (trust assumptions, vendor lock-in). You access a competitive marketplace of specialized provers and integrate cryptographic guarantees in weeks instead of quarters.
For ZK proving teams: You don’t need to serve every use case. Focus on what you do best, whether that’s low-latency GPU proving for real-time Ethereum block execution or specialized coprocessors for perpetual swap matching engines. The marketplace allocates jobs to whoever can serve them most efficiently.
For the broader ecosystem: Verifiable computing becomes decentralized and highly available rather than a scarce resource controlled by centralized operators. Applications can cryptographically guarantee computation correctness without sacrificing decentralization.
The Road to Mainnet
We will be launching the Brevis ProverNet beta mainnet very soon. Initially it will be running on a simplified version of the TODA auction with no staking, allowing us to onboard a strong set of provers and expand to full staking functionalities at mainnet launch.
Brevis Network© 2023 