Auditing Crypto: The Existence and Rights Assertions (2026)

Accounting·

Auditing Crypto: The Existence and Rights Assertions (2026)

Proving a company owns the crypto on its balance sheet is the hardest audit assertion in Web3. Existence and rights and obligations require control evidence, not just an explorer balance. The procedures the AICPA practice aid describes, why a public address is not ownership, and the custody nuance.
Author avatar Wag3s TeamEditorial team specializing in Web3 finance, crypto tax, and DAO operations. Based in Zurich, Switzerland.

Reviewed by Wag3s Editorial Team — verified against the AICPA Accounting for and Auditing of Digital Assets practice aid (non-authoritative) and the existence / rights assertions under SAS 143 and SAS 145 · Last reviewed May 2026

Auditing Crypto: The Existence and Rights Assertions

Two audit assertions that are near-mechanical for cash become the crux of a crypto engagement: existence (the asset is real) and rights and obligations (the entity actually controls it). A bank confirmation settles both for a cash balance. A blockchain explorer settles neither: it shows that an address holds tokens, never that the audited entity can move them. This guide is about those two assertions specifically — what counts as control evidence, how custody changes where that evidence lives, and why a displayed balance is the beginning of the procedure, not the end of it. For the mirror-image assertion (is there crypto you failed to record?), see completeness.

The assertions in brief

  • Existence and rights and obligations are the crypto audit's hard assertions: a public-address balance is not, by itself, ownership.
  • Ownership means demonstrable control of the private keys, or a valid contractual claim on a custodian.
  • The AICPA digital-assets practice aid (non-authoritative) describes the procedures: explorer confirmation, hardware-wallet inspection, custody verification, third-party confirmation, and key-control evidence (a signed message or a controlled transaction).
  • The authoritative basis is the applicable auditing standards — in the US, SAS 145 (risk assessment) and SAS 143 (estimates). The practice aid applies them; it does not replace them.
  • Custody changes where the evidence lives: self-custody points to key control; third-party custody points to the custodian relationship plus confirmation.
  • An explorer screenshot is not control evidence.

Why ownership is the hard part

For most assets, existence and rights are routine. For crypto they are the crux, because:

  • a blockchain explorer proves an address holds tokens, not that the entity controls that address;
  • anyone can display any address as "theirs";
  • control is bearer-like — whoever holds the keys controls the asset.

So an auditor cannot accept a displayed balance as ownership. The assertion to satisfy is control: the entity can move the assets (keys) or has an enforceable claim on them (custodian).

The procedures (per the AICPA practice aid)

The AICPA "Accounting for and Auditing of Digital Assets" practice aid — explicitly non-authoritative — sets out procedures auditors use to apply the authoritative standards to crypto:

  • confirm on-chain balances via blockchain explorers (a starting point, not proof of control);
  • inspect hardware wallets and key-management arrangements;
  • verify custody arrangements for custodied assets;
  • obtain third-party confirmations (custodians, counterparties);
  • test key control — for example a verifiable signed message from the address, or a controlled micro-transaction, linking the address to the entity.

These apply the risk-assessment standard (SAS 145 — understanding the entity and assessing risks) and the estimates standard (SAS 143) to the crypto context. The practice aid is the how; the standards are the requirement.

Self-custody vs third-party custody

Where the evidence lives
Self-custodyDemonstrable key control: signatures, controlled transactions, key-management governance, address-to-records linkage
Third-party custodyThe custodian relationship: the contract, independent confirmation of the entity's holdings, and where available a service-auditor report on the custodian's controls

In both cases the auditor must connect the position to the entity's rights. An explorer balance (self-custody) or a custodian statement (third-party) is necessary but not sufficient on its own.

The weak procedure to avoid

The recurring weakness is accepting an explorer screenshot or a self-prepared balance list as evidence of ownership. It evidences neither control nor rights. A defensible file pairs the on-chain position with control evidence (signature/controlled movement or custodian confirmation) and ties the address set to the reconciled ledger and the audit trail. This is also the substance behind the proof-of-reserves vs audit distinction.

Step-by-step: building an audit-ready wallet ownership file

The following steps describe what a company's finance team should assemble before the audit, so that the existence and rights assertions can be tested efficiently rather than reconstructed under time pressure:

Step 1 — Compile the complete wallet register. List every address the company owns or controls, by chain, with the date of first use, the custody arrangement (self-custody vs third-party), and the corresponding line in the general ledger. This register is the population the auditor tests completeness against. An undisclosed address that holds material value and is discovered during the audit is an existence failure.

Step 2 — Assign a control-evidence type per address. For each self-custodied address: identify who holds the private key, in what form (hardware wallet, MPC, multi-sig), and what the signing protocol is. For each custodied address: locate the custody agreement, the custodian's confirmation procedure, and any service-auditor report (SOC 1 or equivalent) covering the custodian's controls.

Step 3 — Prepare signing capability for the audit window. For self-custodied addresses, be ready to produce a verifiable signed message from each address on request during the audit. This is the primary key-control evidence. A controlled micro-transaction (sending a specified tiny amount to a specified address at the auditor's request) is an alternative where signed-message tooling is unavailable. Both directly demonstrate control.

Step 4 — Tie each address to the books. The reconciliation between on-chain balance and the general ledger entry — via the sub-ledger or crypto accounting tool — must be complete and current at the audit date. The auditor tests whether the balance the company asserts is actually on-chain; this reconciliation is the link between the blockchain reality and the accounting record.

Step 5 — Document the multi-sig governance. If any addresses are multi-sig (e.g. Gnosis Safe), document the threshold, the key holders, and the signing policy. The auditor needs to understand who constitutes a quorum, because the rights assertion depends on whether the entity as a legal entity can actually access and move the funds — not just whether a signatory can.

Practical guidance

  1. Maintain a complete, owned wallet inventory linked to the books — completeness first.
  2. Hold key-control evidence ready — signing capability or a controlled-transaction protocol per address.
  3. For custodied assets, keep the contract and confirmations and any service-auditor report.
  4. Do not rely on explorer screenshots as ownership evidence.
  5. Document the address-to-entity linkage so existence and rights are testable.
  6. Treat the AICPA practice aid as the application guide, the auditing standards as the requirement.

How vendor tools support the existence assertion

Cryptio and Bitwave maintain the owned-wallet inventory, link addresses to the ledger, and retain the reconciliation evidence auditors test for existence and rights. Confirm the tool can produce a complete address set tied to the books and support control evidence (not just explorer balances) — the inventory's completeness and the address-to-records linkage are the audit-critical features.

Where Wag3s fits

Wag3s Ledger maintains a complete owned-wallet inventory linked to the accounting records across chains, retains the reconciliation and control-evidence trail, and keeps custody arrangements documented so the existence and rights assertions can be tested rather than asserted from an explorer view. It assembles and preserves that evidence for the auditor to test; it does not perform the procedures or conclude on the assertion — the signing test, the custodian confirmation, and the sufficiency judgement remain the auditor's. See the Ledger product page and the Wag3s for accountants page.


Further reading

Sources

Editorial disclaimer
This article is informational and does not constitute audit advice. The AICPA practice aid is non-authoritative; authoritative requirements are the applicable auditing standards. Confirm procedures with the engagement team.