If I forgot to record the cost basis at the moment of step two in the case (transferring into the self-custody wallet), and only remember the amount from later transferring into Exchange B, can I still calculate this correctly?
Yes, as long as you remember the original acquisition information (buying 10 tokens for $5,000 on Exchange A), you can go back and recalculate the correct cost basis for these 4 tokens ($2,000). You don't necessarily need to leave an independent record at every single transfer step — as long as the original source acquisition information is complete enough, combined with the quantity transferred each time (4 tokens), you can theoretically reconstruct the correct cost basis.
But if even your original source acquisition information is incomplete (for example, you don't remember the exact amount or quantity from the original purchase), reconstructing it after the fact becomes significantly harder in that situation — you might need to rely on Exchange A's historical records or account statements to reconstruct the original data, which is also why it's advisable to fully record all relevant information from the very moment you first acquire an asset.
If the remaining 6 tokens staying on Exchange A in the case later go through another partial transfer, does the cost basis calculation become even more complex?
Yes, it becomes more complex, but the calculation logic is essentially the same principle applied repeatedly — the 6 tokens staying on Exchange A have a cost basis of $3,000 (averaging $500 per token). If later a portion of these 6 gets transferred out again (say, 2 tokens), those 2 tokens' cost basis calculation likewise follows proportional allocation: 2 tokens ÷ 6 tokens × $3,000 = $1,000, with the remaining 4 tokens' cost basis being $3,000 minus $1,000, equaling $2,000.
Each new partial transfer needs to recalculate the proportion based on "that batch's currently remaining cost basis," rather than going back and referencing the original $5,000 to calculate. If your holding history involves multiple, repeated partial transfers, it's strongly advisable to compile a complete timeline, sequentially recording each transfer's quantity and corresponding calculated cost basis, updating entry by entry, avoiding confusion partway through about which baseline figure is being used for the calculation.
If Exchange B's system genuinely displays the cost basis as zero, but I've kept a complete record of my own, which number should I use when filing?
You should use your own correctly kept record ($2,000), not the wrong number Exchange B's system displays (zero) — when filing taxes, what matters is reflecting the cost basis that correctly represents economic substance, not the number displayed on a platform's interface. Exchange B's system displaying it wrong is typically because it's technically unable to trace this batch of assets' original source before it arrived, which is a limitation at the tool level, not a tax law requirement that you must file according to this wrong number.
In practice, it's advisable that if you find the cost basis a platform displays is inconsistent with your own records, you should file based on your own complete, verifiable correct number, keeping the original purchase record and transfer records as supporting evidence in case you need to explain how this number was calculated in the future. If you're unsure how to handle this kind of gap, it's advisable to consult a tax professional familiar with this kind of cross-platform data issue.
This case's calculation process looks quite involved — if my holding history is more complex than this (say, the same batch of assets transferred a dozen or more times), do I absolutely need professional software to calculate it correctly?
In theory, the calculation logic doesn't change as the number of transfers increases — every partial transfer allocates proportionally based on "that batch's currently remaining cost basis," and every cross-platform move needs verifying that the cost basis correctly carried over. Repeatedly applying this same logic can handle any arbitrarily complex transfer history. But in practice, as the number of transfers increases, the probability of manual calculation error rises significantly — especially since the baseline figure of "currently remaining cost basis" needs continuous updating, and once one step is miscalculated, every subsequent calculation is affected as a result.
If your number of transfers genuinely is high, a more practical approach is relying on tax software that supports this kind of complex scenario to assist with the calculation, but it's likewise advisable to keep your own complete original transaction timeline as a basis for cross-checking, rather than fully relying on the software's calculated result without any manual review. Especially for a holding position involving a larger amount, it's advisable to additionally seek professional help to confirm the overall calculation logic's correctness.
Another term on this site has already explained the basic logic of Cross-Platform Transfer Cost Basis Continuity — a transfer doesn't constitute a disposition event, and the cost basis should carry over unchanged. This article doesn't rehash that principle — instead it uses a concrete case involving a partial transfer and multiple hand-offs to demonstrate just how involved the actual calculation process can get, helping you understand why fully recording every single step's details matters so much.
An investor bought 10 tokens for $5,000 on Exchange A, giving a cost basis of $500 per token. This investor then carried out the following operations: step one, transferring 4 of those tokens to a self-custody wallet; step two, transferring those same 4 tokens from the self-custody wallet to Exchange B; step three, selling those 4 tokens on Exchange B, at a market price of $800 per token at that moment. The whole process involves a partial transfer (transferring 4 out of 10 tokens) and multiple hand-offs (self-custody wallet, then Exchange B).
The 4 tokens being transferred out need their proportional share of the cost basis allocated to them, rather than the entire $5,000 batch cost basis moving along with just those 4. The calculation is: 4 tokens ÷ 10 tokens × $5,000 = $2,000, meaning the cost basis for these 4 transferred tokens should be $2,000 (averaging $500 per token, consistent with the original cost basis). The remaining 6 tokens staying on Exchange A have a cost basis of $5,000 minus $2,000, equaling $3,000.
After these 4 tokens transfer into the self-custody wallet, since the transfer itself doesn't constitute a disposition event, the cost basis should carry over as $2,000, not be reset to zero. This step is the most direct checkpoint for verifying cost basis continuity — if the wallet interface displays a cost basis other than $2,000, it means the recordkeeping tool had a problem handling this transfer.
When these 4 tokens transfer again from the self-custody wallet into Exchange B, this likewise doesn't constitute a disposition event, and the cost basis should continue carrying over as $2,000. This is the second transfer in this case, and also the link most prone to a break — Exchange B only sees the moment this batch of tokens "arrives," and if the cost basis information isn't proactively provided or verified, Exchange B's system might well display this batch's cost basis as zero.
When this investor sells these 4 tokens on Exchange B, the market price is $800 per token, giving sale proceeds of 4 × $800 = $3,200. The taxable income calculation is the sale proceeds minus the correctly carried-over cost basis: $3,200 minus $2,000, equaling a $1,200 capital gain. If the cost basis had been incorrectly reset to zero during the transfer, this transaction's taxable income would be miscalculated as the entire $3,200 — more than double the correct answer.
What this case demonstrates isn't meant for you to memorize this specific calculation's result — it's demonstrating that when a partial transfer combines with multiple hand-offs, cost basis continuity needs to be correctly verified at every single link, and a break at any one link produces a severe error in the final taxable income calculation. In practice, if your holding history involves a similar partial transfer or multiple hand-offs, it's advisable to start recording each operation's date, quantity, and corresponding cost basis in a spreadsheet from the very first transfer — this record will be the only reliable basis for correct future calculation, rather than relying on any single platform or tool's displayed number.
⚠️ This article was researched against the most current regulations and official guidance available at the time of writing, but tax rules change frequently, and the applicable rules can vary by jurisdiction and individual circumstance. This content is intended to help you understand concepts and general direction — it does not constitute formal tax or legal advice. Before filing, please verify current rules directly with the official tax authority in your jurisdiction, or consult a qualified tax professional.