herodotus-primary-sources-2026-05-14

Herodotus primary sources

Reviewed: 2026-05-14 UTC

Core project framing

• https://docs.herodotus.dev/herodotus-docs
  • Best concise official overview in this pass.
  • Used to confirm Herodotus’s self-description as data-access middleware for synchronous access to current and historical onchain data across Ethereum layers.
  • Also the best short source for the product split between Storage Proofs, Storage Proof API, and Turbo.

Storage-proofs mechanism

• https://docs.herodotus.dev/herodotus-docs/developers/storage-proofs
  • Best mechanism page in this pass.
  • Used to confirm Herodotus’s explicit definition of storage proofs as a fusion of inclusion proofs, proofs of computation, and zero-knowledge proofs.
  • Also useful for the historical-data and efficiency framing: only roots or commitments need to move across layers while proofs are generated offchain and verified onchain.

Data Processor / coprocessor framing

• https://docs.herodotus.dev/herodotus-docs/developers/data-processor
  • Best source for the heavier-computation layer.
  • Used to confirm that HDP is framed as a coprocessor that verifies storage proofs on a zkVM and then runs custom computation over authenticated onchain data.
  • Especially important for showing that Herodotus is not just an inclusion-proof service; it also targets aggregate and programmable computation over large historical datasets.

API and scheduling layer

• https://docs.herodotus.dev/herodotus-docs/developers/storage-proof-api
  • Best source for the proof-scheduling and developer-service layer.
  • Used to confirm that the API is intended to hide cryptography and workflow complexity while handling scheduling and mutualized proof-generation costs.
  • Also useful for making the paid service / hosted API layer explicit rather than treating proof generation as magically embedded in the protocol.

Turbo integration and operator path

• https://docs.herodotus.dev/herodotus-docs/developers/turbo
  • Best source for the synchronous smart-contract UX path.
  • Used to confirm the special Turbo RPC, transaction simulation / tracing, proof-request flow, bundle construction, validator-or-sequencer handoff, and operator-fee model.
  • This page is the clearest source for where practical control can concentrate even when final verification stays onchain.

Repository-level implementation framing

• https://raw.githubusercontent.com/HerodotusDev/hdp-cairo/main/README.md
  • Best repo-level implementation summary available in this pass.
  • Used to confirm HDP Cairo’s modular framework design, RPC dependencies, dry-run / fetch-proofs / sound-run workflow, and the note that onchain settlement depends on Satellite-contract MMR inclusion.
  • Helpful for anchoring the docs-first product story to concrete operator and developer workflows.

Main takeaways from this pass

• Herodotus clears the bar because it exposes a reusable historical-state-access and authenticated-computation stack rather than a generic cross-chain data pitch.
• The key analytical split is between proof definition, proof scheduling, synchronous contract integration, heavier offchain computation, and eventual onchain verification.
• The docs make Herodotus especially useful for comparing data coprocessors because they preserve where power can concentrate: API hosting, operator-run Turbo RPCs, proof-generation costs, supported-root infrastructure, and satellite / settlement dependencies.
• Herodotus is therefore strongest in the corpus as a comparison point for Brevis, Lagrange, Axiom-adjacent proving middleware, and other systems that claim trustless historical-state access or verifiable offchain compute.