update form language, fix some callouts

developers/kailua/quick-start.mdx

@@ -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.
 
 Before you get started, you will need the following dependencies installed:
 
@@ -17,37 +17,37 @@
 - [svm](https://github.com/alloy-rs/svm-rs)
 - [foundry](https://book.getfoundry.sh/getting-started/installation)
 
 ## Clone the Kailua repo
 
 ```bash
 git clone https://github.com/risc0/kailua.git && cd kailua
 ```
 
 ## Run the following commands to spin up a devnet
 
 You can deploy a local optimism devnet equipped with Kailua through the following commands:
 
 1. `just devnet-fetch`
     * Fetches `v1.9.1` of the `optimism` monorepo.
 2. `just devnet-build`
     * Builds the local cargo and foundry projects.
 3. `just devnet-up`
     * Starts a local OP Stack devnet using docker.
     * Dumps the output into `devnetlog.txt` for inspection.
 4. `just devnet-upgrade`
     * Upgrades the devnet to use the `KailuaGame` contract.
     * Assumes the default values of the local optimism devnet, but can take parameters.
 5. `just devnet-propose`
     * Launches the Kailua proposer.
     * This runs the sequences, which periodically creates new `KailuaGame` instances.
 6. `just devnet-validate`
     * Launches the Kailua 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.
     * Tests the proposer's canonical chain tracking functionality.
 8. After you're done:
     * `just devnet-down` to stop the running docker containers.

developers/proof-lifecycle.mdx

@@ -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.
 
 <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" />
@@ -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.
 
 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.
 
 ### 2. The App Developer (Requestor) Broadcasts a Proof Request to the Boundless Market
 
 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.
 
 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.
 
@@ -48,13 +48,13 @@
 
 | Parameter                    | Description                                                |
 | ---------------------------- | ---------------------------------------------------------- |
 | **Minimum price**            | The lowest price the requestor is willing to pay.          |
 | **Maximum price**            | The highest price the requestor is willing to pay.         |
 | **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. |
 
 For example, an offer might specify:
 
@@ -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).
 
 ### 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.
 
 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.
 
 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.
 
 Provers will calculate the minimum price at which they are willing to prove a request based on a number of factors. These can include:
 
@@ -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.
 
 _If the program fails to execute (e.g., the guest panics) the prover will not bid._
 
@@ -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.
 
 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.
 
 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.
 
 #### 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.
 
 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.
 
-:::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.
 
 {/* <StripRustCodeComments> */}
 ```rust
@@ -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:
 
 ```solidity
 /// @notice Set the even number stored on the contract. Requires a RISC Zero proof that the number is even.

developers/quick-start.mdx

@@ -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):
 
 ```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:
 
 ```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
 
@@ -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:
 
 ```bash Terminal
 2025-07-01T10:39:30.164558Z  INFO app: Request 2008ac70b2920c9a345ea7fff1ded1fd4302bdf06516a20c fulfilled
@@ -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.
 
 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.

developers/smart-contracts/deployments.mdx

@@ -8,12 +8,12 @@
 
 | Network          | $ZKC Address                                 |
 | ---------------- | --------------------------------------------- |
 | Ethereum Mainnet | `0x000006c2A22ff4A44ff1f5d0F2ed65F781F55555` [(etherscan)](https://etherscan.io/address/0x000006c2A22ff4A44ff1f5d0F2ed65F781F55555)|
 | Base Mainnet     | `0xAA61bB7777bD01B684347961918f1E07fBbCe7CF` [(basescan)](https://basescan.org/address/0xaa61bb7777bd01b684347961918f1e07fbbce7cf)|
 
 ## Market Contracts
 
 ### Mainnets
 
 #### Base
 
@@ -25,7 +25,7 @@
 | `CollateralToken`        | `0xaa61bb7777bd01b684347961918f1e07fbbce7cf` [(basescan)](https://basescan.org/address/0xaa61bb7777bd01b684347961918f1e07fbbce7cf)|
 
 
-### Testnets
+{/* ### Testnets
 
 <Warning>
 These addresses may change at any time!
@@ -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`        | */}