How Auditors Verify Crypto Wallet Ownership

The hardest assertion in a crypto audit is not what you hold. It is that it is yours. Here is how that is actually proven, and what each method does and does not establish.

Key takeaways

There is no counterparty to confirm a self-custodied wallet, so ownership is proven by demonstrating control of the private key.
A signed message is the cleanest method and moves no funds. An instructed transfer is the fallback where signing is not available.
Both must be initiated by the auditor. A signature the client produced at a time of its own choosing proves much less.
Custodial holdings fall back to third-party confirmation under ISA 505, with the ordinary limitation that it is only as good as the custodian.

Every audit of a company holding digital assets reaches the same question, usually within the first fortnight. Management has produced a schedule of wallet addresses and balances. The balances are verifiable by anyone with an internet connection. The ownership is not verifiable at all, at least not from the schedule.

This article sets out the three methods that are actually used, what each one proves, where each one fails, and how the result is documented so it functions as audit evidence rather than as a reassuring email.

Why a Bank Confirmation Has No On-Chain Equivalent

ISA 505 covers external confirmations, and it exists because evidence obtained directly from an independent third party is more reliable than evidence produced inside the entity. For cash, the auditor writes to the bank. The bank has its own records, its own regulator and no interest in helping the client misstate a balance, and it replies directly to the auditor.

A blockchain has no such party. The ledger is public and cannot be edited, which is a genuine advantage for the existence assertion, but there is nobody to write to. The chain records that an address holds a balance. It has no concept of who the address belongs to, and it will never tell you, because that information was never on it.

So ownership has to be established some other way, and the only meaningful definition of ownership in this setting is control. If you can move the asset, it is yours in every sense an audit cares about. If you cannot, no document saying otherwise is worth much.

Method One: The Signed Message

The cleanest method. A private key can sign an arbitrary piece of text, producing a signature that anyone can verify against the corresponding public address without ever seeing the key. The auditor supplies the text, the entity signs it with the wallet in question, and the auditor verifies it independently.

Two details separate a useful signature from a decorative one.

The auditor supplies the text, and it must be unpredictable. In practice it contains the entity's name, the audit period, the date, and often a random string. If the client chooses the wording, a signature produced last year for another purpose can be presented as though it were produced today.

It proves control at the moment of signing. A signature obtained in February evidences control in February. Where the audit needs comfort over the reporting date, the signature is read together with the transaction history: an address that the entity demonstrably controls now, and which shows continuous activity consistent with the entity's own records across the period, supports a reasonable conclusion about the reporting date. An address that was emptied in January and signed in April supports considerably less.

The method is well supported on Bitcoin and on EVM chains, and nothing moves, which makes it the first choice wherever it is available.

Method Two: The Instructed Transfer

Where signing is not available, and it often is not with institutional custody platforms, multi-party computation wallets and some multi-signature arrangements, the fallback is to have the entity move a small amount on the auditor's instruction.

The auditor specifies the amount, the destination address and the window in which it must happen. The entity makes the transfer. The auditor observes it on-chain. Because all three parameters were chosen by the auditor, the transaction demonstrates that the entity could move funds from that address on demand.

The mechanism is only as good as its unpredictability, and this is where it is most often done badly. A transfer the client announces in advance, or makes at a time of its own choosing, or makes to an address it nominated itself, proves substantially less than one made to an auditor-specified destination inside an auditor-specified window. The point of the exercise is that it cannot be arranged in advance.

It has real costs. It incurs network fees, it creates a transaction that has to be accounted for, and for cold storage under a serious key-management policy, requiring a transfer may mean convening signatories and opening a procedure the client would prefer to run on its own schedule. Those are reasonable objections, which is why a signed message is preferred wherever the custody setup supports it.

All three are legitimate. What separates strong evidence from weak is who set the parameters.

Method Three: Custodian and Exchange Confirmations

Where the assets sit with a third party, neither of the first two methods applies, because the entity does not hold the keys. What it holds is a claim against the custodian, and that is confirmed the ordinary way under ISA 505: a request sent directly to the custodian and a response returned directly to the auditor.

The standard's usual cautions apply with some force here. A confirmation is only as reliable as the party providing it, and the crypto custody market ranges from regulated institutions with audited control reports to offshore exchanges whose internal records have never been examined by anyone. A confirmation from the first kind is strong evidence. A screenshot of an account page from the second is not a confirmation at all, and an API key handed to the auditor is better than a screenshot but is still reading the exchange's own display of its own records.

Where a custodian has a service organisation control report covering the relevant period, that materially changes what the confirmation is worth, and it is worth asking for.

Reading Balances at the Reporting Date

Once ownership is settled, balances are the straightforward part, with two details that matter for reproducibility.

Record the block, not just the date. A blockchain does not have a midnight. It has blocks. The defensible approach is to fix the last block before the reporting cut-off in the relevant time zone, record its height and timestamp, and read every balance at that height. Anyone can then re-run the same query and get the same answer, which is what makes it evidence rather than an assertion.

Include everything the address controls. A native balance is the beginning. Token balances, staked positions, amounts locked in lending protocols, liquidity positions and pending rewards may all be economically the entity's and none of them appear in a naive balance query. Completeness failures here are common and are usually the result of asking a simpler question than the position deserved.

Documenting It as Audit Evidence Under ISA 500

ISA 500 requires audit evidence to be sufficient and appropriate, and the practical test on the file is whether someone else could follow what was done and reach the same conclusion. For wallet verification that means recording:

The exact message text supplied and who supplied it, with the signature and the verification output.
For instructed transfers, the parameters the auditor set, when they were communicated, and the resulting transaction hash.
The block height and timestamp at which each balance was read, and the query or tool used.
The data source, with a note on why it is considered reliable, since a block explorer is itself a third party.
Anything that could not be verified, stated plainly, with the effect on the conclusion.

That last point is the one that distinguishes a working paper from a sales document. A file that records two wallets verified by signature, one by instructed transfer, and one custodial balance confirmed only by an unsigned screenshot is far more useful than a file that quietly implies all four were treated the same way.

Where ISA 620 Fits

None of the above requires the audit firm to build this capability in-house. ISA 620 allows the engagement team to use an auditor's expert where expertise outside accounting and auditing is needed to obtain sufficient appropriate evidence, and the team remains solely responsible for the opinion.

In practice the expert performs the verification and the balance reading, and the engagement team evaluates the work: assessing the expert's competence, capability and objectivity, agreeing the scope and nature of the work in writing beforehand, and testing that the findings are consistent with other audit evidence. The file records that evaluation rather than simply attaching the expert's report.

This is the most common way we are engaged. The audit firm keeps the client, the engagement and the opinion; we do the on-chain work and hand over papers the file can carry. Details are on our crypto audit support page, and where the engagement is a reserves attestation rather than a full audit, that is proof of reserves.

The Short Version

Ownership of a self-custodied wallet is proven by demonstrating control, either through a signature over auditor-supplied text or through a transfer made on auditor-set parameters. Custodial positions are confirmed with the custodian, weighted by how much that custodian's records are worth. Balances are read at a recorded block height so anyone can reproduce them. Everything is documented, including what could not be verified.

None of this is conceptually harder than auditing a bank balance. It is simply unfamiliar, and unfamiliarity is what turns a three-day procedure into a three-month standoff.

How Ondology Labs can help: We are engaged by audit firms as an auditor's expert under ISA 620 and by companies whose auditor cannot test the crypto balances. That is crypto audit support. For exchanges and custodians who need to evidence reserves against customer liabilities, that is proof of reserves, and for the full opinion, statutory crypto audits with our ICPAC-licensed partner.

How Auditors Verify Crypto Wallet Ownership (ISA 500, 505 and 620)