The organising principle
Build the record first, apply the jurisdiction later.
Crypto record-keeping fails when the spreadsheet is designed around this year’s tax return instead of around the underlying economic events. A defensible system should preserve what actually happened, where it happened, which assets and parties were involved, how value was determined, and which evidence supports that reconstruction. Tax treatment, accounting treatment, sanctions analysis, AML questions, and regulatory reporting should sit in separate interpretation layers above those facts.
That distinction matters because there is no single global crypto tax ledger. The OECD’s CARF international reporting standard creates a common framework for service-provider reporting and information exchange, but its rules still need domestic implementation. CARF is organised around the assets covered, the service providers required to collect data, reportable transaction categories, and due diligence identifying users and their tax jurisdictions.
Similarly, AML standards do not make every crypto user subject to one worldwide rulebook. FATF Recommendation 15 and related standards are international standards that countries implement through their own laws and supervisory systems. FATF itself says national frameworks differ and must adapt the standards to local circumstances. As at July 2026, FATF still reported material differences in licensing, Travel Rule implementation, supervision, offshore service-provider treatment, unhosted-wallet risks and DeFi treatment.
So the record system should answer two different questions:
Factual question: What happened?
Legal question: What does jurisdiction X, under the rules applicable to taxpayer Y on date Z, do with what happened?
Those questions should never be collapsed into one field.
A blockchain transaction is evidence, but it is not the whole file. A transaction hash can prove that an on-chain movement occurred. It usually does not establish beneficial ownership of both endpoints, the purpose of the transfer, an off-chain exchange trade, the source of fiat funds, a contractual relationship, the tax residence of the owner, or the valuation methodology used. HMRC accordingly expects more than blockchain history, including exchange downloads, wallet information, transaction details, valuation records and bank statements. Its cryptoasset record-keeping guidance specifically warns that exchanges may retain records only for limited periods or may cease operating.
Primary research question: Among users operating across exchanges, self-custody wallets and DeFi protocols, which missing evidence field most often causes a legitimate self-transfer, bridge movement or asset transformation to be misclassified as a taxable disposal during later reconciliation: destination-wallet ownership evidence, acquisition-lot provenance, transaction-level fees, or contemporaneous transaction-purpose documentation?
A useful evidence base would compare first-pass transaction classifications with subsequently corrected ledgers across anonymised tax or compliance cases. The result could identify which records deliver the greatest reduction in reconstruction errors, rather than assuming that simply collecting more price data produces better records.
This is a records architecture, not legal or tax advice. Local classification still requires the law, guidance and facts applicable to the relevant person and period.
The jurisdiction map
A jurisdiction-neutral system is possible only if it is clear about which parts are genuinely portable and which parts are not.
| Jurisdiction / authority | Instrument | Affected parties | Date orientation | What the records need to anticipate | Remaining uncertainty |
|---|---|---|---|---|---|
| International / OECD | Crypto-Asset Reporting Framework, CARF | Reporting Crypto-Asset Service Providers, with information concerning reportable users | CARF publication dated 8 June 2023; implementation depends on participating jurisdictions | CARF reporting distinguishes crypto-to-fiat exchanges, crypto-to-crypto exchanges and transfers, and records amounts, units and other transactional information. The later XML schema expressly accommodates categories including staking, crypto loans, wrapping, collateral and transfers involving unhosted wallets. | CARF is not a universal taxpayer accounting method. Domestic implementation, scope, deadlines and exchange relationships matter. |
| European Union / Member State tax authorities | Council Directive (EU) 2023/2226, DAC8 | Reporting Crypto-Asset Service Providers and users whose transactions become reportable | Member States were required to transpose the directive by 31 December 2025 and apply it from 1 January 2026. Information for the first 2026 reporting year is exchanged by 30 September 2027. | Users should expect regulated intermediaries to collect identity and transaction information that can later be compared with their tax returns. DAC8 covers both domestic and cross-border activity and requires reporting by crypto-asset type. | The European Commission explicitly tells providers to check domestic reporting requirements, including deadlines and formats. |
| United States / Treasury and IRS | Internal Revenue Code section 6045 regulations and Form 1099-DA | Covered brokers and customers | Broker reporting on Form 1099-DA began for relevant transactions from 1 January 2025. Most 2025 statements did not contain basis. Mandatory basis reporting applies in specified circumstances for covered digital-asset securities sold from 1 January 2026. | Keep independent basis, acquisition-date and transfer records even when a broker issues a form. A broker’s visibility can be incomplete where assets arrived from another wallet or venue. The IRS has also moved US basis accounting towards wallet-by-wallet or account-by-account treatment for affected post-2024 holdings and transactions. | Basis reporting is not universal, and special reporting methods exist for certain stablecoins and NFTs. |
| United Kingdom / HMRC | HMRC Cryptoassets Manual and domestic CARF implementation | Cryptoasset users, and separately reporting cryptoasset service providers | HMRC’s record-keeping manual was published in 2021 and updated in November 2025. UK CARF implementation is intended to support first international exchanges in 2027. | HMRC says individuals should maintain their own transaction records, including asset type, transaction date, buy or sell status, units, sterling value, cumulative holdings, bank statements and wallet addresses. | Tax characterisation can differ by transaction and taxpayer circumstances. Record requirements should therefore remain separate from classifications. |
| International standard / FATF, implemented nationally | FATF Recommendations, particularly virtual-asset standards and Travel Rule requirements | Primarily VASPs and other regulated financial institutions after domestic implementation, with effects on their customers | FATF’s Recommendations were amended through June 2026. In July 2026 FATF reported that 83% of surveyed jurisdictions had passed Travel Rule legislation, with another 11 reporting implementation underway. | Preserve counterparty, wallet, service-provider and transfer-purpose evidence because regulated providers may later ask source-of-funds, source-of-wealth, beneficiary or transaction-context questions. | FATF continued to identify uneven implementation and uncertainty involving offshore VASPs, DeFi arrangements and unhosted wallets. |
The practical conclusion is not that everyone must reproduce CARF, DAC8 or Form 1099-DA in their private ledger. It is that your internal records should contain finer-grained data than any one reporting regime is likely to request. Aggregation can always be performed later. Missing transaction-level facts generally cannot be recreated with the same confidence years afterwards.
The canonical event record
The safest foundation is one canonical event table, with attachments and source files linked to it. Each row represents an economic or blockchain event, not necessarily a taxable event.
A swap, for example, should not simply be stored as ETH -> USDC, taxable. Store the ETH leaving, USDC arriving, fees, protocol, timestamp, transaction hash, wallet, valuation evidence and transaction purpose. Whether local law treats that event as a disposal belongs in a later jurisdiction-specific column or table.
Identity and provenance fields
| Field | What to preserve | Why it survives jurisdiction changes |
|---|---|---|
| Event ID | Your own immutable unique identifier | Lets every later tax calculation, reconciliation and document point back to the same event. |
| Source system | Exchange, wallet, protocol, bank, payroll provider, mining pool, OTC desk or other origin | Establishes where the record came from. |
| Source record ID | Order ID, trade ID, deposit ID, withdrawal ID, invoice number, pool-payment ID or equivalent | Makes later re-verification possible. |
| Raw source file | Original CSV, JSON, API response, statement, PDF or other unmodified export | Governments increasingly emphasise retaining source records and regular exports rather than relying entirely on third-party platforms. HMRC and CRA both warn about the possibility of lost platform access or limited provider retention. |
| Timestamp | Original timestamp, timezone and preferably UTC-normalised timestamp | Local tax years, daily valuation boundaries and holding periods can depend on timing. CRA expressly calls for transaction date and time. |
| Asset identity | Symbol plus full asset identifier | Tickers alone are ambiguous. On-chain tokens should normally include network and contract address; NFTs should include contract and token ID. |
| Network | Bitcoin, Ethereum, Solana, Arbitrum, Base and so on | Necessary to distinguish technically separate assets, transaction hashes and bridge legs. |
| Quantity | Exact quantity before rounding | Reporting systems may aggregate later, but the underlying ledger should not. OECD CARF reporting itself uses units as a distinct data element. |
| From and to locations | Wallet addresses, exchange accounts or other account identifiers | Helps distinguish transfers between the same owner from transfers to another person. HMRC and CRA both specifically identify wallet addresses as relevant records. |
| Transaction identifier | Transaction hash, block reference where useful, and any exchange-side transfer ID | Connects internal records to public-chain evidence. |
| Event type | Buy, sell, swap, transfer, income receipt, staking reward, mining reward, bridge, loan, collateral movement, gift, payment and so on | Preserve the factual event before imposing a tax category. |
| Counterparty | Legal name where known, platform name, wallet address or protocol | CRA explicitly includes the nature of the transaction and the other party among transaction records. |
| Purpose | Self-transfer, investment purchase, salary, invoice payment, liquidity provision, collateral, gift and so on | On-chain movements rarely disclose legal or economic purpose by themselves. |
| Ownership status | mine, joint, business, client, third party, unknown, with evidence reference |
One of the most important facts for distinguishing movements within the same beneficial ownership perimeter from transfers to somebody else. |
| Fiat value | Functional or reporting currency value at the relevant timestamp | Tax authorities commonly require local-currency values. HMRC requires sterling values; CRA requires Canadian-dollar values. |
| Valuation evidence | Price source, quoted pair, timestamp, FX source and methodology | OECD’s reporting schema itself anticipates alternative valuation methods such as third-party values and reasonable estimates, illustrating why valuation methodology should be preserved rather than silently embedded in a number. |
| Fees | Amount, asset used to pay the fee and fee type | Fee treatment can affect basis, proceeds, expense deductions or neither, depending on jurisdiction and context. |
| Acquisition provenance | Original acquisition event or lot reference | Needed to reconstruct basis methods and transfers across venues. US rules provide a particularly clear example of why wallet and acquisition provenance can matter. |
| Evidence links | Contract, invoice, email, protocol documentation, wallet proof, statement, screenshot, correspondence | Explains facts that are not encoded on-chain. |
| Confidence flag | Confirmed, inferred, incomplete, conflicting | Prevents estimated data from later being mistaken for source evidence. |
Do not use the ticker as the asset ID
USDC, ETH, BTC or XYZ is not a sufficiently durable identifier by itself.
For fungible tokens, store at least:
network + contract address + asset name + symbol
For native network assets, store:
network + native asset identifier
For NFTs:
network + contract address + token ID
For wrapped or bridged assets, identify both the source asset and resulting representation. OECD’s 2025 CARF XML schema separately recognises wrapping as a possible exchange type, which is a useful reminder that “same economic exposure” and “same recorded asset” are not necessarily identical concepts.
Never overwrite the historical identity of an asset because a token later migrates, rebrands or changes ticker.
Evidence by transaction type
The general event record should be supplemented according to what can later become disputed.
| Activity | Save this in addition to the canonical record | The question it lets you answer later |
|---|---|---|
| Acquisitions | Purchase confirmation, order and fill history, quantity, consideration paid, acquisition fees, bank or stablecoin funding record, timestamp and valuation | What did this asset actually cost, when was it acquired, and which lot did it create? |
| Sales | Order and fill history, gross proceeds, selling fees, settlement currency, withdrawal records, linked acquisition lots where known | Can reported proceeds and gain calculations be reconstructed independently of an exchange’s later statement? |
| Crypto-to-crypto swaps | Both asset legs, exact quantities, DEX route or exchange pair, fees, wallet, transaction hash and contemporaneous valuation for both sides | Was this an exchange of different assets, and what was the value at the event time? CARF separately recognises crypto-to-crypto acquisitions and disposals. |
| Wallet-to-wallet transfers | Sending and receiving address, evidence that both locations were under the same beneficial ownership, send and receive timestamps, quantity discrepancy and network fee | Was value actually transferred to another person, or merely relocated? Canada’s current crypto guidance gives one example of a jurisdiction expressly treating transfers between a person’s own wallets differently from disposals. |
| Bridge transfers | Source-chain hash, destination-chain hash, bridge provider, source and destination token contracts, amounts before and after bridging, bridge and gas fees, proof that destination wallet is yours, protocol documentation from the relevant date | Did economic ownership continue unchanged, did one asset become another, was a wrapped representation created, and where did any quantity difference go? Do not hard-code “bridge = non-taxable”, because local characterisation can depend on the resulting rights and asset. |
| Staking | Delegation or deposit transaction, validator or platform, reward accrual records, reward receipt or claimability timestamps, token quantity, reward type, commissions, slashing, lock-up terms and valuation evidence | When did the taxpayer obtain the reward, what was received, and was it automatically compounded, claimable or actually transferred? CARF’s technical schema includes staking as a reportable exchange-type indicator in appropriate cases, but that is a reporting classification, not a universal income-recognition rule. |
| Mining | Pool agreement, mining wallet, payout history, block or pool reward identifiers, mining fees, hardware invoices, power records, maintenance and operating records | Can mining receipts and any associated business expenses be evidenced? CRA specifically identifies mining hardware, electricity and related costs, pool fees, hardware information and pool arrangements as records to retain. |
| Airdrops | Project announcement, eligibility rules, snapshot date if relevant, claim transaction, receipt timestamp, quantity, token contract, restrictions and evidence of market availability/value | Was the token unsolicited or claimed, when did control arise, and could a defensible value be determined at the relevant time? Those facts allow later application of whichever jurisdiction’s income and basis rules apply. |
| Forks and migrations | Pre-event holdings, fork or migration documentation, old and new token identifiers, claim or migration transactions, allocation methodology and contemporaneous market evidence | Did the holder receive a new asset, replace an existing asset, or merely experience a technical migration? |
| DeFi swaps | Wallet transaction, decoded token transfers, smart-contract addresses, route, protocol version, minimum output, actual output and fees | A single wallet transaction may contain several economically distinct token movements. Preserve the raw transaction and decoded interpretation separately. |
| Liquidity provision | Assets deposited, LP token or position received, pool contract, position ID, fee earnings, incentives, withdrawals and final assets returned | Were assets transferred into a pool, exchanged for a new position, or merely represented differently? This is precisely the type of question that cannot safely be answered from a generic DeFi label. |
| Lending | Loan terms, token deposited, receipt token if any, interest accrual, withdrawals, borrower or protocol, collateral arrangements | Did ownership or beneficial rights change, what income arose, and what did the user receive in return? The CARF data model explicitly recognises crypto loans and collateral as transaction descriptors in appropriate reporting situations. |
| Borrowing and collateral | Loan agreement or protocol terms, collateral deposits, debt-token records, interest, repayments, collateral substitutions and liquidation events | Was a transfer collateral rather than a disposal, and did any later liquidation create a separate economic event? |
| Liquidations | Trigger price, collateral sold or transferred, debt extinguished, liquidation penalty and protocol transaction | Which assets disappeared, what liability was satisfied and what fees or penalties were incurred? |
| Gifts | Donor and recipient, date, quantity, wallet addresses, gift letter or correspondence, market value and the donor’s acquisition history where available | Some jurisdictions require information inherited from the donor’s basis history, while others may treat gifts differently. Preserving both value and historic basis prevents the later recipient from receiving an asset with no provenance. |
| Inheritance | Estate documents, date-of-death information where relevant, valuation, wallet transfer and legal ownership documentation | Allows the recipient to apply the applicable local succession and basis rules without trying to reconstruct the deceased holder’s records afterwards. |
| Business receipts | Invoice, contract, customer identity, goods or services supplied, invoice currency, crypto amount, payment timestamp, transaction hash and valuation | Was the crypto an investment acquisition, business revenue, salary, reimbursement or something else? |
| Business payments | Supplier invoice, contract, expense category, approval record, crypto sent, wallet, transaction hash, fiat equivalent and any VAT, GST or sales-tax documentation | Supports both the crypto disposition analysis and the underlying business expense or indirect-tax treatment where applicable. |
| Employment and contractor compensation | Employment or contractor agreement, vesting schedule, payslip or invoice, grant documents, token receipt, restrictions and valuation | Separates compensation facts from investment transactions. |
| OTC transactions | Executed agreement, counterparty identity, settlement instructions, transaction hashes, bank wires and pricing methodology | Public-chain information alone may not contain the trade price or legal counterparty. |
| Fiat deposits and withdrawals | Full bank statement, exchange fiat ledger, bank reference, payment processor record and fees | Provides the audit trail between the banking system and crypto venue. HMRC expressly regards fiat records and bank statements as part of the audit trail. |
| Lost, stolen or inaccessible assets | Police or platform reports where applicable, wallet history, correspondence, compromise evidence, attempts to recover access and dates | Local rules differ sharply on when a loss can be recognised. Evidence should establish the facts before anyone attempts the legal classification. |
| Exchange or protocol failure | Statements immediately before failure, claims filed, bankruptcy documents, administrator correspondence and recoveries | Distinguishes a missing record from an actual economic loss and preserves evidence if the platform later disappears. |
Bridges deserve two records, not one vague transfer
A bridge should normally be reconstructable as an event chain:
source wallet -> bridge contract -> bridge mechanism -> destination asset -> destination wallet
Store the source and destination transaction IDs separately.
Then explicitly record:
same beneficial owner? yes / no / unknown
source asset identifier
destination asset identifier
amount sent
amount received
fees
wrapped or native?
bridge protocol
interpretation status: unresolved / reviewed
That design leaves local advisers or software free to decide whether the event is a mere transfer, an exchange, a disposal and reacquisition, or something else without changing the underlying evidence.
DeFi needs an event graph
“One transaction hash equals one tax event” is often a poor data model for smart-contract activity.
A single transaction may involve collateral entering a contract, borrowed assets arriving, fee tokens moving, an incentive token being issued, and an LP or receipt token being minted. FATF’s 2026 review likewise continued to identify DeFi arrangements as an area presenting regulatory implementation difficulties.
Keep the transaction hash as the evidence container, then record each economically meaningful leg underneath it.
That lets a future interpretation layer combine or separate legs according to the applicable rules.
Assumptions, valuation and reconciliation
Most serious reconstruction problems are not caused by an inability to download transactions. They arise because an undocumented assumption silently becomes “fact”.
Maintain a separate assumptions register.
| Assumption category | Example | What the file should contain |
|---|---|---|
| Timezone | “All events converted to Europe/London before daily valuation” | Original timezone, conversion rule, software version and date adopted |
| Reporting currency | GBP, USD, EUR, CAD | FX source and conversion convention |
| Crypto pricing | Exchange close, transaction pair, volume-weighted price, pricing service | Provider, pair, timestamp and fallback hierarchy |
| Illiquid token valuation | No reliable market at reward timestamp | Why the selected method was used and what alternatives were unavailable |
| Wallet ownership | 0x123... is my self-custody wallet |
Exchange withdrawal evidence, signed-message evidence if safely appropriate, device/wallet records, or another corroborating record |
| Missing history | Exchange CSV begins in 2021 but account opened in 2020 | Gap description and reconstruction method |
| Asset equivalence | Wrapped token treated as economically connected to native token | Contract addresses, protocol documentation and explicit note that tax equivalence has not automatically been assumed |
| Bridge treatment | Recorded as a transfer for current draft | Mark this as an interpretation, not immutable source data |
| Lot method | FIFO, specific identification, pooled cost or another method | Jurisdiction, applicable period, authority relied upon and effective date |
| Fees | Added to acquisition cost | Rule applied, fee asset and jurisdiction |
| Staking timing | Valued when received, when claimable or another point | Rule source and the factual evidence for when control arose |
| Airdrop timing | Receipt and valuation time | Eligibility, claimability and market evidence |
| Business versus personal ownership | Wallet assigned to company rather than shareholder | Governance, accounting and legal records supporting the ownership boundary |
Separate source facts from derived values
A robust database might contain four columns that look superficially redundant:
raw_quantity
raw_quote_value
normalised_fiat_value
tax_value
They are not redundant.
raw_quote_value records what the platform said.
normalised_fiat_value records the result of your consistent pricing methodology.
tax_value records whatever adjustment a particular local rule requires.
The same separation should apply to fees, proceeds, basis and income.
This becomes particularly important as tax authorities receive more third-party data. Under EU DAC8, service providers collect and report aggregate transactional information by cryptoasset, including amounts relating to acquisitions, disposals and transfers. In the United States, Form 1099-DA reporting began with 2025 broker transactions, but the IRS warned taxpayers that most 2025 forms would not include basis, leaving taxpayers to calculate it themselves.
Third-party reporting therefore does not eliminate private record-keeping. It increases the need for reconciliation.
Reconcile movement, not just gains
At least periodically, prove:
Opening balance + acquisitions + receipts + inbound transfers - disposals - outbound transfers - fees and other reductions = closing balance
Do this per asset and per wallet or account.
CRA’s current guidance expressly recommends maintaining beginning and ending wallet balances and costs, alongside trade and transfer ledgers. US basis rules provide another reason to retain wallet-level histories, because the IRS’s post-2024 rules and transition procedure require affected taxpayers to account for digital-asset basis on a wallet-by-wallet or account-by-account basis rather than relying on a universal pool spanning every location.
A reconciliation difference should never simply be edited away. Create an exception:
difference: 0.043 ETH
cause: unknown
first observed: 2026-04-12
investigated sources: exchange CSV, wallet history
resolution: fee omitted from original import
correction date
correction evidence
The audit trail should show that a correction occurred, not pretend the first version never existed.
Preservation, security and audit readiness
Keep a source archive and a working ledger
The cleanest structure has three layers:
Source archive: untouched files exactly as obtained.
Normalised ledger: cleaned, standardised events linked back to the source archive.
Interpretation layer: tax, accounting, AML or regulatory classifications created from the normalised ledger.
This prevents software changes from destroying the original evidence.
For example:
text
Copy
/crypto-records/
/sources/
/exchange-a/
2026-01-05_trade_history.csv
2026-01-05_deposit_history.csv
2026-01-05_withdrawal_history.csv
/wallets/
/banks/
/contracts/
/invoices/
/mining/
/staking/
/normalised/
events.parquet
wallets.csv
assets.csv
counterparties.csv
/interpretations/
/UK/
/US/
/EU/
/assumptions/
valuation-policy.md
wallet-ownership-register.csv
missing-data-register.csv
/reconciliations/
/tax-filings/
Preserve raw exports before platforms change
Do not treat an exchange’s live account page as permanent storage.
HMRC warns that an exchange might retain records only briefly or no longer exist when a tax return is examined. Canada’s Revenue Agency similarly recommends regular transaction exports because exchanges use different retention standards and users can lose access or a platform can cease serving the jurisdiction. Its crypto books and records guidance currently requires Canadian taxpayers to retain relevant books and records for at least six years from the end of the last taxation year to which they relate.
That six-year period is a Canadian example, not a universal crypto retention period.
Different jurisdictions, taxpayer types, proceedings and document categories can have different periods. A jurisdiction-neutral archive should therefore not delete source data merely because one country’s ordinary limitation period has elapsed. Establish the applicable destruction rule only after determining the taxpayer, jurisdiction, filing period, open enquiries, amended returns, losses carried forward, ownership history and other relevant circumstances.
Hash important files
For significant records, calculate a cryptographic checksum when the file enters the archive.
A manifest can contain:
text
Copy
filename
date_downloaded
source
reporting_period
file_size
sha256_hash
notes
The hash does not prove that the original data was true. It can, however, help demonstrate that the archived file has not silently changed since the checksum was created.
Never overwrite the original file after import. Correct the normalised ledger instead.
Do not archive secrets you do not need
A tax or compliance archive generally needs public wallet addresses and evidence of ownership. It does not need seed phrases or private keys.
Keep authentication secrets, signing devices and recovery material outside ordinary accounting and compliance files. The evidentiary value of a wallet address does not justify creating a second repository from which the assets themselves could be stolen.
Where proof of wallet control becomes necessary, use a method appropriate to the particular wallet, request and security situation rather than distributing private credentials.
Keep the fiat side
One of the easiest mistakes is preserving every blockchain event but deleting the bank statements that establish how funds entered or left the ecosystem.
Save:
bank statement -> fiat deposit -> exchange account -> asset purchase
and eventually:
asset sale -> fiat balance -> withdrawal -> bank statement
HMRC expressly identifies fiat deposits, ATM records and bank statements as part of the crypto audit trail.
Keep contracts beside transactions
Transactions involving employment tokens, vesting, grants, loans, OTC trades, SAFTs, mining pools, staking providers, company payments or settlements may be impossible to understand from ledger data alone.
Preserve the document that explains why the transfer occurred.
Version matters. For a protocol or contractual arrangement that changes over time, retain the terms applicable when the transaction happened rather than relying solely on today’s web page.
Build an audit bundle annually
An annual close should leave you able to regenerate the year’s ledger without logging into every original platform.
A sensible archive contains the raw exchange and wallet exports, bank records, asset and wallet registers, transaction ledger, valuation methodology, unresolved-exception log, major contracts, staking and mining reports, filed tax calculations where applicable, and a reconciliation proving the closing holdings.
The United States provides a useful example of why independent archives remain necessary even as official reporting expands. The IRS Form 1099-DA broker reporting page confirms that digital-asset broker proceeds are now subject to dedicated information reporting. Yet IRS materials also make clear that basis reporting depends on the year and whether the asset is a covered security, with additional exceptions for some asset categories.
The regulatory direction is towards more third-party visibility, not towards replacing the user’s own history. OECD CARF reporting, EU DAC8 and US Form 1099-DA all strengthen the ability of tax authorities to compare intermediary information with taxpayer reporting, while FATF continues to push wider implementation of transaction-transparency and supervisory requirements for regulated virtual-asset providers.
The durable objective is therefore not “tax-ready records”. It is evidence from which a tax, accounting or compliance answer can be rebuilt under the law that actually applies when the question arrives.
A well-designed crypto archive should let a reviewer move in both directions:
tax return or compliance conclusion -> calculation -> interpreted event -> normalised event -> raw platform or wallet evidence
and:
raw transaction -> ownership and purpose -> valuation -> local legal classification -> return or report
If either path breaks, the record system is incomplete.