Skip to main content
Herodotus Data Processor Banner
Have a look at the Data Processor AI Skill 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 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 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, 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, or orchestrate through HDP Server.
  • High flexibility: you define the computation, constraints, and output format.

​
What HDP is not

HDP is not an indexer 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, 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 or schedule workflows through HDP Server.

​
Architecture at a glance

+------------------------+
| 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 inclusion:
  • The blocks you access must be included in the corresponding Herodotus Satellite MMRs.
  • This is especially important when mixing chains or environments.

​
Continue reading