A Rev. Proc. 2024-28 allocation statement is supposed to be the boring part of the per-wallet migration: you say where each unit's basis sits, you keep the record, you move on. This one came back with a single row — 27,000.998704 ETH — and $0.00 of basis allocated to all of it. Nothing was missing. The balance tied out to the wei against the chain. The engine linked every wallet it was given. The reason the basis is zero is that the coins arrived from an address that was not in the submission set, and an address you don't submit cannot hand basis to one you do.

This is not tax advice. It is a measured run of an open-source engine on a public address, with the limits named.

What we scanned

This is the same address as the ordinary-scale tie-out page, at a much later cutoff. It is also the "cold wallet" in the $44,975,739 cluster measurement — where it was scanned together with the wallets that funded it. Here it is scanned alone. That single change is the whole article.

What came back

The phantom-gain figure is $0 here, and that is not good news. The two runs agree because there are 0 self-transfers inside the submission set — with one wallet, there is nothing to link. Wallet linking has no work to do, so it produces no difference, so the comparison that usually surfaces the problem stays silent.

The 21 unattributed_inflow findings are where the problem actually lives. Two of them:

date amount value at receipt transaction
2022-05-16 30,000 ETH $64,411,423 0x2909ee…4320f
2022-11-24 40,000 ETH $47,436,638 0xe467d3…e04ae

Those are the same two transactions that appear on the cluster page as internal transfers from the Vb 3 Safe to this wallet. There, the sending address was in the set and the basis rode along. Here it wasn't, so the same two transactions are inflows with no acquisition behind them.

The allocation statement it generated

The engine writes the Rev. Proc. 2024-28 specific-unit statement automatically at the cutoff. The whole thing is one row:

asset units basis (USD) lots acquired
ETH 27000.998703822497311274 $0.00 17 2022-11-24 .. 2024-09-29

Total unused basis allocated: $0.00 across 17 lots.

And, in the engine's own words at the bottom of the file:

NOTE: 1 row(s) hold units with no recorded acquisition basis in the scanned history — substantiate or resolve those before relying on this allocation.

The method line on the statement is worth reading closely, because it is also the explanation:

specific-unit allocation — basis is recorded in the wallet where the public chain shows the units held at the boundary, with wallet-to-wallet transfers carrying basis.

"With wallet-to-wallet transfers carrying basis" is conditional on both wallets being present. The transfer-aware mode is on. It cannot help. There is no counterparty in the set to carry basis from.

Why a passing tie-out doesn't protect you

The tie-out gate is the check we lean on hardest — it caught two real defects in our own pipeline before we published any dollar figure. It answers one question: did we account for every unit the chain says you hold? Diff 0 means yes. It says nothing about whether those units have a cost. A ledger can be complete and still be full of coins whose purchase happened somewhere the ledger was never shown. That is the failure mode this run isolates: the data is right and the basis is zero, and no amount of re-scanning the submitted wallet changes it. The fix is upstream of the software — submit the sending wallet, or substantiate the acquisition from records.

Why the calendar matters

Under Rev. Proc. 2024-28 the allocation is a snapshot. Whatever basis assignment is in force at the transition gets carried forward into every later disposal from that wallet. A statement that says $0.00 does not stay a paperwork problem; it becomes the basis figure that prices sales for years. Our walkthrough of that mechanic is in the per-wallet migration guide. The transitional relief in Notice 2026-20 runs out on 2026-12-31 (what changes then). The cheap moment to discover that your allocation statement has a zero row is while you can still add the wallet that explains it.

What the $75,502,809.57 is not

It is an upper bound produced by scanning one wallet in isolation, and it is not a claim about anyone's tax position, filings, or liability. We have no visibility into any of that. Three specific reasons the number reads high:

Outbound transfers are treated as disposals at fair market value. That is the documented behavior when the receiving address isn't in the submission set — the engine cannot tell a sale from a move to your own second wallet, so it prices both as sales. Anything this address sent to an unsubmitted address is in that total.

Prices came from a single source and were not independently confirmed. This run priced from DefiLlama; the second price source (Coinbase ETH-USD daily candles) was unreachable, so no cross-check ran. The engine says so in its own output, and we repeat it here rather than bury it. Note what this does not touch: the ETH quantities and the balance tie-out are computed from chain data and do not depend on any price feed. 27000.998704 = 27000.998704 either way.

Status is partial, with 704 events awaiting professional review. Almost all of it is ERC-20 noise this address did not ask for: the run priced 0 of 683 token events across 0 of 452 token contracts. Unpriceable is not the same as worthless, and a partial result is not a finished return.

How to reproduce

npm run check -- 0xd04daa65144b97f147fbc9a9b45e741df0a28fd7 --until 2024-12-31 --safe-harbor allocation.txt

One caveat we have to state plainly: the free web scan cannot reproduce this run. The free scan caps at 500 events and this address produces 741 by the 2024-12-31 cutoff. The reproducible paths are the open-source CLI above (default cap 5,000 events) or the $79 tax-year pack, which carries the same 5,000-event ceiling. If you want the shape of the method first, /method describes it, and /check runs the free version on your own addresses within its cap.

What this page does not claim