Skip to main content
This page is about building sound HDP applications.

​
Core principle

HDP proves:
  1. The on-chain data your module accessed is authentic for the specified chain/block.
  2. Your Cairo logic ran correctly over that data.
HDP does not automatically prove that an off-chain query/indexer found every item unless your module enforces constraints that make omission/duplication impossible.

​
Pattern: “Gather off-chain, constrain in HDP”

When working with subsets (“all events matching X”), use this shape:
  1. Gather candidates off-chain (indexer/API/backend).
  2. Pass them to HDP.
  3. In Cairo, enforce:
    • membership authenticity,
    • uniqueness,
    • completeness commitment (counter/root/range/accumulator).
If completeness is not constrained, “processed subset” claims are weaker.

​
Useful constraint patterns

  • Monotonic counters: contract-level counters that must match processed counts.
  • Root commitments: Merkle/MMR roots committed on-chain, then matched in HDP (see Verification model).
  • Uniqueness guards: nonce/order constraints to prevent duplicates.
  • Range commitments: explicit (start, end) bounds and deterministic traversal checks.

​
Multi-chain and finality caveat

Even with successful local stages (dry-run/fetch-proofs/sound-run), settlement depends on chain data being present in settlement MMRs. Always confirm your target blocks and chain combination are supported by the relevant MMR state.

​
Practical sizing guidance

Throughput depends on your actual computation and resulting step count, not only on payload shape. Start with a narrow prototype, measure steps/resources, then scale (including splitting and recursive composition when needed).

​
Debugging and iteration tips

  • Keep modules small at first, then add constraints incrementally.
  • Print intermediate values during development (println!).
  • Use fixed known blocks and deterministic test inputs early.
  • Keep assumptions explicit in code and docs.