Skip to main content
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

+-----------+    +-----------+    +-----------+
| 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: 
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: Main output:
  • proofs.json
Command: 
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: 
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)

​
Consistency requirement

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