reclaim-primary-sources-2026-05-11

Reclaim Protocol primary sources

Collected: 2026-05-11 UTC

Primary sources reviewed

• https://www.reclaimprotocol.org/
  • Official homepage
  • Used to confirm the project’s source-verification framing, target use cases, and explicit rejection of document-upload workflows
• https://docs.reclaimprotocol.org/
  • Official docs homepage
  • Used to confirm the end-to-end verification flow: provider definition, HTTPS request identification, field extraction, proof generation, callback delivery, and backend verification
• https://docs.reclaimprotocol.org/zkfetch
  • Official docs for zkFetch
  • Used to confirm that Reclaim also treats API responses as proofable objects and packages proofs as (request, response, zkproof)-style tuples with optional redaction
• https://github.com/reclaimprotocol
  • Official GitHub organization
  • Used to confirm the project’s repository structure around attestors / witness servers, SDKs, TLS client code, proof libraries, and docs
• https://raw.githubusercontent.com/reclaimprotocol/reclaim-js-sdk/main/README.md
  • Official JavaScript SDK README
  • Used to confirm request URLs, status URLs, QR flows, browser-extension support, portal / iframe embedding, verifier-app flow, and callback-oriented claim delivery
• https://raw.githubusercontent.com/reclaimprotocol/attestor-core/main/README.md
  • Official attestor-core README
  • Used to confirm the lower-layer architecture: attestor server sitting between user and internet, TLS-mediated exchange, selective data revelation, attestor signatures, and the possibility of running your own attestor server

Notes

• Reclaim cleared the bar because it is not just another identity-check app or generic zkTLS brand. It productizes the middleware layer between HTTPS transcript authenticity and application-specific claims: provider templates, field extraction logic, claim orchestration, attestor infrastructure, proof delivery UX, and verifier integrations.
• The docs are especially useful because they do not flatten the system into vague proofs from websites rhetoric. They spell out that a provider identifies the relevant HTTPS request, then regex and JSON-path rules isolate the exact fact to prove. That means provider authorship and extraction policy are core control surfaces.
• The official docs also explicitly treat provider creation as a repeatable workflow rather than a one-off internal service. Unsupported websites can be reverse engineered, and the developer tooling is positioned as helping automate that work. This makes Reclaim partly a claim-definition platform.
• The attestor-core repo gives the strongest lower-layer insight: the attestor sits between the user and the internet, leverages TLS plus zero-knowledge proofs, signs the resulting data, and can be self-run. That is a much more specific architectural decomposition than homepage marketing alone.
• The SDK README shows that proof transport is another major control layer. Reclaim can route users through browser extensions, QR flows, mobile app redirects, iframes, or portal tabs, then send proofs to callback URLs. So the user-facing trust and UX surface is not just the cryptography.
• zkFetch matters because it widens the comparison set beyond identity verification. Reclaim can operate as a more general middleware layer for authenticated web/API data, which makes it relevant to payment-proof, compliance, and offchain-fact attestation systems too.
• This entry belongs in the active corpus because it gives the web-proof cluster a productized comparison point between lower-layer primitives such as TLSNotary and higher-layer credential or payment applications.