The traditional audit of a treasury position rests on third-party confirmation. The bank confirms the balance. The custodian confirms the holdings. The auditor sends a letter, the third party signs, the confirmation comes back, the figure ties.
For a crypto-asset position held in proprietary custody, there is no third-party custodian in the conventional sense. The asset is controlled by the holder of the private key. The auditor cannot send a confirmation letter to the blockchain. The procedure has to change.
Proof-of-reserves is the most common mechanism that has emerged to fill the gap. It is useful. It is not, by itself, an audit. The distinction matters for the CFO who is preparing the entity for examination.
The audit problem that crypto introduced
Two assertions need to be tested when an entity claims a crypto-asset position. First, the entity controls the asset. Second, the asset exists on the chain as claimed.
The second is the easy part. A blockchain explorer can confirm that a given address holds a given balance at a given block height, and any party with internet access can run the query. That property is, in audit terms, a meaningful improvement on the opacity of a bank balance, which is observable only to the parties holding the relationship.
The first is the hard part. Visibility of a balance at an address does not prove that the audited entity controls that address. The procedure to test control is cryptographic — typically, the entity signs a message with the private key associated with the address, and the auditor verifies the signature. The procedure is straightforward in principle and unfamiliar to most audit teams in practice, particularly outside the firms that have invested in crypto-asset audit capability.
What proof-of-reserves does well
The full proof-of-reserves construction adds a third element: a Merkle tree of customer balances that allows individual customers to verify their balance is included in the aggregate the entity claims to hold. For an exchange or a custodian, this is genuinely useful. It demonstrates not only that the entity holds assets but that those assets are sufficient to cover the obligations the entity owes to its customers.
The advantages are real:
- The on-chain balance is observable by any party, not just the auditor.
- The verification is continuous, not periodic. A balance can be re-verified at any block.
- The customer-balance Merkle tree, where deployed, distributes part of the verification work to the customers themselves.
- The procedure scales without proportional audit cost, once the infrastructure is built.
What proof-of-reserves does badly
The construction has well-understood limits that the CFO should be honest about with the audit committee.
First, point-in-time proof. A snapshot of reserves at a specific block height does not constrain the entity's behaviour between snapshots. Assets borrowed for the moment of proof and returned afterwards have, in documented cases, produced a proof-of-reserves output that did not survive the next month.
Second, liabilities. Proof-of-reserves demonstrates the asset side. It says nothing about what the entity owes off-chain — to lenders, to counterparties, to taxing authorities. An entity can be technically reserved and economically insolvent at the same time.
Third, qualified vs unqualified. Proof-of-reserves output by an entity itself, without third-party validation, is less reliable than output validated by an independent firm. The market has not yet converged on a single validation standard, and the quality of the validators in the market varies.
Fourth, the asset-quality question. Reserves held in a volatile or illiquid asset may be insufficient to cover stable-value obligations even when the headline numbers match. The composition of the reserves matters as much as the totals.
Where the audit team still has to do work
For the audit of a corporate treasury that includes crypto-assets, proof-of-reserves is an input, not a substitute. The audit team still has to perform:
- Control verification. The cryptographic signing procedure that ties the entity to the address.
- Period-end cut-off. Procedures around the balance-sheet date that match the discipline applied to fiat balances.
- Transaction testing. Sampling of on-chain transactions to verify that they were properly authorised, recorded, and reflected in the accounting.
- Smart contract review. Where assets or obligations are governed by smart contract logic, an assessment of the contract's behaviour, ideally drawing on a specialist code audit.
- Off-chain liability verification. The off-chain obligations that the reserves are notionally backing.
The CFO's documentation burden
The CFO who wants the audit to go efficiently maintains, alongside the on-chain record, a documentation package that the audit team can rely on. It typically includes:
- A wallet inventory — every address controlled by the entity, the purpose of the address, the custody arrangement, and the signatories.
- The custody policy and any third-party custodian agreements.
- The valuation policy and the pricing sources used at period end.
- The smart contract audit reports for any contracts the entity relies on materially.
- The signing records that demonstrate control of each claimed address.
- The reconciliation between on-chain balances and the accounting record, with cut-off documentation.
None of this is unusual in concept. It is the same discipline applied to bank reconciliations, scaled and adapted to the new asset class.
A practical sequence
For a CFO preparing the entity's first audit cycle with a material crypto position:
- Inventory every address and lock the custody policy before the audit field-work begins.
- Agree with the audit team, in writing, the procedures for control verification, valuation, and cut-off. Surprise on these points at year-end is the most common cause of audit delay in this asset class.
- Run a dry-run of the procedures one quarter before period end. The first time the signing procedure is attempted, it should not be at the year-end deadline.
- Maintain proof-of-reserves output, where it is published, as an additional control rather than as a substitute for the audit procedures.
- Document the off-chain liability side as carefully as the asset side. The audit will look there.
This sits inside the CFO in blockchain framework. See also smart contract risk and carbon credit accounting. Lorna writes from practice at IMPT. The verified page records what is and isn't published here.
Lorna Mason is CFO of IMPT, Dublin. The verified public record is on the Verified page. Contact: lorna@impt.io