The Boundless Protocol

The RISC Zero Team

Abstract 2.1.2 Trustless trading . . . . . . . . 3

2.2 A spot market for verifiable compute . 4
We propose Boundless, a decentralized market, ag- 2.2.1 Fulfillment guarantees . . . . . 5
gregation, and smart contract settlement protocol de- 2.2.2 Decentralization . . . . . . . . 6
signed to scale ZK-powered verifiable compute for ev-
2.3 A token . . . . . . . . . . . . . . . . . 6
ery chain.
2.3.1 Proof of verifiable work . . . . 7
In Boundless, operators of GPUs and other com-
modity hardware called “provers” compete for on or 2.3.2 The Vault . . . . . . . . . . . . 8
off-chain requests for zero knowledge proofs issued by 2.4 Verifiable service agreements . . . . . 8
“requestors” via an efficient and open market. Such 2.4.1 A note on data availability . . 9
requests might occur either in the “spot” market or
as part of a “service agreement” contract. In either 3 Implementation 9
case payment is settled in conjunction with the verifi-
cation of the proof on the destination chain specified 4 Conclusion 9
by the requestor.
We describe the following contributions: Proof of
Verifiable Work, a fraud and spam-resistant mecha- 1 Introduction
nism for measuring the complexity, and therefore rel-
ative cost, of a zero knowledge proof which Bound- The idea that computational resources can be traded
less uses to incentivize proving via a token reward is as old as the computing industry itself. Several
issued to provers as they engage in useful “ZK min- models have emerged over the decades, culminating
ing;” the Financialization of Compute, which lever- in modern approaches such as cloud computing and
ages crypto-economic incentives to provide a reliable, on-chain execution.
capital-efficient solution to the problem of matching However, while cloud computing enjoys outstand-
provers and requestors; and Boundless, a practical ing economies of scale, the same cannot be said for
system built upon these ideas. on-chain execution.
The difference is one of trust. A user of a cloud
service implicitly trusts the service provider to per-
Contents form the computation faithfully. In contrast, a user
of a blockchain does not trust any particular node;
1 Introduction 1 instead they trust the protocol, which has mitiga-
1.1 The road to ZK adoption . . . . . . . 2 tions in place for dealing with dishonest nodes. Un-
1.2 The last remaining challenge . . . . . 2 fortunately, the mechanism by which these mitiga-
tions work (re-execution by skeptical, incentivized
2 Boundless 3 validators) necessarily imposes limits on the amount
2.1 The financialization of compute . . . . 3 of computation that can be performed on-chain. De-
2.1.1 An abundant commodity . . . 3 mand for on-chain compute exceeds these limits and

1
so the chain must have yet another mechanism to de- to use, which led to new technologies such as Bul-
cide which of the requested computations it will per- letproofs (2018), Circom (2019), Halo (2019), and
form. In Ethereum and others this is decided by the others. Concurrently, the development of STARKs,
gas market, which simply auctions-off the chain’s lim- together with the release of the CairoVM in 2020,
ited compute resources. While this mechanism has showed that ZK could be secure and programmable
many desirable properties, it does not address the un- without requiring a trusted setup.
derlying problem (the scarcity of on-chain compute); In 2022, RISC Zero released the zkVM, the first
instead, it “prices-out” all but the most high-margin general purpose zero knowledge virtual machine
requests, effectively sacrificing one workload for an- based on a standard architecture (RISC-V). The
other rather than serving them both. zkVM revolutionized the industry: whereas ZK adop-
Modern approaches based on zero knowledge tion previously required the use of exotic program-
proofs (ZKPs) offer a better solution. ZKPs change ming or circuit languages, the zkVM made it pos-
the trust dynamic by making it possible for a node sible to use any programming language that sup-
to prove that a given computation results in a given ports RISC-V. This notably includes Rust, which has
output. This makes it possible for a user, or other an outstanding ecosystem of tools and libraries, and
observer, to trust the result of the computation even which is seeing widespread adoption in blockchain
if they don’t trust the node who performed it. By and other industries.
changing the trust dynamic in this way, ZK obviates One year later, RISC Zero showcased the power of
the need for skeptical re-execution, providing a path the zkVM with the release of Zeth, the first “Type 1”
towards scalable, trustless, decentralized compute. zkEVM. Zeth took the industry by surprise. Previ-
ously, conventional wisdom had it that zkEVMs took
1.1 The road to ZK adoption years to build. With Zeth it was shown that a team
of 3 people could do it in under a month. This dis-
Though the foregoing argument has been known for ruption, together with the cumulative performance
some time, real-world adoption of ZK has been lim- improvements seen in zkVM since its release, has trig-
ited until recently. gered changes to project roadmaps across the indus-
During its early history, the field of zero knowl- try: not only is ZK viable, but with zkVM it’s fast
edge proofs consisted of an eclectic bag of specialized and easy.
tricks, each capable of solving a narrow class of prob-
lems. Public key digital signature schemes such as
1.2 The last remaining challenge
RSA and ECDSA are perhaps the most recognizable
examples from this early era. Unfortunately, adopting ZK is rarely as simple as
As time went on, advances in computational com- writing some Rust and running it in the zkVM. True
plexity theory, particularly in the study of probabilis- adoption forces confrontation with the last remain-
tically checkable proofs, provided strong theoretical ing challenge: end-to-end integration. The essence of
evidence that ZK should be capable of performing the challenge is that, whereas the gas market for on-
general purpose computations. Practical algorithms chain compute is enshrined into the chain’s protocol,
– and a Turing Award – soon followed. access to ZK proving is not. Thus, teams seeking to
But these algorithms, while practical, were still a adopt ZK must build their own pipeline for proofs.
far cry from being easy to use. By their nature they This is a non-trivial challenge, encompassing the lack
were only accessible to people with deep expertise in of suitable decentralized infrastructure, differences in
applied cryptography and a bleeding-edge awareness the control flow between standard on-chain execution
of theoretical results. Still, the launch of Zcash in and ZK-powered execution, incentive management,
2016 demonstrated that the technology was viable. and issues associated with bootstrapping and retain-
This led to an explosion of research aimed at mak- ing proving capacity.
ing ZK more performant, versatile, secure, and easy The zkVM revolutionized the way people write ZK

2
apps. What’s needed is a similar revolution in how work makes it possible for that commodity to be
they are deployed and integrated. trustlessly metered and traded. Boundless leans into
these properties, leveraging market forces to facili-
tate permissionless and trustless trading and utiliza-
2 Boundless tion of verifiable compute – and in doing so provides
an efficient and reliable solution to the end-to-end
To address the challenges associated with ZK adop-
integration challenges described above.
tion we propose Boundless, a fully decentralized ZK-
powered protocol containing smart contracts, novel
cryptographic primitives, and off-chain infrastructure 2.1.1 An abundant commodity
whose permissionless marketplace facilitates secure, ZKP technology has reached a state where it is now
efficient, and reliable execution for any protocol or possible to generate non-trivial ZKPs on consumer
blockchain via the financialization of compute: off-the-shelf hardware such as MacBook Pro and
• Its core is implemented by smart contracts de- gaming PCs. Furthermore, the software for doing
ployed across any compatible blockchain.1 Each so is free and open source. With such a low barrier
deployment is independent and inherits the to entry, it is expected that verifiable compute will
properties of the chain to which it is deployed, generally behave like an abundant commodity.
including decentralization, liveness, and crypto- For users and protocols this means simple, depend-
economic security. able access to verifiable compute, at a stable price.
For industrial provers this means adding value
• It enables infrastructure providers to seamlessly through resource management, capacity planning,
engage with all of these deployments at same pricing, and reliability; by selling service agreements
time, ensuring there’s ample proving liquidity and other differentiated offerings; and by managing
across all chains. or coordinating pools of residential/amateur provers.
Lastly, for traders this means adding value by con-
• It leverages the security properties of zero knowl-
tributing to price discovery and by providing in-
edge proofs and proof of verifiable work to enable
struments that allow market participants to hedge
trustless exchange of payment for compute.
against volatility (see service agreements below).
• It is a marketplace. It solves problems such as
price discovery, liveness, and censorship resis- 2.1.2 Trustless trading
tance by treating ZK-powered verifiable compute
as a commodity that can be traded either di- Unlike physical commodities (where practically ev-
rectly (in the spot market) or indirectly (via ser- ery dispute boils down to a concurrently-observative
vice agreements). intersubjective truth), all of the relevant informa-
tion regarding ZK-powered verifiable compute falls
• Its compute capacity scales linearly with the within the realm of objective truth with bounded un-
compute resources operated by provers: double certainty (i.e. probabilistic soundness under stan-
the hardware, double the capacity. dard cryptographic assumptions). With properly im-
plemented circuits and software (and with suitable
2.1 The financialization of compute choice of cryptographic parameters), this is practi-
cally the same as objective truth, which is why ZK-
In this section we explain the foundational ideas be- powered verifiable compute is so well suited for use
hind Boundless: (1) verifiable compute can be re- in trustless contexts.2
garded as a commodity, and (2) proof of verifiable
2 We take this opportunity to call for greater adoption of
1 For
didactic reasons, this paper restricts its attention to formal verification at all levels – from properties of the under-
Ethereum and its EVM-based L2s. lying theories all the way up to guarantees about real world

3
 But this property alone does not allow verifiable a public forum (the Boundless Marketplace), ei-
compute to be efficiently traded. For that one also ther on-chain or offchain.
requires a trustless and secure way to meter the
amount of compute that went into a particular task. 2. Initially, the requestor is not willing to pay very
In Boundless this metering is implemented by proof much to have their request fulfilled. They are
of verifiable work, a simple but robust mechanism willing to let some time pass to see if anyone
that, among other things, allows provers to reveal the will fulfill it for a low price.
amount of work that went into a particular proof.
3. As time goes on, if the request is not fulfilled, the
These properties – the objectivity of the result to-
requestor increases the amount they are willing
gether with the integrity of the metrics reported by
to pay.
proof of verifiable work – enable trustless trading of
verifiable compute. 4. Eventually, either:

(a) The price rises to a level where someone

2.2 A spot market for verifiable com- (Bob, Charlie, or someone else) is willing
pute to fulfill the request; or
We begin with a simple example. Alice wants to use (b) The price rises until it’s so high that the
an on-chain app that requires her to submit a ZKP. requestor is unwilling to go any higher. If
The ZKP can be generated by anyone with sufficient there’s still no takers, the request goes un-
compute resources and access to the necessary data. fulfilled.
Alice doesn’t want to generate the ZKP herself and
so begins looking for someone who can generate and This approach has several benefits:
submit it for her. Bob and Charlie are both inter-
ested in generating the ZKP for Alice as long as she’s • Dutch auctions conclude once the first bid is con-
willing to pay enough to cover costs plus a reasonable firmed.4 This property makes Dutch auctions
profit. particularly well suited to low-latency situations
Alice is able to describe the required computation as well as on-chain implementations.
and from this description it is possible for Bob and
Charlie to estimate the amount of work that would • The “reverse” aspect of the auction results in a
be needed to fulfill her request.3 Thus, from a market simpler protocol than an “ordinary” auction. In
perspective, the only question is: who is willing/able an “ordinary” auction provers would be required
to do it for the lowest price? to advertise their prices and capacity. Doing this
in a trustless, generic manner is not easy. The
The Boundless Marketplace answers this question
reverse auction avoids those challenges.
by facilitating a reverse Dutch auction. In a reverse
Dutch auction, price discovery works as follows: • The reverse Dutch exhibits desirable efficiency
and stability properties. Crucially, it gets Alice
1. The requestor (Alice) announces their request in the lowest possible price with low overhead.
implementations – and to thank our partners at Nethermind,
Thus, when Alice needs a ZKP, she publishes a
Veridise, Runtime Verification, and the Ethereum Foundation
for their significant contributions in this area. request to the Boundless Marketplace containing the
3 They can do this by fetching the necessary data and run- following data:
ning the requested computation in a non-proving executor.
This is relatively inexpensive to do, de-risks the request by 4 To see why, note that the price function is monotonically

ensuring the given data really leads to a successful result, and non-decreasing. This means the first bid is guaranteed to be
tells them exactly how much work is needed to generate the the lowest and thus the requestor has no reason to consider
proof. any later bids.

4
 • A machine-readable description of the ZKP she quest. Without loss of generality, suppose Charlie
needs generated (together with any other meta- picks a lower price than Bob.7
data needed to fulfill the request).5 As time goes on and the request remains open,
the price programmatically increases as per the price
• A timestamp indicating when the auction is function. Eventually the price approaches Charlie’s
scheduled to begin. threshold. When it does, he has two choices:

• A monotone, non-decreasing price function (de- 1. Immediately fulfill the request. Charlie can do
nominated in ETH or ERC20). this by racing to generate the proof and fulfill
the request before the price increases to such a
• An optional bond (staked by provers seeking to point as to attract competition.
lock the request).
2. Immediately lock the request. This operation
• An expiration date/deadline. grants Charlie the exclusive right to fulfill the
request. This lock allows him to engage in the
After picking her request parameters, Alice pub- task of proof generation without fear that a com-
lishes her request. For this she has several options: petitor will swoop in and fulfill the request at the
last second. To secure this exclusivity, he must
• She can publish her request on-chain to the lock-up some stake. He will lose this stake if he
Boundless Marketplace contract (on the chain fails to fulfill the request before the given dead-
of her choosing). line.

• She can sign her request and publish it offchain In some situations Alice might prefer to disallow
to one or more separate protocols (a third-party locking. She can express this as part of her request.
gossip protocol, exchange, listing service, etc). In this case path (2) above would be prohibited.
When Charlie fulfills her request he is program-
In either case her request will ultimately be fulfilled matically paid the prover’s fee, which is equal to the
via the Boundless Marketplace contract on the chain request’s price minus the market’s fee (which is deter-
specified by her request. mined by the market’s take rate, and which accrues
Once Alice’s request has been published, Bob and to the market’s vault). The request’s price is deter-
Charlie both begin evaluating the work necessary mined by the price function at either the time of lock
to fulfill it. They evaluate the request based on (if Charlie locked the request prior to fulfillment) or
the description (see footnote 3) the stated expira- fulfillment (if he didn’t). To save on gas fees asso-
tion/deadline, their current workload, other oppor- ciated with proof verification (and if permitted by
tunities available in the market, their desired profit Alice’s request), Charlie can deliver the proof as part
margin, the likelihood that someone else will be will- of an aggregated batch.
ing to do it for less, etc.6
Based on these factors they both pick a price 2.2.1 Fulfillment guarantees
above-which they would be willing to fulfill the re-
When everything goes right, Alice pays the lowest
5 To save on on-chain data costs, the request metadata may
possible price to receive her proof before her specified
include references to offchain data such as magnet links, IPFS
links, HTTPS links, S3 links, links to DA platforms, etc. Long- 7 Maybe Bob has a higher cost basis than Charlie, or maybe

term data availability is not generally required; in the spot he just seeks a higher profit margin. Maybe Bob doesn’t expect
market, it is expected that prospective provers will attempt to Charlie to pick a lower price, or maybe Bob has decided that
fetch the data before attempting to lock or prove a request. the request won’t be profitable even at its max price. In what
6 This evaluation can be automated through the use of mod- follows, the reasons why Bob picked a higher price target than
els. Charlie won’t matter.

5
deadline. But what if somebody locks her request but light of this, we now consider the following: what’s
fails to meet the deadline (possibly on purpose)? to stop a monopoly from forming?
If Charlie locks Alice’s request but misses the dead- To answer this, we return to Bob and Charlie, the
line, then he will lose his stake, and Alice will be re- provers from our previous example.
funded. What happens next depends on how Alice Suppose Charlie out-scales the competition and
configured her request: grows to a point where he is responsible for the vast
majority of proving. Bob is rarely able to lock a re-
• In the simplest case, the lost stake is sent to the quest and is effectively pushed out of the market.
market contract (where it can be distributed to If Charlie continues to fulfill requests at a reason-
token holders via the points mechanism) and the able price, then all is well. But what if Charlie starts
request’s lifecycle is considered complete. raising rates or refuses to fulfill certain kinds of re-
quests?
• Alternatively, if her request allows it, the re-
As Charlie abuses his monopoly, Bob starts to see
quest enters into a “retry” phase. During this
an opportunity. Charlie’s grip on the market is not
phase, locking is disabled and provers are re-
absolute: he may have a monopoly on the proof mar-
warded with a portion of the original prover’s
ket, but he does not have a monopoly on the hard-
lost stake (the remainder being sent to the mar-
ware needed to engage in the proof market. Indeed,
ket contract). Assuming Alice tuned the staking
Bob already has the necessary hardware (a MacBook
requirement appropriately, provers will recognize
Pro or gaming PC will do); if the opportunity is great
the premium being offered and race to fulfill her
enough, he can even spin up a fleet of cloud instances
request.
for maximum effect. The software is easy to deploy
and run. So, if Bob can make a profit by undercut-
Other strategies are also available to Alice. For
ting Charlie’s prices or fulfilling the requests Charlie
example, if Alice needs the proof right now, she can
is ignoring, then he will step into the market and do
submit a request with a short deadline, and locking
so.
disabled, and a high, constant price. When Bob and
In the Boundless Marketplace, the goal is to pro-
Charlie see the request, they’ll recognize the high pre-
vide users with a reliable service at a low cost. This
mium being offered and race to fulfill it.
goal is achieved by ensuring that people like Bob can
Alternatively, suppose Alice needs her request to
easily use the hardware they already have to jump
be fulfilled within 3 days (i.e. some period of time
in and correct the market. This reliance on market
that greatly exceeds the time required to generate the
forces (and permissionless chains) is the key sense
proof). In this case she could submit a request with
in which Boundless is decentralized. The barriers to
a much shorter deadline (say, 12 hours), a reason-
joining the market as a prover are low: the software
able initial price, an attractive maximum price, and a
is open source and works with commodity hardware,
moderately high staking requirement. If her request
so that the proving supply is permissionless and own-
fails to attract any interest, she still has plenty of
erless. This ideally will provide sufficient “compute
time remaining to re-issue the request with a higher
liquidity” to correct aberrations in the marketplace.
price or different parameters.
Consequently, a request made to the Boundless Mar-
ketplace will be fulfilled at a fair price when there is
2.2.2 Decentralization at least one party for whom it is profitable to do so.
Proof generation at scale is an industrial process, and
like other industrial processes, it has economies of 2.3 A token
scale. All else being equal, a data center next to a
river is going to be able to generate more proofs at a To facilitate reliable, low-friction trading and trust-
lower cost than a pool of residential gaming PCs. In less governance, the Boundless Marketplace includes

6
a novel token called $ZKC with the following prop- payments they receive from requestors upon fulfill-
erties: ment, and the native rewards provided by proof of
verifiable work.
• A cap on total supply. But this begs the question: what does it mean to
“contribute” to the market? While the definition of
• A variable minting rate, ultimately controlled by “contribution” will ultimately fall to tokenholder gov-
tokenholders via on-chain governance, which de- ernance, at launch there will be two key metrics:
termines how quickly the supply cap is reached.
Newly minted tokens are distributed to provers • Value delivered. By this metric, provers who are
as part of the proof of verifiable work reward responsible for a large percentage of the fees col-
mechanism (see below). lected by the market should receive a large re-
ward.
• Ability to generate points, which confer access
to the fees collected by the market. • Work performed. By this metric, provers who
are responsible for a large percentage of the cy-
• Ability to stake in the spot market and/or ser- cles proven should receive a large reward.
vice agreements.
These metrics are synthesized into a reward via the
• A variable reward frequency (controlled by gov- following rule: each prover is rewarded according to
ernance) that determines how often tokens and either their proportion of fees collected by the mar-
points are minted/distributed. ket8 or their proportion of cycles proven – whichever
is smaller.9
We describe these concepts in greater detail in the
For example, suppose Bob is responsible for 25% of
sections below.
fees collected by the market but only proved 10% of
the cycles. In this case he would receive 10% of the
2.3.1 Proof of verifiable work newly minted tokens. Conversely, suppose Charlie is
responsible for 75% of the fees collected by the market
As requests are fulfilled, the Boundless Marketplace
but proved 90% of the cycles. In this case he would
inherently tracks various metrics related to reward
receive 75% of the newly minted tokens.
distribution. Specifically, for each reward epoch,
In the example above, we see that Bob and Charlie
Boundless tracks:
account for all of the fees and cycles, but only wind up
receiving 10% + 75% = 85% of the newly minted to-
• The cumulative fees collected by the market.
kens. The remaining 15% are simply burned, thereby
This is a measure of value provided.
reducing the minting rate.
• The cumulative number of cycles proven by the The ability to track the number of cycles proven
market. This is a measure of work performed. depends critically on a unique feature of RISC Zero’s
zkVM called proof of verifiable work. This feature
It also tracks these metrics on a per-prover basis. gives provers the ability to include (in their proofs)
Thus, for any given epoch, for any given prover, it is metadata about the number of cycles that went into
easy to calculate the percentage of fees (resp. cycles) the proof. This metadata is cryptographically secure,
attributed to requests fulfilled by that prover. 8 Boundless supports payments in ETH or ERC20 tokens.
Using these metrics, Boundless’ smart contract However, for the purposes of the reward mechanism, only those
programmatically rewards provers by distributing fees denominated in ETH are considered.
9 The fee proportion is ignored in the special case where
newly minted tokens to them in proportion to their
governance has set the market’s take rate to 0%. In this case
contributions to the market. Consequently, the mar- provers are rewarded exactly in proportion to the number of
ket provides provers with two sources of revenue: the cycles they proved.

7
meaning that the prover cannot manipulate/alter it 2.4 Verifiable service agreements
without invalidating the proof,10 and is also stamped
with an unique immutable value (a nonce) that pre- A verifiable service agreement is a binding commit-
vents the proof from being “double counted” by the ment between a prover and a requestor, typically lay-
reward mechanism. ing out terms by which the requestor can oblige the
prover to perform some verifiable work.
Mechanically, service agreements are implemented
2.3.2 The Vault by smart contracts that make use of Boundless’ mar-
ket, vault, aggregation, delivery, and reward mecha-
As alluded to above, the market takes a fee on all nisms. By design, the universe of potential service
fulfilled requests. This fee is calculated as a percent- agreements is left open: Boundless allows anyone
age (called the take rate) of the request price. The to permissionlessly bring new kinds of service agree-
take rate is configurable by tokenholder governance. ments to market simply by deploying a compatible
Fees collected by the market in this manner are ulti- contract. This flexibility allows for the creation of
mately distributed to $ZKC holders. In this section instruments tailored to different use cases while still
we describe the mechanism by which that happens. enjoying the economies of scale and intrinsic rewards
Recall that the market is deployed on multiple provided by the Boundless marketplace.
chains. Each of these deployments has its own fee We illustrate the utility of service agreements with
pool, into which the fees collected by the market are two examples.
deposited. First we return to Alice and Charlie. Recall that
Each deployment also has a vault (implemented Alice, an end user, used the spot market to purchase a
by an immutable smart contract) containing locked- proof from Charlie (a prover). She knows she’s going
up tokens. $ZKC holders can permissionlessly lock- to make more requests in the future, so she reaches
up their tokens in the vault. While locked-up, to- out to Charlie and offers a deal: she’s willing to pay
kens earn (non-transferable) points which can later a small up-front sum in exchange for the ability to
be burnt to extract fees from the pool and/or un- purchase 100 more similar requests, one at a time,
lock tokens held in the vault. The extraction/unlock at a limited frequency, sometime over the next year,
mechanism is based on proportionality: an entity who at a predetermined price per cycle. They memorial-
burns 1% of all outstanding points will be rewarded ize this agreement with a smart contract – a service
with 1% of the fees in the pool (at time of burn); agreement – that gives Alice trustless, disintermedi-
similarly, an entity who burns 1% of their points has ated recourse in the event that Charlie fails to uphold
the option to unlock 1% of their tokens at that same his end of the bargain.
time. Charlie likes this arrangement because it estab-
In addition to point generation, tokens locked-up lishes an easy payment rail with Alice while also help-
in the vault can also be staked into a service agree- ing him with his long-term capacity planning. Alice
ment (see below) or used to lock a request in the spot also likes this arrangement. On the one hand, the ser-
market. As with all tokens locked-up in the vault, vice agreement reduces her exposure to unpredictable
tokens staked in this manner continue to generate increases in the (spot) price of proving. On the other
points programmatically. hand, if she doesn’t make as many requests as she ini-
tially planned, then she’s out the cost of the service
10 Intuitively, this feature works by adding constraints to the agreement but doesn’t need to pay for her unused
zkVM circuits that effectively implement a monotonic counter requests. Furthermore, if the terms of the service
whose value correlates with the number of cycles of (ZK) exe- agreement allow for it, she can recover some of her
cution needed to generate the proof. The full details, such as costs by selling the service agreement to another user.
the protections against malleability and the means of account-
ing for the cost of different circuits, are beyond the scope of But Alice isn’t the only party looking for a service
this paper. agreement. For our second example we turn to Pam,

8
a protocol developer who seeks to ensure there’s am- withheld the data, and so it would appear (to the
ple proving supply for her core protocol. Specifically, service agreement’s smart contract) that Alice issued
she is looking for a service agreement that provides: a valid request and Charlie failed to fulfill it. By
exploiting this, Alice can cause Charlie to be slashed
• A bunch of proving over the next year, possi- through no fault of his own.
bly with sudden spikes, possibly with significant To defend against this, provers must consider the
growth before the end of year. data availability requirements implied by an agree-
ment before entering into it. For example, if the
• Timely delivery of proofs (to ensure the protocol
agreement only applies to requests that can be
runs smoothly.)
served using data from permissionless sources (such
Pam reaches out to Charlie to purchase a service as Ethereum, EigenDA, Celestia, etc), then the risk
agreement, but this alone is not enough: no matter to the prover stemming from data (un)availability is
how reliable Charlie has been in the past, no matter relatively low. Luckily, most decentralized applica-
how much stake he puts behind the contract, there tions should naturally satisfy this requirement, as the
is always a chance that Charlie might fail to uphold relationship between data availability and progress is
his end of the bargain. If this should happen, Pam not unique to ZK.
always has the option of using the spot market as a
backstop (Sections 2.2 and 2.2.2). However, given the
enormity of her workload, she’d prefer to avoid “on
3 Implementation
demand” pricing. Boundless is being built in the open. See the re-
So Pam seeks out others like Charlie and purchases questor, prover, and developer docs, as well as the
service agreements from them as well. She accumu- code itself, at https://beboundless.xyz.
lates these service agreements into a basket. This ad-
dresses her reliability concerns: by construction, no
single point of failure can prevent this basket from 4 Conclusion
delivering proofs. But the basket is also quite large,
possibly several times larger than the expected work- Much has changed since Satoshi published his 9 page
load. Thus she takes one last step and fractional- masterpiece more than 15 years ago, but many things
izes the basket. This gives her the ability to sell-off have stayed the same. The majority of the on-chain
th
the excess capacity while also giving buyers access to ecosystem is still rooted in 20 century cryptogra-
the kind of high-end SLAs that are traditionally only phy. Recent advances in zero knowledge proofs rep-
available to large protocols. resent a significant step forward and we propose that
Boundless is the right way to realize their potential.
2.4.1 A note on data availability
As discussed in Section 2.2, provers in the spot mar-
ket engage with requests at their own discretion and
are therefore free to ignore requests for which the
data is unavailable (footnotes 3 and 5).
For service agreements, the situation can be more
subtle. For example, suppose Alice buys a service
agreement from Charlie that obliges him to fulfill her
requests (and which slashes him should he fail to do
so). What happens if Alice issues a request to Charlie
but fails to provide the data needed to fulfill it? In
general, there is no way for Charlie to prove that Alice

9
Requestor

gib proof! Discover Ramp Up

phase

Time
Last call

Price
To match with a prover, The price Alice offers goes up until
she conducts a reverse either (a) someone agrees to do it or
Alice wants a proof Dutch auction (b) Alice gives up

Provers
plz pay for proof gpu Imma slash u Charlie
Time

Price Charlie
misses the
Charlie locks Alice’s request. dealine Charlie misses the deadline
Bob & Charlie want to get He will lose his stake if he fails Charlie gets slashed; his stake
paid to make proofs to deliver on time is used to fund a new auction

Charlie delivers
on time Fallback auction
Result succeeds

Yay!!

Happy Alice