Merge pull request #26 from boundless-xyz/Updated-Priority-List-Language

Priority list language update

Author: sasha-computer

developers/tutorials/request.mdx

@@ -1,7 +1,7 @@
 ---
-title: Request a Proof
-description: Request a proof from the Boundless market.
-icon: hand-point-up
+title: "Request a Proof"
+description: "Request a proof from the Boundless market."
+icon: "hand-point-up"
 ---
 
 import { PriorityRequestorForm } from '/snippets/priority-requestor-form.jsx';
@@ -16,33 +16,26 @@ Therefore, this page is split into two sections:
 - The second section, [Request Configuration](#request-configuration), covers all available configuration options for the 5% of requests that require fine-tuning.
 
 <Note>
-  The *Sending a Request* section uses the counter example as a template, its
-  source code can be found at:
-  [boundless/examples/counter](https://github.com/boundless-xyz/boundless/tree/main/examples/counter)
+  The _Sending a Request_ section uses the counter example as a template, its source code can be found at: [boundless/examples/counter](https://github.com/boundless-xyz/boundless/tree/main/examples/counter)
 </Note>
 
 ## Sending a Request
 
 <Note>
-  If you want to submit a one-off request via the Boundless CLI, please see
-  [Requesting a Proof via the Boundless
+  If you want to submit a one-off request via the Boundless CLI, please see [Requesting a Proof via the Boundless
   CLI](/developers/tooling/cli#requesting-a-proof-via-the-boundless-cli).
 </Note>
 
 ### 1. Setting environment variables
 
 <Tip>
-  We recommend using [clap](https://crates.io/crates/clap) to parse these
-  environment variables, as seen in
-  [apps/L37-52](https://github.com/boundless-xyz/boundless/blob/cdc2435b6119a009c2cc73dc227a250bee7594fc/examples/counter/apps/src/main.rs#L37-L52).
+  We recommend using [clap](https://crates.io/crates/clap) to parse these environment variables, as seen in [apps/L37-52](https://github.com/boundless-xyz/boundless/blob/cdc2435b6119a009c2cc73dc227a250bee7594fc/examples/counter/apps/src/main.rs#L37-L52).
 </Tip>
 
 #### Blockchain
 
 <Tip>
-  We recommend using Alchemy for your RPC URL during testing; their free tier is
-  more than enough to test requesting a proof. Receiving proofs requires event
-  queries, which public RPCs may not support.
+  We recommend using Alchemy for your RPC URL during testing; their free tier is more than enough to test requesting a proof. Receiving proofs requires event queries, which public RPCs may not support.
 </Tip>
 
 Since we are submitting requests onchain, we will need private key for a wallet with sufficient funds on Sepolia, and a working RPC URL:
@@ -55,12 +48,11 @@ export PRIVATE_KEY="abcdef..."
 #### Storage Provider
 
 <Tip>
-For this tutorial, we suggest using a Pinata API key which will upload your program at runtime.
+  For this tutorial, we suggest using a Pinata API key which will upload your program at runtime.
 
-If you do not want to use an API key, or if you want to use a provider other than Pinata, you can pre-upload you program to a public URL (this could be hosted via Pinata or any other service).
-
-To see more information about this option, please read [No Storage Provider](/developers/tutorials/request#no-storage-provider).
+  If you do not want to use an API key, or if you want to use a provider other than Pinata, you can pre-upload you program to a public URL (this could be hosted via Pinata or any other service).
 
+  To see more information about this option, please read [No Storage Provider](/developers/tutorials/request#no-storage-provider).
 </Tip>
 
 To make a program, and its inputs, accessible to provers, they need to be hosted at a public URL. We recommend using IPFS for storage, particularly via [Pinata](https://pinata.cloud), as their free tier comfortably covers most Boundless use cases.
@@ -200,13 +192,11 @@ let request = client.new_request()
 ### Inputs
 
 <Tip>
-  When working with trusted provers, you can store inputs in *Amazon S3* and
-  restrict access via AWS S3's permission management - [Sensitive Inputs
+  When working with trusted provers, you can store inputs in _Amazon S3_ and restrict access via AWS S3's permission management - [Sensitive Inputs
   tutorial](/developers/tutorials/sensitive-inputs).
 </Tip>
 
-To execute and run proving, the prover requires the inputs of the program.
-Inputs can be provides as a public URL, or "inline" by including them directly in the request.
+To execute and run proving, the prover requires the inputs of the program. Inputs can be provides as a public URL, or "inline" by including them directly in the request.
 
 Program inputs are uploaded to the same storage provider. This can be done manually like so:
 
@@ -226,8 +216,7 @@ let (request_id, expires_at) = client.submit_onchain(request).await?;
 
 In this example, inputs are included inline if they are small (e.g. less than 1 kB) or uploaded to a public URL first if they are large.
 
-When submitting requests onchain with inline inputs, this will cost more gas if the inputs are large.
-The offchain order-stream service also places limits on the size of inline input.
+When submitting requests onchain with inline inputs, this will cost more gas if the inputs are large. The offchain order-stream service also places limits on the size of inline input.
 
 ### Proof Types
 
@@ -264,9 +253,7 @@ let request = client
 ```
 
 <Note>
-  Blake3 Groth16 proofs are only supported with the `ClaimDigestMatch`
-  predicate, meaning you should only use this if you do not require the journal
-  to be delivered on-chain. Additionally, the journal must be exactly 32 bytes.
+  Blake3 Groth16 proofs are only supported with the `ClaimDigestMatch` predicate, meaning you should only use this if you do not require the journal to be delivered on-chain. Additionally, the journal must be exactly 32 bytes.
 </Note>
 
 For more details on proof types and when to use each, see [Proof Types](/developers/tutorials/proof-types).
@@ -290,9 +277,7 @@ let (request_id, expires_at) = client.submit_onchain(request).await?; // [!code
 #### Offchain
 
 <Note>
-  When using offchain requests, you are required to deposit funds into the
-  Boundless market contract before you can make any proof requests. This can be
-  done with the [Boundless CLI](/developers/tooling/cli#requestor).
+  When using offchain requests, you are required to deposit funds into the Boundless market contract before you can make any proof requests. This can be done with the [Boundless CLI](/developers/tooling/cli#requestor).
 </Note>
 
 To submit a request offchain, we use:
@@ -322,7 +307,6 @@ There are two ways to configure auction parameters:
   - You want to configure cycle-based pricing that applies to all requests
   - You need to adjust gas estimates or other calculation parameters
   - You want consistent pricing logic across multiple requests
-
 - Use `with_offer` when:
   - You need to override the automatic calculations for a specific request
   - You want to set exact prices rather than using cycle-based and gas-price calculations
@@ -384,10 +368,8 @@ With this configuration, the SDK will execute the request to estimate cycles and
 ### Funding Modes
 
 <Warning>
-  For most use-cases, we recommend using the default setting of `Always`, which
-  ensures that your requests will always be fully funded and thus can be
-  fulfilled by the network. *Setting any other funding mode is considered an
-  advanced feature*, and may lead to a degredation of proof fufillment rate.
+  For most use-cases, we recommend using the default setting of `Always`, which ensures that your requests will always be fully funded and thus can be fulfilled by the network. _Setting any other funding mode is considered an
+  advanced feature_, and may lead to a degredation of proof fufillment rate.
 </Warning>
 
 When submitting requests onchain, the Boundless Market SDK needs to fund the request with ETH to cover the `max_price` (see [ Auction Parameters](/developers/tutorials/auction#what-auction-parameters-are-configurable)) of the proof.
@@ -415,8 +397,7 @@ let funding_mode = FundingMode::Always;
 ```
 
 <Tip>
-  If your balance is more than 3x the `max_price`, the SDK will log a warning
-  suggesting you consider a different funding mode to avoid overfunding.
+  If your balance is more than 3x the `max_price`, the SDK will log a warning suggesting you consider a different funding mode to avoid overfunding.
 </Tip>
 
 #### Never
@@ -428,8 +409,7 @@ let funding_mode = FundingMode::Never;
 ```
 
 <Warning>
-  When using `Never` mode, you must ensure your onchain balance is sufficient to
-  cover the `max_price` of each request. Otherwise, requests may fail.
+  When using `Never` mode, you must ensure your onchain balance is sufficient to cover the `max_price` of each request. Otherwise, requests may fail.
 </Warning>
 
 #### AvailableBalance
@@ -452,9 +432,7 @@ let funding_mode = FundingMode::BelowThreshold(threshold);
 ```
 
 <Tip>
-  Set the threshold appropriately to avoid underfunding. The threshold should be
-  at least as large as your typical `max_price` to ensure requests can be funded
-  when needed.
+  Set the threshold appropriately to avoid underfunding. The threshold should be at least as large as your typical `max_price` to ensure requests can be funded when needed.
 </Tip>
 
 #### MinMaxBalance
@@ -473,6 +451,5 @@ let funding_mode = FundingMode::MinMaxBalance {
 This mode should minimize the number of onchain fundings while ensuring sufficient balance is maintained. It's ideal for applications that make frequent requests and want to optimize gas costs by reducing the number of funding transactions.
 
 <Tip>
-  When the balance drops below `min_balance`, the SDK will fund up to
-  `max_balance` in a single transaction, reducing the need for frequent top-ups.
-</Tip>
+  When the balance drops below `min_balance`, the SDK will fund up to `max_balance` in a single transaction, reducing the need for frequent top-ups.
+</Tip>

snippets/priority-requestor-form.jsx

@@ -10,8 +10,8 @@ export const PriorityRequestorForm = () => {
         <div className="text-sm text-amber-800 dark:text-amber-300 space-y-3">
           <p>
             For the best experience, we offer a priority requestor list that
-            provides optimal performance for proof requests. Fill out the form
-            below to be considered for testing credits and priority access.
+            provides optimal performance for requestors looking to go to production. Fill out the form
+            below to be considered for developer assistance.
           </p>
         </div>