Reclaim ProtocolReclaim ProtocolTrust Center

Data Privacy

Our guarantee

PII from your users' verified profiles never reaches our servers. By construction, not by policy.

The threat model

We assume our own logs, our own team, and our cloud infrastructure could all be adversarial. The guarantee has to hold even if our database is breached, one of our engineers goes rogue, or our cloud provider is compelled to hand over our data.

How it’s enforced

Two independent layers, each doing its own job:
  1. By design (cryptographic). Verification happens on the user's device, or inside a TEE-hosted client. From there, the verified data and its zero-knowledge proof are delivered directly to your application's backend callback. Our servers never see either one.
  2. By audit (behavioral). Every week we pull a random sample of live sessions, then run a large language model over every log line looking for PII that might have leaked. Findings are published on this page.

The cryptographic guarantee is what you actually rely on in production. The weekly audit is a tripwire. It's how we'd catch ourselves if we ever shipped a regression that broke layer 1.

How you verify

All of Reclaim Protocol's verification code is open-source on GitHub. Clone it and confirm for yourself that no raw data path ever leaves the user's device or the TEE-hosted client. Every weekly audit run is published below, with per-session verdicts and the exact PII categories we scan for.

What you still trust

The mathematical soundness of Reclaim Protocol's cryptography, always. And, when verification runs inside our TEE-hosted client (the Node SDK path, not the in-app SDK), the hardware TEE itself: AMD SEV on Google Cloud Confidential VMs. We deliberately do nottrust the user's device. The zk proofs are sound even against a fully malicious user. That's the whole point of using them.
Last checked: 5d ago
JunJulAug
Monitoring started · May 9Aug 6

Today · Jun 17· 50 days ahead are placeholders for future runs

© 2026 Reclaim Protocol · trust.reclaimprotocol.org

DocumentationContact

10

Sessions analyzed

9

Clean sessions

1

Needs attention

Per-session verdict

1 needs attention9 clean
  • ⚠ Needs attention668251****
    High trust
    IP address

    A raw public IP address was logged in a session update event. Per Reclaim's privacy rules, IP addresses should be resolved to country level and discarded, not stored or logged in raw form.

  • ✓ Clean0cf083****
    High trust

    No personally identifiable information detected.

  • ✓ Clean8d0ed3****
    High trust

    No personally identifiable information detected.

  • ✓ Cleanb145c7****
    High trust

    No personally identifiable information detected.

  • ✓ Clean8cf9cd****
    High trust

    No personally identifiable information detected.

  • ✓ Clean71888b****
    High trust

    No personally identifiable information detected.

  • ✓ Clean77963b****
    High trust

    No personally identifiable information detected.

  • ✓ Cleana8d9ff****
    High trust

    No personally identifiable information detected.

  • ✓ Cleandc58ff****
    High trust

    No personally identifiable information detected.

  • ✓ Clean2fd6d9****
    High trust

    No personally identifiable information detected.

How this check works

  1. We randomly select 10 live verification sessions from the past week
  2. Each session's logs are analyzed independently by AI for any personally identifiable information
  3. PII includes: names, emails, phone numbers, physical addresses, financial data, government IDs
  4. Acceptable data (not flagged): session IDs, device models, wallet addresses, verification URLs
90% Pass
Last checked: 5d ago

Methodology

Verified weekly: an LLM scans the logs of a random sample of live sessions for any PII that may have leaked through.