Crypto audit

The auditor starts by reading the chain. Given a public address, a block explorer shows the balance at the reporting date, and that is evidence the asset exists. The displayed balance is not evidence that the client owns it.

Ownership is tested by asking the client to do something only the key holder can do. The usual procedures are a cryptographic message signed with the key, which the auditor then verifies against the public address, or a small transfer to an address the auditor names, observed on the chain. ISACA sets out these procedures by audit assertion, including a signed message as the evidence for the rights assertion. Both tests have a limit worth knowing: they prove that somebody with access signed at that moment, and not that the client is the only party with access, which is why the auditor also examines who holds key material and how a transfer is authorized.

Establishing completeness is harder because undisclosed wallets may be missing from the client's records. With a bank the auditor can ask the institution for all accounts in the client's name. On a public chain there is no such register: an address is a number, and a client's undisclosed wallet looks exactly like a stranger's.

The procedures therefore work from the client's side inward. The auditor obtains the list of every exchange, custodian and protocol relationship in the period, confirms each one, and traces the addresses from those relationships. Transaction analysis then tests whether the disclosed set is plausible: funds leaving a known wallet to an address that never appears in the records is the flag. CBIZ notes the same requirement, including wallets with a zero balance at period end that were active during the year, which a balance-only approach would miss entirely.

Where the client uses a regulated custodian, the audit looks more familiar, and the confirmation is only the start. The custodian confirms the holding, which answers existence and rights, and the auditor then has to decide whether the custodian's own controls can be relied on.

That decision runs on a service organization report, a SOC 1 or an equivalent assurance report on the custodian's control environment, covering key generation, segregation of client assets and authorization of transfers. The auditor reads the report, checks that its period covers the client's year and that the controls tested are the ones the client depends on, and identifies the controls the report expects the client to run at its own end. A custody arrangement also changes the accounting question, since a claim on a custodian is a different asset from a coin the client controls, and crypto custody sets out the arrangements.

The auditor does not price the position; it tests the policy that priced it. That means the written valuation policy, the source and timestamp it names, the stored evidence of the prices actually used, and the exception log where the policy fell through to a fallback source.

For a position measured with judgment, the testing goes further into the model and its parameters. Digital asset valuation sets out the policy from the preparer's side, and digital asset accounting the measurement basis the policy has to serve.

No separate crypto audit standard exists. The audit runs under the normal standards, with the crypto-specific work falling under ISA 500 on audit evidence and ISA 540 on estimates, which is where a judgment-based valuation is tested. For a German statutory audit the IDW publishes the practice guidance the profession follows, and the audit itself sits in the framework described under financial audit in Germany.

What this means in practice is that no rule automatically establishes that a particular procedure is sufficient. The auditor has to judge whether a signed message is sufficient appropriate evidence in the circumstances, document that judgment, and defend it in an inspection.

Two different things share the word audit, and conflating them has cost people money. A smart contract security audit is a code review: specialists read a contract looking for exploitable flaws and publish a report on the code. The smart contract security audit says nothing about anybody's financial statements, and it is not performed by a statutory auditor.

A financial statement audit gives an opinion on whether a set of accounts is free from material misstatement. The two meet in one place: where a client's assets sit inside a protocol, the financial auditor may consider the code review as part of understanding the risk, and it remains the auditor's own judgment. A press release announcing that a protocol is audited is a statement about code, and reading it as assurance over reserves or solvency is the error that proof of reserves examines.

Holders should prepare five items before the audit, because assembling them later increases the cost. Prepare a complete list of every wallet, exchange account, custodian and protocol used during the year, including those closed or emptied. Document who holds key material and who may authorize each transfer. Provide the valuation policy dated before the period and the full transaction history reconciled to the general ledger. Include the custodian's service organization report whenever the audit relies on that report.

An auditor that cannot get sufficient evidence over existence or completeness has to modify the opinion, and a qualified opinion on a crypto holding is a problem with a fund's investors and its supervisor long before it is a problem with the accounts.