1) Run locally (developer loop)
Best for fast iteration on module logic. Core flow:hdp dry-run -m <compiled_module>.json --print_outputhdp fetch-proofshdp sound-run -m <compiled_module>.json --print_output
2) Prove with Atlantic
Best when you want managed proving and verification pipelines. Atlantic can be used with different prover modes exposed in Atlantic docs (for example Stone/SHARP andS-two). This lets teams optimize for workflow needs without running prover infrastructure themselves.
Typical flow:
- Produce trace/PIE from HDP run
- Submit Atlantic query
- Track query status and retrieve proof-related job details
- Verify on chosen target (for example L1, L2, or off-chain mode depending on workflow)
3) Use HDP Server API (orchestrated path)
Best when you want API-driven scheduling and lifecycle management from your backend. This is not the same as State Server:- HDP Server API orchestrates HDP task execution lifecycle (
/tasks, status, retries, outputs). - State Server provides injected-state trie read/write/proof endpoints used in injected-state workflows.
POST /tasks-> schedule a taskGET /tasks/{task_uuid}/status-> track task statusGET /tasks/{task_uuid}/details-> inspect execution metadataPOST /tasks/{task_uuid}/retry-> retry failed tasks
- HDP Server Introduction
- Schedule a new task
- Get task status
- List tasks
- Get task details
- Get task state transitions
- Get task output preimage
- Get used MMRs
- Retry task
- Decommitment only
Choosing the path
- Use local HDP for module development and testing.
- Use Atlantic for self-running but managed proving/verification.
- Use HDP Server for full managed orchestration including proving/verification with Atlantic.

