> ## 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.

# Design Patterns and Constraints

> How to design sound HDP modules without overtrusting off-chain indexing

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](/data-structure-indexer-api/introduction) 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](/data-structure-indexer-api/introduction)/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](/data-processor/verification)).
* **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`](/data-processor/pipeline)), settlement depends on chain data being present in settlement [MMRs](/data-processor/verification).

Always confirm your target blocks and chain combination are supported by the relevant [MMR](/data-processor/verification) 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.
