Crypto Audit Readiness: What Auditors Actually Look For

Most Web3 companies discover their audit problems three weeks before close. By then, fixing them costs 10x what prevention would have. Here's what auditors actually look for.

The standard advice ("keep good records, label your wallets, reconcile monthly") is correct but useless. It tells you the destination, not the route. What auditors really want is a defensible chain of evidence linking on-chain reality to your financial statements. That chain breaks in predictable places, and audit teams know exactly where to push.

This article walks through what a Big Four or mid-tier crypto auditor opens with on day one, what they escalate, and the gaps that turn a six-week engagement into a three-month nightmare.

The five audit assertions for cryptoassets

Audit work is structured around assertions. For digital assets, the same five from traditional audit apply, but each has a Web3-specific twist:

• Existence: the assets reported on the balance sheet actually exist and the entity controls them at the reporting date.
• Completeness: every transaction that should be recorded has been recorded. No missing wallets, no missing chains, no missing internal transfers.
• Valuation: assets are recorded at the correct fair value, with documented pricing sources and a defensible methodology.
• Rights and obligations: the entity has legal rights to the assets and any encumbrances (staked, locked, lent, collateralized) are disclosed.
• Presentation and disclosure: assets are classified correctly (intangible, financial, inventory depending on framework), and disclosures cover material risks.

If your finance team can't produce evidence for each of these in under 48 hours, your audit will run long. Auditors look for gaps in the evidence trail, not just whether you "have records."

Existence: proving you control the wallets you claim to control

This is where most first-time crypto audits stumble. Holding the address in a spreadsheet is not proof of control. Auditors expect one of three things:

1. Signed message verification: the entity signs a specific message (often the audit firm's name plus a date) using the private key. The auditor verifies the signature against the public address. Cheap, fast, conclusive.
2. Test transaction: the entity moves a small, auditor-specified amount in or out of the wallet on an auditor-specified date. Documented with transaction hash.
3. Custodian confirmation: for assets held with Coinbase Custody, BitGo, Fireblocks, Anchorage, the auditor sends a third-party confirmation request directly to the custodian.

For multi-sig wallets, expect questions about every signer: who they are, what their role is, whether any signers have left the company, and how key rotation is handled. A Safe wallet with a former CFO still on the signer list is a finding, not a footnote.

Cold storage adds a wrinkle. Auditors will want to observe the signing ceremony or accept signed-message proof from the cold device. Hardware wallets in a safe with no documented procedure for who can access them is a control deficiency.

Completeness: catching transactions you didn't record

Completeness is the assertion that breaks audits. The risk: you reconciled the wallets you remembered to reconcile.

Auditors test completeness by going outside your records:

• Block explorer reconciliation: they pull every transaction for every disclosed wallet directly from Etherscan, Solscan, or chain-specific equivalents, and compare to your ledger. Any unrecorded transaction is a finding.
• Wallet discovery: they look for wallets you didn't disclose. Common techniques include reviewing employee disclosures, scanning corporate Gnosis Safe transaction history for outflows to unknown addresses, and checking exchange API connections against your declared exchange accounts.
• Cross-chain coverage: they ask which chains you operate on. If you say "Ethereum, Polygon, Arbitrum" but your treasury uses a bridge to Base, expect questions about why Base isn't in scope.
• Internal transfers: moving assets between two of your own wallets shouldn't generate a P&L impact, but it generates two on-chain events. Auditors verify these are eliminated correctly.

The reliable completeness fix: a single source of truth that pulls every wallet, every chain, every CEX account into one ledger. If you reconcile from a spreadsheet built per-quarter, completeness will fail.

Valuation: pricing sources, fair value at reporting date, custodian statements

Under FASB ASU 2023-08 (effective for fiscal years beginning after 15 December 2024), crypto assets are measured at fair value with changes in net income each period. IFRS treatment depends on classification but typically also requires fair value evidence. Either way, auditors want documentation of:

• Pricing source policy: which exchange or aggregator you use, and why. Coinbase, Kraken, CoinGecko, CoinMarketCap, Chainlink oracles each use different methodologies. Pick one, document why, apply consistently.
• Reporting-date snapshots: the price used at each reporting date, captured at a specific time (UTC midnight is common), with screenshots or API receipts.
• Level 1 vs Level 2 vs Level 3 hierarchy: major tokens with active markets are typically Level 1. LP positions, vested tokens, and illiquid governance tokens drift toward Level 2 or 3 and require disclosure.
• Illiquid tokens: for tokens without an active market, expect detailed scrutiny: trading volume, bid-ask spreads, recent OTC trades. A "$50M position" in a token with $200K daily volume cannot be valued at last-trade price.
• Staked, locked, vested: encumbered assets need separate disclosure and sometimes a discount for lock-up duration.

Custodian statements help, but auditors don't accept them at face value. They reconcile custodian-reported balances back to on-chain wallet balances at the reporting date.

The internal controls auditors expect (SOC 1 / SOC 2 implications)

For financial statement audits, internal controls over financial reporting (ICFR) get reviewed even if you're not subject to formal SOX. For SOC 2 engagements, controls are the audit. The crypto-specific controls auditors actually look for:

• Wallet creation policy: who can create a corporate wallet, what approvals are needed, where the keys are stored, who has signing authority.
• Transaction approval: multi-sig thresholds, approval workflows, segregation of duties between transaction initiators and approvers.
• Key management: storage, rotation, recovery, offboarding when employees leave.
• Pricing and valuation controls: how prices are pulled, who reviews valuation entries, how exceptions are handled.
• Reconciliation cadence: frequency, who performs, who reviews, how exceptions are resolved.
• Change management: for smart contracts the entity controls, who can deploy, who reviews, how changes are tested.

A SOC 2 Type II report covers the operating effectiveness of these controls over a period (typically 6 to 12 months). It's not a compliance trophy. It's evidence your controls actually work in practice. For Wag3s customers asking about this, our SOC 2 Type II is in progress for Q4 2026, with ISO 27001 targeted for Q1 2027.

The audit trail: what good documentation looks like

Auditors look for a chain that runs: source event → categorization decision → journal entry → financial statement line. Break the chain anywhere and the audit slows down. Good documentation includes:

• Transaction hash: the on-chain anchor.
• Date and time: block timestamp, with timezone.
• Counterparty: wallet address, label, and (where relevant) KYC status.
• Asset and amount: with token contract address, not just a ticker.
• USD-equivalent value at execution: with the pricing source used.
• Category: payroll, vendor payment, revenue, treasury rebalance, gas, internal transfer.
• Supporting document: invoice, contract, governance proposal, board approval.
• Journal entry reference: the GL entry the transaction maps to.

If your audit trail consists of CSV exports from Etherscan plus a separate spreadsheet of categorizations, expect re-performance work. Wag3s Ledger generates a transaction-level audit trail with the eight financial reports auditors typically request, exportable in formats your accountants and auditors recognize.

Common audit findings in Web3 (and how to prevent them)

Findings, ranked by frequency we see in first-time Web3 audits:

Most of these aren't "we had no controls." They're "our controls didn't generate audit evidence in a format the auditor could test." The fix is usually tooling, not policy.

Working with custodians: SOC 1 reports and proof-of-reserves

If you use Coinbase Custody, BitGo, Fireblocks, Anchorage, or similar, your auditor is going to ask for the custodian's SOC 1 report. SOC 1 covers controls relevant to financial reporting at the service organization. The auditor reads it to determine which of the custodian's controls they can rely on, and which they need to test independently.

What to check:

• Type II, not Type I: Type I is a point-in-time snapshot. Type II covers operating effectiveness over a period.
• Period coverage: must align with your audit period. A SOC 1 covering Jan-Jun 2026 doesn't cover your Sep 2026 year-end balance.
• Carve-outs: sub-service organizations excluded from the report. If your custodian uses a sub-custodian, the sub-custodian needs its own coverage.
• Complementary user entity controls (CUECs): controls the report assumes you have implemented. If you don't have them, the SOC 1 doesn't help.

Proof-of-reserves is a separate exercise from SOC 1. It demonstrates that customer balances at the custodian are backed by on-chain holdings. Useful for transparency, not a substitute for a SOC 1 report.

Pre-audit checklist

12 weeks out

• Confirm scope with your auditor (entity, period, frameworks, materiality)
• Inventory every wallet, every chain, every CEX account, every custodian
• Pull SOC 1 / SOC 2 reports from custodians and service providers
• Document pricing source policy in writing
• Run a dry reconciliation for the most recent closed quarter
• Identify any wallets requiring signed-message proof of control

4 weeks out

• Generate the eight standard financial reports for the audit period
• Prepare existence evidence (signed messages or test transactions) for every wallet
• Document multi-sig signer changes during the period
• Compile encumbrance disclosures (staked, locked, lent, collateralized)
• Walk your auditor through the chart of accounts and category mapping
• Resolve any pricing exceptions or illiquid valuation positions

Audit week

• Single point of contact for auditor questions
• Read-only access to your transaction data with filtering by date, wallet, category
• Daily standup with the audit team to clear questions same-day
• Document every decision the auditor flags, even minor ones, for future reference

FAQ

Q: Do we need a SOC 2 to get audited? A: No. SOC 2 is a separate engagement focused on security and operational controls. A financial statement audit reviews ICFR but doesn't require SOC 2. That said, customers and partners often ask for SOC 2 — and the same control work supports both.

Q: How does the new FASB rule (ASU 2023-08) change audit work? A: Fair value measurement each period means more pricing-source documentation and more sensitivity to mark-to-market gains and losses. Impairment-only accounting under the prior guidance let some valuation issues hide; fair value surfaces them.

Q: Can our auditor accept blockchain data as primary evidence? A: Yes, on-chain data is increasingly accepted as audit evidence by major firms. The PCAOB has issued guidance acknowledging blockchain data as a source. The auditor still needs to verify the entity controls the addresses, that the data hasn't been tampered with via the entity's tooling, and that pricing is correctly applied.

Q: We use a DAO-style multi-sig for treasury. Is that auditable? A: Yes, with the same evidence pattern: prove control of the multi-sig (signed messages from a quorum of signers works), document the signer set and approval thresholds, and reconcile transactions. DAOs without legal entity wrappers face additional questions about who the audit opinion is addressed to.

Q: What if our auditor has never done crypto? A: Common in mid-market engagements. Plan for more time, more education, and more documentation. Provide them with the AICPA Practice Aid on Digital Assets and the PCAOB spotlight document early. Consider engaging a specialist for valuation or smart contract questions that get into the weeds.

Further reading

• Wag3s Ledger, audit-ready accounting with transaction-level audit trail and eight financial reports
• Wag3s Trust, security and compliance posture, including SOC 2 Type II progress and ISO 27001 timeline
• IFRS vs GAAP for Crypto Assets, accounting framework choices and their audit implications
• Crypto Accounting Revolution, how blockchain analytics changed compliance work
• AICPA Practice Aid: Accounting for and Auditing of Digital Assets, the reference document U.S. auditors work from
• PCAOB Spotlight: Auditing Considerations Related to Cryptoassets, regulator guidance on inspection findings and expectations

The companies that pass their first crypto audit cleanly aren't the ones with the cleanest spreadsheets. They're the ones whose tooling generates evidence in the format auditors need, on demand. Build that infrastructure before the engagement letter is signed, and the audit becomes a review rather than an excavation.