Glossary

Proof Market

A proof market is a decentralized marketplace where ZK proof generation is outsourced to competing provers who bid on validity proofs.

Key Takeaways

  • A proof market is a decentralized marketplace that matches proof requests from applications (such as ZK rollups) with independent provers who compete on price and latency to generate validity proofs.
  • By outsourcing proof generation to a competitive market, rollups avoid single-prover failure, reduce costs through bidding, and let specialized hardware operators serve multiple clients simultaneously.
  • Proof markets extend the concept of proposer-builder separation to the proving layer: just as block building is separated from block proposing, proof generation is separated from sequencing.

What Is a Proof Market?

A proof market is a protocol or platform that creates a two-sided marketplace for zero-knowledge proof generation. On one side, applications that need proofs (rollup sequencers, bridges, or any protocol requiring verifiable computation) post proof requests. On the other side, independent provers with specialized hardware compete to fulfill those requests at the lowest cost and fastest turnaround.

The core insight is that proof generation is computationally expensive but commoditizable. A rollup running its own dedicated prover bears high fixed costs and a single point of failure. A proof market transforms this into a competitive service: provers invest in optimized hardware and software, amortize costs across many clients, and pass the savings on through competitive bidding.

The concept emerged from the observation that most ZK rollups were outsourcing proof generation to a handful of centralized prover-as-a-service companies. Proof markets formalize this outsourcing into an open, permissionless protocol where any prover can participate and any application can submit requests.

How It Works

Proof markets function as auction-style matching engines between proof requestors and proof generators. While implementations differ across projects, the general flow follows a consistent pattern:

  1. A requestor (such as a rollup sequencer) submits a proof request specifying the computation to be proved, the proof system (such as SNARK or STARK), the deadline, and the maximum price they will pay
  2. Registered provers evaluate the request and submit bids based on their available compute capacity, hardware efficiency, and desired margin
  3. The market's matching mechanism selects a winning prover, typically based on a combination of price and estimated completion time
  4. The selected prover generates the proof and submits it back to the market contract within the agreed deadline
  5. The market contract verifies that the proof is valid and releases payment to the prover

If the prover fails to deliver a valid proof within the deadline, the request is reassigned to another prover or the prover's staked collateral is slashed as a penalty.

Auction Mechanisms

Different proof markets use different auction designs to match requestors with provers:

  • First-price auctions: provers bid their asking price and the lowest bid wins. Simple but can lead to strategic underbidding
  • Dutch auctions: the offered price starts high and decreases over time. The first prover to accept the price wins the job, balancing urgency against cost
  • Double auctions: both requestors and provers submit bids and asks, and the mechanism matches them. This is the approach used by protocols like Brevis ProverNet, which employs a truthful online double auction to prevent gaming

Staking and Accountability

To prevent provers from accepting jobs and failing to deliver, most proof markets require provers to stake tokens as collateral. If a prover misses a deadline or submits an invalid proof, their stake is slashed. This creates an economic guarantee of reliability: provers only accept work they are confident they can complete.

// Simplified proof market request flow
interface ProofRequest {
  circuit: bytes;        // The computation to prove
  proofSystem: string;   // e.g., "groth16", "plonk", "stark"
  deadline: uint256;     // Block number by which proof must arrive
  maxPrice: uint256;     // Maximum payment in market token
  callbackAddr: address; // Contract to receive the proof
}

// Prover bids on the request
interface ProverBid {
  requestId: bytes32;
  askPrice: uint256;     // Prover's asking price
  estimatedTime: uint256;
  proverStake: uint256;  // Collateral locked for this job
}

Prover-Sequencer Separation

Proof markets formalize a separation of roles that mirrors proposer-builder separation (PBS) on Ethereum. In the same way that PBS separates the role of building blocks from proposing them, proof markets separate the role of generating proofs from the sequencer's role of ordering and batching transactions. This is sometimes called prover-sequencer separation (PSS).

Without this separation, a single entity controlling both sequencing and proving could gain asymmetric advantages: selectively delaying proofs, extracting MEV through proof timing, or censoring transactions by refusing to prove certain batches. Separating these roles and letting the market assign proving duties reduces this concentration of power.

Major Proof Market Projects

Several projects have launched or are building proof markets, each with different architectural choices:

ProjectMechanismStatus
Succinct NetworkAuction node matching with PROVE token for payments and stakingMainnet (August 2025)
Boundless (RISC Zero)Open market with Proof of Verifiable Work rewardsMainnet (September 2025)
=nil; FoundationAuction-marketplace hybrid using zkLLVM compilerLive since 2023
Brevis ProverNetTruthful online double auction with BREV tokenWhitepaper (November 2025)
LagrangeProver network with dedicated capacity agreementsActive partnerships

These projects differ in whether they function as open marketplaces (any prover, any requestor) or as managed prover networks with capacity commitments. Some, like Boundless, aim to support multiple zkVMs so provers can serve different proof systems from a single infrastructure.

Why Proof Markets Matter

Liveness Guarantees

A ZK rollup with a single prover is only as live as that prover. If the prover goes offline, no new validity proofs can be submitted, and the rollup effectively stalls. A proof market provides redundancy: if one prover fails, the request is automatically reassigned to another. As long as the market has active participants, the rollup maintains liveness.

Cost Reduction Through Competition

When a rollup runs its own prover, it bears the full cost of specialized hardware (GPUs, FPGAs, or custom ASICs) regardless of utilization. Dedicated provers are often idle between batches, paying for capacity they are not using. In a proof market, provers serve multiple clients and compete on price, driving costs toward the marginal cost of compute rather than the fixed cost of infrastructure.

This matters for rollup economics: proving costs are a significant portion of a rollup's operating expenses alongside data availability fees. Reducing proving costs through market competition directly improves the rollup's unit economics and can lower fees for end users.

Hardware Specialization

Proof generation benefits enormously from hardware acceleration. GPUs can be 10 to 100 times faster than CPUs for certain proof systems, and custom FPGAs or ASICs can push performance further. A proof market creates a natural incentive for provers to invest in specialized hardware: faster hardware means winning more bids at lower prices, which translates to higher revenue. This investment cycle pushes the entire ecosystem toward faster, cheaper proofs.

Use Cases

  • ZK rollup proving: the primary use case. ZK rollups outsource batch verification proofs to the market instead of running dedicated prover infrastructure
  • Cross-chain bridge verification: bridges that use validity proofs to verify state transitions on source chains can outsource proof generation to the market
  • Proof aggregation: aggregation services that combine multiple proofs into a single proof for cheaper on-chain verification can source individual proofs from the market
  • Verifiable computation for applications: any application needing to prove a computation was executed correctly (machine learning inference, database queries, identity attestations) can submit requests
  • Recursive proof generation: provers can specialize in generating recursive proofs that verify other proofs, enabling proof compression pipelines

Risks and Considerations

Prover Centralization

Despite the goal of decentralization, proof markets can centralize around a small number of well-funded provers with access to the best hardware. Proof generation is capital-intensive, and economies of scale favor large operators. If only a few provers can profitably compete, the market recreates the centralization it was designed to eliminate, just with an auction layer on top.

Trust in Outsourced Proving

When a rollup outsources proving to an external market, it introduces a dependency on the market's availability and the honesty of provers. While validity proofs are mathematically verifiable (a malicious prover cannot produce a fake proof that passes verification), a prover can still cause harm by refusing to prove certain transactions, delaying proofs strategically, or colluding with sequencers to extract value.

Latency vs. Cost Tradeoff

Proof markets introduce a matching step between request and fulfillment that adds latency compared to a dedicated prover. For rollups where time to finality is critical, the auction overhead may be unacceptable. Some proof markets address this with pre-committed capacity agreements where provers reserve capacity for specific clients, but this partially negates the benefits of an open market.

Economic Sustainability

Many proof markets rely on token incentives to bootstrap prover participation. If token rewards exceed the actual value of proofs being generated, the market depends on token inflation rather than genuine demand. Whether proof markets can sustain themselves on organic demand alone, especially as proof generation becomes more efficient and cheaper, remains an open question.

Proof System Fragmentation

Different rollups use different proof systems ( SNARKs, STARKs, Plonk, Groth16, and others). A prover optimized for one system cannot necessarily serve another. This fragmentation limits the depth of competition in any single proof system and may prevent proof markets from achieving the liquidity needed for efficient price discovery.

For a deeper look at the economics of ZK rollups and how proving costs fit into the broader cost structure, see the research article on rollup economics. For background on how proposer-builder separation works at the Ethereum layer, see the analysis of MEV and PBS validator economics.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.