> ## 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.
# Data Processor (HDP)
> What HDP is, why teams use it, and what it can (and cannot) prove — verifiable computation over historical on-chain data with Cairo modules.
Have a look at the [Data Processor AI Skill](/skills/data-processor) to give
your LLM a head start on using HDP.
HDP (Herodotus Data Processor) is a Cairo framework for **provable on-chain data access + provable computation**.
You write Cairo logic, HDP fetches and verifies the required chain data and proofs, then executes your logic and produces a trace that can be proven.
## The problem HDP solves
Historical on-chain data is hard to use in a verifiable way at scale.
* [Indexers](/data-structure-indexer-api/introduction) are fast, but not cryptographic truth by themselves.
* Raw chain replay is expensive and difficult to operationalize.
* Proving historical statements needs both the data and a proof trail back to trusted roots.
## Why HDP is great for builders
HDP removes most of the painful parts of proof-backed chain data work:
* **You can use storage proofs without becoming a storage-proof expert.**
* **You can read historical state from [MMR-backed](/data-processor/verification) chain history**, not only latest state.
* **You write simple Cairo1 modules while leveraging Cairo0 performance** thanks to HDP's backend.
* **You can choose managed proving in [Atlantic](/atlantic-api/introduction)**, use the latest `S-two` prover and legacy `Stone`, leveraging the cost savings of using SHARP (Starkware's shared proving service) and proving your programs alongside StarkNet itself and many other projects.
* **You can stay Solidity-first for business logic** by utilizing the provable ETH Call and use HDP where proof-backed historical access is needed.
## What HDP gives you
* **Trustless access to historical and current chain data** from supported EVM chains and Starknet.
* **Provable execution** of your Cairo program over that authenticated data.
* **Cross-chain modules** where one program reads from multiple chains in a single run.
* **Composable proving flows**: run locally, send to [Atlantic](/atlantic-api/introduction), or orchestrate through [HDP Server](/data-processor-api/introduction).
* **High flexibility**: you define the computation, constraints, and output format.
## What HDP is not
HDP is **not** an [indexer](/data-structure-indexer-api/introduction) and **not** a SQL-like query engine by itself.
If you need "all events matching condition X", you typically:
1. Gather candidate data off-chain ([indexer](/data-structure-indexer-api/introduction), backend, or your own pipeline).
2. Feed that data into your HDP module.
3. Add hard constraints in Cairo so missing/duplicated/tampered data is rejected.
This separation is important and keeps the system explicit and auditable.
## Why teams use HDP
* **Historical state checks** (for example, balances at specific old blocks).
* **Governance and voting logic** (for example, voting power at vote time).
* **Airdrop eligibility and scoring** over historical activity.
* **Compliance-style checks** over a bounded transaction/event set.
* **Bridge and cross-chain accounting** with one verifiable pipeline.
* **Faster product delivery** because teams do not need to hand-build proof plumbing from scratch.
## Execution model in one view
HDP follows three practical stages:
1. **Dry run**: discover which on-chain facts your module needs.
2. **Fetch proofs**: retrieve required chain data and proofs.
3. **Sound run**: execute the module against verified data and generate the trace / Cairo PIE.
From there, you can send proving/verification jobs to [Atlantic](/atlantic-api/introduction) or schedule workflows through [HDP Server](/data-processor-api/introduction).
## Architecture at a glance
```text theme={null}
+------------------------+
| Cairo1 module |
| uses hdp.* APIs |
+------------------------+
| Cairo0 bootloader |
| verifiers + outputs |
+------------------------+
| Rust hints/handlers |
| Dry: RPC keys |
| Sound: memorizer reads |
+------------------------+
```
## Important finality note
Even when local stages succeed, settlement depends on [MMR](/data-processor/verification) inclusion:
* The blocks you access must be included in the corresponding [Herodotus Satellite](https://github.com/HerodotusDev/satellite) MMRs.
* This is especially important when mixing chains or environments.
## Continue reading
* [More in-depth technical HDP docs](https://herodotusdev.github.io/hdp-cairo/)
* [CLI installation and usage](/data-processor/cli-installation)
* [Architecture overview](/data-processor/architecture)
* [Pipeline stages](/data-processor/pipeline)
* [HDP Capabilities and API Surface](/data-processor/capabilities)
* [Verification model](/data-processor/verification)
* [State management](/data-processor/state-management)
* [State Server](/data-processor/state-server)
* [Output model](/data-processor/output)
* [Provable EVM Contract Calls (`execute_eth_call`)](/data-processor/eth-call)
* [Proving with STWO](/data-processor/proving)
* [Ways to run HDP](/data-processor/running-hdp)
* [HDP Server docs](/data-processor-api/introduction)
* [Design patterns and constraints](/data-processor/design-patterns)
* [Examples mapped to use cases](/data-processor/examples)
* [CLI reference](/data-processor/reference-cli)
* [Configuration reference](/data-processor/reference-configuration)
* [Types reference](/data-processor/reference-types)
* [Debugging](/data-processor/debugging)
* [Glossary](/data-processor/glossary)