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:
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:
Takes the attested data from the payload (Merkle root, total reserves, total liabilities, proof ID, feed ID, timestamp)
Recomputes the hash from those values
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:
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?
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:
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:
Take two consecutive proofs
Confirm the later proof's "previous root" matches the earlier proof's root
Verify the chained root was correctly computed
This ensures the historical sequence is intact. See Merkle Trees, Commitments & Chainingfor 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: https://github.com/Artificial-Financial-Intelligence/por-proof-verifier-script
Last updated