Auditing Crypto: The Existence and Rights Assertions (2026)
Auditing Crypto: The Existence and Rights Assertions (2026)
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-custody | Demonstrable key control: signatures, controlled transactions, key-management governance, address-to-records linkage |
| Third-party custody | The 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
- Maintain a complete, owned wallet inventory linked to the books — completeness first.
- Hold key-control evidence ready — signing capability or a controlled-transaction protocol per address.
- For custodied assets, keep the contract and confirmations and any service-auditor report.
- Do not rely on explorer screenshots as ownership evidence.
- Document the address-to-entity linkage so existence and rights are testable.
- 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
- Crypto Audit Readiness
- Proof of Reserves vs a Financial-Statement Audit
- Auditing Crypto Fair Value
- Crypto Audit Trail and Piste d'Audit Fiable
- Multi-Chain Reconciliation
- The FEC for Crypto in France
Sources
- AICPA & CIMA — Accounting for and Auditing of Digital Assets practice aid (non-authoritative): procedures for the existence and rights-and-obligations assertions — explorer confirmation, hardware-wallet inspection, custody verification, third-party confirmation, and key-control evidence (signed message or controlled transaction).
- AICPA & CIMA — Statement on Auditing Standards No. 145, Understanding the Entity and Its Environment and Assessing the Risks of Material Misstatement: the authoritative risk-assessment basis the practice aid applies (effective for periods ending on or after 15 December 2023).
- AICPA & CIMA — Statement on Auditing Standards No. 143, Auditing Accounting Estimates and Related Disclosures: the authoritative estimates basis where measurement judgement is involved.
Proof of Reserves vs a Financial-Statement Audit: What They Are Not (2026)
A proof-of-reserves report is not a financial-statement audit. PoR is a limited-scope, point-in-time check of on-chain assets against customer liabilities, often with no assurance. The scope gap, the limitations regulators flag, and why the two are complementary, not equivalent.
Auditing Crypto Fair Value: Principal Market and the Hierarchy (2026)
With fair value now mandatory under US GAAP ASU 2023-08, the valuation assertion is central to a crypto audit. The principal-market determination, the fair-value hierarchy, pricing-source evidence, and the AICPA practice-aid procedures — why a single exchange print is not a defensible fair value.
Every chain, integration, and competitor mentioned in this article gets its own page — coverage detail, comparison signals, and the audit trail your finance team needs.
- Chain
Ethereum
ERC-20, DeFi, gas, restaking — the largest ecosystem.
View page - Chain
Solana
SPL tokens, native stake, Jupiter, Metaplex NFTs.
View page - Integration
NetSuite integration
Mid-market and enterprise crypto subledger.
View page - Integration
QuickBooks integration
SMB GL with daily JE sync.
View page - Integration
Safe integration
DAO and corporate multi-sig accounting.
View page - Compare
Wag3s vs Cryptio
Side-by-side enterprise subledger comparison.
View page