# Zero-Knowledge Proofs This section explains how mathematical proofs verify that computations are correct, without revealing the private data behind them. ### **The Idea Behind Zero-Knowledge Proofs** Imagine you want to prove to someone that you know the combination to a safe, without actually telling them the combination. You could open the safe in front of them. They'd be convinced you know the combination, but they still wouldn't know what it is. **Zero-knowledge proofs** (ZKPs) work the same way, but with math. They let you prove a statement is true like "these numbers add up to this total" without revealing what the numbers are. This might sound like magic, but it's well-established mathematics. Zero-knowledge proofs have been studied since the 1980s and are used today in blockchains, digital identity systems, and privacy-preserving applications worldwide. ### **Why ZKPs Matter in This System** This system handles sensitive financial data. Individual reserve positions, custodian-level breakdowns, liability details — this information needs to stay private. But the aggregate numbers like total reserves, total liabilities need to be provably correct. ZKPs solve this tension. They let the system publish **totals** that anyone can see, while keeping the **breakdown** private, and providing mathematical proof that the totals are computed correctly from the hidden values. Without ZKPs, you'd face an impossible choice: * **Full transparency** — publish everything, including sensitive business data * **Full privacy** — publish nothing, and ask people to trust you ZKPs give you a third option: **privacy with proof**. ### **What This System Proves with ZKPs** Two types of proofs are generated for every attestation: #### **1. The Merkle Root Is Correct** The Merkle root is the single hash that represents all committed data (see [Merkle Trees, Commitments & Chaining](https://docs.afiprotocol.xyz/proof-of-reserve-network/merkle-trees-commitments-and-chaining)). The ZK proof demonstrates that this root was correctly computed from the individual commitments. **What this means for you:** No one fabricated the root. It genuinely came from hashing all the committed values in the proper structure. The data integrity is mathematically guaranteed. #### **2. The Totals Are Correct** Two separate sum proofs are generated: * **Reserves proof** — proves the individual reserve values add up to the published total reserves * **Liabilities proof** — proves the individual liability values add up to the published total liabilities **What this means for you:** The published totals ($X in reserves, $Y in liabilities) are exactly the sum of the actual positions. No values were added, removed, or altered. And crucially, you can verify this without seeing what each individual position is. **Analogy:** Imagine a teacher announces that the class average on a test was 82%. A ZK proof would let you verify that 82% is the correct average of all student scores, without revealing any individual student's score. ### **How It Works (Without Getting Too Technical)** #### **The Setup (One-Time)** Before the system can generate proofs, a one-time setup process creates two special keys: * **Proving key** — used by the system to generate proofs (stays with the system) * **Verification key** — used by anyone to check proofs (public, included in every payload) This setup is called a **trusted setup ceremony**. It's done once, and the resulting keys are used for all future proofs. The keys are specific to the computation being proven — if the computation changes, new keys are needed. #### **Proof Generation (Every Attestation)** When the system processes new data, it: 1. Takes the private inputs (individual values and their secrets) 2. Takes the public inputs (the total, the Merkle root) 3. Feeds them into the proof system 4. Produces a compact proof, just a few hundred bytes, regardless of how much data went in The proof generation uses a system called **Groth16**, which is one of the most widely used and well-audited zero-knowledge proof systems. It's known for producing very small proofs that can be verified very quickly. #### **Verification (Anyone, Anytime)** To verify a ZK proof, you need three things: * The proof itself * The public values (totals, Merkle root) * The verification key The verification is a single mathematical check that returns either "valid" or "invalid." There's no gray area. If it's valid, the computation was correct. Period. Verification is fast. It takes milliseconds and can be done by anyone with the proof payload. No special access, no credentials, no need to contact the system. ### **What Makes ZK Proofs Trustworthy?** #### **Mathematical Soundness** ZK proofs are based on well-studied mathematical problems. The security doesn't depend on hardware, network configuration, or operational practices. It depends on mathematics. If the proof verifies, the computation was correct. This isn't a probabilistic statement or an estimate. It's a mathematical certainty (with negligible error probability, like 1 in 2^128, which is effectively impossible). #### **Public Verification** Anyone can verify. The verification key is public and included in every proof payload. There's no gatekeeper, no API to call, no permission needed. You can verify offline, on your own machine, using open-source tools. #### **Compact and Efficient** Regardless of how many values go into the computation, the proof is always the same small size which is roughly 200 bytes. This makes it practical to store, transmit, and verify proofs at scale. #### **Independence from Hardware** ZK proofs are purely mathematical. They don't rely on any hardware, cloud provider, or trusted third party. Even if the TEE hardware were theoretically compromised, the ZK proofs would still hold. This independence is what makes the combination of TEE and ZK so powerful — they provide overlapping guarantees through completely different mechanisms. ### **Privacy Guarantees** What ZK proofs reveal and hide in this system: | Revealed (Public) | Hidden (Private) | | ---------------------------------- | ----------------------------------------- | | Total reserves | Individual reserve amounts per custodian | | Total liabilities | Individual liability amounts per position | | Merkle root | The values behind each commitment | | Whether reserves cover liabilities | Exact collateralization ratio breakdown | | Proof validity (correct/incorrect) | Master secret and derived salts | The public information is enough for users to verify that the system is properly collateralized. The private information protects sensitive business relationships and competitive positions. ### **Collateralization Verification** After both sum proofs are generated, the system checks: > Are total reserves greater than or equal to total liabilities? This simple comparison, combined with the ZK proofs guaranteeing both totals are correct, gives verifiers cryptographic assurance of the collateralization status. The result — `isCollateralized: true` or `false` — is included in every proof payload. ### **The Bigger Picture** ZK proofs are one layer in this system's security model:
Each layer is independent. Each provides its own guarantees. Together, they create a level of verifiability that no single mechanism could achieve alone. For the technical community: the system uses Groth16 proofs over the BN128 curve, with Poseidon hashing for ZK-friendly commitments and keccak256 for EVM-compatible commitments. Circuit implementations and verification keys are open and auditable.