Proof of Reserves (PoR) gives crypto users a way to check reserve-related information instead of relying solely on an exchange's assurances. On Bitunix, users can review published reserve information and use cryptographic verification to check whether their account record is included in the relevant dataset.
Understanding the result matters just as much as completing the check. PoR can provide evidence of reserve coverage and data integrity, but it is not a complete financial audit or a guarantee that an exchange will always be able to meet every obligation.
What Is Proof of Reserves (PoR)?
Proof of Reserves is a transparency method used by crypto exchanges and custodians to provide evidence of the digital assets they hold in relation to customer balances. Depending on the system, it may combine wallet-ownership checks, reserve data, and cryptographic techniques that allow users to verify account inclusion.
The basic question is straightforward: does the exchange report holding enough of the relevant assets to cover the customer balances included in its PoR calculation?
For example, if a report covers 100 BTC in customer balances and the exchange demonstrates control of 105 BTC in the corresponding reserves, the reported reserve ratio for that asset would be 105%. That figure describes the assets and liabilities included in the report; it does not automatically account for every debt or obligation the exchange may have elsewhere.
PoR is therefore one way to assess exchange transparency. It gives users verifiable information, but the scope and reliability of that information depend on how the verification process is designed and what the report includes.
How Does Bitunix Proof of Reserves Work?
Bitunix Proof of Reserves dashboard showing 156% BTC, 108% ETH, and 105% USDT reserve ratios with Merkle tree verification.
The official Bitunix Proof of Reserves page describes its reserve-ratio calculation, Merkle tree structure, and tools for verifying user assets. Its published explanation centers on checking account records against a cryptographic reference known as the Merkle root hash.
What Is a Merkle Tree?
A Merkle tree is a data structure that organizes many records into a hierarchy of cryptographic hashes. Each account record is represented by a hash, and those hashes are combined in successive layers until they produce a single value called the Merkle root.
Think of the root as a compact fingerprint of a particular dataset. If the underlying data changes, the resulting hashes will generally change too.
This structure makes it possible to verify that a specific record belongs to a dataset without needing to reveal every other record in it. In a PoR system, that can help users check their own balance record while keeping other users' account details private.
What Does a Merkle Root Hash Prove?
A Merkle root helps establish the integrity of the dataset to which it corresponds. With the relevant account data and verification path, a user can check whether their record produces a result consistent with the published root.
However, the root alone does not prove that an exchange controls sufficient on-chain assets, nor does it establish that all liabilities have been disclosed. Those questions require additional evidence about reserve holdings, the scope of reported liabilities, and the verification process.
That distinction is important: cryptographic inclusion, reserve coverage, and overall solvency are related but separate questions.
How Account Balance Verification Works
At a high level, the verification process works as follows:
Account balance information is represented in a cryptographic data structure.
The data is combined through successive hashing steps to generate a Merkle root.
A user obtains the verification information associated with their account and the relevant report.
The verification tool checks whether the account record and its proof are consistent with the published root.
A successful check supports the conclusion that the submitted record is included in the dataset represented by that root. To assess reserve coverage, users should also review the corresponding reserve figures and understand which assets and liabilities the report covers.
How to Verify Your Assets on Bitunix
Bitunix provides an online verification process and an open-source Proof of Reserves verification tool. The exact interface may change, so use the current official page and instructions rather than relying on outdated menu names.
How to verify your assets using Bitunix Proof of Reserves in four steps.
Step 1: Open the Official Proof of Reserves Page
Visit the Bitunix Proof of Reserves page. Review the available report information and locate the option to verify your assets.
For account-specific records, you may need to sign in to Bitunix. Always access the service through the official website, and do not share passwords, authentication codes, or private keys with anyone claiming to help with verification.
Step 2: Open Your Account Verification Record
Follow the verification option shown for the relevant report. Depending on the available interface, you may be able to open your account record directly or copy its Merkle leaf information for a separate verification check.
A Merkle leaf is the hash representing a record at the bottom layer of the tree. Use the record associated with the report you want to verify; information from a different report may not match its Merkle root.
Step 3: Submit the Verification Information
If the interface provides an online verifier, select the appropriate report and enter or paste the required verification information. Submit the check and review the result.
If the result indicates that verification succeeds, it means the submitted record is consistent with the relevant Merkle tree root under that verification process. It does not independently establish that every exchange liability has been disclosed or that the platform is free of financial risk.
Step 4: Verify with the Open-Source Tool if Needed
Bitunix also publishes a verification tool in its official GitHub repository. The repository describes a workflow that uses the verification program and the corresponding merkle_tree_bitunix.json data file.
If you choose this route, follow the current repository instructions carefully:
Obtain the relevant verification data and tool from official Bitunix sources.
Download the version appropriate for your operating system and architecture.
Follow the repository's instructions to place the required data file and run the verifier.
Review whether the result reports a match with the Merkle root hash.
The repository describes a successful result as “Consistent with the Merkle tree root hash. The verification succeeds”. If the result is inconsistent, check that you are using the correct report, matching data file, and compatible tool version before drawing conclusions.
What If Your Account Has No Verification Record?
An account may not appear in a particular report for several reasons. For example, Bitunix's asset verification help guide notes that an account created after an audit, or an account that does not hold the audited tokens, may not have a corresponding record in that report.
A missing record should not automatically be interpreted as proof that funds are missing. First, check the report date, the assets covered, and whether your account existed when the dataset was prepared. If the result remains unclear, contact Bitunix support through official channels.
How to Read Bitunix Reserve Ratios
The Bitunix PoR page defines its reserve ratio as:
Reserve ratio = Funds on the platform ÷ Funds of users × 100%
The ratio compares the reported platform funds with the corresponding reported user funds. Its meaning depends on the assets covered and the underlying data used in the calculation.
What Does a Reserve Ratio of 100% or Higher Mean?
A ratio of 100% means the reported reserve amount equals the corresponding reported user balances. A ratio above 100% means the reported reserves exceed those balances for the asset being measured.
For example, a reported reserve ratio of 105% indicates that the reported reserve amount is 1.05 times the covered user balances. It does not mean that every possible liability across the exchange's business is covered.
Compare like with like. If a report measures BTC reserves against BTC-denominated customer balances, a surplus in another asset should not automatically be treated as a substitute for a shortfall in BTC. Check the report's asset-by-asset figures and methodology before interpreting the overall result.
Why Reporting Dates and Asset Coverage Matter
PoR is generally based on data collected at a particular point in time. Deposits, withdrawals, trading activity, and changes in asset holdings can occur after the snapshot is taken.
When reviewing a report, check:
Reporting date: When were the reserve and account data recorded?
Asset coverage: Which tokens and customer balances are included?
Reserve evidence: How are the reported assets identified and verified?
Liability scope: Does the process establish only the inclusion of customer balance records, or does it also provide evidence about the completeness of liabilities?
Verification method: Can users independently check their account records against the published cryptographic data?
These details help put a reserve ratio into context. A single percentage without its reporting date, asset scope, and methodology offers only a partial view.
What Are the Limitations of Proof of Reserves?
PoR can improve transparency, but it should not be treated as a complete measure of an exchange's financial health.
The PCAOB's investor advisory on Proof of Reserve reports warns that these reports have inherent limitations and should not be relied on alone to conclude that an entity has sufficient assets to meet all customer liabilities. The U.S. SEC's investor bulletin on alternatives to financial statement audits also explains that PoR-style reports may not provide a complete picture of an entity's liabilities or financial position.
PoR Does Not Necessarily Show Every Liability
A reserve report may show assets held and compare them with a defined set of user balances. It does not necessarily capture every borrowing, contractual obligation, or other liability the business may have.
This is why evidence of reserves should not automatically be described as proof of solvency. A fuller assessment would require evidence about both assets and liabilities, along with the scope and quality of the relevant review.
PoR Is Not a Guarantee of Future Withdrawals
A report reflects the information available for its reporting period. It cannot guarantee that the same assets will remain available later, that market conditions will not change, or that withdrawals will always be processed without delay.
PoR is best understood as one transparency measure, not a promise about future outcomes.
Independent Verification and Reporting Frequency Matter
The strength of a PoR process depends on its methodology, the reliability of the underlying data, the evidence supporting asset ownership, and whether the review is independent where applicable. Reporting frequency also matters because older data may not reflect current holdings and balances.
When assessing an exchange, look beyond the headline ratio. Review the published methodology, the date of the report, the assets covered, and the verification options available to users.
