Read 2026-10-31 · four exchange APIs · rebuilt daily

What a proof of reserves exchange report leaves out

Merkle tree inclusion and liability suppression

A standard proof of reserves exchange report uses a Merkle tree to let you check if your account balance was included in the audit aggregate. The exchange hashes your account ID and balance into a leaf node, then combines leaf nodes upwards to form a root hash. If your balance is present, your leaf mathematically contributes to that published root hash.

This process proves asset presence, but it relies on complete liability disclosure. The total asset figure published by an exchange is only valid if every single user account is included in the aggregate sum. If an exchange omits accounts with large positive balances, or includes fictitious accounts with negative balances to offset real liabilities, the resulting Merkle root understates total user deposits.

If an exchange holds 10,000 BTC in custody wallets but owes 15,000 BTC to depositors, it can publish a Merkle tree that excludes 5,000 BTC of user accounts. The remaining user accounts will verify their balances against the root successfully, even though the venue is insolvent by 33%.

Snapshot timing and temporary liquidity

Public proofs of reserve are static snapshots taken at a single block timestamp. They do not track continuous asset control over time. An exchange can temporarily inflate its address balances immediately before the snapshot is taken, then move those funds back after the block is finalized.

To execute this balance manipulation, a venue borrows assets from institutional lenders, decentralized finance pools, or sister entities right before the target block height. The borrowed tokens arrive in the exchange wallets, generating an on-chain address snapshot showing full coverage. Once the cryptographic snapshot completes, the venue returns the borrowed tokens along with interest.

The published report reflects wallet balances that existed for only a few minutes. If a venue borrows 2,000 BTC for a two-hour window to pass a monthly snapshot, the resulting attestation shows 2,000 BTC of assets that are no longer present when you open a perpetual trade the following day.

Venue execution costs and live funding comparisons

While proof of reserves addresses long-term balance sheet risks, daily holding costs impact your margin balances immediately. Exchanges charge baseline maker and taker fees alongside periodic funding payments for perpetual contracts.

The table below shows the default baseline taker fees alongside the current 8-hour funding rates for SOL perpetual contracts across four venues.

A negative funding rate means short position holders pay long position holders. Holding a long position on bitget earns 0.0132% per 8-hour interval while carrying a baseline taker fee of 0.0300%. On bybit, holding that same long position costs 0.0100% per 8-hour interval alongside a higher baseline taker fee of 0.0550%.

What a complete financial audit requires

A cryptographic attestation is an automated script execution, not a financial audit. An independent accountant checking a venue balance sheet must evaluate three distinct categories that a Merkle tree snapshot cannot touch.

First, an audit requires verified access to off-chain bank accounts containing fiat currencies. Merkle trees only verify native blockchain tokens. Second, an audit requires inspecting legal liabilities, including corporate debts, outstanding venture loans, and collateralized line-of-credit agreements. Third, an auditor must confirm who holds the private keys to the wallet addresses. If an exchange holds assets in a wallet where a third-party custodian has primary withdrawal authority, those assets are encumbered by contract.

Identifying weak attestations

You can evaluate the strength of a published proof of reserves by looking at three specific technical disclosures in the report documentation.

First, check if the report includes a Zero-Knowledge proof mechanism. Standard Merkle trees allow an exchange to hide negative balance accounts within the tree structure. Zero-Knowledge proofs mathematically prevent any node from containing a negative value, ensuring that no accounts are used to artificially suppress total listed liabilities.

Second, check whether the audit covers third-party borrowing data. If the attestation provider does not cross-examine corporate debt registries and institutional lending platforms, the asset total remains vulnerable to temporary snapshot borrowing.

Third, confirm whether the exchange updates its Merkle root continuously or on a scheduled delay. A monthly attestation leaves 720 hours of unverified wallet movements between snapshots. Continuous or daily cryptographic updates significantly raise the cost of temporary liquidity borrowing for the exchange.

Read next