Proof of Solvency

A cryptographic proof that demonstrates the total assets held by an institution. It typically involves the exchange or custodian publishing a Merkle root of its wallet addresses and balances, which can be independently verified against on-chain data. This proves the existence and control of assets but does not, on its own, prove they exceed liabilities.

A proof that cryptographically commits to the sum of all customer account balances (liabilities). Using a Merkle tree, each user's balance and account ID are hashed into a leaf. The exchange publishes the Merkle root, allowing any user to verify their inclusion. This proves the total amount the exchange owes without revealing individual data.

A critical feature that allows any user to cryptographically verify that their specific account balance is correctly included in the total liabilities. By providing a Merkle proof (a path of hashes from their leaf to the published root), users can independently confirm their balance was part of the calculation, preventing the exchange from omitting large liabilities.

Advanced cryptographic techniques used to enhance privacy and verification. zk-SNARKs can prove that the sum of all liabilities in the Merkle tree is less than or equal to the proven reserves, without revealing any individual balances or the total liability amount. This provides a stronger, more private attestation of solvency.

Proof of Solvency is most effective when performed regularly (e.g., daily or weekly). Frequent attestations create a near real-time audit trail, making it significantly harder for an institution to become insolvent and hide it. This moves auditing from a periodic event to a continuous process.

The core principle that proofs must be verifiable by any third party—users, auditors, or the public—using only public data (the published proofs and blockchain state). This removes the need to trust the institution's word and shifts the model to trust-minimized verification, a cornerstone of decentralized finance.

Oracles fetch and verify off-chain reserve attestations from trusted third parties. This includes:

• Bank statements and custodial reports proving fiat holdings.
• On-chain wallet balances for cryptocurrency reserves.
• Auditor signatures and timestamped proofs to ensure data freshness and authenticity.

Oracles aggregate the total user liabilities from the platform's internal database. This involves:

• Calculating the sum of all user account balances.
• Generating a cryptographic commitment (like a Merkle root) to this data.
• Providing this commitment as a verifiable input to the Proof of Solvency circuit, ensuring liabilities are accurately represented without exposing individual user data.

For advanced privacy-preserving proofs, oracles supply the verified data as private inputs to a zero-knowledge circuit. This allows the prover (the custodian) to demonstrate that reserves >= liabilities without revealing the exact amounts of either. The oracle's role is to attest that the private inputs fed into the ZK system are correct and current.

When reserves and liabilities are in different assets (e.g., BTC reserves backing USD liabilities), oracles provide real-time price feeds. This enables the proof to demonstrate solvency by valuing all assets and liabilities in a common unit (like USD). The proof's validity depends entirely on the accuracy and manipulation-resistance of these oracle-provided prices.

Decentralized oracle networks can act as automation triggers. Based on predefined conditions—such as time intervals, significant market movements, or changes in reserve composition—an oracle can send a transaction to initiate a new Proof of Solvency generation. This creates a trustless, verifiable audit schedule.

Once generated, the cryptographic proof and its supporting data (like the Merkle root of liabilities) are published on-chain. Oracles can be used to verify the proof's inputs against their own independently sourced data. This creates a system of cross-verification, where the on-chain proof is checked against the oracle's attested state of the world.

A standard Proof of Solvency provides a cryptographic snapshot of assets and liabilities at a specific moment. This means it does not prove continuous solvency between audits. A custodian could be insolvent for days or weeks before the next proof is published, a critical limitation known as temporal risk.

The proof's validity depends on the integrity of the off-chain data used to compile the liability list (customer balances). If this internal database is falsified, the cryptographic proof will still be valid but will represent a fraudulent state. This creates a trusted setup for the liability side of the proof.

To protect user privacy, proofs often use cryptographic commitments like Merkle Trees and zero-knowledge proofs. While this hides individual balances, it also introduces complexity and can make it difficult for third parties to fully verify the proof's correctness without relying on the auditor's or custodian's software.

A proof typically covers on-chain assets (e.g., Bitcoin, Ethereum). It may not account for off-chain liabilities like fiat loans, derivatives exposure, or unreported losses. It also cannot prove the custodian controls the private keys for the proven assets, only that the assets exist at the listed addresses.

Fully verifying a sophisticated proof (e.g., one using zk-SNARKs) requires technical expertise and computational resources. This creates a verification gap where most users must trust that a few experts or auditors have correctly verified the proof, reducing its utility as a transparent, user-verifiable tool.

Proof of Solvency verifies asset backing but does not assess liquidity risk. A custodian could be solvent but illiquid (e.g., assets locked in long-term staking or illiquid tokens), unable to meet sudden withdrawal demands. It is a necessary but insufficient condition for proving overall financial health.

A fundamental data structure used to construct Proof of Solvency. Client account balances are hashed as leaves, which are then recursively hashed up to a single Merkle root. This allows a user to verify their inclusion in the total liability set with a compact Merkle proof, without exposing other users' data.

A cryptographic method where one party (the prover) can prove to another (the verifier) that a statement is true without revealing any information beyond the validity of the statement itself. Advanced Proof of Solvency schemes use ZK-SNARKs or ZK-STARKs to prove solvency while maintaining complete privacy for all client balances and the custodian's total assets.

The asset-side component of Proof of Solvency. It cryptographically proves the custodian controls a set of assets (e.g., on-chain Bitcoin or Ethereum) equal to or greater than a claimed value. This is typically done by signing a message with the private keys controlling the funds, providing a cryptographic attestation of ownership at a specific block height.

The liability-side component of Proof of Solvency. It proves the total sum of all client claims against the custodian, without revealing individual account details. This is commonly implemented using a Merkle sum tree, where each leaf includes a balance, enabling the prover to commit to the total sum in the root hash.

A fundamental primitive where a value is hidden (e.g., hashed) to produce a commitment, which can later be revealed and verified. In Proof of Solvency, the Merkle root acts as a commitment to the entire set of client liabilities. The custodian binds themselves to this data set, preventing them from altering it after the fact.

A traditional banking practice where institutions lend out a portion of deposited funds, holding only a fraction as reserves. Proof of Solvency is designed to detect and prevent this scenario in digital asset custodians by requiring cryptographic proof that assets ≥ liabilities. A failure to provide proof suggests potential fractional reserve activity or insolvency risk.