Proof of reserves vs self-custody: what 'not your keys' really means for traders

Contents

1. The false comfort of a healthy ratio
2. What proof of reserves actually checks
3. Three failure modes PoR cannot detect
4. Why zk-SNARKs close some gaps but not all
5. What "not your keys" actually means
6. The self-custody spectrum
7. The honest trade-off
8. Five questions every trader should answer right now
9. The gap PoR was never designed to close
10. FAQs

Proof of reserves was supposed to fix the trust problem. After FTX collapsed in November 2022, exchanges rushed to publish Merkle tree snapshots and third-party attestations. The message was clear: look, we have your money. The problem is that FTX also had proof of reserves snapshots that looked fine - right up until they didn't.

PoR is not a lie. It's a specific tool with specific limits. Most traders treat it as a solvency guarantee. It isn't. Understanding the gap between what PoR proves and what it doesn't is the difference between informed risk management and false comfort.

The false comfort of a healthy ratio

Recent PoR reports look reassuring on the surface. Kraken's March 2026 snapshot showed a 101.6% BTC collateralisation ratio. Phemex published April 2026 figures showing 131% overcollateralisation. MEXC's May 2026 Hacken audit reported 293% BTC reserves against liabilities. All healthy numbers.

But those ratios don't answer the only question that matters: are those reserves actually there at the moment you need to withdraw?

What proof of reserves actually checks

A standard PoR audit works like this. The exchange takes a snapshot of its on-chain wallets at a specific point in time. A third-party auditor constructs a Merkle tree of customer balances, letting individual traders verify their own balance is included in the total. The auditor confirms the exchange controls the wallets holding those assets.

The math checks two things: that the sum of individual balances matches the claimed total, and that the exchange controls wallets with at least that much on-chain.

It does not check:

• Off-chain liabilities - undisclosed loans, rehypothecated assets, or counterparty obligations that don't appear in the snapshot
• Operational security - whether the exchange's signing infrastructure, multisig setup, or internal controls are sound
• Continuity - whether the reserves shown at snapshot time are still there a week, a day, or an hour later

These aren't edge cases. They're the exact failure modes behind the largest losses in crypto exchange history.

Three failure modes PoR cannot detect

Custodial loans and rehypothecation

FTX is the canonical example. The exchange reportedly moved approximately USD 8 billion in customer funds to Alameda Research, its affiliated trading firm. PoR snapshots taken during that period showed healthy reserve ratios because the methodology didn't capture the liability side of that transfer. The assets appeared on-chain in exchange wallets. The loans to Alameda did not appear in the audit.

Rehypothecation - using customer deposits as collateral for exchange-level borrowing - is structurally invisible to any snapshot-based audit. The assets can be present at the moment of the snapshot and gone by the time you request a withdrawal.

Operational security failure

Bybit lost approximately USD 1.5 billion in February 2026 in a single attack attributed to the Lazarus Group. This wasn't a smart contract exploit or a broken cryptographic primitive. Attackers compromised the signing interface used by Bybit's multisig signers. The signers approved a transaction that looked legitimate on their screens but executed a different payload. The funds were gone before anyone realised what had happened.

No PoR system detects this. The reserves were real. The signing infrastructure was compromised. Proof of reserves tells you nothing about whether the people and systems controlling those reserves are actually secure.

Snapshot gaming

Cobo and Web3.com Ventures analysis has documented a straightforward manipulation: exchanges borrow reserves for the snapshot period and return them afterward. The snapshot shows full collateralisation. The borrowed assets leave immediately after the audit window closes.

Zondacrypto's 2026 collapse in Poland illustrated the continuity problem directly. Hot wallet reserves fell 99.7% between consecutive PoR reports. The snapshots themselves showed healthy figures. The gap between reports was where the problem lived. Continuous monitoring would have caught it. Periodic attestations didn't.

Why zk-SNARKs close some gaps but not all

Vitalik Buterin proposed using zk-SNARK proofs to improve on standard PoR. The idea: prove cryptographically that the sum of all individual balances is less than or equal to total reserves, without revealing individual account data. This closes the liabilities gap. An exchange can't hide undisclosed obligations if the proof covers the full liability side of the balance sheet.

That's a meaningful improvement over snapshot-based Merkle tree audits. But it still doesn't address operational security. A zk-SNARK proof that reserves match liabilities says nothing about whether the exchange's multisig signers will approve a malicious transaction tomorrow. Cryptographic proof of solvency and cryptographic proof of security are different problems.

What "not your keys" actually means

The phrase gets repeated so often it's become noise. Here's the mechanic.

A private key is spending authority. Whoever controls the private key controls the asset. When you deposit funds on a centralised exchange, you transfer that spending authority to the exchange. What you receive in return is a credit - an IOU. The exchange owes you the asset. You don't own it on-chain.

An IOU is only as good as the counterparty behind it. If the exchange is insolvent, compromised, or frozen by a regulator, your IOU may be worth less than the underlying asset it represents. You have a claim. You don't have the coins.

A 2026 survey of approximately 3,000 US crypto holders found that 66% consider self-custody important and 46% specifically fear major exchange breaches. Yet 88% still store the majority of their holdings on centralised exchanges. Most traders know the risk. They accept it anyway, usually for convenience.

The self-custody spectrum

Self-custody isn't binary. There's a range of options, each with different trade-offs between security and operational speed.

Full cold storage is maximum security. Your private keys never touch an internet-connected device. The trade-off is zero trading speed. You can't open or close a position in seconds from a hardware wallet sitting in a safe.

Hot wallet gives you maximum speed. Keys are accessible. The trade-off is maximum exposure - a compromised device or browser extension means the keys are gone.

On-chain perpetual margin on Hyperliquid sits in a different category. Your margin lives on-chain, not in an exchange's internal database. It's not held by Hyperliquid's front-end, and it's not held by any interface you use to access the protocol. You can verify your balance on-chain at any time. Matching, margin, funding, and settlement all happen on Hyperliquid's on-chain central limit order book.

This architecture closes the specific risk PoR tries and often fails to address: custodial counterparty risk. Your funds aren't an IOU from anyone.

Stacked Markets is a front-end terminal built on top of Hyperliquid's protocol. It holds zero user balances and zero signing keys. Every order you place is signed by your wallet and routed directly to Hyperliquid's on-chain CLOB. If Stacked Markets disappeared tomorrow, your funds would still be on-chain, accessible through any other Hyperliquid interface or directly through the protocol. The optional agent wallet is a local, browser-based signing key - it never reaches Stacked servers. You can verify the custody claim on-chain.

The honest trade-off

Non-custodial architecture eliminates custodial counterparty risk. That's a specific, meaningful thing. It's not the same as eliminating all risk.

Smart contract vulnerabilities, oracle manipulation, and governance attacks are real risks in on-chain systems. A compromised oracle can trigger incorrect liquidations. A governance attack can alter protocol parameters. These risks exist on Hyperliquid as they do on any on-chain protocol.

The distinction matters because PoR is specifically a response to custodial counterparty risk - the risk that the exchange holding your funds is insolvent, dishonest, or compromised. Non-custodial architecture addresses that specific risk directly. It doesn't address smart contract risk, and it doesn't claim to.

Moving from a CEX to an on-chain perp DEX is a trade: you eliminate the risk that an exchange misappropriates or loses your funds, and you accept the residual risks of the on-chain system you're using instead. That trade is worth making in most cases. Make it with clear eyes.

Five questions every trader should answer right now

Before you trade another position, you should be able to answer these about where your funds actually are:

1. Who controls the private keys to your trading margin? If the answer is "the exchange," your funds are an IOU.
2. When was the last PoR audit for the exchange holding your funds, and what methodology did it use? Merkle tree snapshots are better than nothing. They don't cover liabilities.
3. Does the exchange publish continuous on-chain wallet monitoring, or only periodic snapshots? Zondacrypto's collapse happened between reports.
4. What is the exchange's multisig structure, and has it ever been publicly audited? The Bybit attack exploited the signing interface, not the cryptography.
5. If the exchange froze withdrawals tomorrow, what would your legal claim be, and how long would it take to resolve? This is the IOU question in practical terms.

If you can't answer all five, you're holding custodial risk you haven't priced in.

The gap PoR was never designed to close

Proof of reserves verifies one specific thing: that an exchange's on-chain assets exceeded its reported customer liabilities at a given moment. That's it. It doesn't verify operational security. It doesn't verify the absence of undisclosed liabilities. It doesn't guarantee those reserves will be there when you need them.

"Not your keys" isn't a slogan. It's a description of how spending authority works on a blockchain. If you don't control the private key, you don't own the asset - you own a claim against whoever does. That claim is only as secure as the counterparty behind it.

On-chain perpetual trading on Hyperliquid, accessed through a non-custodial front-end, is one of the few trading architectures where you can actually verify custody rather than trust a snapshot. Your margin is on-chain. Settlement is on-chain. The risk you're taking is protocol risk, not counterparty risk. Those are different risks and they require different due diligence.

The traders who got hurt in FTX, in Bybit's breach, and in Zondacrypto's collapse weren't naive. They trusted PoR reports and exchange reputations. The architecture failed them, not their reading of the numbers.

---

Test the non-custodial architecture yourself before committing real capital. Stacked Markets has a testnet mode with full terminal functionality and clear network badges.

stackedmarkets.com

FAQs