Summary: Relic Protocol is worth cataloging not as just another oracle, proving API, or generic ZK project, but as an early mechanism-focused attempt to make historical Ethereum data natively usable onchain. The primary materials reviewed here describe a system that batches Ethereum block headers into Merkle trees, anchors those trees onchain, and uses zk-SNARKs to prove that the committed header history really follows Ethereum’s chain. From there, users can combine block-history proofs with Merkle Patricia proofs over stateRoot, transactionsRoot, receiptsRoot, or storageRoot, then submit the result to verifier contracts and optionally persist the proven fact in a Reliquary for later reuse. That makes Relic a useful comparison point for Herodotus, Brevis, Lagrange, Axiom-adjacent middleware, and authenticated-query systems because the real control surfaces are not only proof validity, but also who runs the proving service, how recent-versus-deep history is bridged, whether facts are recomputed or stored for reuse, and how much application logic is built on top of proven historical claims.
What it does:
Provides onchain access to historical Ethereum state by committing Merkle roots for fixed groups of block headers and verifying their correctness with zk-SNARKs
Uses offchain proving infrastructure to build proofs over historical block-header chains, then verifies those proofs cheaply onchain through dedicated contracts
Bridges the gap between very recent block hashes available inside the EVM and older history by combining published block-history roots with smaller proof flows for more recent but not EVM-accessible blocks
Lets developers prove historical facts about transactions, receipts, storage, or account state by combining a proven block header with Merkle Patricia proofs against Ethereum trie roots
Exposes verifier contracts and a Reliquary pattern so once a fact is proven onchain it can be stored and queried by other applications without regenerating the full proof every time
Ships example applications like airdrops, historical gas-floor checks, RANDAO access, Uniswap V2 TWAP usage, and account-age / birth certificate style proofs to show the protocol as reusable middleware rather than a single app
Key claims:
Relic clears the corpus bar because it separates a reusable mechanism family: block-history commitment, zk-authenticated chain linkage, trie-level fact proving, application-side fact persistence, and example-driven downstream use are all distinct layers with different centralization and UX implications.
The monorepo README gives the cleanest technical core: Relic stores Merkle roots for groups of 8,192 block headers and uses an UltraPlonK zk-SNARK circuit to prove offchain that the roots correspond to valid Ethereum history that can be cheaply verified onchain.
The Chainlight architecture writeup matters because it makes the operational model explicit. Relic runs a proving server continuously, publishes new historical roots roughly once per 8,192 blocks, and can also issue smaller proofs for intermediate-recent history that is too old for the EVM’s BLOCKHASH window but not yet inside a published root batch.
Relic is especially useful analytically because it turns Ethereum historical-state access into a composable two-step proof pipeline: first prove the relevant block context is authentic, then prove the desired account/storage/receipt/transaction fact against that block’s trie root.
The Reliquary and example repositories show that Relic is not only a proving backend. It also proposes an app-facing pattern where proven facts become reusable onchain objects, including tokenized or queryable claims like account-age attestations.
The organization and repository licensing notes are important context too: core proving and contract repos are public for reference and security review, but parts are licensed for reference use only. That makes Relic a meaningful comparison point against more permissively open proving middleware, because openness of mechanism does not fully equal openness of reuse.
Whitepaper: No standalone canonical whitepaper surfaced in this pass. The strongest primary materials were the official GitHub organization and repositories plus the Relic engineering writeup Building Relic; see ../whitepapers/relic-protocol-primary-sources-2026-05-14.md.