Skip to content
Quantix Security Labs

Proof of Reserves Methodology

A credible proof of reserves needs both sides of the balance sheet. Quantix designs and reviews the technical process: how custodied assets are attested and tied to on-chain balances, how customer liabilities are committed to in a Merkle tree that each user can verify, and what the result does and does not prove.

Verifiable evidence that assets cover liabilities.

Request an AssessmentVerify an inclusion proof
Dark illustration of a Merkle tree of liabilities with one inclusion proof lit from leaf to root and its sibling nodes outlined, reconciled against stacks of reserve assets.

Service overview

Both sides of the balance sheet, and a way for every user to check.

A credible proof of reserves shows that assets exist and are controlled, that liabilities are committed to in a form users can verify, and states plainly what the result does not prove.

Reserves alone prove little. A wallet balance says nothing about what is owed to customers. A proof of reserves therefore has two halves: an attestation of assets, tied to addresses the entity can prove it controls, and a commitment to liabilities, usually a Merkle tree over every customer balance whose root is published.

Each customer receives an inclusion proof: the handful of hashes needed to recompute the root from their own leaf. If their balance, or anyone else’s, were changed after publication, the root would no longer match. Coverage is then the ratio of verified reserves to committed liabilities, per asset.

Quantix designs the methodology and reviews implementations: the encoding, the tree, the ownership proofs, the reconciliation and the user-facing verification tool.

Commitment
SHA-256 Merkle tree with domain-separated leaves
User check
Inclusion proof verified in the browser
Result
Coverage per asset, with stated limits

Applies to

  • Centralised exchanges
  • Custodians and wallet providers
  • Stablecoin and tokenised-asset issuers
  • Lending desks
Merkle liability treesAddress-ownership proofsBalance reconciliationCoverage reporting
Reserve coverage · Modelled custodial exchange16 customer accounts, 8 reserve holdings, snapshot 30 September 2026, 00:00 UTC. Modelled in Quantix Protocol Research.on-chain verifiedcustodian attestedliabilities (100%)

  • BTC

    11 of 16 accounts hold BTC

    Liabilities
    30.077
    On-chain
    31.9
    Attested
    0
    Reserves
    31.9

    106.1%

    106.1% on-chain only

  • ETH

    13 of 16 accounts hold ETH

    Liabilities
    785.9636
    On-chain
    742
    Attested
    70
    Reserves
    812

    103.3%

    94.4% on-chain only

  • USDC

    16 of 16 accounts hold USDC

    Liabilities
    8,341,886.67
    On-chain
    6,200,000
    Attested
    1,850,000
    Reserves
    8,050,000

    96.5%

    74.3% on-chain only

Threats addressed

How a reserve report can mislead.

Each of these has appeared in real programmes. The methodology is designed so that each one is either prevented or disclosed.
  • Liability omission

    Accounts left out of the tree

    Large or dormant accounts excluded so that liabilities look smaller than they are.

  • Negative balances

    Entries that offset others

    Negative or fabricated accounts included to reduce the total without removing anyone.

  • Window dressing

    Borrowed for the snapshot

    Assets borrowed shortly before the snapshot and returned afterwards.

  • Ownership

    Addresses the entity does not control

    Third-party or exchange-adjacent wallets presented as reserves without a signature from their keys.

  • Double counting

    One wallet, two reports

    The same reserves claimed by two entities, or counted twice through a custodian and directly.

  • Encumbrance

    Assets that are already owed

    Reserves pledged as collateral or lent out, still visible on-chain but not available to customers.

  • Cryptography

    Weak tree construction

    Unprefixed leaves, duplicated last nodes or guessable leaves that leak balances or allow forged proofs.

  • Custodian risk

    Unverifiable custodian balances

    Holdings at a custodian reported without an independent statement or reconciliation.

  • Verification tooling

    A verifier that cannot fail

    User-facing tools that fetch the root from the same server as the proof, or never check it at all.

Technical capabilities

Six parts of a proof of reserves, reviewed together.

Each part can be done well and still leave a gap if the others are weak. Reviews cover the whole chain from wallet to user check.

  • Asset attestation

    Reserves enumerated per asset and chain, with balances read at the snapshot from independent nodes.

    • Snapshot height per chain
    • Before and after checks

  • Liability verification

    The customer ledger reconciled with the tree: every account included once, no negative entries.

    • Leaf count and totals
    • Duplicate and negative checks

  • Merkle verification

    Encoding, prefixes, ordering and proof format reviewed, and the root recomputed independently.

    • Domain-separated hashing
    • Per-user nonces

  • Reserve coverage

    Coverage computed per asset, separating balances verified on-chain from balances attested off-chain.

    • Per-asset ratios
    • No cross-asset netting

  • Custodian verification

    Custodian statements reconciled with the entity’s records and, where possible, with on-chain balances.

    • Statement at the snapshot
    • Scope of the attestation

  • On-chain balance analysis

    Flows around the snapshot reviewed for borrowed or circular funds, and for assets that are encumbered.

    • Inflows before the snapshot
    • Outflows after it

Assessment methodology

From snapshot to a proof every user can check.

The method is published with the result, so anyone can recompute the root and the coverage from the same data.
The seven-stage Quantix workflow
  1. 01

    Define scope and snapshot

    Assets, chains, account types and the exact snapshot time and block height per chain.

  2. 02

    Prove address control

    Signed messages over a fresh challenge from every reserve address, or a custodian statement.

  3. 03

    Reconcile on-chain balances

    Balances read from independent nodes at the snapshot heights and compared with the entity’s records.

  4. 04

    Build the liability tree

    One leaf per account with hashed ID, nonce and balances; negative and duplicate entries rejected.

  5. 05

    Compute coverage

    Reserves divided by liabilities per asset, with on-chain and attested holdings shown separately.

  6. 06

    Publish and enable verification

    Root, method and coverage published; each user receives a proof and an independent way to check it.

How the liability tree is built.

Each customer account becomes one leaf: a hashed account ID, a per-account nonce and the balance of every asset, encoded as a fixed string. The nonce stops anyone from guessing a balance by hashing candidate values. Leaves and interior nodes use different one-byte prefixes, as in RFC 6962, so an interior node can never be presented as a leaf.

BTC
satoshi, 10−8 BTC · 11 accounts
ETH
gwei, 10−9 ETH · 13 accounts
USDC
micro-USDC, 10−6 USDC · 16 accounts
Leaf and node hashing, qx-por-v1text
encoding = "qx-por-v1|" idHash "|" nonce "|BTC=" sats "|ETH=" gwei "|USDC=" microleaf     = SHA-256( 0x00 || UTF-8(encoding) )node     = SHA-256( 0x01 || left || right )      # index-orderedroot     = node at the top of the tree # unpaired node at the end of a level: carried up unchanged# amounts: base-10 integers in the smallest unit, never negative
Index-ordered and sorted-pair hashing compared
Index-ordered (used here)Sorted pairs
Parent hashleft ‖ right by positionsmaller ‖ larger by byte value
Proof containssibling hash and side, per levelsibling hashes only
Binds leaf positionYes: two users cannot be handed the same leaf without noticingNo: needs a separate check for duplicate leaves
Typical usePublished liability trees, transparency logsOn-chain allowlists and claims

Verify an inclusion proof yourself.

The tree below commits to the 16 accounts of a modelled custodial exchange. Pick an account: your browser rebuilds its leaf from the balances, hashes it with Web Crypto, folds in one sibling hash per level and compares the result with the published root. Change any balance, even by one satoshi, and the proof fails.

Published root · 30 September 2026, 00:00 UTC

55a34133c5e21532dcce82d3d0f5919edc402cf665ad636e52ea369c9a830684

16 leaves · depth 4 · SHA-256

1. Pick an account

Hashed account ID
8d325064dcf582e6a0e338e82df6c9e9250abb4be90d9e2811b02ca06d760fb3
Nonce
783d46aec8826c7b812abefab77c1e95

2. Check, or change, the balances

3. Follow the proof to the root

Merkle tree of 16 leaves. The path from leaf 5 to the root is highlighted, with the sibling hash used at each level.8e4b286fac10777c1a3b21d915e7c2be2f1a6ff739a4924b20f6c467a27bae907f3667aa23827b764e7b79533a4a5cdac278e97d73dfd52a66e4cd2b55a301020304050607080910111213141516root

path recomputed in your browsersibling hash from the proofdiffers from the published tree

Verifying…

  1. Leaf encoding

    qx-por-v1|8d325064dcf582e6a0e338e82df6c9e9250abb4be90d9e2811b02ca06d760fb3|783d46aec8826c7b812abefab77c1e95|BTC=286114767|ETH=89066543329|USDC=16321830000

  2. 00Leaf hashSHA-256( 0x00 ‖ UTF-8(encoding) )—
  3. 01Level 1SHA-256( 0x01 ‖ previous ‖ sibling ), sibling 21d9782a…1a2070—
  4. 02Level 2SHA-256( 0x01 ‖ previous ‖ sibling ), sibling 7b76789b…6470ed—
  5. 03Level 3SHA-256( 0x01 ‖ sibling ‖ previous ), sibling c2783c56…765072—
  6. 04Level 4SHA-256( 0x01 ‖ previous ‖ sibling ), sibling cd2b259f…ebf9d0—

Tools & techniques

Standard cryptography, independent data.

Nothing in a proof of reserves should depend on trusting Quantix or the entity’s own tooling. Every primitive is public and every value can be recomputed.
Tools and techniques used for Proof of Reserves Methodology
Tool or techniqueCategoryWhat it is used for
SHA-256 (FIPS 180-4)HashingLeaf and node hashes of the liability tree.
RFC 6962 domain separationTree constructionDistinct leaf and node prefixes, borrowed from Certificate Transparency, to rule out second-preimage forgeries.
Web Crypto SubtleCrypto.digestUser verificationRecomputes the user’s leaf and path in the browser, with no data sent anywhere.
BIP-322 signed messagesAddress controlProves control of Bitcoin reserve addresses, including SegWit and Taproot.
EIP-191 and EIP-1271 signaturesAddress controlProves control of EVM addresses and smart-contract wallets such as multisigs.
Independent full nodesBalance dataBalances read at the snapshot height from nodes not operated by the entity.
Merkle sum treesAlternative designEach node also commits to the sum below it, so totals and non-negativity can be checked from the proof.
Zero-knowledge proofs of liabilitiesAlternative designProves totals and non-negativity without revealing individual balances; reviewed when proposed.

Ecosystem coverage

Technical depth per execution environment.

Address-control proofs and balance queries differ per chain: signature schemes, smart-contract wallets and finality all affect the method.

Ethereum

Layer 1, proof of stake EVM

Programming languages
SolidityVyperYul
Supported standards
  • ERC-20
  • ERC-721
  • ERC-1155
  • ERC-4626
  • EIP-2612
  • EIP-712
  • ERC-1967
  • ERC-4337
Typical vulnerabilities
  • Reentrancy, including read-only reentrancy
  • Oracle and spot-price manipulation
  • Access control on privileged functions
  • Proxy storage collisions and initializer misuse
  • Signature replay across chains and contracts
  • Front-running and MEV exposure
Assessment methodologies
  • Line-by-line manual review
  • Invariant fuzzing (Foundry, Echidna)
  • Symbolic execution and formal verification
  • Economic attack modelling
Monitoring capabilities
  • Proxy admin and implementation changes
  • Governance proposals and timelock queues
  • Large transfers and treasury outflows
  • Oracle deviation against reference feeds

Ecosystems indicate technical specialisation only, not partnerships or endorsements.

Deliverables

A method others can repeat, and a result they can recompute.

Deliverables are written so that a third party with the published data can reach the same root and the same coverage.

  • Methodology document

    Scope, snapshot, encoding, tree construction, ownership proofs and limits.

  • Tree and proof specification

    Exact leaf encoding, hashing, ordering and proof format, with test vectors.

  • Independent recomputation

    Root and coverage recomputed by Quantix from the entity’s data.

  • Ownership evidence review

    Every signature and custodian statement checked against the snapshot challenge.

  • Verification tool review

    The user-facing verifier reviewed for correctness and for where it gets the root.

  • Limitations statement

    What the result does not prove, in language customers can understand.

Reserve holdings and the evidence behind each

Reserve holdings at the snapshot, with custody type and evidence of control
HoldingAmountEvidence of control
R-01Cold wallet ASelf-custody24.5 BTCBIP-322 signed message over the snapshot challenge
R-02Cold wallet BSelf-custody6 BTCBIP-322 signed message over the snapshot challenge
R-03Hot walletSelf-custody1.4 BTCBIP-322 signed message over the snapshot challenge
R-04Cold multisigSelf-custody640 ETHEIP-1271 signature from the multisig over the snapshot challenge
R-05Hot walletSelf-custody102 ETHEIP-191 signed message over the snapshot challenge
R-06Custodian accountThird-party custodian70 ETHCustodian balance statement at the snapshot
R-07Cold multisigSelf-custody6,200,000 USDCEIP-1271 signature from the multisig over the snapshot challenge
R-08Custodian accountThird-party custodian1,850,000 USDCCustodian balance statement at the snapshot

Worked example: holdings are labelled by role; no address belongs to a real entity.

What a proof of reserves does not prove

It is a snapshot
Coverage holds at one moment. Assets borrowed for the snapshot and returned afterwards look identical to owned assets unless the review looks before and after.
Liabilities can be omitted
A user can check that their own account is included, not that every account is. The more users verify, the stronger the assurance.
Encumbrance is invisible on-chain
A wallet’s balance does not show whether the assets are pledged, lent or owed to someone else.
Attested balances rely on the custodian
Holdings at a third-party custodian are only as reliable as the custodian’s statement and its own controls.
It is not an audit of solvency
Other liabilities, operating costs and off-platform obligations are outside the tree. A proof of reserves is evidence, not a financial audit.

Key assessment areas

  • Asset attestation and address ownership
  • Liability tree construction
  • Merkle inclusion proofs
  • Reserve coverage computation
  • Custodian verification
  • On-chain balance analysis

Typical deliverables

  • Verification methodology document
  • Liability tree and proof specification
  • Independent recomputation of reserve coverage
  • User-facing verification tool review

Relevant research

Read the work behind the service.

Research on the signature schemes, cryptographic constructions and on-chain analysis a proof of reserves relies on.
Research hub

Publications

Case studies

All case studies

Research assessments

Security assessments library
Compare all services

FAQ

Questions teams ask before an engagement

No. It shows that, at one moment, the entity controlled assets covering the customer liabilities committed to in the tree. Other liabilities, encumbrance and what happens after the snapshot are outside it. The limitations statement says so explicitly.

Without it, anyone could guess a balance by hashing candidate values with a known account ID and comparing the result with a published leaf. A random per-account nonce, given only to that customer, makes leaves reveal nothing.

So that an interior node can never be presented as a leaf. Without separation, an attacker could build a fake "leaf" from two child hashes and produce a valid-looking proof. The 0x00 and 0x01 prefixes follow RFC 6962.

Yes. The encoding and hashing rules are public. A user can rebuild their leaf and fold their proof with any SHA-256 implementation, and compare the result with a root published independently of the proof, for example in a signed statement or on-chain.

A custodial exchange modelled in Quantix Protocol Research, with 16 accounts and labelled holdings; it is not a real exchange. The tree, proofs and coverage are computed from that model when the site is built, and verified in your browser.

Publish a proof your customers can check.

Tell us which assets and chains are in scope, how customer balances are held and who your custodians are. We will propose a methodology and say plainly what it will and will not prove.

Request an AssessmentSecurity research & advisory