Succinct is building a protocol on Ethereum that coordinates a distributed network of provers to generate zero knowledge proofs for any piece of software. This protocol creates a two-sided marketplace between provers and requesters, enabling anyone to receive proofs for applications such as blockchains, bridges, AI agents, games, and more. 

In this blog post, we introduce the architecture of the Succinct Prover Network as a verifiable application and the utility of the PROVE token. PROVE is the payments token of the Succinct Prover Network. It further incentivizes provers to provide competitive prices to requesters and secures the network via staking, the distribution of value, and governance. 

For a TLDR, read the FAQs at the end of this post!

Introduction: The Succinct Prover Network

Last year, we introduced the core ideas behind the Succinct Prover Network in our whitepaper. We laid out the importance of a permissionless marketplace for proof generation that aggregates supply and demand to create the world’s most robust, efficient proving cluster. As zero knowledge proofs proliferate, Succinct is building the layer that will provide all applications with the most reliable proving service while coordinating the ecosystem of datacenters, node operators, home provers, and hardware teams that will work to improve proof generation. 

While architecting the network, we thought about a user experience for both requesters and provers that would enable secure payments, verifiable matching, and a high performance user experience. In short, we wanted to give users of the prover network all the benefits of crypto’s verifiability with the speed and efficiency of a normal web application. 

To achieve this, the prover network implements a decentralized marketplace where any prover can quickly join and begin fulfilling proofs and any requester can expect to receive competitive prices as a verifiable application (vApp). Open entry into the marketplace lets provers compete to provide the most efficient proving service. The network is powered by the following main ideas: 

• A network architecture as a vApp that provides users with the experience of interacting with a high performance web application while giving them the assurance that their deposits are secure and enabling them to independently verify the state of the network. 
• A token that enables payments, incentivizes provers, and secures the network.
• An auction mechanism that allocates proofs to the most competitive provers.

Network Architecture

The network is architected as a vApp that settles to Ethereum. Concretely, this means that the network is composed of off-chain components that manage the auction process and proof assignment, and on-chain smart contracts that settle state roots and proofs of correct execution. This is similar to the design pattern of an L2 sequencer separating execution from on-chain settlement. The network does not custody user funds, allows secure payments, and enables anyone to verify that it handled the proof request matching process correctly. 

We introduced the vApp development paradigm in our recent paper. We showed how advancements in zero knowledge virtual machines can be used to design applications that have the performance of web2, with the verifiability of web3. The Succinct Prover Network leverages this design pattern to give users the best of both worlds. 

This architecture enables a unified deployment that avoids the limitations in transaction throughput of existing chains. Users do not have to deal with the block latency of any current blockchain and instead face a real-time experience. We believe this is the best architecture for a prover network that will serve web2 and web3 applications alike. 

Off-chain and On-chain Components

We now cover the basic service-level components of the network which operate off-chain, as well as the on-chain smart contracts used for settlement. Except for payments, which are handled on-chain, users only interact with fast off-chain components that manage proof assignments and fulfillments. 

There are two main components:

• Off-chain auctioneer service: the auctioneer service is the main off-chain entity responsible for matching user requests to provers. Requesters submit proof requests and payments and provers submit bids to the auctioneer; requesters receive proofs and provers receive payments in return. Because users interact with the auctioneer directly through RPC calls, they face a high performance, real-time system. 
• On-chain settlement contracts: the settlement contracts settle state roots and ZK proofs periodically submitted by the auctioneer. These proofs contain the updates that the auctioneer makes to the state of the network, via incoming requests, cancellations, and fulfillments. The settlement contracts also allows users to withdraw their funds directly from Ethereum.  

The separation of execution and settlement is a hallmark of the network’s architecture. Because the auctioneer is responsible for processing requests and proof fulfillments, users face a fast web application. The settlement contract ensures the verifiability of the network and the security of user deposits. In particular, the auctioneer does not custody any user funds. Funds live on Ethereum, where they can be withdrawn directly by the user. 

Auctioneer Service and Verifiable Database

The network makes use of a backend architecture that can allow anyone to independently verify updates of balances and proof fulfillments made in the network with the high performance of a normal web application. The auctioneer is the main actor that holds user state and periodically posts proofs of state updates to Ethereum. The auctioneer service is composed of two pieces:

• A verifiable database that stores user balances, pending proof requests, and proof fulfillments. This database is made commitment-friendly via Merkle proofs of read and write operations that are posted to Ethereum. 
• A prover that reads from the database and computes a ZK proof of the new state of the network. The prover is composed of an SP1 program that contains the state transition function of the network. The state transition function tracks balance updates, proof assignments, and proof fulfillments. The prover then executes and generates proofs of this program and periodically settles these proofs on Ethereum, which can be used by anyone to independently verify the state of the network. 

Importantly, because users interact directly with the database, they face a real-time experience in request submission and bidding. Periodic proofs allow them to verify the state of the network.

The PROVE Token

The PROVE token is an ERC-20 token, issued on Ethereum, that serves three main functions within the Succinct Prover Network: 

1. PROVE is the payment token of the Succinct Prover Network. Requesters pay provers in PROVE. 
2. PROVE secures the network via staking, distribution of value, and governance.
3. PROVE incentivizes provers to provide competitive prices to requesters. 

PROVE has an initial supply of 1 billion tokens and a maximum emissions rate of new tokens set by the network’s governance. 

Staking

Provers stake PROVE in order to be able to participate in auctions and fulfill proofs. This stake acts as economic security to hold provers accountable for griefing on proofs and missed deadlines. Stakers can also participate in protocol governance, updating network parameters such as the emissions rate, staking requirements, and additional auction details. Stakers receive the network emissions set by the protocol. 

Delegation

Anyone can stake PROVE and delegate it to provers to cover the provers’ staking requirements. Delegates also earn a fraction of PROVE fees for the economic security they provide to the prover. Delegated stakers can stake to at most one prover at any time. 

Walkthrough: Staking

Suppose Alice makes a proof request, and in that same period, the network generates new PROVE tokens in emissions. The network distributes the fees from Alice’s proof requests and emissions among the prover who fulfills her proof, the delegates that have staked to that prover, and the protocol treasury. 

1. The winning prover earns a majority of the fees.   
2. The delegates staked to the winning prover earn a fraction of the fees for the request, decided by the prover, for providing economic security to the prover.
3. The protocol takes a network fee, which is transferred to the treasury.

The network emissions are further distributed pro-rata to all the stakers. 

Incentives

The PROVE token will also be used to incentivize provers to invest in infrastructure and lower costs over time. More details will be coming soon!

Governance

The PROVE token is used to vote on important network parameters. Some parameters that governance votes on include: 

• The network fee collected by the protocol treasury
• Auction-related parameters, such as the auction format to be used
• Staking requirements

Auction Mechanism

The network makes use of real-time bidding for proof requests to assign the requests to the most efficient provers currently able to fulfill them. The auction mechanism enables price discovery with minimal latency and uses PROVE tokens for payments. The initial version of the network uses a simple reverse auction to allocate the request to the lowest bidding prover. Over time, this mechanism can transition to the proof contest mechanism described in our whitepaper, which distributes rewards to a broader set of provers to encourage decentralization.   

We provide a walkthrough of how requesters and provers participate in the auction mechanism. 

Walkthrough: Requesting Proofs

Requesting proofs is made easy with on-chain PROVE payments that securely handle user funds and the off-chain backend that handles request data. Suppose that Alice runs a ZK rollup and wishes to request a proof. Alice’s proof request requires at least 50 PROVE to be staked in order to participate in the auction for her proof, for a maximum fee of 100 PROVE. Alice sets a deadline of 10 minutes for the proof. 

Alice can easily do this using the Succinct Prover Network:

1. Alice transfers PROVE to the auctioneer to pay for her proof. 
2. Alice initiates a proof request containing the program to be proven, the proof’s deadline, and the maximum fee she is willing to pay, and sends it to the network’s off-chain auctioneer via an RPC call. 
3. Alice’s request is directed to the off-chain auctioneer, where it is matched to the cheapest prover willing to fulfill it, at a price of at most 100 PROVE. 
4. Alice receives the proof and the payment is transferred to the prover . 
5. The balance updates are settled on Ethereum as a single ZK proof, allowing Alice to independently verify the transaction was made correctly.

In addition to this simple user flow, the network makes it easy for Alice to withdraw funds from the smart contract without the permission of any off-chain actors. Even if the auctioneer is not live, Alice can easily withdraw her funds directly from Ethereum. 

Walkthrough: Fulfilling Proofs

It is similarly easy for provers to fulfill proof requests. Provers participate in auctions to compete on the price of proofs, and receive fees in PROVE from users. Suppose Bob, Charlie, and Don are provers and are competing for the ability to fulfill Alice’s proof request. We illustrate several cases: 

1. Bob has 100 PROVE staked and Charlie has 150 PROVE staked. Both of them are eligible to participate in the auction. Don, on the other hand, only has 25 PROVE staked. He is ineligible to participate in the auction. 
2. Bob and Charlie submit bids of 60 PROVE and 70 PROVE to the off-chain auctioneer, respectively, to prove Alice’s request.
3. Bob wins the auction, and the proof request is assigned to him; from assignment, he has 10 minutes to fulfill the proof. 
4. Bob submits the fulfilled proof to the off-chain auctioneer within 10 minutes, and the payment of 60 PROVE is transferred to him from Alice. 

If Bob does not submit a proof that was assigned to him within 10 minutes, the proof request is cancelled and Bob’s stake is slashed for 50 PROVE. Alice can retry her request to request the proof from other provers. 

Alternatively, Alice can enter into a service level agreement with Bob by whitelisting him as the only prover eligible to fulfill her request. In this case, Charlie and Don are ineligible to participate in the auction, and only Bob can join.

On-Demand Requests and Off-Chain Reservations

The network allows anyone to request proofs by directly interacting with the auctioneer. This connects the user to a distributed set of provers that are available to fulfill the request. Users have two options when requesting proofs: 

• On-demand requests: Requests can be sent to the network on-demand, where they are entered into an open auction into the available pool of provers. This is particularly beneficial for users that would like to find the most competitive prices for their proofs from all the provers that are online. On-demand requests are also useful for applications that require burst capacity and don’t have recurring requests over long periods of time.
• Off-chain reservations: Alternatively, users that require strong reliability guarantees or large-scale proving can enter into off-chain service level agreements with provers. These agreements can then be implemented in the network by whitelisting the agreed upon provers and can potentially allow for better pricing due to their long-run nature. The whitelist only allows the approved provers to bid in the auction for the request. 

By providing users with flexibility in the types of services they can request, the network serves all users with a single unified interface.

Testnet Stage 2.5: End-to-end Deployment

We’ll be deploying an end-to-end version of this system in Stage 2.5 of our testnet in a few weeks. In Stage 2.5, application developers will be able to easily request proofs. Whether you’re running a rollup, trying to scale a layer 1 blockchain, or developing a next generation game, we’d like you to try out the network. 

We’ll also be onboarding provers to participate in competitive proving in Stage 2.5. You’ll be able to stake in the testnet, bid for requests, and fulfill them on demand. Stay tuned for this announcement! 

FAQs

What is the Succinct Prover Network?

The Succinct Prover Network is a protocol on Ethereum that implements a decentralized marketplace for zero knowledge proof generation. It enables any application, from blockchains to ZK rollups to games to get proofs from a distributed set of provers. 

What is the architecture of the Succinct Prover Network?

The network is architected as a verifiable application (vApp), with an off-chain auctioneer that manages user requests and matching, and on-chain smart contracts that settle state roots and proofs. Similar to an L2 sequencer and the on-chain settlement of an L2, this allows anyone to independently verify the state of the network while ensuring that users get a high performance experience. 

What is the PROVE token? 

PROVE is the payment token of the network. It is used for network security via staking and governance and aligns incentives between provers and requesters.

What is the PROVE supply? 

PROVE has an initial supply of 1 billion tokens. The total supply can be changed by PROVE emissions, which are modified by the network’s governance. 

How are provers assigned to requests? 

The network runs an auction to assign requests to the most efficient provers; initially, this will be a reverse auction. This auction is handled off-chain. Anyone can independently verify the outcome of the auction with ZK proofs that are posted on-chain. Users can request proofs on-demand or enter into off-chain reservations with provers. 

When will the network be live? 

We will be releasing an end-to-end deployment of this system in Stage 2.5 of our testnet in a few weeks. Keep your eye out for the announcement!