SMSF Bitcoin Audit Guide

Collaborative security in this context refers to a 2-of-3 multisignature (multisig) arrangement: multiple keys are held by different parties, and a configured threshold of signatures (e.g. two of three) is required to move funds. In plain terms:

• Multiple keys exist; no single key can move the Bitcoin alone.
• Trustees (or their delegates) retain control; they are signers and direct the use of the vault.
• No single party—including The Bitcoin Adviser or the software platform—can unilaterally move funds.
• There are no pooled assets; the vault is attributed to the SMSF (or the client).
• There is no unilateral third-party authority over the assets.

Software providers are not custodians. The platform that coordinates multisig (e.g. Unchained, Theya) provides software and coordination services. They do not custody Bitcoin; the assets are on the Bitcoin network and controlled by the key holders according to the multisig policy.

Scope and limitations. This guide focuses on Australian SMSFs. Lost keys, inheritance of SMSF Bitcoin, and tax implications of multisig transfers are complex; trustees should seek specific professional advice. If you are outside Australia, consult your local regulations.

Bitcoin held in an SMSF under this model is on-chain: it exists as entries on the Bitcoin network, controlled by the keys that form the multisig vault. The trustees (or their authorised signers) control those keys and are responsible for access and decisions. Trustees remain responsible for the fund's investment strategy, record-keeping, and compliance. This is consistent with self-custody principles and with the Australian Taxation Office's expectations that SMSF trustees understand and control fund assets. For current guidance, see the ATO's pages on self-managed super funds and, where applicable, crypto assets.

In this holding model, the auditor is ordinarily trying to get comfortable that the SMSF acquired the Bitcoin, that the fund's records align with the transaction and balance history, that the reporting-date holding is supportable, that the reporting-date value is supportable, and that the holding has been kept separate from personal assets.

Existence / balance

• On-chain balance at the relevant reporting date.
• Transaction history and relevant TXIDs.
• Reconciliation of the reported balance to the fund's records.

Attribution to the SMSF

• SMSF source of funds.
• Acquisition records linked to the relevant wallet or vault.
• Consistent identification of the holding in the fund's records.
• Clear separation from personal assets.

Valuation

• Reporting-date BTC quantity.
• Documented valuation approach.
• Objective and supportable market data.
• Retained evidence of price source and date.

A trustee or director attestation can support attribution of a wallet or vault to the SMSF, but it is not ordinarily relied on in isolation. It is strongest where it aligns with the objective record, including SMSF source of funds, transaction traceability, separation from personal assets, wallet attribution records, and reconciliation of the year-end balance. Trustee attestation is supporting evidence. It is strongest where it aligns with the objective transaction and record trail.

Put simply: trustee attestation supports the evidence trail; it does not replace it.

For reporting and audit purposes, the fund should use a documented valuation approach based on objective and supportable market data at the relevant reporting date. The method used should be retained with the fund's records and applied consistently unless a deliberate policy change is made and documented.

If open, close, spot, or exchange-specific methodology is used, it should be applied consistently. The formulas below are tools to implement a chosen policy, not a substitute for one.

Spreadsheet tools to support your valuation policy

Valuation calculator — Get the Bitcoin price for a specific date and currency (for audit and reporting).

Our reports show balances and movements in Bitcoin. For audit purposes, accountants often need market value and fiat amounts for each transaction. You can look up the Bitcoin price for any date and in your chosen currency using built-in spreadsheet functions in Google Sheets or Excel.

Google Sheets — Current price in AUD: =GOOGLEFINANCE("CURRENCY:BTCAUD"). For the closing price on the date in cell A2:

=INDEX(GOOGLEFINANCE("CURRENCY:BTCAUD","close",A2,A2,"DAILY"),2,2)

You can use "open", "high", or "low" instead of "close". For other currencies, replace BTCAUD with BTCUSD, BTCEUR, BTCCAD, etc. Data may be delayed by up to 20 minutes.

Excel (Microsoft 365) — For a single date in cell A2, returning date and close price in AUD:

=STOCKHISTORY("BTCAUD", A2, A2, 0, 1, 0, 1)

Ticker ("BTCAUD", "BTCUSD", "BTCEUR", etc.), then property codes: 0 = Date, 1 = Close, 2 = Open, 3 = High, 4 = Low, 5 = Volume. Requires Microsoft 365; data is end-of-day.

Valuation basis (open, close, high, or low) is a matter of professional judgment and documented fund policy. The formulas above help you apply your chosen basis consistently; they do not substitute for that policy.

We provide the following to support trustees, accountants, and auditors:

• Statement of Holdings — snapshot of vault balances and attribution at a point in time.
• Full transaction history — transaction IDs and details for movements into and out of the vault.
• Vault balances — on-chain balance information for the vault addresses.
• Service agreement — the client’s agreement with The Bitcoin Adviser (our Terms of Service and any engagement terms).
• Invoices — for fees paid for advisory and co-signing services.

Verification does not require disclosure of private keys, seed phrases, or any action that would weaken the security of the SMSF's Bitcoin. The relevant evidence can be supported through the documentation above and, where appropriate, view-only or export-based records that do not expose signing authority.

Audit evidence should not require disclosure of private key material, seed phrases, or any other action that weakens the security of the SMSF's Bitcoin. In this self-custody model, the objective is to substantiate the holding and valuation without creating unnecessary security or privacy risks.

The following are not provided to anyone, including auditors or accountants:

• Private keys
• Seed phrases or other key material
• Custody attestations (we are not a custodian)
• Third-party reserve statements or Proof-of-Reserves reports (no custodian relationship exists)
• Requests that would unnecessarily expand exposure of wallet security information beyond what is reasonably required

Audit requirements can be satisfied using the documentation set out in the “What we provide” section above.