Add docs on claim digest match and blake3

developers/tutorials/proof-types.mdx

@@ -1,29 +1,29 @@
 ---
 title: Proof Types
 description: Boundless supports different types of proof delivery, from efficient merkle inclusion proofs to raw Groth16 proofs for cross-chain verification.
 icon: file-pen
 ---
 
 
 ## Default: Merkle Inclusion Proofs
 
 By default, Boundless delivers proofs on-chain as merkle inclusion proofs:
 
 1. Proofs are batched together are aggregated into a single Groth16 proof.
 2. The aggregated proof is verified once on-chain
 3. Individual proofs are verified through cheap merkle inclusion proofs into this root
 
 This design is what makes Boundless cost-effective for on-chain verification.
 
 ## Requesting a specific proof type
 
 While merkle inclusion proofs are efficient for on-chain verification, there may be cases where you need to access the underlying proof instead of a merkle inclusion proof. For example:
 
 1. Cross-chain verification where you need to verify the proof on a different chain
 2. Integration with other systems that expect a specific proof type
 3. Custom verification logic that requires the full proof
 
 Boundless supports requesting a raw Groth16 proof instead of a merkle inclusion proof. You can specify this in your proof request by setting the `proof_type` to `ProofType::Groth16`:
 
 {/* <StripRustCodeComments> */}
 ```rust
@@ -51,18 +51,54 @@
 ```
 {/* </StripRustCodeComments> */}
 
+In addition, Boundless also supports requesting a Blake3 Groth16 proof. This proof type allows for proofs to be verified in environments where SHA2 hashing is impossible or expensive (e.g. BitVM). You can specify this in your proof request by setting the `proof_type` to  `ProofType::Blake3Groth16`:
+Note: Blake3 Groth16 proofs require is only supported with the `ClaimDigestMatch` predicate, meaning that you should only use this if you do not require the journal to be delivered on-chain. 
+{/* <StripRustCodeComments> */}
+```rust
+# use alloy_primitives::utils::parse_ether;
+# use boundless_market::{Client, request_builder::OfferParams};
+# use url::Url;
+# async fn create_blake3_groth16_request(
+#     client: Client,
+#     program: &'static [u8],
+#     input: &[u8]
+# ) -> anyhow::Result<()> {
+let request = client.new_request()
+    .with_program(program)
+    .with_stdin(input)
+    .with_blake3_groth16_proof()  // Request Blake3 Groth16 proof
+    .with_offer(
+        OfferParams::builder()
+            .min_price(parse_ether("0.001")?)
+            .max_price(parse_ether("0.002")?)
+            .timeout(1000)
+            .lock_timeout(1000)
+    );
+# Ok(())
+# }
+```
+{/* </StripRustCodeComments> */}
+
 ## Considerations
 
 When choosing between proof types, consider:
 
 1. **Gas Costs**
    - Merkle inclusion proofs are much cheaper to verify on-chain
    - Raw Groth16 proofs require full SNARK verification each time. This will increase the price of the proof
 
 2. **Use Case Requirements**
    - If you only need on-chain verification, use the default merkle inclusion proof
    - If you need cross-chain verification or raw proof data, use Groth16
    - If you need to compose the proof by verifying it within another zkVM guest program, use Groth16
+   - If you don't need the journal to be authenticated, consider using the ClaimDigestMatch predicate
+
+### Predicate Types
+When constructing a Proof Request, we can set a `Requirement` with some predicate type. The available predicate types are `DigestMatch`, `PrefixMatch`, and `ClaimDigestMatch`. 
+These predicates ensure that the journal of our guest program match what we expect. 
+Specifying the `DigestMatch` and `PrefixMatch` predicates will require delivery of the journal when a request is being fulfilled. 
+There are times where we are building an application that does not require the journal to be delivered on-chain.
+If this is the case, `ClaimDigestMatch` will save potentially a lot of gas, since Provers will not need to submit potentially large journals on-chain.
 
 ## Example: Proof Composition using Proof Types