Tamper-Proof Verifications

We assume anyone in the pipeline could be adversarial. Our own servers. Our cloud provider. One of our own engineers. A man-in-the-middle. An end user trying to forge a fact about themselves. The integrity guarantee has to hold against all of them.

Three independent layers, each one sufficient against a different attacker:

1. Cryptographic binding (zk proofs). Every verification is cryptographically bound to its underlying data. Change any byte, and the proof falls apart. This is what stops malicious users and man-in-the-middle attackers.
2. Open-source verification code. All of the code that generates a verification (SDKs, proof generators, attestor services) is public on GitHub. There is no proprietary path that could be quietly weakened.
3. TEE attestation (for server-side verifications). When the verification runs on our infrastructure (the Node SDK path), the running code is provable, end-to-end, against the open-source code on GitHub via hardware-signed attestations. Neither we nor our cloud provider can substitute a malicious implementation. How →

Plus continuous AI-based security scanning of the open-source code itself. It's a tripwire to catch any regression that might weaken layer 1.

Every verification repo is open. Clone it and audit it yourself. We publish recipes for running independent AI-based security audits with Anthropic Code Security and Trail of Bits. The full report from our own continuous scan is available under NDA, see below.

The mathematical soundness of Reclaim Protocol's cryptography (peer-reviewed at IACR ePrint 2024/733), the TEE attestation chain (AMD SEV on Google Cloud Confidential VMs, covered separately on the TEE page), and the open-source toolchain the SDKs are built with.