Rev. Proc. 2024-28: correcting an automatic crypto allocation based on erroneous wallet balances

4 replies
22 views

I’m preparing my unfiled 2025 return using TurboTax Desktop and Koinly (crypto tax software that gets imported into TurboTax).

Koinly generated a January 1, 2025 migration from universal to wallet-based cost tracking using “Lowest Cost → Biggest Wallet.” I do not recall manually creating or approving it, and I made no separate allocation instructions. I cannot establish the account-specific creation/activation date or that a timely allocation plan was documented.

A subsequent reconciliation established that Koinly’s recorded FTX US USDC balance was an accounting artifact from overlapping USD/USDC representations—not actual remaining USDC. Coinbase statements independently establish the actual Coinbase opening quantity.

The proposed correction applies the same allocation rule to corrected wallet balances, preserves original acquisition dates and costs, and excludes costs previously used on filed returns. It would be implemented through an external reporting ledger because Koinly does not allow individual migration-lot reassignment.

Under Rev. Proc. 2024-28, particularly §3.09 and the timing/irrevocability provisions:

Can this be treated as correcting erroneous allocation inputs rather than making a new allocation?
How should the absence of documented timely allocation history affect that conclusion?
If safe-harbor eligibility cannot be established, what rules govern substantiation of the corrected wallet basis?

I understand that factual tracing alone does not establish a safe-harbor exemption. I would appreciate an explanation supported by the applicable authority, rather than simply instructions for entering basis in TurboTax.

M-MTax

Level 15

1. Correcting Erroneous Allocation Inputs vs. Making a New Allocation

Your proposed fix cannot be treated as a mere correction of inputs if it reallocates basis to completely different wallets than those established on January 1, 2025.

The Irrevocability Barrier: Section 3 of Rev. Proc. 2024-28 mandates that a safe-harbor allocation made on January 1, 2025, is irrevocable. The IRS treats the allocation as a definitive binding event to transition from universal to wallet-by-wallet tracking.
The "Artifact" Problem: Koinly assigned cost basis to a phantom FTX US USDC balance. Because those assets did not legally or factually exist in an FTX US wallet on January 1, 2025, any allocation to that wallet violates the core requirement of the Revenue Procedure: basis can only be allocated to a wallet that actually holds the remaining units of that digital asset as of January 1, 2025.
The Outcome: Moving basis away from the FTX US wallet definition into the Coinbase wallet represents a subsequent shift of tax lots. The IRS interprets this as a new or modified allocation, which is expressly barred by the irrevocability provisions once the January 1, 2025 deadline has passed.

2. Absence of Documented Timely Allocation History

The lack of a documented, contemporaneous allocation plan further invalidates safe-harbor eligibility.

Substantiation Requirements: To claim the safe harbor, you must maintain records demonstrating a definitive, systematic choice of method executed precisely as of January 1, 2025.
Software Defaults Do Not Protect You: Relying on a retroactively discovered automated software algorithm (“Lowest Cost → Biggest Wallet”) that you did not consciously approve or document before the deadline fails the requirement for an intentional global or specific unit allocation.
Systemic Failure: Because your ledger relied on inaccurate wallet quantities (the FTX representation), the automated rule generated an inherently unreasonable layout. A safe harbor cannot retroactively absorb clerical or data-sync errors under the guise of an automated process.

3. Substantiation Rules Outside the Safe Harbor

Because safe-harbor eligibility cannot be established, you fall entirely under standard tax law, where historical factual tracing dictates your position.

Without the safe harbor, your accounting must conform to Treasury Regulation § 1.1012-1(j), which governs the wallet-by-wallet tracking rules effective for the 2025 tax year.

Rule Category	Governing Authority & Application
Strict Specific Identification	Under Treas. Reg. § 1.1012-1(j)(3), you must prove the exact date, time, and acquisition cost of the specific units leaving a specific wallet. Because your Koinly migration applied a universal pool logic across an erroneous layout, you must rebuild the sub-ledger manually.
Default Relief Method	If your external reporting ledger cannot perfectly track contemporaneous specific identification for 2025 dispositions, you are forced into a per-wallet First-In, First-Out (FIFO) convention. You cannot use an unauthorized cross-wallet HIFO or "biggest wallet" logic outside the safe harbor.
General Burden of Proof	Under IRC § 6001, the taxpayer carries the burden to show the correct cost basis. Your external reporting ledger, backed by direct Coinbase statements and FTX transaction histories, will serve as your primary defense during an audit to prove you did not double-count basis previously used on filed returns.

Moving Forward: You should implement your corrected external reporting ledger using strict, wallet-specific tracking protocols. Be prepared to append a formal disclosure statement (such as Form 8275) to your 2025 return to transparently outline your departure from the automated software migration and to explain your reliance on verified source documentation.

username4071734Author

Level 2

Thank you—this helps identify the concerns. Could you clarify two points?

Section 5.02 distinguishes specific-unit and global allocation deadlines, and §4.02(6) addresses irrevocability. What authority establishes that correcting an allocation to nonexistent wallet units is necessarily a prohibited new allocation, rather than correction of an invalid calculation? I recognize that this does not itself prove correction is permitted.

Also, outside the safe harbor, how should opening wallet basis be established where prior universal tracking assigned costs across wallets? Applying wallet-specific FIFO afterward appears to require resolving that opening inventory first.

I would appreciate distinguishing express requirements from your interpretation of this particular software-error situation.

Thanks so much for your help!

M-MTax

Level 15

The distinction between an invalid calculation correction and a prohibited modified allocation relies on the strict textual definition of a wallet or account under Rev. Proc. 2024-28.

Express Requirement (§ 4.01): The safe harbor explicitly states it is only available to taxpayers who hold digital asset units in their wallet or account as of January 1, 2025. You can only allocate "unattached basis" to a wallet that actually holds remaining units of that specific digital asset.
The Irrevocability Provision (§ 4.02(6)): It explicitly states that an allocation made under this safe harbor is irrevocable.
Interpretation vs. Authority: The IRS has not published a specific "clerical error exception" for Rev. Proc. 2024-28 that allows a taxpayer to undo a finalized allocation after the deadline.
- The Conservative Position: Moving basis from a "phantom" wallet definitions to an actual wallet definitions (Coinbase) shifts tax lots between separate economic silos. Because the safe harbor is irrevocable, a strict reading dictates that once the deadline has passed, any shift of basis between accounts is treated as a prohibited modification.
- The Intermediary "Invalid Allocation" Argument: Your argument that an allocation to a zero-unit phantom balance is void ab initio (invalid from the start) is a logical legal position. However, it is an interpretation. If the safe harbor allocation is deemed void because it failed the requirement of allocating to actual remaining units, the legal result is not an automatic right to create a corrected safe-harbor allocation out-of-time. Instead, the failure invalidates safe-harbor eligibility entirely, forcing you out of the safe harbor and into historical tracing rules.