The site's referral record is not registered; the code, benefits and commercial arrangement in the account-opening guide remain unverified. That relationship is why this page describes the limits of the evidence rather than telling you which platform's reserves you should find reassuring. Full disclosure.
What proof of reserves proves, and what it cannot
Proof of reserves is a real piece of evidence about a narrow question. Most of the weight placed on it belongs to questions it was never designed to answer.
A published ratio above 100% reads like a clean bill of health. It is a measurement of one side of a balance sheet at one instant, and four things that decide whether your assets are safe sit outside its frame entirely.
What it actually confirms
Two things, and both of them are worth having.
That the platform controls addresses holding a stated quantity of an asset. The addresses are published, the balances are visible on a public chain, and control is demonstrated cryptographically rather than asserted.
That the total of user balances used in the comparison includes yours. This is the half people skip. A reserves figure with no liability side is just a wallet balance; the proof only means something if the platform also commits to a total of what it owes. Merkle-tree schemes let an individual user verify that their own balance was included in that total, without the platform revealing anyone else's.
That second property is why the individual verification step matters. If users do not check, the platform could in principle omit balances from the total it publishes, and the ratio would look better than it is. The scheme's integrity depends on some proportion of users actually running the check.
The four fields worth reading, and the one worth ignoring
The ratio is the largest number on the page and the least informative. Anything at or slightly above 100% tells you approximately nothing that the next platform's page does not also tell you.
What carries information is the metadata around it.
- Snapshot time and block height. The page above states 01/08/26 00:00:00 UTC at BTC block height 962079. The block height is the part that matters: it pins the claim to a specific, publicly checkable point in a chain's history rather than to a date the platform typed in.
- Verification mechanism. This one states zk-SNARKs. A zero-knowledge scheme lets the platform prove the liability total was computed correctly without publishing individual balances — which addresses a genuine weakness in plain Merkle-tree schemes, where a user could infer things about others' holdings.
- Which assets are covered. The page above shows BTC, ETH, USDT and BNB, with ratios of 100.25%, 100.25%, 103.62% and 100.82% respectively. Assets not on the list are not covered by any of this, and the list is always shorter than the trading catalogue.
- The Merkle root hash. Its presence is what lets you verify your own inclusion. A page without one is publishing a claim, not a proof.
Four fields, none of them the headline. If you only ever read the ratio, you are reading the one number the platform has the most control over presenting well.
The four things it structurally cannot reach
These are not weaknesses in any particular implementation. They are consequences of what the measurement is, and no improvement in methodology removes them.
It does not cover other liabilities
The comparison is reserves against user balances. A company has other obligations: borrowings, payables, judgments, tax positions, commitments to counterparties. None of them appear. A platform can hold assets fully covering user balances and still be insolvent overall, because insolvency is decided by total liabilities, and this measures one category of them.
It does not distinguish owned assets from borrowed ones
The snapshot shows control of addresses at an instant. It does not show how the assets got there or what obligations attach to them. Assets borrowed shortly before a snapshot and returned shortly after satisfy the measurement completely while representing no real coverage. This is not an accusation about anyone; it is a description of what a single-instant measurement can and cannot exclude.
It only covers the assets on the list
Four assets is a meaningful sample and not the whole book. Anything you hold outside the covered set — smaller tokens especially, which are exactly where a shortfall is most likely to be concealed — is unaddressed by the exercise.
It says nothing about any moment after the snapshot
This is the limit people find hardest to hold onto. The proof describes one instant. Everything that happened the following morning is outside it. A monthly cadence produces twelve statements a year about twelve instants and no statement at all about the 353 other days.
Which is why cadence is worth more attention than the ratio. Frequent snapshots do not extend the coverage of any individual proof; they reduce the size of the unobserved gaps between them.
Why this is not an audit
The two are routinely conflated, including by people who should know better, so it is worth stating the difference plainly.
A financial audit examines both sides of a balance sheet over a period, is performed by a licensed firm carrying professional liability for its opinion, follows a defined standard, and produces a signed report someone can be held to. Proof of reserves examines one side at one instant, is usually self-published, follows no common standard, and carries no professional liability.
Some platforms have their proof-of-reserves process reviewed by a third party. That is better than not doing so, and it still is not a financial audit — the scope of the review is the scope of the exercise, which is the asset side at an instant.
The honest summary is that proof of reserves is a good answer to a narrow question and no answer at all to the broad one. It belongs in a pre-funding check as one item among several, weighted accordingly. Our checklist puts it sixth of seven, below the small withdrawal test and below reading the insolvency clause in the terms — both of which tell you more about your actual position.
How to use it anyway
Three things it genuinely supports:
- Verify your own inclusion. If the platform provides the tool, run it. The scheme's value depends on users doing this, and it takes a few minutes.
- Compare a platform against its own history. A cadence that was monthly and has quietly become irregular is a change worth noticing. Comparing one platform's ratio against another's is far less informative than comparing a platform against itself over time.
- Treat absence as information. Not publishing at all, or publishing without a block height, a mechanism or a Merkle root, tells you something — not that anything is wrong, but that this particular check is unavailable to you.
What it does not support is the sentence people most want to derive from it. It cannot tell you your assets are safe, because most of the ways they could fail to be safe are outside what it measures.
What an inclusion check actually tests
The user-facing verifier is not a decorative extra. It is the step that connects your account balance to the liability commitment used in the published calculation. Without it, you know that the platform published a total and you know that it controls some addresses, but you do not know whether your own balance entered that total.
A typical check gives you a record identifier, a balance snapshot, a Merkle path or proof file, and the root against which the proof is evaluated. The interface may run the calculation for you. Record the snapshot date and result, but never paste credentials, recovery codes or private keys into an independent website that claims to verify it. A legitimate inclusion check works from proof data supplied by the platform and does not need authority over your account.
The result has narrow language. A successful check means the balance shown for your record was included in that snapshot's liability commitment. It does not confirm that the balance is the amount you expected unless you compare it, and it does not expand the proof to liabilities or assets outside the published scope.
Build a history instead of comparing headline ratios
One snapshot becomes more useful when placed beside the same platform's earlier snapshots. Keep a simple record with the publication date, block height, covered assets, verification method, whether you could verify inclusion and the link to any third-party report. The goal is not to predict failure from a table. It is to notice changes in what the platform is willing and able to prove.
Changes that deserve a follow-up question include a cadence becoming irregular, an asset disappearing from the covered list, a verification tool no longer accepting current records, a third-party report changing scope, or a snapshot published without the block height that appeared before. None proves a shortfall. Each means the evidence has changed, which is more informative than a tiny movement in a reserve ratio.
Also record restatements. If a platform replaces a snapshot, the useful facts are what changed, why it changed and whether the old file remains available. Quiet replacement makes a history hard to audit; an explicit correction with both versions available strengthens the record even when the original contained an error.
Read the scope before the assurance language
When an accounting or assurance firm is named, open the actual report rather than relying on the logo. Identify the commissioning entity, the measurement date, the assets and liabilities included, the procedures performed and the standard, if any, under which the work was done. A report about an agreed set of procedures is not an opinion on solvency merely because a professional firm performed it.
Pay particular attention to exclusions. Customer balances may exclude certain products, affiliated entities or assets that cannot be supported by the method. Reserves may include assets held with custodians rather than only on-chain addresses. Those can be legitimate boundaries, but the headline ratio is meaningful only inside them.
Finally, check whether the report is addressed to the public, to management or to another specified party. That tells you who the work was designed for and who may rely on it. The name of a firm adds less information than the scope paragraph and the list of procedures. Read those first.
Questions
Does a proof-of-reserves ratio above 100% mean my funds are safe?
No. It means that at one instant the platform controlled addresses holding more of the listed assets than the user balances it reported for them. It says nothing about the platform's other liabilities, whether the assets were borrowed for the snapshot, assets outside the listed set, or any moment after the snapshot was taken.
Is proof of reserves the same as an audit?
No. An audit examines both sides of a balance sheet over a period, is performed by a licensed firm carrying professional liability, follows a defined standard and produces a signed report. Proof of reserves examines the asset side at one instant, is usually self-published, follows no common standard and carries no professional liability. A third-party review of the process is better than none, and still not a financial audit.
Which fields on a proof-of-reserves page actually matter?
The snapshot time and corresponding block height, the verification mechanism, the list of assets covered, and the Merkle root hash. The ratio itself is the least informative number on the page, because almost every platform publishing one shows a figure at or slightly above 100%.
Why does the snapshot time matter so much?
Because the proof describes that instant and nothing else. A monthly cadence produces twelve statements about twelve moments and no statement about the days between them. Frequent snapshots do not widen the coverage of any individual proof; they shorten the unobserved gaps, which is a different and lesser thing.
What does verifying my own inclusion actually do?
It confirms your balance was counted in the liability total the ratio was calculated against. Without that step from some proportion of users, a platform could understate what it owes and the ratio would look better than it is. This is why the individual check exists and why running it, when the tool is offered, is worth the few minutes.