> ## Documentation Index
> Fetch the complete documentation index at: https://docs.boundless.network/llms.txt
> Use this file to discover all available pages before exploring further.

# Proof Types

> Boundless supports different types of proof delivery, from efficient merkle inclusion proofs to raw Groth16 proofs for cross-chain verification.

## 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.

## Options: 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.

### Request a Groth16 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`:

```rust theme={null}
let request = client.new_request()
    .with_program(program)
    .with_stdin(input)
    .with_groth16_proof();  // Request raw Groth16 proof
```

### Request a Blake3 Groth16 Proof

<Note>
  Blake3 Groth16 proofs are 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. Blake3 Groth16 proofs also require the
  journal to be of size 32 bytes.
</Note>

Boundless 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`:

```rust theme={null}
let request = client
    .new_request()
    .with_program(program)
    .with_stdin(input)
    .with_blake3_groth16_proof();  // Request Blake3 Groth16 proof
```

## 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 on-chain, consider using `ClaimDigestMatch` to save gas (see [Journal Delivery](#journal-delivery-onchain))
   * If your journal size exceeds 10KB, use `ClaimDigestMatch` and design your application to store journals off-chain (see [Journal Size Limits](#journal-size-limits))

### Journal Delivery Onchain

When a proof request is fulfilled, the journal can optionally be delivered on-chain. This is controlled by the predicate type you specify in your `Requirement`:

* **`DigestMatch` / `PrefixMatch`** require the journal to be delivered on-chain when the request is fulfilled.
* **`ClaimDigestMatch`** does not require journal delivery. Only the claim digest is verified on-chain.

If your application doesn't need the journal on-chain, using `ClaimDigestMatch` can lead to lower prices since provers won't need to submit potentially large journal data.

#### Journal Size Limits

To prevent griefing attacks where requestors force provers to post expensive amounts of calldata on-chain, there is a **10KB limit** on journal size for on-chain delivery. Provers will ignore requests that require journals larger than 10KB to be posted on-chain.

If your journal exceeds 10KB, use `ClaimDigestMatch` and design your application to store journals off-chain (e.g. via IPFS, a blob storage service, or your own backend).

## Example: Proof Composition using Proof Types

In the [Proof Composition example](https://github.com/boundless-xyz/boundless/tree/main/examples/proof-composition), we demonstrate how to compose a proof from multiple proofs.

Composing a proof requires us to verify a previously generated Groth16 proof within the zkVM guest program. This requires us to request a raw Groth16 proof from the Boundless Market.

In the composition example, we first request a raw Groth16 proof from the Boundless Market using the `ECHO` guest program.

```rust theme={null}
let request = client.new_request()
    .with_program(program)
    .with_stdin(input)
    .with_groth16_proof();  // Request raw Groth16 proof
```

We then provide the Groth16 proof as input to the `IDENTITY` zkVM guest program, and verify the proof.

```rust theme={null}
use risc0_zkvm::guest::env;
use risc0_zkvm::{Digest, Receipt};

fn main() {
    let (image_id, receipt): (Digest, Receipt) = env::read();
    let claim = receipt.claim().unwrap();
    receipt.verify(image_id).unwrap();
    ....
}
```