Read the Date and Coverage First
The June summary lists BTC, ETH, SOL, USDT, USDC, ADA, XRP and USDG as covered assets. Coverage is asset-specific: a bitcoin reserve ratio is not a measure of backing for every currency or product on the platform.
Kraken’s methodology page says spot balances in covered assets are included, onchain staking balances are combined with spot balances, and margin balances receive positive position-value adjustments. Futures collateral has a separate record in the same customer-balance tree; treatment of unrealized profit and loss depends on the futures product. Customers should therefore compare the reported balance with the applicable snapshot methodology, rather than assume it must equal today’s trading-screen balance.
Kraken expressly says verification excludes subsequent trades and transactions and assets outside the review’s scope. Its methodology FAQ lists six assets, while the dated summary lists eight; the dated report’s assessment scope is the relevant reference for a particular review.
Inclusion Is Not Wallet Control
Kraken says the independent accountant aggregates customer balances into a **Merkle tree**, a cryptographic structure with a shared fingerprint called the root. Customers can check that their own balance record connects to that root without publishing everyone else’s balances.
To check inclusion, Kraken directs customers to **Account icon → Proof of Reserves** in Kraken Pro, select the review date and choose **Verify yourself**. Its instructions also allow customers to use their Merkle Leaf ID in the third-party accountant’s verification tool.
That establishes membership in the committed dataset. It does not independently establish that every other customer or obligation was included: confirming one record is not a completeness test of the exchange’s books.
Wallet-control evidence is a separate step. Kraken says the accountant obtains digital signatures produced by the exchange for onchain addresses, then compares their balances with the customer balances represented in the tree. This tests control over the counted funds at the review point. Kraken acknowledges that it cannot prove exclusive possession of the private keys, identify hidden encumbrances or establish that funds were not borrowed to pass the review.
Read the Accountant’s Scope, Not Just Its Name
The June summary identifies The Network Firm LLP but does not state the engagement standard, assurance level or detailed procedures. Those terms are unknown from the summary alone; the accountant’s report, rather than the provider label, is needed to establish them.
The Network Firm’s current description of its Merkle-tree service says it issues CPA attestation reports under AICPA standards and links the report to the published Merkle root. That general service description does not establish the precise terms of the June engagement.
The distinction matters. The PCAOB’s Office of the Investor Advocate explains that agreed-upon-procedures reports provide factual findings, not an opinion on financial stability. A reserve review should not be treated as a financial-statement audit or a guarantee that assets remain available after the snapshot.
Even a correctly included balance and demonstrated wallet control cannot alone prove complete liabilities, unencumbered assets or solvency. Nor do they establish a customer’s contractual withdrawal eligibility or operational access.
These are distinct questions, illustrated—not answered for Kraken—by prior reporting. The Defiant’s Liquid report distinguished reserve coverage and available user swaps from restricted normal federation withdrawals. Its Datavault report distinguished an offchain exchange-account credit from a withdrawal the company said it had been unable to complete. Neither is a finding about Kraken.
Kraken itself notes that keys may have been lost or funds stolen since the latest reserve review: the snapshot cannot establish what happened afterward.
thedefiant.io
