Onchain Proof of Reserves: The Double-Count Trap

Onchain proof of reserves is a method for verifying a token's supply and the balances held at an issuer's disclosed addresses. It does not verify the off-chain reserves themselves. It can confirm two things directly: how many tokens an issuer has minted, and how much of a given asset sits in the wallet addresses the issuer claims. It cannot, on its own, confirm that a bank account holds the dollars behind a fiat-backed stablecoin. That last mile still requires an attestation from a third party.

For a finance or risk team evaluating an issuer, the whole job fits in one sentence: onchain supply is not proof of backing. You can verify the liability side of the balance sheet (tokens outstanding) with total independence. You can verify onchain assets (crypto collateral in disclosed wallets) with the same independence. The moment reserves leave the chain, into T-bills, cash, or a custody account, you are back to trusting a signed statement.

The supply number you can verify is usually wrong

Here is the uncomfortable part. Even the half of the balance sheet you can read directly from the blockchain, the liability side, is commonly computed wrong. The naive method is to sum totalSupply across every chain a token lives on and call that the circulating supply. That number is inflated, often by billions, because bridged and wrapped representations of the same token get counted as if each were independent issuance.

The mechanics are simple. When a token moves from Ethereum to another chain through a bridge, the original is typically locked and a new representation is minted on the destination chain. Both now report a positive totalSupply. Sum them, and you have counted the same underlying dollar of liability twice. Wrapped versions behave the same way. The token contract on each chain is telling the truth about its own supply. The error is in the addition.

On Allium data for 23 September 2026, this is what the gap looks like across stablecoins.

A reader can reproduce this adjustment against their own data. The screen is native versus bridged: for each chain a token appears on, classify its supply as native issuance (minted directly by the issuer's contract on that chain) or as a bridged or wrapped representation of supply that was already issued elsewhere. Sum only the native issuance. Everything classified as bridged is a claim on liability already counted at its origin, so including it double counts. The $29.31B flagged as bridged does not net exactly to the $23.97B overstatement because the two figures are measured differently: one is the gross bridged total, the other is the net effect on the deduplicated supply figure after accounting for how those representations relate to their native origins.

The discipline holds throughout: this adjustment corrects the liability count, and a correct liability count still says nothing about whether reserves back it. It only means that when you compare supply to reserves, you are comparing the reserves against the real liability rather than an inflated one.

Key takeaways

• Summing totalSupply across chains double counts bridged and wrapped tokens. On Allium data for 23 September 2026, that overstated stablecoin supply by $23.97B ($337.71B raw versus $313.74B native). Deduplicate to native issuance before comparing supply to reserves.
• Onchain proof of reserves verifies the assets an issuer holds in disclosed wallets and the liabilities (token supply) it has minted. Solvency is assets minus liabilities, so a credible proof needs both sides, not just a large reserve wallet.
• Onchain supply is checkable by anyone from the token contract. Off-chain reserves (bank cash, Treasuries) are not on any blockchain and cannot be proven onchain. That gap is filled by an attestation, not by code.
• A Merkle-tree proof of reserves shows an exchange controls certain wallets at a snapshot in time. It does not prove those assets are unencumbered, unborrowed, or still there an hour later.
• Fiat-backed stablecoins depend more heavily on attestations than overcollateralized onchain-native tokens, because most of their reserves live off-chain by design.

Why the FTX collapse made this a board-level question

Before November 2022, proof of reserves was a niche exchange feature. After FTX, it became a demand. The lesson risk teams took away was specific: a liability you can measure yourself is worth more than one you are told. Onchain verification answers part of that by moving the assets and the liabilities into public view.

The distinction matters because different token types expose you to different amounts of off-chain trust. USDC issuer Circle publishes reserve reports and the addresses of its onchain holdings; per Circle's transparency disclosures (retrieved September 25, 2026), a large share of reserves sits in a regulated money market fund and cash, which are off-chain instruments verified by attestation. Tether publishes attestations and reserve data on its transparency page (retrieved September 25, 2026). For any fiat-backed token, the reserves sit off-chain by construction, so they are outside what a chain read can show.

Overcollateralized, onchain-native stablecoins invert this. Sky (formerly MakerDAO), which issues DAI and USDS, holds collateral in smart contracts you can query directly, though it has added off-chain real-world assets that reintroduce attestation dependence. The practical rule: the more of an issuer's reserves live on a blockchain, the more of its proof of reserves you can verify without trusting anyone.

How onchain proof of reserves works, step by step

1. Establish liabilities. Read the total supply from the token's smart contract. For an ERC-20, this is the totalSupply value, adjusted for any addresses the issuer designates as burned or non-circulating, and deduplicated across chains so bridged and wrapped copies are not counted as native issuance. This is fully independent and updates every block.
2. Establish onchain assets. Sum the balances of the wallet addresses the issuer has publicly attested to owning. For onchain collateral, this is a direct read. The trust assumption here is address ownership, not balance.
3. Prove address control (for exchanges). Custodial platforms often sign a message from each reserve address, or move a small verification transaction, to demonstrate they control the private keys. Some use a Merkle tree of customer balances so each user can confirm their balance was included in the liability total.
4. Attest off-chain assets. An accounting firm confirms bank balances, Treasury holdings, and money market positions as of a snapshot date, then publishes a report. This is the step no blockchain can perform.
5. Reconcile. Assets (onchain plus attested off-chain) are compared against liabilities (deduplicated token supply plus, for exchanges, customer deposits). A solvent issuer shows assets greater than or equal to liabilities.

What each method can and cannot prove

A worked reconciliation for a fiat-backed stablecoin

Suppose an issuer reports the following at a snapshot. These figures are illustrative, chosen to show which lines you can check yourself and which you cannot.

In this illustration you can check balances at the disclosed addresses totalling $150,000,000 of the $1,020,000,000, about 15%, conditional on those addresses being the issuer's. The other 85% rests on the attestation. If the off-chain figure were wrong or stale, onchain data would not catch it, because those dollars never touch a chain. This is why a 102% headline ratio tells a risk team less than the split between verifiable and attested reserves does.

Before and after: what real proof of reserves changes for a risk team

• Continuous liability monitoring: instead of waiting for a monthly report to learn how many tokens are outstanding, you read supply live from the contract.
• Independent asset confirmation: instead of accepting a reserve figure on faith, you sum the disclosed wallets yourself and flag when balances diverge from the reported number.
• Snapshot-gap awareness: instead of treating a quarterly attestation as continuous assurance, you know precisely which window is covered and which is not, and you size that blind spot deliberately.
• Address-level exposure mapping: instead of a single reserve total, you see concentration across custodians and chains, so a single failed counterparty does not surprise you.

The field-level problem behind verifying reserves at scale

Reading one reserve wallet on one chain is straightforward. Verifying an issuer whose reserves and supply span Ethereum, Solana, Tron, and several Layer 2s, in different token standards, is not. The same reserve holding shows up as different raw log formats on each chain, and a tokenized Treasury on one network does not automatically map to the same asset and issuer identifiers on another. The bridged double-count is a symptom of the same underlying problem: to know whether a given supply entry is native issuance or a bridged copy, every holding has to resolve to consistent fields: asset, issuer, holding address, chain, amount, USD value at the snapshot, and native-versus-bridged classification. Without that, you are comparing incompatible records and cannot produce one clean supply or reserve figure.

Allium normalizes records across 150+ blockchains into standardized fields for assets, issuers, addresses, transaction types, and native-versus-bridged classification, which is what lets bridged representations be screened out and a reserve figure be reconciled consistently across chains rather than reassembled by hand per network. The underlying tables and schemas are documented in the Allium docs. Allium is data infrastructure, not an auditor, so it addresses the onchain half of the problem, the assets and liabilities that live on a blockchain, and not the off-chain attestation.

Risks and open questions

• Point-in-time proofs miss borrowed assets. An exchange can borrow assets, prove reserves at a moment, then return them. Point-in-time proofs do not detect this without continuous monitoring or attestations covering the full period.
• Liabilities are the hard half. Merkle-tree proofs show assets and can include disclosed customer balances, but an issuer can omit liabilities. A proof of assets without a complete, verified proof of liabilities does not establish solvency.
• Address ownership is a claim. Anyone can point at a wealthy wallet. Only a signed message or verification transaction demonstrates control, and control at a snapshot is not the same as unencumbered ownership.
• Off-chain reserves stay off-chain. For fiat-backed tokens, the majority of reserves cannot be proven onchain by construction. No amount of onchain tooling closes this gap; only an attestation does.
• No standard format. Issuers disclose wallets, snapshot cadence, and reserve composition differently, so proofs are hard to compare like for like across issuers.

Frequently asked questions

Why does summing token supply across chains overstate it?

When a token bridges to another chain, the original is typically locked and a new representation is minted on the destination chain, so both report a positive totalSupply for the same underlying dollar. Wrapped versions behave the same way. Summing every chain's totalSupply counts these copies as independent issuance. On Allium data for 23 September 2026, that overstated stablecoin supply by $23.97B ($337.71B raw versus $313.74B native). The fix is to deduplicate to native issuance.

How do I deduplicate to native supply myself?

For each chain a token appears on, classify its supply as native issuance (minted directly by the issuer's contract on that chain) or as a bridged or wrapped representation of supply already issued elsewhere. Sum only the native issuance. Anything classified as bridged is a claim on liability already counted at its origin, so including it double counts.

Does onchain proof of reserves prove a stablecoin is fully backed?

No. It proves how many tokens are outstanding and how much sits in disclosed onchain wallets. For fiat-backed stablecoins, most reserves are off-chain cash and Treasuries that no blockchain can verify, so full backing still depends on a third-party attestation.

What is the difference between proof of reserves and proof of liabilities?

Proof of reserves shows the assets an issuer holds. Proof of liabilities shows what it owes, meaning token supply or customer deposits. Solvency requires both. A large reserve wallet means nothing if undisclosed liabilities exceed it, which is why complete liability proof is the harder and more important half.

Can I verify a token's supply myself?

Yes, though carefully. Reading totalSupply from the token's smart contract on one chain is fully independent. To get true circulating supply you must adjust for burned and non-circulating addresses, and deduplicate bridged and wrapped copies across chains so they are not counted as native issuance.

What does a Merkle-tree proof of reserves actually show?

It lets an exchange demonstrate control of specific wallets at a snapshot and lets each user confirm their balance was included in the total liabilities. It does not prove the assets are unborrowed, unencumbered, or still present after the snapshot.

Why do issuers still need auditors if reserves are onchain?

Because most reserves for fiat-backed tokens are not onchain. Bank cash, money market funds, and Treasuries exist off-chain, and only an accounting firm can confirm those balances. Onchain data verifies the blockchain half of the balance sheet; attestations cover the rest.

Allium provides onchain data infrastructure. Companies named in this article may be Allium customers, prospects or commercial counterparties. This article is informational only and is not investment, legal or tax advice. Data and information last reviewed: September 29, 2026.