Relic Protocol primary sources
Reviewed: 2026-05-14 UTC
Organization-level framing
- https://github.com/Relic-Protocol
- Best concise public statement of what Relic says it is.
- Used to confirm the organization-level description: a provably secure source of historical data on Ethereum.
- Also useful for grounding the visible public surface: the org exposes contracts, circuits, examples, and SDK/boilerplate repositories rather than only a marketing site.
Core proving design
- https://github.com/Relic-Protocol/relic-monorepo
- Best source for the core mechanism in this pass.
- Used to confirm that Relic’s goal is onchain access to historical Ethereum state, that it stores Merkle roots for groups of 8,192 block headers, and that it uses an UltraPlonK zk-SNARK circuit to prove offchain that the committed history is valid and cheaply verifiable onchain.
- Also useful for noting the reference-use-only licensing around parts of the proving stack.
Onchain verifier / contract layer
- https://github.com/Relic-Protocol/relic-contracts
- Best source for the smart-contract side of the system.
- Used to confirm that Relic ships dedicated Solidity/Yul contracts, tests against a mainnet fork, and similarly treats key contract code as reference-use-only rather than broadly reusable production middleware.
App-facing examples and downstream use cases
- https://github.com/Relic-Protocol/relic-examples
- Best source for how Relic expected developers to consume the protocol.
- Used to confirm that Relic published example applications including airdrop, daily gas-floor, RANDAO, Uniswap V2 TWAP, and historical-account / NFT-style proof patterns.
- Important because it shows Relic as reusable historical-proof middleware, not merely a backend service.
Architecture walkthrough
- https://blog.chainlight.io/building-relic-7454eeda3dbe
- Best narrative explanation of the full proof pipeline.
- Used to confirm the storage-cost motivation for Merkle-committed block history, the need to zk-prove block-chain linkage, the 24/7 proving server that publishes roots once every 8,192 blocks, and the split between published deep-history roots versus ad hoc proofs for intermediate-recent history.
- Especially useful for confirming the two-step application flow: authenticate the historical block, then prove the desired transaction/receipt/storage/account fact against that block’s trie roots, optionally persisting the result in a
Reliquary.
Main takeaways from this pass
- Relic is best understood as historical-state access middleware for Ethereum, not as a generic oracle or generic zk app.
- The most useful analytical split is between block-history authentication, trie-level fact proving, and application-side persistence/reuse of proven facts.
- Relic is especially valuable in the corpus because it exposes an early design where authenticated historical queries are not only answered once, but can be turned into reusable onchain facts, while still depending on an operator-run proving service and partially closed licensing around core implementation pieces.