The cost basis is the figure subtracted from a disposal proceeds value to compute a capital gain or loss. For crypto, it is the most consequential single number in a tax return — it can move a year-end position from a $40,000 gain to a $5,000 loss without a single trade changing.
What the IRS, HMRC, and BMF will accept
The United States permits specific identification of lots provided the taxpayer can demonstrate which lot was disposed of. In practice this means the taxpayer must keep records of the acquisition date, basis, and disposal of each lot. Where specific identification is not used, the default is FIFO — first in, first out.
The United Kingdom uses share pooling rules adapted for crypto: a "section 104" pool aggregates all units of an identical asset, and disposals reduce the pool. Same-day and 30-day "bed and breakfasting" rules complicate the picture. FIFO and LIFO are not directly available; the pool is the only model HMRC recognises.
Germany applies FIFO by statute for crypto (per BMF guidance) and recognises a one-year holding-period exemption that converts a long-held disposal to zero-rate. The interaction of FIFO and the one-year clock makes lot-level record keeping critical.
The four methods, side by side
FIFO (First In, First Out) disposes of the oldest lot first. In a long bull market, FIFO maximises the gain reported (the oldest lot has the lowest basis). In a flat or declining market it minimises gain.
LIFO (Last In, First Out) disposes of the most recently acquired lot. In a long bull market, LIFO minimises the gain reported. The IRS does not generally accept LIFO for crypto without specific identification documentation.
HIFO (Highest In, First Out) disposes of the highest-basis lot first. This is the optimal method to minimise a tax bill in any market direction, because it always disposes of the lot with the lowest gain. It is a specific-identification method and requires lot-level records.
Average Cost combines all units of an identical asset into a single weighted-average basis. Permitted for mutual funds in the US but not for crypto; HMRC's pool method is the closest analogue but is not arithmetically a simple average.
Why this is harder than it sounds
A single ETH balance is rarely a single lot. A typical wallet that has been used for a year holds dozens of lots from spot buys, staking rewards, airdrops, swaps, gas refunds, and yield. Each lot has its own acquisition date and basis. A swap from USDC to ETH on Uniswap creates a new ETH lot at the swap price; the USDC lot is disposed of at the same price. A reward token received from Lido staking creates a fresh lot at the spot price on the reward date. A gas refund — the surplus ETH returned by a transaction that overestimated gas — is not a lot creation; it is a reduction in basis of the originating lot.
A crypto tax calculator that does not separate these events into discrete lots — and most do not — silently averages them. The user sees a single ETH balance and a single average cost. The number on the tax return is wrong, often by enough to matter.
What Atlas Ledger does differently
Atlas Ledger creates a CostBasisLot row for every acquisition event — including reward, airdrop, and swap-receive events that competitors collapse. Every disposal selects a specific lot under the user's chosen method (FIFO, LIFO, HIFO, or HMRC pool). The selected method is locked at portfolio creation and cannot be changed retroactively without an explicit re-computation flow that produces an audit log of the old and new positions.
The result is that the tax form's "cost basis" column is not a calculation derived from a balance — it is the sum of the basis values on the specific lots that were sold. That is what the IRS, HMRC, and BMF actually require.
Takeaway: The choice of cost basis method is rarely the problem; the lot-level record keeping is. If your crypto tax tool can't show you the basis of each lot you currently hold, the cost-basis number on its tax form is a guess.