Bitbase Proof of Reserves: What It Publishes and How to Check Your Own Balance

2026-09-07

Most exchange transparency pages ask you to read a number and believe it. Bitbase publishes a monthly reserve ratio for four assets, and alongside it a cryptographic root hash that lets you confirm your own balance was counted, on your own machine, without asking the exchange to vouch for the answer. Here is what the disclosure contains, how the check works, and what it still cannot tell you.

Bitbase Proof of Reserves: What It Publishes and How to Check Your Own Balance-bitbase-1445

What Bitbase publishes each month

The commitment is a 1:1 reserve against all user assets, disclosed once a month. Each disclosure carries two things: a reserve ratio for every covered asset, and a single Merkle root hash for that period's snapshot.

The ratio is defined plainly on the proof of reserves page as platform on-chain funds divided by platform user assets, with 100% or above meaning fully reserved. Coverage runs to four assets: BTC, ETH, USDT and USDC.

The figures are a snapshot, not a live feed. The balances counted are the ones on the books on the first of the month, which is why the number you see there can differ from the balance in your account right now. A deposit made after the snapshot is not missing; it belongs to the next period. That timing is the ordinary way this is done, and the reason is that every user has to be counted at the same instant for the total to mean anything.

The August 2026 disclosure, in figures

The August 2026 period was snapshotted on 1 September 2026 and published on 4 September at 10:28 UTC, with the next disclosure due 7 September at 16:00 UTC. Its Merkle root is the hexadecimal string beginning b9d49dd8 and ending 70765e2f, and the algorithm version is labelled POR_V1.

Asset	Reserve ratio for August 2026
BTC	100.78%
ETH	109.03%
USDT	101.96%
USDC	109.06%

Two readings of that table are worth separating. All four sit above 100%, which is what the commitment requires. And this is the first published period, so there is exactly one data point per asset. A single point describes a moment; it does not yet describe a track record, and reading a trend into it would be reading something that is not there. The value of a monthly cadence is what it produces over time, and that accumulation has just started.

Checking your own balance in two clicks

A published ratio is a claim about the whole platform. The part you can check personally is narrower and more useful: whether your account was inside the set that produced it.

Sign in, open My Asset Report, choose the disclosure period, and select one-click verification. The browser takes your verification data, which is a Merkle path, and recomputes the root hash upward from your own leaf, then compares the result against the root published on the public page. Matching roots mean your assets were included in that snapshot.

The computation runs locally. Your verification data is not sent back to a server, which matters because that data describes your balances. If the result says you had no assets in the snapshot, the usual explanation is timing rather than error: no BTC, ETH, USDT or USDC balance existed on the account at the snapshot instant, typically because registration or the first deposit came afterwards.

What the Merkle tree is doing underneath

A Merkle tree hashes a large set of records in layers until everything condenses into one value at the top. Each leaf here is one user's asset data at the snapshot, desensitised and hashed; each layer above combines pairs until a single root remains.

The property that makes this useful is brittleness. Alter, delete or insert a single record and the root changes completely, so a root published on 4 September pins the dataset that produced it. The exchange cannot quietly revise the snapshot afterwards and still show the same root.

The construction is specified rather than described, which is what lets someone else reimplement it. A leaf is a fixed string that opens with the version tag POR_V1, then the audit ID, then the record ID, then the four balances in a fixed order: BTC, ETH, USDT, USDC. Balances always carry eight decimal places. The leaf hash is the SHA-256 of that string.

Each step upward then concatenates two hashes and takes SHA-256 of the result, and the only question at each step is which of the two goes first. The proof file answers it per node: a node marked LEFT is placed before the running hash, a node marked RIGHT after it. Pinning both the string format and the concatenation order is what makes two independent implementations land on the same root instead of two plausible different ones.

Verifying it offline, trusting nobody

The in-browser check is convenient, but it still runs code the exchange served you. For a check that does not, Bitbase publishes an open-source verifier at github.com/BitbaseGlobal/proof-of-reserves-verifier. It needs Node.js 20 or later and has no third-party dependencies, so there is very little to audit before you run it.

Download your verification data as JSON, then run the tool against that file with node, passing your downloaded proof as the argument and adding the root option with the hash you copied from the public page yourself. It exits 0 on success, 1 when the hashes do not verify, and 2 when the file or arguments are malformed. The repository also ships an anonymised example so you can watch the tool work before pointing it at your own file, though that example is a demonstration and not a substitute for your real proof.

Supplying the root yourself is the part that carries the weight. If the tool both computed the root and told you what to compare it against, the comparison would be circular. Copying the published value in by hand is what turns the exercise into an independent check.

What this proves and what it does not

Proof of reserves is a mechanism with a defined edge, and Bitbase states one limit outright on its own page: this is not equivalent to an audit, and it does not constitute an audit opinion from any firm.

Settled by the disclosure	Not settled by it
Your balance was in the snapshot	Whether every liability was reported
Reserve ratios at the snapshot instant	Anything that happened afterwards
The snapshot cannot be edited after publication	Whether the on-chain funds are exclusively the platform's

The middle row of the right column is why a monthly rhythm matters more than any single strong number. The right column's other two rows are structural to this class of mechanism rather than specific to any one venue: reserves are the asset side, and proving liabilities is the harder half, while on-chain balances demonstrate control at a moment without demonstrating that the coins were not borrowed for it.

None of that makes the disclosure hollow. It makes it one input among several, to be read next to how an exchange splits hot and cold storage and which custody model it runs, which is the frame the wider guide to researching an exchange sets out.

The bottom line

Bitbase discloses monthly reserve ratios for BTC, ETH, USDT and USDC together with a Merkle root, and the August 2026 period reports all four above 100%. The ratio is the exchange's claim; the root is what lets you test your own slice of it.

Doing that test takes two clicks in My Asset Report, and doing it in a way that depends on nobody takes one command against the open-source verifier with a root hash you copied yourself. Neither is an audit, and neither says anything about the month after the snapshot. Both are considerably better than taking a number on faith. To keep learning the fundamentals, follow more from Bitbase Academy.