Skip to main content
HDP is a layered system that combines Cairo1 developer ergonomics with Cairo0 verification/runtime machinery and Rust orchestration.

​
Layers

  • Cairo1 user layer: your module uses hdp_cairo APIs.
  • Bootloader layer (Cairo0): loads and executes the compiled Cairo1 class.
  • Verification layer (Cairo0): validates MMR/MPT/Patricia proofs (see Verification model).
  • Hint processors (Rust): bridge Cairo VM execution with proof decoding and data handling.
  • Orchestration layer (Rust): runs dry-run, fetch-proofs, and sound-run.

​
Data flow

+-----------+    +-----------+    +-----------+
| Dry Run   | -> | Fetcher   | -> | Sound Run |
| RPC keys  |    | Proofs    |    | Verify run|
+-----------+    +-----------+    +-----------+

dry_run_output.json -> proofs.json -> outputs

​
Cairo1 and Cairo0 boundary

  • Cairo1 module code requests data through hdp_cairo.
  • Under the hood this uses VM syscalls routed to HDP handlers.
  • In dry run, handlers query RPCs and record accessed keys.
  • In sound run, handlers read from already-verified memorizers (offline path).
This keeps your module logic the same across stages while switching the data source from live RPC to verified local state. For stage-by-stage behavior, see Pipeline stages.

​
Syscall model (high level)

  • Main selector for HDP data access: CallContract
  • Hashing selector used by runtime: Keccak
Routing uses:
  • special contract addresses for internal handlers,
  • plus chain-id-aware dispatch for EVM vs Starknet access paths.

​
Why this architecture matters

  • You write simple module logic once.
  • HDP separates discovery, proof retrieval, and deterministic replay.
  • The final execution is reproducible and ready for proof workflows.