Proof of reserves
Show that customer funds are there, in a form anyone can check.
What it is
Proof of reserves answers one question: does the platform actually hold what its users are owed? It pairs an inventory of on-chain holdings with a cryptographic commitment to the liability side, so each user can confirm their own balance was included.
The hard part is not the wallet list. It is proving control of those wallets, proving no double-counting between them, and constructing the liability tree so a user can verify inclusion without learning anything about anyone else's balance.
What we examine
- Wallet inventory with cryptographic proof of control, not just an address list.
- On-chain holdings verified at a fixed block height, with the height published.
- Liability side committed through a Merkle tree, so every user can verify their own inclusion.
- Double-counting and borrowed-funds checks between wallets and across the snapshot window.
- Coverage ratio stated per asset, not averaged into one flattering number.
- A published verification method your users can follow without trusting us.
- Repeat attestations on a schedule, because a single snapshot proves very little.
What you get
A signed attestation stating coverage per asset at a named block height.
The Merkle root and the tooling your users need to verify their own inclusion.
A public-facing summary written for users, not just for auditors.
The method, published, so a sceptic can check our work rather than take it on faith.
How the engagement runs
- 01
Scope
Assets, wallets, the liability source of truth and the snapshot schedule, plus a fixed quote.
- 02
Prove control
Signed messages or test movements establish that the wallets are genuinely yours.
- 03
Snapshot
Holdings and liabilities captured at one named block height and reconciled asset by asset.
- 04
Publish
Attestation, Merkle root and verification instructions, ready for your users.
What we cover
Languages
- Solidity
- Vyper
- Rust
- Move
- Cairo
- Go
- TypeScript
- Huff
- Yul
Chains
- Ethereum
- Solana
- BNB Chain
- Polygon
- Avalanche
- Arbitrum
- Base
- TRON
- Optimism
- Cardano
- Polkadot
- Cosmos
- NEAR
- Aptos
- Sui
- TON
- Hedera
- Algorand
- Stellar
- Starknet
- ZKsync Era
- Linea
- Sei
- Sonic
- Scroll
- Mantle
- Injective
- Cronos
- Celo
- Gnosis
- Fantom
- Kaia
- Ronin
- Immutable
- Blast
- Berachain
- Monad
- Hyperliquid EVM
- Stacks
- Rootstock
- Kava
- Osmosis
- MultiversX
- Conflux
- Telos
- Theta
- Chiliz
- XDC Network
- Filecoin FVM
- Ontology
- WEMIX
- Fuel
- Taiko
- Polygon zkEVM
- BOB
- Fraxtal
- Mode
- ZetaChain
- Metis
- Manta Pacific
- IOTA EVM
- Neo X
- Unichain
- World Chain
- Soneium
- Abstract
- Ink
- Movement
- Plume
- Etherlink
- EOS
- Flow
- Zilliqa
- Harmony
- Moonbeam
- Astar
- Aurora
Not listed? Ask. If it runs smart contracts, we almost certainly review it.
Questions we get asked
Does this prove we are solvent?
It proves coverage of the liabilities included in the snapshot, at one point in time. It says nothing about off-balance-sheet obligations or what happens the next day. We state that limit in the attestation rather than letting the marketing blur it.
Do our users see each other's balances?
No. The liability tree lets a user verify that their own balance was included in the total, and reveals nothing about anyone else.
How often should we do it?
Quarterly at minimum, monthly if you are a serious exchange. A single snapshot is a marketing exercise; a schedule is evidence.
Often bought with
Compliance and business logic audit
Every feature traced to the licence it triggers, in every market you plan to serve.
Neutral transaction verification
A neutral third party checks both sides of a large transfer before it happens.
Monitoring and incident retainer
Continuous on-chain monitoring with automated response, and a team on call when something moves.
Tell us what you are building and when you launch. Fixed quote in 48 hours.
Get a fixed quote