Section 104 Pool for Crypto Explained — HMRC Cost Basis Rules

Every UK crypto investor has the same question when they try to calculate capital gains: which coins did I sell? If you bought ETH at three different prices over two years, and you sell some today, which purchase are you selling against? The cheapest? The most recent? The first one in?

The answer is none of the above. HMRC does not use FIFO (first in, first out), LIFO (last in, first out), or specific identification. Instead, they require Section 104 pooling — a weighted average cost basis method that treats all your holdings of the same token as a single "pool" with one average cost per unit.

But Section 104 is only the third matching rule. Before it applies, HMRC requires you to check two other rules first: the same-day rule and the 30-day "Bed and Breakfast" rule. Miss either of these and your entire calculation is wrong.

This guide explains all three rules, shows exactly how the Section 104 pool works with a concrete numerical example, covers the edge cases that trip up DeFi users, and explains how ChainTax automates the entire process.

What is a Section 104 pool?

Section 104 of the Taxation of Chargeable Gains Act 1992 (TCGA 1992) establishes the concept of a "pooled holding" for shares and securities. HMRC extended this to cryptoassets in their Cryptoassets Manual (CRYPTO22200). The principle is simple: you maintain one pool per token, tracking two numbers:

• Total quantity — how many units of the token you hold
• Total allowable cost — the aggregate GBP cost basis of those units, including acquisition costs and gas fees

When you dispose of tokens, you calculate the average cost per unit (total cost ÷ total quantity), multiply by the number of units disposed, and deduct that from your proceeds to determine the gain or loss.

Each token has its own separate pool. Your ETH pool, your USDC pool, your UNI pool — all independent. You cannot offset the cost basis of one token against proceeds from another within a pool.

The three HMRC matching rules (in order)

Section 104 pooling is actually the last of three matching rules HMRC applies. Before the pool is consulted, two anti-avoidance rules take priority. The order matters — you must apply them sequentially:

Rule 1: Same-day matching

If you buy and sell the same token on the same day, those transactions are matched against each other first. This prevents you from selling at a loss, immediately rebuying, and claiming the loss against your pooled cost basis.

"Same day" means the same calendar day in the Europe/London timezone. This is a detail most tools get wrong — a transaction at 23:30 UTC on 5 April during BST (British Summer Time) is actually on 6 April London time, which is the start of the next tax year. Getting the timezone wrong can shift disposals between tax years.

Rule 2: The 30-day Bed and Breakfast rule

If you sell a token and reacquire the same token within 30 days, the disposal is matched against that reacquisition rather than the Section 104 pool. This is the crypto equivalent of the "Bed and Breakfast" rule from traditional share dealing (s106A TCGA 1992).

The rule prevents a common tax avoidance strategy: selling tokens to crystallise a loss (reducing your tax bill), then immediately buying them back. With the B&B rule, HMRC effectively treats the disposal as if you never sold — your cost basis is the reacquisition price, not the pool average.

Rule 3: Section 104 pool

Only after same-day and B&B matching are exhausted does the Section 104 pool apply. Any disposed units not matched by the first two rules are matched against the pool at the current weighted average cost.

This three-step process runs for every single disposal. With hundreds of swaps across Uniswap, Curve, and 1inch, applying this manually is effectively impossible. A single missed B&B match cascades through every subsequent S104 calculation.

How the Section 104 pool works: a step-by-step example

Here is a concrete example showing how the pool is built and reduced over time.

Notice that the average cost per unit does not change when you sell — only the total quantity and total cost decrease proportionally. The £1,300 average remains until the next acquisition changes the weighted average.

What happens when the pool reaches zero?

If you sell all your ETH, the pool empties. If you later buy ETH again (outside the 30-day B&B window), a new pool starts from scratch with the new acquisition cost. There is no carry-over of historic averages.

Gas fees and the Section 104 pool

Gas fees paid on a transaction are an allowable cost for CGT purposes (HMRC CRYPTO22400). How they affect the pool depends on the transaction type:

• Gas on acquisitions: Added to the cost basis of the acquired tokens, increasing the pool's total cost. If you buy 2 ETH for £2,000 and pay £30 in gas, the pool records £2,030.
• Gas on disposals: Deducted from the gain (or added to the loss). The gas fee reduces your net proceeds. Selling 1 ETH for £2,000 with £25 gas means effective proceeds of £1,975.

At scale, gas fees add up significantly — especially during high-congestion periods where a single Uniswap swap could cost £50–200 in gas. Tracking gas correctly can materially reduce your CGT liability.

DeFi income and the Section 104 pool

Staking rewards, LP fee income, and other DeFi income events create an important interaction with the Section 104 pool. When you receive tokens as income (e.g. CRV gauge rewards, stETH rebases, or LP fee distributions), two things happen:

1. Income tax: You owe income tax on the fair market value (FMV) in GBP at the moment of receipt. This is miscellaneous income (s688 ITTOIA 2005).
2. Pool acquisition: The received tokens enter your Section 104 pool at that same FMV. This becomes their cost basis for future CGT purposes.

This prevents double taxation. You pay income tax on receipt, and when you later sell those tokens, you only pay CGT on the appreciation above the FMV at which you already paid income tax. See our guide to reporting staking rewards for the full breakdown of how each protocol (Lido, Rocket Pool, Aave) handles this.

Why precision matters: integer arithmetic and rounding

Section 104 pools involve dividing large numbers, and rounding errors compound across hundreds of transactions. Consider a pool of 3.7182 ETH with a cost basis of £4,827.36. The average cost per unit is £1,298.1767... — how do you handle the recurring decimal?

HMRC doesn't prescribe a specific rounding method, but any floating-point approach introduces cumulative errors. ChainTax handles this by performing all calculations in GBP pence as integers (BigInt arithmetic). No floating-point, no rounding drift, no precision loss — even across thousands of transactions. The pool cost is stored as an exact integer count of pence, and each disposal reduces it by the exact proportional share.

This is the same approach banks and financial systems use for monetary calculations. It sounds like a small detail, but across a year of active DeFi trading it can be the difference between accurate and inaccurate tax figures.

Tokens, pools, and what counts as "the same asset"

Each distinct token has its own Section 104 pool. ETH and WETH are treated as the same asset (wrapping is not a disposal), but ETH and stETH are different pools. ETH and rETH are different pools. USDC on Ethereum and USDC on Arbitrum are the same asset — bridging is not a disposal, and the cost basis transfers across chains.

This creates some practical questions that HMRC guidance does not fully address:

• Wrapped vs unwrapped: ETH ↔ WETH wrapping is widely treated as non-disposable (it is the same underlying asset in a different container). ChainTax classifies wraps and unwraps as transfers, not disposals.
• Bridged tokens: Moving USDC from Ethereum to Arbitrum via a bridge does not change the asset. The cost basis carries over. ChainTax detects bridge transactions (Hop, Arbitrum Gateway, Optimism Bridge, Base, Polygon) and classifies them as non-taxable transfers.
• Liquid staking derivatives: stETH, rETH, and cbETH are different tokens from ETH. Depositing ETH into Lido and receiving stETH is a disposal of ETH and an acquisition of stETH. Each has its own S104 pool.

The annual exempt amount and loss carry-forward

For the 2024/25 and 2025/26 tax years, the annual exempt amount for capital gains is £3,000. Net gains below this threshold are tax-free. This is significantly lower than previous years (£12,300 until 2022/23, £6,000 in 2023/24), which means more investors are now above the threshold.

Capital losses can be carried forward indefinitely. However, HMRC only allows you to use carried-forward losses to reduce your net gain down to the annual exempt amount — not below it. You cannot create an artificial loss to carry forward by over-applying previous years' losses.

Common mistakes with Section 104 calculations

After processing thousands of DeFi wallets, these are the errors we see most frequently:

1. Using FIFO instead of S104 pooling. Often caused by using a US-focused tax tool. The gains will be materially different, and HMRC does not accept FIFO for individuals.
2. Ignoring the B&B rule. DeFi users frequently sell a token on one DEX and buy it back minutes later on another. If the reacquisition is within 30 days, B&B applies — and the gain calculation changes completely.
3. Missing income acquisitions. Staking rewards and LP fees that enter the pool as acquisitions are often overlooked. This understates your cost basis, causing you to overpay CGT.
4. Wrong timezone for same-day matching. Using UTC instead of Europe/London means transactions near midnight can be matched to the wrong day. BST runs from late March to late October, shifting the boundary by one hour.
5. Treating bridges as disposals. Moving tokens via Arbitrum Gateway or Optimism Bridge is not a disposal. If your tool classifies these as swaps, it creates phantom gains and corrupts the S104 pool.
6. Floating-point rounding errors. Tools that calculate in decimal GBP (not integer pence) accumulate rounding errors. After hundreds of transactions, the pool cost basis drifts from the correct figure.

How ChainTax handles Section 104 automatically

ChainTax builds the Section 104 pool for every token in your wallet automatically. Here is what happens when you scan your wallet:

1. Transaction classification: Every on-chain transaction is classified using deterministic protocol handlers for Uniswap, Curve, Lido, Aave, 1inch, Balancer, Rocket Pool, and more. Swaps, LP operations, staking events, bridge transfers, and income events are all identified.
2. GBP pricing: Each event is priced in GBP using DefiLlama and CoinGecko data, with gas fees included as allowable costs.
3. Three-rule HMRC matching: Same-day matching runs first, then the 30-day B&B rule, then Section 104 pooling. Every disposal records which matching rule was used.
4. Show Working: For every disposal, you can see the exact matching rule applied, the S104 pool state before and after, and the full gain calculation. This is the audit trail HMRC expects.

You can try the classification engine for free using the transaction explainer — paste any Ethereum transaction hash and see how ChainTax classifies it.

SA108 and Section 104: where it goes on your return

For the 2024/25 tax year, crypto disposals are reported in the dedicated cryptoassets section of SA108 (boxes 13.1–13.8):

• Box 13.1: Number of disposals
• Box 13.2: Total disposal proceeds
• Box 13.3: Total allowable costs (this is where your S104 pool cost basis appears, aggregated across all disposals)
• Box 13.4: Total gains (sum of all positive gains)
• Box 13.5: Total losses (sum of all negative gains)
• Box 13.6: Net gains or losses after offset

ChainTax generates all SA108 box values directly from the engine output. The "Show Working" feature provides the transaction-level detail behind each box, so you can verify every number before filing.

Quick reference: Section 104 rules summary