Exchange proof of reserves with liabilities
What is exchange proof of reserves with liabilities?
Exchange proof of reserves with liabilities is how a crypto exchange shows that the assets in its wallets cover what it owes customers, asset by asset: wallet balances at one snapshot block on one side, and on the other the total of customer balances, published as a Merkle tree so each customer can check their own balance is counted.
Exchanges and custodians publish it because customers and counterparties can’t otherwise see whether deposits are backed, and an accounting firm’s review covers only the moment of the snapshot.
Goldsky keeps each reserve wallet’s balance at every block it changes and runs a scheduled check against the liability totals from your ledger between reviews, while the customer balances, the Merkle tree and the review stay with you and your accounting firm.
Who uses exchange proof of reserves with liabilities?
Crypto exchanges, brokers and custodians that hold customer assets in their own wallets; an issuer showing a token is fully backed runs continuous proof of reserves instead.
How exchange proof of reserves with liabilities works
The diagram follows one check from the exchange’s reserve wallets to the reserve ratio and the accounting firm’s review, and shows who does each step. Your setup may differ.
List the wallets that hold customer assets
Reserves are the assets in wallets the exchange controls, so the check starts from a complete list of them.
Each wallet goes on the list with its asset and chain, and the exchange has to be able to sign with its key, which is how a review confirms control. A wallet left off understates reserves; one the exchange doesn’t control overstates them.
Keep each reserve wallet’s balance
Handled by Goldsky TurboAny moment you later pick for a check or a review needs every wallet’s balance at that block.
The balance has to be read at the block where it changed, for tokens and the chain’s own coin alike. Reading on a timer misses movements between reads, such as assets borrowed in just before a snapshot and returned after it.
With Goldsky, the wallet list can be a Turbo Pipelines dynamic table, and a transform reads
Read balances with Turbo SQL functions (opens in a new tab)balanceOfwith_gs_eth_callat each transfer’s block, or_gs_evm_get_balancesfor the chain’s own coin. The pipeline writes each balance to a table in your Compose app’s Postgres database, in a schema of its own.Check on a schedule between reviews
Handled by Goldsky ComposeAn accountant’s review covers one moment and says nothing about the days after it.
The check runs often enough to find a shortfall while it’s still small, and every run is kept, so you can show reserves were held between reviews too.
A Compose task with a cron trigger runs the check at the interval you set, and each run’s calls and results are logged.
Run a task on a schedule (opens in a new tab)Read customer liabilities from your ledger
Handled by Goldsky ComposeLiabilities are what the exchange owes customers in each asset, and they live in its own books, not on the chain.
Totals are per asset and taken at the moment of the check, with staked balances and open margin positions counted the way your review methodology counts them. Liabilities from a different moment than the balances make the ratio meaningless.
The task calls your ledger’s API with
Make auditable HTTP requests (opens in a new tab)ctx.fetch, which retries a failed request and records the call and its response in the run’s log.Compare reserves with liabilities
Handled by Goldsky ComposeThe reserve ratio, assets held divided by what customers are owed, says whether every customer balance is covered.
Each asset is checked on its own, because a surplus in one asset doesn’t cover a shortfall in another. A ratio below your floor raises an alert with the asset, both totals and the block, and a ratio at or above it is still recorded.
Each run of the Compose task reads the latest balances with
See the reserve-check task (opens in a new tab)ctx.db.query, adds them up for each asset, works out the ratio against your floor and posts an alert to your endpoint when it falls short.Have an accountant review a snapshot
Customers and counterparties want an outside party to confirm the exchange holds what it owes.
The accountant puts every customer balance at the snapshot into a Merkle tree (a structure that lets each customer check their balance is included), checks the exchange’s signatures for its wallets and compares their balances with the total. The review isn’t an audit: it covers one moment and may not show whether assets were borrowed for it.
What you control
- Your team
- List the wallets that hold customer assets
- Your providers
- Accounting firm
Questions and answers
What is proof of liabilities?
Proof of liabilities is the half of an exchange’s proof of reserves that shows the total it owes customers, usually as a Merkle tree of every customer balance at the snapshot, so each customer can check their own balance is counted. Comparing that total with the assets in the exchange’s wallets at the same block shows whether every balance is covered. An accounting firm usually reviews both sides, but the review covers one moment and isn’t an audit.
Security and deployment
- SOC 2 Type IIIndependently audited security controls.
- Dedicated infrastructureSingle-tenant options for production workloads.
- Data residencyCloud, on-premises or co-located.
More use cases that track supply and reserves
- Proof of reserves for stablecoinsKeep a per-chain record of mints, burns and supply, and check it against reserves.
- Stablecoin mint and redemption monitoringRecord every mint and redemption of a stablecoin as it happens, on every chain.
- Continuous proof of reservesCompare onchain supply with reported reserves on a schedule, then publish the ratio or alert on a gap.
- Daily stablecoin supply by chain for PS-01 reportsKeep the daily per-chain supply, issued, redeemed, issuer-held, frozen and lost figures that feed the weekly OCC PS-01 report.
- Month-end stablecoin supply for reserve reportsProduce the month-end supply across all chains that the monthly reserve report and its examination need.
- Stablecoin redemption spike alertsAlert when redemption requests in a single 24-hour period pass 10% of a brand’s outstanding issuance, the point at which the OCC must be told within 24 hours.
- MiCA daily usage cap for stablecoinsTrack the quarterly average of daily transactions and their value against the 1M transactions and €200M a day limits, and warn well before an issuer must stop issuing.
- Supply data for stablecoin issuance platformsGive an issuance platform one view of supply across every coin and chain it runs.
- Stablecoin depeg and manipulation alertsAlert the issuer when its coin trades off peg in its own pools or pool activity looks like manipulation, on every chain it runs on.
- Tokenized money market funds in stablecoin reservesTrack stablecoin reserves held as tokenized money market fund shares and check them against the reserve record.
Use cases built the same way
- Wrapped bitcoin reserve monitoringCheck a wrapped bitcoin token’s supply on every chain against the BTC at its custodian’s reserve addresses, and alert on any gap.
- Authorize and capture stablecoin paymentsHold a buyer’s stablecoins in an escrow contract at checkout, capture them to the merchant as orders ship, void what can’t be filled and refund after capture.
- Payout prefunding in USDCPrefund a payout network in USDC and track the balance so payouts never stall.
- Cross-chain transfer trackingSee every cross-chain stablecoin transfer as settled, in flight or stalled, and catch the stuck ones.
Run exchange proof of reserves with liabilities on Goldsky
We’ll map it to your systems and show you what Goldsky runs, so your team builds the product, not the pipelines underneath it.