CARF / DAC8: mapping crypto transactions
The narrative behind this reference sheet.
Read the guide →A reference sheet for the mapping layer: which ledger events fall into which reporting category, what is measured for each, and the asset identity decisions that have to be made once and applied consistently.
The framework does not report trades. It reports an aggregate identified by four things together: the user, the reporting period, the crypto-asset, and the transaction category. Everything in the mapping layer exists to get ledger rows into that shape without losing or double-counting anything.
| Ledger event | Category | Note |
|---|---|---|
| Purchase of a crypto-asset with fiat | Exchange against fiat | Acquisition side. Reported gross, not netted against disposals. |
| Sale of a crypto-asset for fiat | Exchange against fiat | Disposal side, reported separately from acquisitions. |
| Trade of one crypto-asset for another | Exchange between crypto-assets | Produces an acquisition and a disposal, each valued at the time of the transaction. |
| Deposit received on-chain | Transfer in | Distinct from any exchange it subsequently funds. |
| Withdrawal sent on-chain | Transfer out | Split by whether the destination is associated with a known provider. |
| Payment to a merchant in crypto-assets | Transfer, retail payment treatment | The framework treats retail payment transactions over a defined value as a distinct case. |
| Movement between a user’s own accounts | Not a transfer out | Internal movement. Treating it as a transfer inflates the reported population. |
| Cancelled or reversed transaction | Excluded | Excluded consistently under a documented policy rather than netted arbitrarily. |
Four decisions have to be made once and applied to every period, including retrospectively when a comparison is drawn:
Some ledger events do not map cleanly and need a documented position rather than an implicit one: staking rewards and similar accruals; airdrops and other unsolicited receipts; forks producing a new asset; fee-only movements; and transfers to addresses that cannot be attributed to a provider. Each of these should have a written treatment that a reviewer can read, because the mapping is where a supervisor or auditor will look first.
This sheet describes the mapping problem, not the field-level specification. Element names, allowed values, thresholds and the treatment of individual transaction types are set out in the framework’s schema and user guide, and in any national variant a jurisdiction mandates. Interpretation in this area is developing actively, so confirm against the current edition rather than a prior cycle.
Primary instruments only. Each is named in full so the reference remains traceable even if a link moves.
REGREP is an independent software provider. This record explains a reporting framework in plain language and is not legal, tax or regulatory advice. Confirm scope, thresholds and submission dates with your competent authority before you file.
More on this framework, and the module that produces the filing.
The narrative behind this reference sheet.
Read the guide →Settle the perimeter before building the mapping.
Read the questions →Categorise, aggregate and export the validated exchange file.
See the module →Bring your ledger in the shape your systems hold it. The module handles categorisation, aggregation and schema validation.