Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions developers/kailua/quick-start.mdx
Original file line number Diff line number Diff line change
@@ -1,13 +1,13 @@
# Quick Start

:::note[Reminders]
<Note>
- **OP Kailua** enables rollup operators to add a new fault proof system to their rollup via the Optimism `DisputeGameFactory`
contract.
- **OP Kailua's** contracts rely on ZK proofs to finalize/dismiss output proposals, and are compatible with
Optimism's Bedrock contracts `v1.4.0` and above.
:::
</Note>

This tutorial will run you through on how to spin up a local OP Kailua devnet for development purposes.

Check warning on line 10 in developers/kailua/quick-start.mdx

View check run for this annotation

Mintlify / Mintlify Validation (boundless) - vale-spellcheck

developers/kailua/quick-start.mdx#L10

Did you really mean 'Kailua'?

Check warning on line 10 in developers/kailua/quick-start.mdx

View check run for this annotation

Mintlify / Mintlify Validation (boundless) - vale-spellcheck

developers/kailua/quick-start.mdx#L10

Did you really mean 'devnet'?

Before you get started, you will need the following dependencies installed:

Expand All @@ -17,37 +17,37 @@
- [svm](https://github.com/alloy-rs/svm-rs)
- [foundry](https://book.getfoundry.sh/getting-started/installation)

## Clone the Kailua repo

Check warning on line 20 in developers/kailua/quick-start.mdx

View check run for this annotation

Mintlify / Mintlify Validation (boundless) - vale-spellcheck

developers/kailua/quick-start.mdx#L20

Did you really mean 'Kailua'?

```bash
git clone https://github.com/risc0/kailua.git && cd kailua
```

## Run the following commands to spin up a devnet

Check warning on line 26 in developers/kailua/quick-start.mdx

View check run for this annotation

Mintlify / Mintlify Validation (boundless) - vale-spellcheck

developers/kailua/quick-start.mdx#L26

Did you really mean 'devnet'?

You can deploy a local optimism devnet equipped with Kailua through the following commands:

Check warning on line 28 in developers/kailua/quick-start.mdx

View check run for this annotation

Mintlify / Mintlify Validation (boundless) - vale-spellcheck

developers/kailua/quick-start.mdx#L28

Did you really mean 'devnet'?

Check warning on line 28 in developers/kailua/quick-start.mdx

View check run for this annotation

Mintlify / Mintlify Validation (boundless) - vale-spellcheck

developers/kailua/quick-start.mdx#L28

Did you really mean 'Kailua'?

1. `just devnet-fetch`
* Fetches `v1.9.1` of the `optimism` monorepo.

Check warning on line 31 in developers/kailua/quick-start.mdx

View check run for this annotation

Mintlify / Mintlify Validation (boundless) - vale-spellcheck

developers/kailua/quick-start.mdx#L31

Did you really mean 'monorepo'?
2. `just devnet-build`
* Builds the local cargo and foundry projects.
3. `just devnet-up`
* Starts a local OP Stack devnet using docker.

Check warning on line 35 in developers/kailua/quick-start.mdx

View check run for this annotation

Mintlify / Mintlify Validation (boundless) - vale-spellcheck

developers/kailua/quick-start.mdx#L35

Did you really mean 'devnet'?
* Dumps the output into `devnetlog.txt` for inspection.
4. `just devnet-upgrade`
* Upgrades the devnet to use the `KailuaGame` contract.

Check warning on line 38 in developers/kailua/quick-start.mdx

View check run for this annotation

Mintlify / Mintlify Validation (boundless) - vale-spellcheck

developers/kailua/quick-start.mdx#L38

Did you really mean 'devnet'?
* Assumes the default values of the local optimism devnet, but can take parameters.

Check warning on line 39 in developers/kailua/quick-start.mdx

View check run for this annotation

Mintlify / Mintlify Validation (boundless) - vale-spellcheck

developers/kailua/quick-start.mdx#L39

Did you really mean 'devnet'?
5. `just devnet-propose`
* Launches the Kailua proposer.

Check warning on line 41 in developers/kailua/quick-start.mdx

View check run for this annotation

Mintlify / Mintlify Validation (boundless) - vale-spellcheck

developers/kailua/quick-start.mdx#L41

Did you really mean 'Kailua'?
* This runs the sequences, which periodically creates new `KailuaGame` instances.
6. `just devnet-validate`
* Launches the Kailua validator.

Check warning on line 44 in developers/kailua/quick-start.mdx

View check run for this annotation

Mintlify / Mintlify Validation (boundless) - vale-spellcheck

developers/kailua/quick-start.mdx#L44

Did you really mean 'Kailua'?

Check warning on line 44 in developers/kailua/quick-start.mdx

View check run for this annotation

Mintlify / Mintlify Validation (boundless) - vale-spellcheck

developers/kailua/quick-start.mdx#L44

Did you really mean 'validator'?
* This monitors `KailuaGame` instances for disputes and creates proofs to resolve them.
* (VALIDITY PROVING) Use `just devnet-validate [block-height]` to generate validity proofs to fast-forward finality until the specified L2 block height.
* (DEVELOPMENT MODE): Use `RISC0_DEV_MODE=1` to use fake proofs.
7. `just devnet-fault`
* Deploys a single `KailuaGame` instance with a faulty sequencing proposal.
* Tests the validator's fault proving functionality.

Check warning on line 50 in developers/kailua/quick-start.mdx

View check run for this annotation

Mintlify / Mintlify Validation (boundless) - vale-spellcheck

developers/kailua/quick-start.mdx#L50

Did you really mean 'validator's'?
* Tests the proposer's canonical chain tracking functionality.
8. After you're done:
* `just devnet-down` to stop the running docker containers.
Expand Down
6 changes: 3 additions & 3 deletions developers/proof-lifecycle.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@

On this page, the entirety of a proof's lifetime in the Boundless Market is covered; starting from a proof request to bid submission and lock in by a prover, through to proof submission and finally to proof verification.

This overview is aimed at app developers i.e., requestors, and therefore for simplicity, it will abstract some complexity away from the specifics of provers. This will be covered in its entirety at a later stage for public access testnet.
This overview is aimed at app developers i.e., requestors, and therefore for simplicity, it will abstract some complexity away from the specifics of provers. This will be covered in its entirety at a later stage.

Check warning on line 10 in developers/proof-lifecycle.mdx

View check run for this annotation

Mintlify / Mintlify Validation (boundless) - vale-spellcheck

developers/proof-lifecycle.mdx#L10

Did you really mean 'requestors'?

<Frame caption="Figure 1: A process diagram following the lifecycle of a proof chronologically in the Boundless Market.">
<img src="/images/proof-lifecycle.png" alt="The lifecycle of a Boundless Proof" />
Expand All @@ -30,15 +30,15 @@
For more info, see [Build A Program](/developers/tutorials/build), and [Getting Started with the zkVM](https://dev.risczero.com/api/zkvm/quickstart).
</Info>

The app developer begins their Boundless journey by writing an application for the zkVM in Rust. The zkVM provides a zero-knowledge proof of the correct execution of this program. A proof of execution is a receipt; it contains the output― the journal and the cryptographic proof - the seal. The seal is the cryptographic proof. In [zkVM terminology](https://dev.risczero.com/terminology#seal), the seal usually refers to a zk-STARK or SNARK. In Boundless, the seal is a Merkle inclusion proof into an aggregated proof.

Check warning on line 33 in developers/proof-lifecycle.mdx

View check run for this annotation

Mintlify / Mintlify Validation (boundless) - vale-spellcheck

developers/proof-lifecycle.mdx#L33

Did you really mean 'Merkle'?

With a zkVM program ready, the app developer will require some way to carry out proving. This can be done [locally](https://dev.risczero.com/api/generating-proofs/local-proving), but requires significant hardware investment and maintenance long-term, especially to enable parallelized GPU proving. The Boundless Market allows for anyone to request a proof, regardless of their hardware, they are known as requestors. Boundless handles the connection between requestors and provers i.e., people with dedicated and significant proving hardware, to facilitate proving in a decentralized and permissionless manner.

Check warning on line 35 in developers/proof-lifecycle.mdx

View check run for this annotation

Mintlify / Mintlify Validation (boundless) - vale-spellcheck

developers/proof-lifecycle.mdx#L35

Did you really mean 'requestors'?

Check warning on line 35 in developers/proof-lifecycle.mdx

View check run for this annotation

Mintlify / Mintlify Validation (boundless) - vale-spellcheck

developers/proof-lifecycle.mdx#L35

Did you really mean 'requestors'?

Check warning on line 35 in developers/proof-lifecycle.mdx

View check run for this annotation

Mintlify / Mintlify Validation (boundless) - vale-spellcheck

developers/proof-lifecycle.mdx#L35

Did you really mean 'permissionless'?

### 2. The App Developer (Requestor) Broadcasts a Proof Request to the Boundless Market

Check warning on line 37 in developers/proof-lifecycle.mdx

View check run for this annotation

Mintlify / Mintlify Validation (boundless) - vale-spellcheck

developers/proof-lifecycle.mdx#L37

Did you really mean 'Requestor'?

The app developer will start the proving process by requesting a proof from the Boundless Market.

Requests can be sent onchain, in a transaction to the market contract, or offchain through the order-stream server depending on the user's censorship-resistance requirements. When submitting a request offchain, they should first deposit funds to the market to cover the maximum price in their offer.

Check warning on line 41 in developers/proof-lifecycle.mdx

View check run for this annotation

Mintlify / Mintlify Validation (boundless) - vale-spellcheck

developers/proof-lifecycle.mdx#L41

Did you really mean 'onchain'?

Check warning on line 41 in developers/proof-lifecycle.mdx

View check run for this annotation

Mintlify / Mintlify Validation (boundless) - vale-spellcheck

developers/proof-lifecycle.mdx#L41

Did you really mean 'offchain'?

Check warning on line 41 in developers/proof-lifecycle.mdx

View check run for this annotation

Mintlify / Mintlify Validation (boundless) - vale-spellcheck

developers/proof-lifecycle.mdx#L41

Did you really mean 'offchain'?

The bid matching mechanism used by the market is a [reverse Dutch auction](https://en.wikipedia.org/wiki/Reverse_auction#Dutch_reverse_auctions). An application submits a proof request that contains parameters specifying the program to be proven, the input, and an offer.

Expand All @@ -48,13 +48,13 @@

| Parameter | Description |
| ---------------------------- | ---------------------------------------------------------- |
| **Minimum price** | The lowest price the requestor is willing to pay. |

Check warning on line 51 in developers/proof-lifecycle.mdx

View check run for this annotation

Mintlify / Mintlify Validation (boundless) - vale-spellcheck

developers/proof-lifecycle.mdx#L51

Did you really mean 'requestor'?
| **Maximum price** | The highest price the requestor is willing to pay. |

Check warning on line 52 in developers/proof-lifecycle.mdx

View check run for this annotation

Mintlify / Mintlify Validation (boundless) - vale-spellcheck

developers/proof-lifecycle.mdx#L52

Did you really mean 'requestor'?
| **Ramp-up start** | Defined as a timestamp. |
| **Length of ramp-up period** | Measured in seconds since the start of the bid. |
| **Lock timeout** | Measured in seconds since the start of the bid. |
| **Timeout** | Measured in seconds since the start of the bid. |
| **Lock collateral** | The slashable amount if a prover fails to deliver a proof. |

Check warning on line 57 in developers/proof-lifecycle.mdx

View check run for this annotation

Mintlify / Mintlify Validation (boundless) - vale-spellcheck

developers/proof-lifecycle.mdx#L57

Did you really mean 'slashable'?

For example, an offer might specify:

Expand Down Expand Up @@ -109,19 +109,19 @@
}
```

The predicate refers to a specific constraint on the value of the journal, the public outputs. During proof verification, the image ID and the journal are checked to make sure that the proof fulfills the request. The callback specifies a callback required to be called when the proof is delivered. The selector specifies the required proof type (e.g., Groth16 or Merkle inclusion proof).

Check warning on line 112 in developers/proof-lifecycle.mdx

View check run for this annotation

Mintlify / Mintlify Validation (boundless) - vale-spellcheck

developers/proof-lifecycle.mdx#L112

Did you really mean 'Merkle'?

### 3. Provers Bid on the Request

After a proof request is broadcast, a reverse Dutch auction runs according to the parameters specified by the offer.

From the moment the request is broadcast, the auction price is the set at the minimum price specified in the offer. During the ramp-up period, the price is increased linearly up to the maximum price. After the ramp-up period, the price stays at the max price until the request expires. At any time, a prover can submit a bid, accepting the current price and winning the auction. Because the price only increases, the first bid is the best price for the requestor.

Check warning on line 118 in developers/proof-lifecycle.mdx

View check run for this annotation

Mintlify / Mintlify Validation (boundless) - vale-spellcheck

developers/proof-lifecycle.mdx#L118

Did you really mean 'requestor'?

When the prover submits their bid, the auction ends and they "lock" the request. Once a request is locked, only that prover can be paid for submitting a proof. This ensures that the prover will not waste their compute resources, as they know no other prover can take the request instead. By increasing market efficiency, this lowers prices.

However, locking a request requires the prover to put up collateral, which will be slashed if they fail to deliver a proof before the request timeout. Slashed collateral is used to incentivize other provers to fulfill the request in the case where the locker fails to deliver the proof. Requestors choose the collateral value according to their application's requirements. A low collateral value may result in a better price, however there would be less incentive for another prover to fulfill the request in the case where the locker fails to deliver the proof. A higher collateral value may decrease the chance an unreliable prover will lock the request.

Check warning on line 122 in developers/proof-lifecycle.mdx

View check run for this annotation

Mintlify / Mintlify Validation (boundless) - vale-spellcheck

developers/proof-lifecycle.mdx#L122

Did you really mean 'Requestors'?

An unlocked request can be directly fulfilled, without first being locked. When this happens, the prover will be paid according to the auction price at that moment. Applications may disable locking entirely by setting the collateral amount impossibly high (e.g., higher than the total supply of the collateral token), ensuring that no prover can lock the request and disincentivizing others from proving.

Check warning on line 124 in developers/proof-lifecycle.mdx

View check run for this annotation

Mintlify / Mintlify Validation (boundless) - vale-spellcheck

developers/proof-lifecycle.mdx#L124

Did you really mean 'disincentivizing'?

Provers will calculate the minimum price at which they are willing to prove a request based on a number of factors. These can include:

Expand All @@ -130,7 +130,7 @@
- Timeout and LockTimeout length, determining how long they have to complete the proof.
- Input and program size, determining bandwidth costs to download the request.

It is also worth noting that the prover's software will download the program, from the request's image URL, and execute it to determine the number of [cycles](https://dev.risczero.com/terminology#clock-cycles) and estimate the proving load.

Check warning on line 133 in developers/proof-lifecycle.mdx

View check run for this annotation

Mintlify / Mintlify Validation (boundless) - vale-spellcheck

developers/proof-lifecycle.mdx#L133

Did you really mean 'prover's'?

_If the program fails to execute (e.g., the guest panics) the prover will not bid._

Expand All @@ -140,25 +140,25 @@

#### Provers Batch Proof Requests

The proof submitted by the prover is an aggregated proof, which proves a batch of program executions. Why is Boundless designed like this? The direct goal of aggregation is to amortize the cost of expensive proof verification onchain, both for the requestor and the prover.

Check warning on line 143 in developers/proof-lifecycle.mdx

View check run for this annotation

Mintlify / Mintlify Validation (boundless) - vale-spellcheck

developers/proof-lifecycle.mdx#L143

Did you really mean 'onchain'?

Check warning on line 143 in developers/proof-lifecycle.mdx

View check run for this annotation

Mintlify / Mintlify Validation (boundless) - vale-spellcheck

developers/proof-lifecycle.mdx#L143

Did you really mean 'requestor'?

Let's start with an assumption: the prover has locked themselves into a number of individual proof requests. A naive implementation would be to have the prover generate a proof for each proof request, send each proof onchain and pay gas for each verification. This would work, but it would cause a lot of needless expense; the prover has to send each individual proof onchain to the market contract. This will rack up expensive gas costs, affecting the efficiency of the market.

Check warning on line 145 in developers/proof-lifecycle.mdx

View check run for this annotation

Mintlify / Mintlify Validation (boundless) - vale-spellcheck

developers/proof-lifecycle.mdx#L145

Did you really mean 'onchain'?

Check warning on line 145 in developers/proof-lifecycle.mdx

View check run for this annotation

Mintlify / Mintlify Validation (boundless) - vale-spellcheck

developers/proof-lifecycle.mdx#L145

Did you really mean 'onchain'?

Starting with the provers, a clear solution is to batch the proof requests together. Instead of proving one request, sending that proof onchain, and moving onto the next request, the prover can work on multiple proof requests and prove each one without interruption, submitting one aggregated proof for the whole batch.

Check warning on line 147 in developers/proof-lifecycle.mdx

View check run for this annotation

Mintlify / Mintlify Validation (boundless) - vale-spellcheck

developers/proof-lifecycle.mdx#L147

Did you really mean 'onchain'?

#### Prover Submits the Requested Proof On-Chain

In order to fulfill a batch of requests, and receive payment, the prover provides an aggregated proof. This aggregated proof is constructed as a Merkle tree, where the leaves are the proofs for the individual requests in the batch. At the root is a single Groth16 proof that attests to the validity of all proofs in the batch. Each individual request has a Merkle inclusion proof linking it to the root. Once the root is verified, the result is cached and the Merkle inclusion proofs are cheap to verify onchain.

Check warning on line 151 in developers/proof-lifecycle.mdx

View check run for this annotation

Mintlify / Mintlify Validation (boundless) - vale-spellcheck

developers/proof-lifecycle.mdx#L151

Did you really mean 'Merkle'?

Check warning on line 151 in developers/proof-lifecycle.mdx

View check run for this annotation

Mintlify / Mintlify Validation (boundless) - vale-spellcheck

developers/proof-lifecycle.mdx#L151

Did you really mean 'Merkle'?

Check warning on line 151 in developers/proof-lifecycle.mdx

View check run for this annotation

Mintlify / Mintlify Validation (boundless) - vale-spellcheck

developers/proof-lifecycle.mdx#L151

Did you really mean 'Merkle'?

Check warning on line 151 in developers/proof-lifecycle.mdx

View check run for this annotation

Mintlify / Mintlify Validation (boundless) - vale-spellcheck

developers/proof-lifecycle.mdx#L151

Did you really mean 'onchain'?

When the prover submits the aggregated proof, the Market contract verifies it and pays the prover if all conditions are met. At the same time, the contract emits an event that signals to the requestor that their request is fulfilled, and provides the Merkle inclusion proof.

Check warning on line 153 in developers/proof-lifecycle.mdx

View check run for this annotation

Mintlify / Mintlify Validation (boundless) - vale-spellcheck

developers/proof-lifecycle.mdx#L153

Did you really mean 'requestor'?

Check warning on line 153 in developers/proof-lifecycle.mdx

View check run for this annotation

Mintlify / Mintlify Validation (boundless) - vale-spellcheck

developers/proof-lifecycle.mdx#L153

Did you really mean 'Merkle'?

:::note[Note]
<Note>
The requestor can use this Merkle inclusion proof as an effective representation of a verified execution, and use it as such in their application.
:::
</Note>

### 5. The App Developer Retrieves Their Proof, to Use in Their Application

When the prover fulfills their request, the requestor (the app developer) will receive their proof.

Check warning on line 161 in developers/proof-lifecycle.mdx

View check run for this annotation

Mintlify / Mintlify Validation (boundless) - vale-spellcheck

developers/proof-lifecycle.mdx#L161

Did you really mean 'requestor'?

{/* <StripRustCodeComments> */}
```rust
Expand All @@ -185,7 +185,7 @@
```
{/* </StripRustCodeComments> */}

The journal is the public output of the program, and the seal is the cryptographic proof. Since Boundless uses aggregated proofs, the seal will be a Merkle inclusion proof, but verification works the same as for Groth16: the application contract sends the seal to the verifier contract. We recommend using the [RiscZeroVerifierRouter](https://dev.risczero.com/api/blockchain-integration/contracts/verifier), which will allow your application to seamlessly use both Groth16 and Merkle inclusion proofs. Below is an example from the Boundless Foundry Template:

Check warning on line 188 in developers/proof-lifecycle.mdx

View check run for this annotation

Mintlify / Mintlify Validation (boundless) - vale-spellcheck

developers/proof-lifecycle.mdx#L188

Did you really mean 'Merkle'?

Check warning on line 188 in developers/proof-lifecycle.mdx

View check run for this annotation

Mintlify / Mintlify Validation (boundless) - vale-spellcheck

developers/proof-lifecycle.mdx#L188

Did you really mean 'Merkle'?

```solidity
/// @notice Set the even number stored on the contract. Requires a RISC Zero proof that the number is even.
Expand Down
4 changes: 2 additions & 2 deletions developers/quick-start.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -51,23 +51,23 @@

## Set up your environment variables

Export your Sepolia wallet private key as an environment variable (making sure it has enough funds), and export a valid RPC URL (you can use the public one provided):

Check warning on line 54 in developers/quick-start.mdx

View check run for this annotation

Mintlify / Mintlify Validation (boundless) - vale-spellcheck

developers/quick-start.mdx#L54

Did you really mean 'Sepolia'?

```bash
export RPC_URL="https://ethereum-sepolia-rpc.publicnode.com"
export PRIVATE_KEY="YOUR_PRIVATE_KEY"
```

You'll also need a deployment of the EvenNumber contract. You can use a predeployed contract on Sepolia:

Check warning on line 61 in developers/quick-start.mdx

View check run for this annotation

Mintlify / Mintlify Validation (boundless) - vale-spellcheck

developers/quick-start.mdx#L61

Did you really mean 'predeployed'?

Check warning on line 61 in developers/quick-start.mdx

View check run for this annotation

Mintlify / Mintlify Validation (boundless) - vale-spellcheck

developers/quick-start.mdx#L61

Did you really mean 'Sepolia'?

```bash
export EVEN_NUMBER_ADDRESS="0xE819474E78ad6e1C720a21250b9986e1f6A866A3"
```
:::note[Deploy your own version of EvenNumber.sol]
<Note>
If you'd like to deploy your own version of the `EvenNumber.sol` contract, please run:
`cargo build && forge script contracts/scripts/Deploy.s.sol --rpc-url ${RPC_URL:?} --broadcast -vv`
after which you can export your deployed contract address to EVEN_NUMBER_ADDRESS.
:::
</Note>

## Run the example app

Expand All @@ -87,7 +87,7 @@
2025-07-01T10:37:26.144716Z INFO app: Waiting for request 2008ac70b2920c9a345ea7fff1ded1fd4302bdf06516a20c to be fulfilled
```

and the app will query the status of the proof request until it is fulfilled. Once it fulfilled, you'll see output confirming the receipt of the proof, and confirmation of the transaction sent onchain calling the `set` function with the proof as calldata:

Check warning on line 90 in developers/quick-start.mdx

View check run for this annotation

Mintlify / Mintlify Validation (boundless) - vale-spellcheck

developers/quick-start.mdx#L90

Did you really mean 'onchain'?

Check warning on line 90 in developers/quick-start.mdx

View check run for this annotation

Mintlify / Mintlify Validation (boundless) - vale-spellcheck

developers/quick-start.mdx#L90

Did you really mean 'calldata'?

```bash Terminal
2025-07-01T10:39:30.164558Z INFO app: Request 2008ac70b2920c9a345ea7fff1ded1fd4302bdf06516a20c fulfilled
Expand All @@ -97,6 +97,6 @@
2025-07-01T10:39:42.902820Z INFO app: The number variable for contract at address: 0xe819474e78ad6e1c720a21250b9986e1f6a866a3 is set to 4
```

You've now requested your first proof from Boundless, received that proof and sent that proof onchain for verification. Effectively, you've offloaded computation offchain with the same trust model as onchain, all thanks to the power of ZK. This is the true power of verifiable compute.

Check warning on line 100 in developers/quick-start.mdx

View check run for this annotation

Mintlify / Mintlify Validation (boundless) - vale-spellcheck

developers/quick-start.mdx#L100

Did you really mean 'onchain'?

Check warning on line 100 in developers/quick-start.mdx

View check run for this annotation

Mintlify / Mintlify Validation (boundless) - vale-spellcheck

developers/quick-start.mdx#L100

Did you really mean 'offchain'?

Check warning on line 100 in developers/quick-start.mdx

View check run for this annotation

Mintlify / Mintlify Validation (boundless) - vale-spellcheck

developers/quick-start.mdx#L100

Did you really mean 'onchain'?

To learn more about each individual step, please refer to [Build A Program](/developers/tutorials/build). If you want to do some further development on your local fork of the Boundless Foundry Template, please read the [Development](https://github.com/boundless-xyz/boundless-foundry-template?tab=readme-ov-file#development) section on the README.
10 changes: 4 additions & 6 deletions developers/smart-contracts/deployments.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -8,12 +8,12 @@

| Network | $ZKC Address |
| ---------------- | --------------------------------------------- |
| Ethereum Mainnet | `0x000006c2A22ff4A44ff1f5d0F2ed65F781F55555` [(etherscan)](https://etherscan.io/address/0x000006c2A22ff4A44ff1f5d0F2ed65F781F55555)|

Check warning on line 11 in developers/smart-contracts/deployments.mdx

View check run for this annotation

Mintlify / Mintlify Validation (boundless) - vale-spellcheck

developers/smart-contracts/deployments.mdx#L11

Did you really mean 'Ethereum'?

Check warning on line 11 in developers/smart-contracts/deployments.mdx

View check run for this annotation

Mintlify / Mintlify Validation (boundless) - vale-spellcheck

developers/smart-contracts/deployments.mdx#L11

Did you really mean 'Mainnet'?
| Base Mainnet | `0xAA61bB7777bD01B684347961918f1E07fBbCe7CF` [(basescan)](https://basescan.org/address/0xaa61bb7777bd01b684347961918f1e07fbbce7cf)|

Check warning on line 12 in developers/smart-contracts/deployments.mdx

View check run for this annotation

Mintlify / Mintlify Validation (boundless) - vale-spellcheck

developers/smart-contracts/deployments.mdx#L12

Did you really mean 'Mainnet'?

## Market Contracts

### Mainnets

Check warning on line 16 in developers/smart-contracts/deployments.mdx

View check run for this annotation

Mintlify / Mintlify Validation (boundless) - vale-spellcheck

developers/smart-contracts/deployments.mdx#L16

Did you really mean 'Mainnets'?

#### Base

Expand All @@ -25,7 +25,7 @@
| `CollateralToken` | `0xaa61bb7777bd01b684347961918f1e07fbbce7cf` [(basescan)](https://basescan.org/address/0xaa61bb7777bd01b684347961918f1e07fbbce7cf)|


### Testnets
{/* ### Testnets

<Warning>
These addresses may change at any time!
Expand All @@ -47,22 +47,20 @@
| `BoundlessMarket` | `0xc211b581cb62e3a6d396a592bab34979e1bbba7d` [(etherscan)](https://sepolia.etherscan.io/address/0xc211b581cb62e3a6d396a592bab34979e1bbba7d) |
| `RiscZeroVerifierRouter` | `0x925d8331ddc0a1F0d96E68CF073DFE1d92b69187` [(etherscan)](https://sepolia.etherscan.io/address/0x925d8331ddc0a1F0d96E68CF073DFE1d92b69187) |
| `SetVerifier` | `0xcb9D14347b1e816831ECeE46EC199144F360B55c` [(etherscan)](https://sepolia.etherscan.io/address/0xcb9D14347b1e816831ECeE46EC199144F360B55c) |
| `CollateralToken` | `0xb4fc69a452d09d2662bd8c3b5bb756902260ae28` [(etherscan)](https://sepolia.etherscan.io/address/0xb4fc69a452d09d2662bd8c3b5bb756902260ae28) |
| `CollateralToken` | `0xb4fc69a452d09d2662bd8c3b5bb756902260ae28` [(etherscan)](https://sepolia.etherscan.io/address/0xb4fc69a452d09d2662bd8c3b5bb756902260ae28) | */}

## Order Stream

The Order Stream is a service that relays your requests to provers offchain.
When a request is [submitted to the order stream](/developers/tutorials/request#offchain), it is broadcast to all provers.

### Mainnets

| Network | Order Stream URL |
| ---------------- | --------------------------------------------- |
| Base Mainnet | `https://base-mainnet.boundless.network` |

### Testnets
{/* ### Testnets

| Network | Order Stream URL |
| ---------------- | --------------------------------------------- |
| Ethereum Sepolia | `https://eth-sepolia.boundless.network` |
| Base Sepolia | `https://base-sepolia.boundless.network` |
| Base Sepolia | `https://base-sepolia.boundless.network` | */}
Loading