Relic Protocol

• Name: Relic Protocol
• URL: https://relicprotocol.com/
• Category: historical-state access infrastructure / Ethereum storage-proof middleware / zk-SNARK-authenticated data coprocessor
• Tags: ethereum-ecosystem
• 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.
• Sources:
  • https://github.com/Relic-Protocol
  • https://github.com/Relic-Protocol/relic-monorepo
  • https://github.com/Relic-Protocol/relic-contracts
  • https://github.com/Relic-Protocol/relic-examples
  • https://blog.chainlight.io/building-relic-7454eeda3dbe

Internal linkages

• Best upward historical-state reads: axiom and herodotus.
• Broader proving-stack contrast: brevis.

Control surface

• The useful questions are who publishes header-history commitments, who actually runs the proving service, how the recent-history bridge is handled, and whether apps depend on fresh proof generation or on stored facts inside the Reliquary pattern.

• Good mechanism note. Still a smaller branch read than the stronger query-and-coprocessor stacks above it.

• Last reviewed: 2026-06-08 UTC