A multi-wallet and multi-exchange amendment is rarely a small project. The taxpayer has activity spread across several custodial exchanges, multiple self-custody wallets, one or more chains, and frequently a list of DeFi protocols, NFT marketplaces, bridges, and fiat ramps. The original return reflected what the available records and the available tax software could produce at the time. A reconstruction for an amended return rebuilds the underlying ledger from primary sources so that the corrected Form 8949, Schedule D, and any Schedule 1 or Schedule C entries are supported by a coherent transaction history rather than by a partial replay of the original software run.
That posture matters because reconstruction is the engineering work behind the corrected return position. The IRS sees Form 1040-X, the supporting schedules, and any 1099-DA reconciliation; it sees the response if the corrected return is examined. The taxpayer’s protection lives in the workpaper file. A clean multi-wallet reconstruction produces an audit-ready ledger that ties every disposition to a source acquisition, every transfer between the taxpayer’s own systems to a matched pair, and every ordinary-income receipt to a fair market value source on the dominion-and-control date.
The fast decision table
| Situation | Reconstruction posture | Why |
|---|---|---|
| Activity across 3+ wallets / exchanges, original return used a single pooled software run | Full source-system reconstruction before any amendment | Pooled software output cannot satisfy the wallet-by-wallet basis rule for tax year 2025 forward and frequently misclassifies transfers between the taxpayer’s own systems. |
| Self-custody wallets used in addition to custodial exchanges | Wallet inventory + ownership documentation + on-chain reconciliation | Self-custody activity lives on-chain and must be reconstructed from block-explorer data; ownership has to be documented because the taxpayer holds the keys. |
| Multiple chains used (Ethereum, Bitcoin, Solana, Layer-2 networks, alt-L1s) | Chain-by-chain ledger then unified reconciliation | Each chain has its own block explorer, transaction model, and export format; the unified ledger has to bring them together with a consistent time and basis framework. |
| DeFi protocols (liquidity pools, lending, staking, yield) used | Protocol-by-protocol treatment memo, then ledger | DeFi events have variable tax treatment depending on protocol mechanics; the reconstruction needs a memo per protocol category. |
| Bridges or wrap transactions used | Bridge transaction reconciliation as a discrete workpaper | Bridges and wraps can be taxable dispositions or non-taxable substitutions depending on the bridge architecture; treating them all as one is usually wrong. |
| Records are missing for some years or some wallets | Reconstruction with documented unresolved-records list | A complete reconstruction may not be possible; the workpaper file should document what was reconstructed, what was estimated, and what remains unresolved. |
| Activity crossed January 1, 2025 | Allocation analysis under Rev. Proc. 2024-28 plus reconstruction | The wallet-by-wallet basis rule and the one-time pre-2025 safe harbor allocation are part of the reconstruction, not separate workpapers. |
The source-system inventory
Reconstruction begins with a complete inventory of every system the taxpayer touched. Without the inventory, the reconstruction is necessarily incomplete; with it, every later workpaper has a defined scope. The inventory should be a structured list:
| Category | Specific instance | Identifier | Active dates | Records available |
|---|---|---|---|---|
| Custodial exchange | (e.g., Coinbase, Kraken, Binance.US) | account ID or email | start / end | CSV export status, statement availability |
| Self-custody wallet | wallet name | address(es), chain | start / end | block-explorer access, seed-phrase backup, transaction count |
| DeFi protocol | protocol name + chain | wallet address that interacted | start / end | protocol UI history, contract events |
| NFT marketplace | marketplace name | account / wallet | start / end | marketplace export, on-chain confirmation |
| Bridge | bridge name + chains | source and destination wallets | start / end | bridge UI history, on-chain confirmations |
| Fiat ramp | bank / payment processor | account number / linkage | start / end | bank statements, exchange deposit records |
The inventory is not the end product; it is the scope statement. Every later workpaper draws from one or more inventory rows. Gaps in the inventory become exception items in the final ledger.
Proving wallet ownership
For self-custody wallets, the corrected return position depends on the taxpayer’s ability to demonstrate ownership of each address. The reconstruction workpaper should document the evidence:
- Records of seed-phrase or private-key custody (without the keys themselves)
- Hardware-wallet device serial numbers and purchase records
- Signed messages from the address that the taxpayer can reproduce on demand
- Funding records that tie a known taxpayer source (fiat ramp, custodial exchange withdrawal) to the address
- Withdrawal records from the address to a known taxpayer destination
Ownership evidence is what allows a transfer between two of the taxpayer’s own wallets to be treated as a non-taxable transfer rather than a disposition. Without it, the corrected position is harder to defend on review.
Transfer matching across systems
The most consequential reconstruction workpaper is the transfer-matching log. Every withdrawal from one of the taxpayer’s systems should be paired with the corresponding deposit on another of the taxpayer’s systems. Unmatched withdrawals typically look like dispositions in software output; unmatched deposits typically look like zero-basis acquisitions. Matched pairs preserve basis and holding period across the transfer.
The matching workpaper should record, for each transfer:
- The originating system and the destination system
- The withdrawal transaction ID (on-chain hash or exchange reference)
- The deposit transaction ID (on-chain hash or exchange reference)
- The asset, quantity, and date
- Any fee deducted in transit (network fee, exchange withdrawal fee)
- The basis and holding period being preserved
- Any unresolved gap and the evidence supporting an inference
Cross-chain transfers via bridges add a step: the source-chain transaction and the destination-chain transaction are separate on-chain events linked by the bridge’s protocol logic. The matching workpaper should document both legs.
Chain chronology
A unified ledger across multiple chains requires a consistent time framework. Two practical choices:
- UTC across all chains. Use the on-chain timestamp from each block as the transaction time. Cross-chain comparisons are straightforward; the FMV source for each transaction date is a single look-up per asset per date.
- Taxpayer’s local time. Convert all timestamps to the taxpayer’s time zone before sorting. Useful when the corrected return narrative needs to align with the taxpayer’s recall of events.
Whichever framework is used, the reconstruction should apply it consistently. Mixed time frameworks (UTC for some transactions, local time for others) produce ordering errors that distort lot identification and holding period.
DeFi protocol treatment memos
A DeFi-heavy reconstruction needs a treatment memo per protocol category. The memo addresses:
- The economic substance of the protocol (lending, liquidity provision, staking, yield, governance, derivatives)
- The taxable events the protocol generates (deposits, withdrawals, position changes, reward claims, fee accruals)
- The basis treatment for any tokens received (income-derived basis at FMV on receipt, basis substitution for wrapped tokens, basis preservation for non-taxable transfers)
- The recognition timing (dominion-and-control date for ordinary-income events, disposition date for capital events)
- Any limitations in the available records and how the gaps were filled
Common protocol categories that warrant their own memo:
- Lending protocols (Aave, Compound, etc.)
- Liquidity pools (Uniswap, Curve, Balancer, etc.)
- Yield aggregators
- Staking (native protocol staking vs. liquid-staking derivatives)
- Governance-token claims
- Derivatives and perpetual futures
NFT activity reconstruction
NFT activity has its own data sources and its own treatment questions:
- Marketplace exports (OpenSea, Blur, Magic Eden, etc.)
- On-chain mint and transfer records
- Royalty receipts as ordinary income at FMV on receipt
- Bundled sales versus individual sales for cost-basis allocation
- Wash-trade artifacts that may need to be filtered before lot tracking
- Creator vs. collector posture, which can change the character of income
The reconstruction should produce a clean NFT ledger that ties to the unified workpaper, not a side calculation that contradicts the main schedules.
Bridges, wraps, and liquid-staking derivatives
Bridges, wrap transactions, and liquid-staking derivatives (LSDs) are the events most often handled inconsistently by aggregators. The reconstruction should document, for each event:
- The exact tokens that went in and the exact tokens that came out
- The protocol’s representation of the relationship (1:1 wrap, redeemable claim, derivative position)
- The taxable-event analysis (substitute property, taxable exchange, no event)
- The basis treatment of the received token
A consistent treatment per protocol is more important than a particular treatment; what matters is that the methodology memo explains why each event was treated the way it was.
The audit-ready ledger
The output of reconstruction is the audit-ready ledger. The ledger should:
- Reflect every wallet and every account in the source-system inventory
- Reconcile to the corrected Form 8949 totals (gross proceeds, basis, gain/loss, by short-term and long-term)
- Reconcile to the corrected Schedule 1 or Schedule C totals for ordinary-income receipts
- Reconcile to the 1099-DA gross-proceeds totals where applicable, with explanations for any difference
- Carry the lot-identification method used and the records supporting it
- Carry the basis-allocation method under Rev. Proc. 2024-28 where applicable
- Include the exception list for any unresolved items
- Be reproducible: another practitioner with the same source records should be able to rebuild the ledger and reach the same result
| Reconstruction deliverable | Purpose |
|---|---|
| Source-system inventory | Defines the scope of the reconstruction |
| Wallet ownership documentation | Supports non-taxable-transfer treatment for self-custody movements |
| Transfer-matching log | Pairs withdrawals to deposits across the taxpayer’s systems |
| Per-protocol treatment memos | Documents the tax treatment of DeFi, NFT, bridge, and wrap activity |
| Chain-by-chain ledger | Source-of-truth transaction history per chain |
| Unified ledger | Cross-chain reconciliation that produces the corrected schedules |
| Methodology memo | Lot identification, fee allocation, basis allocation, FMV sources, exception handling |
| Exception list | Items the reconstruction could not resolve, with supporting evidence |
| Corrected Form 8949 / Schedule D / Schedule 1 / Schedule C | The amended return position |
| Decision memo | Why the amendment is being filed, what changed, why the corrected position is supportable |
Multi-year considerations
A reconstruction usually spans years even when the amendment is for a single year. Carryforward losses, basis schedules for assets still held, holding period for partially-disposed lots, ordinary-income totals affecting later computations, and the Rev. Proc. 2024-28 January 1, 2025 allocation all interact across years. The reconstruction file should walk the year-by-year effects forward and confirm that the corrected position is consistent across every year still open for amendment.
When reconstruction is partial
A complete reconstruction is not always possible. When records are missing for a wallet, a chain, or a period, the workpaper should:
- Document what is missing and the evidence that the activity occurred
- Apply a defensible estimation method where appropriate (e.g., reasonable acquisition assumptions for transferred-in units with no source records)
- Flag any zero-basis positions that result from missing records, with the supporting reasoning
- Keep the exception list open so that the corrected return position can be re-evaluated if records surface later
A partial reconstruction with a clear exception list is more defensible than a clean-looking ledger that silently papered over gaps.
What to upload for a reconstruction review
Upload the documents that allow a practitioner to evaluate the scope and design the reconstruction:
- the originally filed federal return for each year at issue, and any prior amendments
- the existing crypto tax software output and any exception reports
- exchange CSV exports for every custodial account ever used
- a list of self-custody wallet addresses with the chains they hold
- DeFi protocol histories, NFT marketplace exports, bridge histories
- fiat on-ramp and off-ramp records (bank statements, wire records)
- prior basis schedules, methodology notes, or memos prepared by other professionals
- any 1099-DA, 1099-B, 1099-MISC, or similar information returns received
- a short note describing the years involved, the rough number of transactions, and any specific concerns
Pre-contact reconstruction is the focus of the review
A defensible amended return depends on the reconstruction file behind it. The amendment-risk review handles the source-system inventory, the wallet ownership documentation, the transfer-matching log, the protocol treatment memos, the unified ledger, and the methodology memo before Form 1040-X is filed. The review’s output is a corrected return position supported by an audit-ready workpaper file.
Next step: request a digital-asset reconstruction review
Upload the original return, the existing software output, the exchange exports, the self-custody wallet list, the DeFi and NFT records, and any 1099-DA forms through the secure intake process for a digital-asset multi-wallet and multi-exchange reconstruction review. The review will define the scope, build the source-system inventory, design the workpaper structure, and produce the corrected ledger and Form 1040-X position.
Sources checked: IRS, Digital assets; IRS Notice 2014-21, Treatment of virtual currency; IRS Revenue Ruling 2023-14, Staking rewards; IRS Revenue Procedure 2024-28, Safe harbor and wallet-by-wallet allocation for digital assets; IRS, File an amended return; IRS, About Form 1040-X; IRS, Form 8949; IRS, Form 1099-DA; 26 USC 1001, determination of amount of and recognition of gain or loss; 26 USC 1012, basis of property – cost; 26 USC 6045, returns of brokers; 26 USC 6501, limitations on assessment and collection; 26 USC 6511, limitations on credit or refund; Treas. Reg. 1.1012-1(c), identification of stock or securities; Treas. Reg. 1.6045-1, gross proceeds and basis reporting by brokers (final, July 2024).
By Noah Green CPA CFE – published via the Sheepdog Tax digital-asset amendment review content lane (NGO).