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

# Pipeline Stages

> Dry run, fetch-proofs, and sound run end-to-end

HDP execution is split into three stages so proof collection and deterministic execution stay clean and debuggable.

## Why three stages

You can only fetch proofs after you know which keys your module touched.\
So HDP first discovers keys, then fetches proofs, then replays computation offline.

## Flow

```text theme={null}
+-----------+    +-----------+    +-----------+
| Dry Run   | -> | Fetcher   | -> | Sound Run |
| RPC keys  |    | Proofs    |    | Verify run|
+-----------+    +-----------+    +-----------+

dry_run_output.json -> proofs.json -> outputs
```

## Stage 1: Dry run

Purpose:

* Execute module against live RPCs
* Collect every key used by EVM/Starknet/injected-state/unconstrained handlers

Main output:

* `dry_run_output.json`

Command:

```bash theme={null}
hdp dry-run -m <module.compiled_contract_class.json> --print_output
```

## Stage 2: Fetch proofs

Purpose:

* Build proof payloads from keys found in stage 1

Proof sources:

* MMR proofs for headers (via [Herodotus Indexer](/data-structure-indexer-api/introduction))
* MPT/Patricia proofs for state (see [Verification model](/data-processor/verification))
* Injected-state proofs from the [state server](/data-processor/state-server)
* Unconstrained payloads (for example bytecode blobs validated later by hash)

Main output:

* `proofs.json`

Command:

```bash theme={null}
hdp fetch-proofs --inputs dry_run_output.json --output proofs.json
```

Useful options:

* `--mmr-hasher-config <path>`
* `--mmr-deployment-config <path>`

## Stage 3: Sound run

Purpose:

* Verify proofs
* Execute the same module offline (no RPC calls)
* Produce commitments for downstream verification and settlement workflows

Main outputs:

* `task_hash`
* `output_root`
* `mmr_metas`

Command:

```bash theme={null}
hdp sound-run -m <module.compiled_contract_class.json> --proofs proofs.json --print_output
```

Proof-mode options:

* `--proof_mode`
* `--cairo_pie <path>`
* `--stwo_prover_input <path>` (when CLI is built with [STWO support](/data-processor/proving))

## Consistency requirement

`proofs.json` must come from the matching `dry_run_output.json` for the same module and inputs.