How to Handle a Hard Fork in Portfolio Tracking Software

11 October 2026

A hard fork splits your holdings into two separate assets, and your tracking software needs a manual intervention to keep records honest. The core task is to ensure your pre-fork cost basis carries over to the original chain, while the new chain's tokens get a cost basis of zero (in most jurisdictions) and a fair market value entry on the fork date. You handle this by creating a new asset, recording the fork as a tax-free event, and then manually assigning the correct cost basis to the original token.

Here is the detail.

Why a hard fork breaks automatic tracking

Most portfolio trackers and tax software rely on transaction history from exchanges and wallet APIs. When a hard fork occurs, the blockchain splits. The software sees the original chain's transactions, but it has no inherent knowledge of the new chain's tokens because they were never sent to you. They simply appeared on a new ledger.

Consequently, the software will not automatically create a second position for the forked asset. If you do nothing, your portfolio will show only the original coin, and your cost basis will remain attached to that single holding. That is wrong for two reasons: you now own two different assets, and the tax treatment differs.

The General Procedure

The exact steps vary by software, but the logic is consistent across platforms. You are essentially creating a new transaction record that mimics the fork event.

1. Identify the fork date and block height. You need the exact moment the chain split. This is public information, available from block explorers or the project's official communication. Do not guess; the transaction date matters for tax purposes.

2. Create a new asset in your tracking software. If the software has a built-in asset list, search for the new ticker. If it is not there, you will need to add a custom asset. Name it clearly, including the chain it belongs to (e.g., "Bitcoin Cash (BCH)" vs. "Bitcoin (BTC)").

3. Add a "fork" or "hard fork" transaction. This is usually found under "manual transactions" or "add income." The transaction should have:

4. Date: The exact fork date and time (use UTC to avoid errors).
5. From: The original asset (e.g., 1 BTC).
6. To: The new asset (e.g., 1 BCH).
7. Amount: The amount of the new asset you received. This equals the amount of the original you held at the fork.
8. Proceeds: Zero. This is not income.

9. Cost basis: Zero for the new asset.

10. Assign cost basis to the original asset. This is the part most people miss. The original token (e.g., BTC) keeps its original cost basis. The new token (e.g., BCH) gets a cost basis of zero. You do not split the original cost basis between the two. The original cost basis stays with the original chain.

11. Record the fair market value of the new asset. On the fork date, the new asset has a market value. You need to record this as the "value" of the new holding for portfolio valuation purposes. This is not your cost basis; it is just a current market value. Your tracking software may ask for a "price" or "value" field when you add the asset. Use the price on the fork date.

The Zero-Cost-Basis Rule

The crucial tax principle is that a hard fork is not a taxable event at the moment it occurs. You do not realize a gain or loss. Instead, the new coin inherits a cost basis of zero. This means when you eventually sell the forked coin, the entire sale price is taxable as a capital gain.

Some software will automatically assign a cost basis of zero when you use the "hard fork" transaction type. Others will not. Check your software's documentation. If it does not, you may need to manually adjust the cost basis of the new asset to zero.

What if the Software Does Not Have a Fork Option?

If your software lacks a dedicated fork transaction type, use a workaround. Create a "mining" or "income" transaction for the new coin, with the amount received and a value of zero. Then, manually set the cost basis of that new asset to zero. This is not perfect, but it achieves the same accounting result.

Alternatively, some software allows you to do a "transfer" between two assets. You can transfer the original amount to the new asset, but you must manually zero out the cost basis on the new asset's transaction.

Handling the original coin's price

After the fork, the original coin's price will be volatile. Your software will track this automatically via price feeds. You do not need to adjust anything for the original coin beyond the fork date. The cost basis remains whatever it was before the fork.

A Note on Airdrops and Subsequent Forks

The same logic applies to airdrops that are not hard forks, but be careful. Some airdrops are taxable income. The distinction is whether you took an action to receive the new tokens. A pure hard fork - where the network splits and you do nothing - is not income. An airdrop where you had to claim tokens or connect a wallet may be treated differently. When in doubt, the zero-cost-basis rule is the safest starting point for a hard fork, but not for a promotional airdrop.

After you finish the entry

Once you have recorded the fork, verify the results.

• Check the original asset's cost basis. It should be unchanged.
• Check the new asset's cost basis. It should be zero.
• Check the new asset's current value. It should reflect the market price on the fork date.

If your software shows a capital gain or loss on the fork date itself, you have made an error. A hard fork is not a disposal.

When the software gets it wrong

Sometimes, a software update or an API sync will attempt to handle a fork automatically. This can work, but it can also fail. If you see a sudden gain or loss on the fork date, or if the new asset appears with a cost basis equal to the original, you must correct it manually. Do not rely on automatic updates to be tax-correct. They are designed for convenience, not for the nuanced accounting of a chain split.

The Bottom Line

Handling a hard fork in your tracking software is a manual task. The sequence is simple: create the new asset, record the fork as a zero-value event, keep the original cost basis on the original coin, and set the new coin's cost basis to zero. The fair market value on the fork date is for portfolio valuation, not for tax cost. Get that sequence right, and your records will survive an audit. Get it wrong, and you will overpay or underpay tax later. The former is a mistake; the latter is a problem.

Back to portfolio