Design Proof of Reserves - System Design | WinJob

Problem Statement: Exchange Proof of Reserves

Section 1 covers understanding for a Kraken/Chainlink-class Proof of Reserves platform.

Proof of Reserves (PoR) answers one question: do customer balances on our internal ledger have matching assets we control on-chain?
Post-FTX, exchanges publish wallet lists plus Merkle trees so users verify inclusion without revealing neighbor balances.
Liabilities are the sum of user account balances in the exchange ledger at snapshot time T (integer smallest units).
Assets are provable balances at labeled hot, cold, staking, and treasury wallets—double-counting is the #1 engineering bug.
Coverage ratio = total provable assets / total liabilities; must be ≥ 1.0 with disclosed buffers for operational float.
Merkle leaf typically hashes (user_id_salt, balance) so users get inclusion proofs without publishing the full user list.
Third-party auditor signs the methodology + wallet list + root hash; engineering owns reproducible build pipeline.
Chainlink PoR feeds let DeFi protocols consume attestation roots on-chain—your design should expose a signed publish hook.
Nic Carter's PoR framework stresses liabilities definition, asset definition, and transparency of wallet ownership.
Hot wallets move fast; cold wallets dominate BTC/ETH reserves—both must be in scope or explain exclusion.
Borrowed assets used as collateral must not count as reserves unless you net against user borrow liabilities explicitly.
Stablecoins count at face value only if tokens are held 1:1 in known addresses—no unbacked internal IOUs.
Snapshot requires brief trading freeze or logical snapshot isolation so liabilities do not move mid-tree build.
Reconciliation job compares ledger liabilities to sum of Merkle leaves; mismatch blocks publication.
User verify flow: download proof path + root + auditor signature; client recomputes leaf hash with their account id salt.
CAP: liability snapshot is CP in PostgreSQL; chain balances are AP with quorum RPC and delayed finality buffers.
Idempotent snapshot jobs keyed by snapshot_id; replays must not duplicate Merkle roots in public archive.
Privacy: never publish raw balances in leaves—use salted hashes and optional ZK upgrade path in v2.
Attack: exchange moves funds after snapshot photo—mitigate with continuous wallet monitoring between attestations.
Attack: exclude large liability buckets (margin, earn)—interviewers ask what product lines are in liability definition.
Regulators want historical archive of roots, wallet lists, and coverage ratio time series.
Interview opening: separate custody proof from exchange solvency of corporate equity—PoR is necessary not sufficient.
Staff+ cite Kraken's public Merkle verification tool and Binance's zkPoR direction as industry benchmarks.
Do not confuse PoR with Proof of Solvency (includes off-chain fiat and corporate debt)—state MVP boundary.
Operational metric: time to rebuild Merkle tree for 12M users—shard builders horizontally.

Metrics interviewers expect

liabilities ≤ provable assets
Merkle leaf per user
Kraken-style PoR
third-party audit

Engineering notes

PoR pipeline for Problem Statement: Exchange Proof of Reserves: snapshot liabilities at block T, aggregate labeled wallets with RPC quorum, compute coverage ratio, build salted Merkle tree, publish auditor-signed attestation, expose user verify API.

Publish gate halts if coverage < policy buffer or ledger–Merkle reconciliation fails.

Store roots and proofs in immutable object lock buckets for regulatory history.

javaOne Dark Pro

1 public record PorContext1(String snapshotId, byte[] merkleRoot, long totalLiabilitiesSat) {}

pythonOne Dark Pro

1 def coverage_ratio(assets: int, liabilities: int) -> float:
2     return assets / liabilities if liabilities else 0.0

typescriptOne Dark Pro

1 export function leafHash(salt: string, accountId: string, balance: string): string {
2   return sha256(`${salt}:${accountId}:${balance}`);
3 }

Why interviewers care

Proof of Reserves interviews reward crisp scope, explicit trade-offs, and failure stories—not generic microservice diagrams.

Interview checkpoint

Name one failure story for Problem Statement: Exchange Proof of Reserves that proves you understand real outages, not happy-path diagrams.

Key Highlights

•liabilities ≤ provable assets
•Merkle leaf per user
•Kraken-style PoR
•third-party audit

1	def coverage_ratio(assets: int, liabilities: int) -> float:
2	return assets / liabilities if liabilities else 0.0