# Verification
This section explains how anyone can independently verify a proof, confirming that the data is authentic, untampered, and correctly computed. No special access or credentials required.
### **The Promise of Independent Verification**
Every claim this system makes can be checked by anyone, anywhere, without trusting the system operator. The proof payload contains everything needed for verification — certificates, keys, proofs, and data. A verifier works entirely independently.
This is a fundamental design principle: **don't trust, verify.**
### **What's in a Proof Payload**
Before diving into verification steps, here's what a proof payload contains:
| Section | What's Inside |
| ------------------------ | ------------------------------------------------------------------------------------- |
| **Metadata** | Version, data feed identifier, timestamp, unique proof ID |
| **Verified Totals** | Total reserves and total liabilities in USD |
| **Merkle Proof** | The root hash, all field commitments, and the previous root (for chain verification) |
| **TEE Attestation** | The hardware-signed attestation document, code measurements, and attested data fields |
| **ZK Proofs** | Mathematical proofs for the Merkle root and sum computations |
| **Verification Context** | Root CA certificate and ZK verification keys |
Everything needed to verify is included. No external calls, no APIs, no downloads.
### **The Five Verification Checks**
A complete verification performs five independent checks. Each one validates a different aspect of the proof:
Let's walk through each one.
#### **Check 1: Hardware Authenticity**
**Question:** Was this attestation produced by genuine TEE hardware?
**How it's verified:**
The attestation document is signed by the enclave's hardware. That signature is backed by a certificate chain — a sequence of digital certificates, each vouching for the next, leading all the way up to the hardware provider's Root Certificate Authority.
Think of it like verifying a passport:
* The passport (attestation) has a stamp (signature)
* The stamp traces to a local authority (enclave certificate)
* The local authority traces to a national authority (intermediate certificate)
* The national authority traces to an internationally recognized body (Root CA)
If the chain is valid and unbroken, the attestation came from genuine hardware. The Root CA certificate is publicly known and included in the payload for convenience.
**What passing means:** A real TEE enclave produced this attestation. It's not a software-generated fake.
#### **Check 2: Code Integrity**
**Question:** Was the enclave running the correct, unmodified software?
**How it's verified:**
The attestation includes code measurement values — fingerprints of the software that ran inside the enclave. These are compared against the **expected values** published when the software was deployed. They must match exactly.
Think of it like a seal on a software package. When the manufacturer ships the software, they publish the seal's pattern. When you receive the package, you check the seal. If it matches, the software hasn't been tampered with.
**What passing means:** The enclave ran the expected software. No modifications, no backdoors, no unauthorized changes.
#### **Check 3: Data Binding**
**Question:** Does the attestation actually cover the data in this payload?
**How it's verified:**
The attestation document contains a data hash. This is the value that the hardware signed. The verifier:
1. Takes the attested data from the payload (Merkle root, total reserves, total liabilities, proof ID, feed ID, timestamp)
2. Recomputes the hash from those values
3. Compares it to the data hash in the attestation
If they match, the hardware attested exactly this data, not some other data that was swapped in later.
**Why this matters:** Without this check, someone could take a valid attestation from one computation and attach it to different data. The data binding ensures the attestation and the payload are inseparable.
**What passing means:** The data in this payload is exactly what the hardware computed and signed. Nothing was swapped or modified after attestation.
#### **Check 4: Mathematical Correctness**
**Question:** Are the computations provably correct?
**How it's verified:**
Three ZK proofs are checked:
**A. Merkle Root Proof** Verifies that the published Merkle root was correctly computed from the leaf commitments. This ensures the root genuinely represents the committed data.
**B. Reserves Sum Proof** Verifies that hidden individual reserve values add up to the published total reserves. This ensures the total isn't fabricated.
**C. Liabilities Sum Proof** Verifies that hidden individual liability values add up to the published total liabilities. Same guarantee as above.
Each verification is a mathematical check using the verification keys included in the payload. The check returns a simple yes or no — there's no ambiguity.
**What passing means:** The Merkle root is correctly computed. The total reserves are the true sum of individual reserves. The total liabilities are the true sum of individual liabilities. All of this is proven with mathematical certainty.
#### **Check 5: Merkle Root Consistency**
**Question:** Do the commitments in the payload actually produce the claimed root?
**How it's verified:**
The verifier takes all the field commitments from the payload and rebuilds the Merkle tree from scratch. If the recomputed root matches the root in the attestation, the commitments are genuine.
This check closes the loop: the commitments produce the root, the root is attested by hardware, the ZK proof confirms the computation. Everything connects.
**What passing means:** The commitments in the payload are the original ones — nothing was added, removed, or altered after the tree was built.
### **What Full Verification Tells You**
If all five checks pass, you know:
| Statement | Guarantee |
| --------------------------------------- | ----------------------------------------------------- |
| The proof came from real hardware | Certificate chain validates to the provider's Root CA |
| The correct code was running | Code measurements match expected values |
| The data hasn't been swapped | Attestation hash matches payload data |
| The totals are mathematically correct | ZK proofs verify |
| The commitments are genuine | Merkle root recomputation matches |
| The system is (or isn't) collateralized | Total reserves vs. total liabilities |
This isn't "probably correct" or "we checked and it looked fine." It's cryptographic certainty backed by hardware and mathematics.
### **What If a Check Fails?**
| Failed Check | What It Might Mean |
| ------------------------ | --------------------------------------------------------------------------------------------------- |
| Hardware authenticity | The attestation wasn't produced by genuine TEE hardware — it may be fabricated |
| Code integrity | The enclave ran different code than expected — the software may have been modified |
| Data binding | The payload data doesn't match what was attested — the data may have been swapped after computation |
| Mathematical correctness | The computation has errors or the proofs were fabricated — the totals may not be correct |
| Merkle root consistency | The commitments were altered after the tree was built — the data may have been tampered with |
Any single failure means the proof should not be trusted. The system is designed so that all checks must pass.
### **Verification Is Optional but Available**
Not every consumer of this data needs to run full verification. Different audiences have different needs:
| Audience | Typical Approach |
| ------------------ | ------------------------------------------------------------------------------ |
| End users | Check the collateralization status; trust that the protocol runs verification |
| Protocol operators | Run full verification on every proof; alert on failures |
| Auditors | Run full verification; also check code measurements against deployment records |
| Regulators | Run full verification; may also request raw data disclosure with salts |
| Researchers | Run full verification; inspect proof structure and timing |
The important thing is that verification **can** be done by anyone. The option is always there.
### **Offline Verification**
The proof payload is self-contained. Verification doesn't require:
* An internet connection
* Access to the system's servers
* An API key or credentials
* Any proprietary software
All you need is the proof payload and open-source verification tools. The system provides reference verification scripts, and the payload format is documented so anyone can build their own verifier.
### **Chain Verification**
Beyond verifying individual proofs, you can verify the **chain** between consecutive proofs:
1. Take two consecutive proofs
2. Confirm the later proof's "previous root" matches the earlier proof's root
3. Verify the chained root was correctly computed
This ensures the historical sequence is intact. See [Merkle Trees, Commitments & Chaining](https://docs.afiprotocol.xyz/proof-of-reserve-network/merkle-trees-commitments-and-chaining)for details.
### **Browser Verification**
The system includes a browser-compatible verification reference, meaning proofs can be verified directly in a web browser without any server-side processing. This is particularly useful for:
* Building user-facing dashboards that verify proofs in real time
* Allowing anyone to verify proofs without installing anything
* Embedding verification into web applications
**For Self Verification here is the Repo:** \
