How to Read a Proof of Reserves Report: Every Field and What It Tells You

2026-09-20

A proof of reserves report is a short document with a lot of load-bearing detail. The period identifier says which snapshot you are looking at, the snapshot date says when balances were frozen, the algorithm version says how the tree was built, the root hash is what your own verification has to match, and the per-asset ratios say whether holdings covered balances. This guide goes field by field and says what each one is for and where each one can mislead.

Reading a proof of reserves report: period, snapshot date, algorithm version, root hash and per-asset coverage

What a disclosure actually contains

A disclosure is not a narrative. It is a small set of identifiers and numbers, and almost all of its value sits in whether those identifiers let you tie your own proof file to the published claim.

Everything else on the page is context. The explanation of Merkle trees, the reassurance about privacy, the description of the verification flow: useful for understanding, but none of it is what you check. What you check is a handful of fields that either line up with your own file or do not.

Reading it well therefore means knowing which fields are load-bearing. The rest of this guide takes them in the order they matter.

The fields, and what each one is for

Field	What it is	What to look at
Period identifier	Which disclosure this is	That it matches the period of your proof file
Snapshot date	When balances were frozen	Whether your deposit was before or after it
Algorithm version	How the tree was built	That your verifier implements this version
Status	Whether the period is final	That it is published rather than pending
Root hash	The summary of the whole tree	That it equals the root you compute
Per-asset ratio	Holdings divided by liabilities	That each covered asset is at or above 100%
Coverage list	Which assets are included	Which of your assets are outside the scope

Two of these are identifiers, two are metadata, and three are the actual claim. Mixing them up is how people end up reassured by a report they never checked.

The period and the snapshot date

The period identifier is what stops you comparing the wrong things. Disclosures repeat on a cycle, each one produces its own tree, and each tree has its own root. A root that does not match is meaningless information if you were looking at a different period than your proof file came from.

The snapshot date is the more consequential of the two, because it defines what the report is about. Balances are frozen at that moment, typically the first of the month, and everything after it belongs to the next disclosure. A deposit made the following day is not missing from the report; it is simply not part of this one.

That is also the explanation for the most common alarm. Users who registered or funded an account after the snapshot are told their assets are not in it, which is correct and not a fault. The mechanics of running the check are in how to verify proof of reserves.

The algorithm version and why it is printed

An algorithm version looks like housekeeping and is not. It says exactly how a leaf is composed and how hashes are combined going up the tree, and those choices are not universal.

Two details in particular have to be pinned down or independent verification cannot work. The first is how balances are formatted, since a value written with a different number of decimal places hashes differently. The second is the order of concatenation at each level, because hashing a left sibling before a right one gives a different result than the reverse.

Publishing the version is what makes an independent verifier possible at all. If you are running your own tool, the version on the report is the thing that tells you whether your implementation is the right one for that period, and a version change is a signal to check rather than to assume.

The root hash

The root hash is the one field that does all the load-bearing work. It is a single value derived from every leaf in the tree, and its property is that changing anything at all in the underlying data changes it completely.

That property is why publishing it is a commitment. Once a root is public, the exchange cannot revise a balance, add an account or remove one without every user's verification failing at once. It cannot fix the tree quietly, and it cannot fix it for one person without breaking it for everyone.

Practically, you compare it twice. It has to equal the root recorded inside your own proof file, and it has to equal the root shown on the public page for that same period. Only the second comparison ties your account to the set everyone else was shown, and the structure behind that is explained in what is proof of reserves.

The ratios and the coverage list

The reserve ratio is on-chain holdings divided by user liabilities, and 100% is the threshold. At or above it, the exchange held enough of that asset to cover balances at the snapshot moment.

Read the ratios one asset at a time. A platform can sit comfortably above the line on one coin and below it on another, and any single blended figure across everything it custodies conceals exactly that. Per-asset reporting is more informative than a headline number, and its absence is itself a finding.

Then read the coverage list, which is the field people skip. A disclosure covering four assets makes no claim about a fifth. That is a scope boundary rather than a defect, but it only functions as information if you notice which of your holdings fall outside it.

What is deliberately not in the report

A proof of reserves is a statement about assets at a moment, and three things follow from that which no field in the report will tell you.

It says nothing about liabilities beyond the user balances that went into the tree, so it is not a solvency statement. It says nothing about what happened after the snapshot, since a later transfer changes the position without changing the published root. And it says nothing about whether the on-chain assets were exclusively the platform's, because address control at a point in time is not the same as unencumbered ownership.

None of that makes the report weak. It makes it specific, which is the more useful property, and it is why the liability side needs its own treatment in proof of reserves and liabilities.

The bottom line

Read a disclosure by starting with the identifiers rather than the reassurances. Confirm the period matches your proof file, note the snapshot date and where your own deposits sit relative to it, and check that the algorithm version is the one your verifier expects.

Then read the claim itself. The root hash has to match what you compute, the ratio for each covered asset has to be at or above 100%, and the coverage list tells you which of your assets the report never spoke about. A report that omits any of those fields is not a shorter report; it is one you cannot finish checking. For more from Bitbase Academy, keep reading.