OAK — OnChain Attack Knowledge

Mitigation · OAK-M36 · venue

OAK-M36 — Proof-of-Reserves Cryptographic Auditing

Class
venue
Audience
venue (CEX), risk-team, regulator
Maps to Techniques
OAK-T11.001, OAK-T11.002, OAK-T11.003

Description

Proof-of-reserves (PoR) cryptographic auditing is the venue-side mitigation by which a centralised exchange or custody operator publishes a cryptographic attestation that binds (a) on-chain assets it claims to control, (b) liabilities it claims to owe to depositors, and (c) the per-account inclusion of each depositor in the attested liability set. The mature form is a triple-construction: proof-of-assets (signed messages from claimed-controlled wallets, or ZK-proof of wallet-control without revealing addresses), proof-of-liabilities (Merkle-tree-of-account-balances published as a root with per-depositor inclusion proofs), and the assets ≥ liabilities equality check. Each depositor verifies their own balance is in the tree; the public verifies the assets-side controls and the aggregate liabilities-side root; auditors verify the construction integrity of the two halves. M36 is the cryptographic detection layer for fractional-reserve and rehypothecation failure modes that surfaced catastrophically in the Mt. Gox 2014 and FTX November 2022 collapses, and that remain a structural risk wherever the on-chain user-deposit surface is collapsed into a venue-controlled custody surface.

The structural distinction from a traditional financial-statement audit is that PoR is publicly verifiable on-chain — every depositor can run the inclusion check directly against the published Merkle tree without trusting an audit firm's PDF. The trust model collapses from "the depositor trusts the auditor's claim that the venue's books balance" to "the depositor trusts the cryptographic primitives plus the venue's wallet-control claim". This is not a complete trust collapse — wallet-control claims still rely on signature verification at attestation time, and the liabilities side requires the venue to honestly include all depositors — but it removes the largest historical opacity gap. The post-FTX cohort (Binance, Kraken, Bitfinex, BitMEX, OKX, Crypto.com, Bybit, and others) all rolled out Merkle-tree PoR attestations through 2022–2023; the calibration and integrity vary by venue, and the structural limitations below are well-documented.

The canonical anti-pattern reference set is unambiguous. Mt. Gox (Feb 2014): insolvency hidden for ~2 years; ~850k BTC missing at collapse; no PoR infrastructure; depositors had no verification path. FTX (Nov 2022): ~$8B customer-deposit hole at collapse; Alameda commingling and rehypothecation hidden behind opaque "audit"-class claims that did not include cryptographic depositor-side verification; the structural failure was precisely the absence of M36-class infrastructure. The post-FTX industry-wide PoR rollout was the explicit response: Binance, Kraken, and others framed their PoR publications directly against the FTX-comparison axis. PoR does not eliminate exchange-collapse risk, but it materially narrows the window during which fractional-reserve insolvency can be hidden — provided the attestation cadence is high enough, the construction integrity is sound, and the assets-side claim is independently verifiable.

How it applies

  • OAK-T11.001 (third-party signing / custody vendor compromise): PoR provides indirect detection capability for the depositor-side question "are my assets actually still under the venue's control?". A venue that has suffered a custody compromise but has not yet disclosed it would, under regular high-cadence PoR, either need to admit the loss (assets-side claim updates downward) or commit fraud at the attestation layer (signing for assets it no longer controls). The latter is detectable via on-chain spend-trace cross-checking against the claimed-control wallet set. M36 narrows the disclosure-suppression window for venue-side breach events.
  • OAK-T11.002 (wallet-software distribution compromise): out-of-scope at the venue layer; M36 does not address end-user wallet-software risk, which falls under M30 (per-dApp domain and app-store package allowlist) and adjacent end-user controls.
  • OAK-T11.003 (in-use multisig smart-contract manipulation): partially in-scope where the venue's custody architecture relies on multi-sig contracts that PoR's claimed-control attestation covers. A PoR attestation that signs over multi-sig-controlled wallets, paired with an authority-graph publication for the multi-sig itself, surfaces the in-use-modification surface to public verification.
  • Custody-rehypothecation framing (T11 broadly construed): the canonical M36 surface. The venue claims to hold customer deposits in segregated custody; the actual operational practice may include rehypothecation, internal lending, or commingling. PoR at high cadence with both halves of the construction (assets and liabilities) is the only deterministic public detection layer for this class of failure. The Mt. Gox and FTX cases are both retrospectively classifiable as M36-absence cases: the failure pattern was knowable months-to-years before collapse only via insider visibility, and the depositor-side detection capability was structurally zero.

Limitations

  • Liabilities-side requires a trust assumption. The venue constructs the Merkle tree of depositor balances; depositors verify their own inclusion but cannot verify that the tree contains all liabilities. A venue could omit large depositors from the tree (with their cooperation, e.g., institutional custody arrangements) and the published root would still be valid against the (incomplete) inclusion proofs. Zero-knowledge-proof variants (zkPoR) attempt to address this with proofs over total-liability bounds, but require the venue to commit to a verifier-checkable construction; full elimination of the liabilities-side trust assumption is an open problem.
  • PoR snapshot does not preclude inter-snapshot rehypothecation. A venue can move assets between snapshot times to satisfy each individual attestation while operating insolvent in continuous time. Higher cadence (daily, hourly, near-real-time) narrows this window but does not close it; "borrow-for-attestation" patterns have been alleged against several venues in the post-FTX rollout cohort. The defender posture is to require both high cadence and real-time on-chain monitoring of the claimed-control wallet set (M03-class continuous monitoring of the attestation-bound addresses).
  • Wallet-control claims rely on signature verification at attestation time. A venue can claim control over a wallet by signing a message from it; this proves control at the moment of signing. Subsequent loss of control (key compromise, custody-vendor incident) is not surfaced by the prior attestation. Continuous control verification requires either ongoing signing cadence or independent on-chain monitoring of the claimed wallets.
  • Off-chain assets and liabilities are out-of-scope. PoR is structurally a tool for on-chain custody. Fiat reserves, off-chain securities, off-chain derivative exposures, and intra-corporate-group lending are not addressable via PoR; the venue's full balance sheet requires traditional audit alongside PoR. The FTX failure spanned both on-chain and off-chain commingling; PoR alone would not have caught the Alameda-side off-chain rehypothecation, only the on-chain customer-deposit-segregation failure.
  • Attestation construction integrity varies by venue. Several PoR rollouts in the post-FTX cohort have been criticised for construction issues: tree formats that allow negative balances to cancel positive balances at the aggregation step, signature-set composition that does not cover the venue's full claimed-control wallet set, attestation-firm involvement that operates as a private review rather than a public verification artefact. The defender posture is to read the construction specification, not just the existence-of-PoR claim.
  • Capacity for retrospective verification is limited. PoR is forward-looking: depositors verify going forward. A venue that publishes PoR for the first time after a long period of fractional-reserve operation does not, by virtue of PoR adoption, retrospectively close the prior gap. Several venues in the post-FTX cohort were operating under ambiguity about prior-period reserve status that the new PoR roll-out did not resolve.

Reference implementations

  • BitMEX 2021–present: one of the earliest production Merkle-tree PoR implementations; per-depositor inclusion-proof tooling published; bi-monthly cadence. BitMEX's roll-out predated the FTX-driven industry-wide cohort and has been cited as a methodological reference.
  • Kraken 2022–present: Merkle-tree PoR with depositor-side verification tooling; cadence increased post-FTX; methodology paper published. Kraken framed its post-FTX PoR rollout explicitly against the FTX-comparison axis.
  • Bitfinex 2022–present: PoR published with on-chain assets-side proof and Merkle-tree liabilities-side. The Bitfinex 2016 breach (T11.001 reference case) and the subsequent reserve-publication discipline form the operational backstory.
  • Binance 2022–present: PoR rollout post-FTX with zk-SNARK liabilities-side variant explored; the largest-scale PoR deployment in production. Construction-integrity questions have been raised at the analyst layer; the deployment is the largest single PoR data point in the industry.
  • OKX, Crypto.com, Bybit, Coinbase (institutional custody), and others: post-FTX PoR roll-outs with varying construction quality and cadence; the industry standardisation question (canonical attestation format, regulator-ratifiable spec) remains open.
  • zkPoR research and tooling: the zero-knowledge-proof variant addresses the liabilities-side completeness question via proofs that the published tree contains the full liability aggregate without revealing individual balances. zkPoR implementations are emerging at multiple venues; the cryptographic primitives are mature, but production deployment at scale is still in early phase.
  • Cross-firm standardisation discussion: the post-FTX industry has discussed, without converging on, a canonical PoR attestation format that would allow cross-venue comparability and regulator-ratifiable standardisation. The standardisation problem is at the venue-industry coordination layer; until convergence, M36 effectiveness varies materially by venue-specific construction.

Citations

  • [mtgoxbankruptcy2014] — Mt. Gox bankruptcy announcement (Feb 2014); canonical M36-absence reference where PoR infrastructure would have surfaced insolvency materially earlier.
  • [wizsecmtgox2015] — WizSec post-collapse forensic reconstruction; documents the multi-year gap between actual insolvency and disclosure that PoR would have narrowed.
  • [wizsecmtgox2017] — WizSec breaking-open analysis Part 1; documents the breach-to-bankruptcy timeline.
  • [wizsecmtgox2020] — WizSec breach-to-bankruptcy reconstruction Part 4; the canonical retrospective on the Mt. Gox failure mode.
  • [mtgoxtrustee2024] — Mt. Gox trustee 2024 distribution announcement; the long-tail recovery profile of the canonical M36-absence case.
  • [bitfinexpostmortem2016] — Bitfinex 2016 breach disclosure; the operational-history reference behind subsequent Bitfinex reserve-publication discipline.
  • [chainalysis2024dprk] — broader cohort context for venue-side losses where M36 narrows the disclosure-suppression window for breach events.

Techniques mitigated (3)