Overview
The proof of reserves MEXC published for October 2026 puts its Bitcoin reserve ratio at 294%, USDT at 122%, USDC at 115% and Ether at 111%, audited monthly by the blockchain security firm
Hacken. Those figures answer one specific question: whether, at a snapshot moment, the on-chain assets a platform holds cover the user liabilities it has declared.
They answer nothing about who holds signing authority over a hot wallet or how operational endpoints are isolated. The
Binance security incident draws that boundary sharply. A reserve ratio of 100% or 300% would have done nothing to stop an EIP-7702 delegation from emptying a hot wallet. Reserves nonetheless decide whether an exchange can absorb the loss afterwards, and that is the half of the question users are actually asking.
Key Takeaways
Proof of reserves combines three checks, covering liabilities, ownership and the reserve calculation, and together they speak to whether assets cover liabilities while saying nothing about internal controls or operational security. A Merkle tree lets a user verify that their own balance was included in the declared liabilities, but not that every other account was included. The Public Company Accounting Oversight Board's March 2023 investor advisory states plainly that these reports are inherently limited and do not address total liabilities, the rights of asset holders, borrowed assets, or asset availability after the snapshot. Most published reserve ratios are self-reported rather than audited, and the two carry different evidential weight. MEXC's figures come with a monthly Hacken audit covering proof of liabilities, proof of ownership, the reserves calculation and Merkle tree verification.
The Question Proof of Reserves Answers
Proof of reserves is not a single action but a combination of three checks, and dropping any one of them changes what the conclusion means.
Component | What it examines | What it cannot establish |
Proof of liabilities | All user deposits and outstanding loans, producing a liability report without exposing individual data | Whether accounts or affiliate obligations were excluded from the count |
Proof of ownership | On-chain verification, contract analysis and signed messages demonstrating control of the relevant addresses | A signature shows key access at that moment, not exclusive or continuing control |
Reserves calculation | Assets under custody valued at live prices and set against declared liabilities | Whether assets are owned or borrowed, and whether they remain available after the snapshot |
The one row a Merkle tree verifies
A Merkle tree lets an individual user confirm that their balance was counted in the platform's declared liability total without seeing anyone else's data. The user takes the proof path for their own record, hashes it up through each level to the published root, and a match confirms the record was in the tree when the report was generated.
That verification covers exactly one row. It says nothing about whether other accounts were fully included, which makes a Merkle proof evidence of inclusion rather than evidence that the liability total is complete. An account left outside the tree leaves every proof inside the tree intact.
The Questions Proof of Reserves Cannot Answer
The
PCAOB investor advisory of March 2023 states that reports of this kind are inherently limited, addressing neither total liabilities, nor the rights of asset holders, nor borrowed assets, nor asset availability after the snapshot, nor internal controls. Those exclusions map almost exactly onto the misreadings that occur in practice.
Everything outside the snapshot
A reserve ratio describes a single instant. Assets can arrive before the snapshot and leave after it, and a snapshot cannot distinguish owned assets from borrowed ones. A report showing 120% evidences 120% at that moment, not on every day thereafter. This is why audit frequency carries weight: monthly and annual reporting share a format while differing several times over in coverage density.
The blind spot on the liability side
Assets are visible on-chain and liabilities are not, which makes the liability side the weakest part of the method. A Merkle tree authenticates only the records placed inside it, so excluded accounts and affiliate obligations leave no trace. Bank borrowings, tax obligations, intra-group guarantees and litigation exposure all sit outside the format, and they are real liabilities that appear in no reserve ratio.
A naive Merkle sum tree also allows an operator to insert fabricated accounts carrying negative balances to shrink the apparent liability total. The industry response has been to add zero-knowledge proofs constraining each batch so that no net balance is negative, though the circuits themselves can carry implementation flaws. In February 2023 an audit firm found a missing range check in one major exchange's circuit, fixed after disclosure, and proofs generated before the fix could not be treated as valid.
A signature is not exclusive control
Proof of ownership rests on signed messages, and a signature establishes only that someone could use that address's key at the moment of signing.
Kraken states on its own page that the method cannot prove exclusive possession of private keys. Assets already staked or pledged as collateral look identical on-chain to unencumbered ones.
Operational security sits entirely outside the scope
This is the most direct lesson of the Binance incident. What the attacker obtained was the ability to have a signature request approved rather than the private key itself, and the initial official investigation points to a compromised DevOps engineer's laptop while reporting no evidence of a wallet private key leak. No component of a proof of reserves touches endpoint isolation, the permission boundary of a service container, or the approval path for a signature request. An exchange holding three times its liabilities is no better placed against that class of attack than one holding exactly enough.
The Boundary the Binance Incident Drew
Setting out the questions users actually asked after the incident makes the scope of proof of reserves plain.
What users want to know | Can proof of reserves answer it | What actually determines it |
Do the platform's assets cover my balance | Yes, as of the snapshot | The reserve ratio and the audit frequency |
Was my balance counted in declared liabilities | Yes, for my own row only | The Merkle proof path |
Will the platform be hacked | No | Key management, endpoint isolation, signature approval controls |
Can the platform absorb a loss on its own | Partly | Reserve headroom, the size of any protection fund, company funds |
When will withdrawals resume | No | The progress of incident response and security checks |
Do the books still balance once assets are replenished | Yes, at the next snapshot | The proof of reserves published after the incident |
The fourth row is where proof of reserves genuinely did work in this incident. Binance has said the SAFU fund and company funds will cover all losses, and whether that commitment holds depends on the headroom on its balance sheet, which is precisely what reserve data describes.
Chainalysis chief executive Jonathan Levin put the theft at about $6.4 billion with roughly $3 billion frozen in remarks at 05:01 UTC on October 30. Binance has said it will update its proof of reserves after remediation, and as of 09:30 UTC on October 30 that update has not appeared and withdrawals remain suspended.
The last row points to the only reliable basis for checking afterwards. The first proof of reserves published after an incident says more than any rolling figure released during it, because it reflects the loss and the replenishment at the same time.
Published reserve ratios do not carry equal weight. Most platforms publish self-reported figures with no third-party conclusion attached. Some use agreed-upon procedures, where the audit firm lists findings without expressing an opinion. A few listed platforms such as
Coinbase publish audited financial statements, which give an opinion on the entire balance sheet including liabilities.
The difference is invisible in calm periods and magnified after an incident. Before comparing percentages across platforms, establish who issued the figure, which components it covers, and how often it appears.
MEXC's October Reserve Data
The proof of reserves MEXC published for October 2026 shows a Bitcoin reserve ratio of 294%, USDT at 122%, USDC at 115% and Ether at 111%, all four above the 100% benchmark with Bitcoin carrying the widest margin. Hacken performs the audit monthly across proof of liabilities, proof of ownership, the reserves calculation and Merkle tree verification, and the custodial wallet addresses are published so that users can check on-chain holdings themselves.
Anything above 100% is headroom rather than redundancy. A ratio of 111% means that after covering every declared liability about 11% remains, space that earns nothing in normal operation and exists for the occasions when something goes wrong. The companion to it is a protection fund, and MEXC's currently holds more than 100 million USDT and 2,000 BTC, 1,000 of which were added in September as the second Bitcoin allocation of the year after an initial one in May, with a stated target of $500 million within two years.
Two checks are available to a user without relying on any further statement from the platform. The
proof of reserves page provides the Merkle proof path for an individual account, confirming that the balance was counted in declared liabilities, and the published custodial addresses allow on-chain holdings to be verified in a block explorer.
What to Look at Beyond Reserves
Proof of reserves addresses solvency and nothing wider. Key management and endpoint isolation determine whether an incident happens at all; reserve headroom and a protection fund determine whether it can be absorbed; and product range, fee structure and liquidity depth determine whether a platform suits how someone actually trades. These belong to different documents, and
MEXC's platform overview covers the last of them, separately from the reserve data.
Conflating them is the most common error of judgment after an incident. A platform with a high reserve ratio may have gaps in operational security, and a platform with a clean security record may disclose its liabilities thinly. Each has to be checked on its own terms.
Exclusive View from James Mitchell
The two most common reactions to proof of reserves after this incident both miss the point. One holds that the method has been discredited, since it stopped nothing. The other treats the reserve ratio as a safety score and ranks platforms by percentage. Both apply the tool to a question it was never built to answer.
Proof of reserves is by design a statement about assets against liabilities, not a security assessment. Its value is in some ways clearer after an incident than before one. When an exchange announces that it will absorb $6.3 billion from its own funds, the only material against which that claim can be tested is its balance sheet, and proof of reserves is the part of that balance sheet a user can check independently. Binance has committed to updating its proof of reserves once remediation is complete, and the timing and content of that document deserve more attention than any rolling frozen total published this week.
The dimension I think gets overlooked is audit frequency. Monthly, quarterly and annual reporting all produce the same percentage in the same format while differing several times over in coverage. The interval between snapshots is this method's structural blind spot, and shortening that interval is the only available way to narrow it. When comparing reserve data across platforms, the frequency and the issuer usually carry more information than the percentage does.
FAQ
Can proof of reserves show that an exchange will not be hacked?
No. Proof of reserves checks the correspondence between declared liabilities and on-chain assets at a point in time, and does not cover internal controls such as key management, endpoint isolation or signature approval paths. In the Binance incident the attacker obtained the ability to have a signature request approved, a class of attack unrelated to how high a reserve ratio stands.
What does a 294% Bitcoin reserve ratio mean?
It means that at the snapshot, MEXC held Bitcoin amounting to about 2.94 times the Bitcoin user liabilities it declared. The portion above 100% is headroom held against unexpected events, and it earns nothing in normal operation.
How do I verify that my own balance was included?
Obtain the Merkle proof path for your account from MEXC's proof of reserves page and hash it up through each level to the published root. A match confirms the record was in the tree when the report was generated. The check covers your own row and says nothing about other accounts.
No. A Merkle tree authenticates only the records placed inside it, so excluded accounts leave no trace, which makes the proof evidence of inclusion rather than of a complete liability total. Off-chain liabilities such as bank borrowings, tax obligations and affiliate guarantees also sit outside the format.
Does it matter how often proof of reserves is updated?
Yes. A reserve ratio describes a single instant, and the interval between snapshots is the method's structural blind spot. Monthly and annual reports share a format while differing several times over in coverage density. MEXC's reserves are audited monthly by Hacken.
What is the difference between a self-reported and an audited reserve ratio?
A self-reported figure carries no third-party conclusion. Under agreed-upon procedures an audit firm lists findings without expressing an opinion. An audited financial statement from a listed company gives an opinion on the whole balance sheet including liabilities. The three differ in evidential weight, so establish how a figure was produced before comparing it with another.
When will Binance update its proof of reserves?
Binance has said it will update its proof of reserves data after remediation and publish a full technical post-mortem. As of 09:30 UTC on October 30, 2026, neither has been released, and withdrawals remain suspended, with the exchange saying it expects resumption to begin within 48 hours.
What part of a proof of reserves should I look at after an incident?
The first report published after the incident carries the most information, because it reflects both the loss and the replenishment of assets. Read the issuer and the components covered first, then the audit frequency and the snapshot date, and only then the percentage.
Disclaimer
This article is for general information only and does not constitute investment, financial, legal or tax advice. Figures are current as of 09:30 UTC on October 30, 2026, the Binance security incident is still developing so amounts and service status may change with subsequent official disclosures, and reserve data should be read from each platform's most recent published report. Crypto assets are highly volatile and can produce losses exceeding the initial outlay. Readers should verify the original disclosures and judge independently, consulting a qualified professional where appropriate.
About the Author
James Mitchell specializes in technical analysis, market trends, and trading strategies for both Bitcoin and altcoins. Based in London, he has over 10 years of experience in financial markets. Before joining MEXC Learn, James worked as a senior analyst at a leading European investment firm, where he developed expertise in risk management and quantitative trading. His transition to cryptocurrency markets began in 2017, and he has since become recognized for his data-driven approach. He holds a Master's degree in Financial Economics from the London School of Economics. His analytical approach combines traditional technical analysis with on-chain metrics to provide readers with actionable insights.
Areas of Expertise: Technical Analysis, Market Trends and Cycles, Trading Strategies, Bitcoin and Altcoin Analysis, Risk Management.
Research References