Privacy + Bitcoin · Starknet
How Starkproof Works
A trustless, privacy-preserving Proof of Reserves protocol on Starknet. Prove solvency without revealing wallet addresses, exact balances, or any identifying information.
THE PROBLEM
The Transparency-Security Dilemma
After FTX collapsed in November 2022, the crypto industry adopted Proof of Reserves as a standard. But the dominant approach — Merkle proofs + on-chain wallet attestations — creates a critical secondary problem:
Publishing PoR today means exposing your entire treasury to the world.- Exact Bitcoin wallet addresses
- Total BTC holdings down to the satoshi
- When and how the treasury moves
- Which wallets are hot vs. cold
THE SOLUTION
Zero-Knowledge Proof of Reserves
Starkproof uses STARK proofs to let any entity prove:
∃ (wallet_addresses, balances, liabilities) such that:
sum(balances) ≥ sum(liabilities)
AND merkle_root(liabilities) == published_commitment
...and the verifier learns nothing except that this statement is true.
DATA MODEL
What's Public vs. Private
PUBLIC (on-chain)
- ✓ Reserve ratio band (100–110%, 110–120%, ≥120%)
- ✓ BTC block height at time of proof
- ✓ Liability Merkle root (commitment hash)
- ✓ Proof timestamp and expiry
- ✓ Entity identifier hash
PRIVATE (never revealed)
- ✗ Bitcoin wallet addresses
- ✗ Exact BTC balances
- ✗ Exact reserve ratio
- ✗ Customer identities
- ✗ Individual liability amounts
CIRCUIT LOGIC
The Cairo Circuit
The circuit enforces these constraints. If any fails, no valid proof can be generated:
1. Assert total_reserves > 0
2. Assert total_liabilities > 0
3. Assert total_reserves >= total_liabilities // ← THE CORE ASSERTION
4. Compute liability_merkle_root = Poseidon-Merkle(account_ids, liabilities)
5. Compute reserve_ratio_band from ratio
6. Output: (liability_merkle_root, reserve_ratio_band)
The Merkle tree uses Poseidon hash — Cairo-native and gas-efficient. The entity cannot change a single customer's liability after publishing the root.
PRIVACY DESIGN
Why Bands Instead of Exact Ratios?
Rather than revealing the exact ratio (e.g., 1.34), the circuit outputs a band (e.g., "between 120% and ∞"). This gives users meaningful information about safety margins while preventing treasury reconstruction from ratio + liability count.
100–110%Minimum reserve — cautious 110–120%Comfortable reserve buffer ≥ 120%Strong overcollateralization FAQ
Can an insolvent entity fake a proof?
No. The circuit assertion total_reserves ≥ total_liabilities will fail if reserves are insufficient. No valid proof can be produced for a false statement. This is the mathematical guarantee of STARKs.
Can the entity change their liability data after submitting?
No. The liability_merkle_root binds all customer liabilities at proof time. Changing a single account's balance would produce a different root, invalidating the proof.
Does this prove the entity disclosed ALL their liabilities?
No. The circuit proves the Merkle root is correctly computed from the DISCLOSED liability set. An entity cannot add undisclosed liabilities without invalidating the root. This is the same limitation as all self-reported PoR systems.
How often must entities re-prove?
Proofs expire after 30 days. Entities must submit a new proof to maintain active status. This prevents stale attestations from being presented as current.