Skip to main content

Token rebases and symbol swaps (AMPL, DOT, BTT)

How to account for situations where a crypto asset is changing its symbol, contract or undergoing a rebase (share-splitting)

Robin Singh avatar
Written by Robin Singh
Updated over 2 weeks ago

A cryptocurrency can undergo different transformations like changing the symbol or changing the amount of tokens you hold. In most cases, those changes should not be taxable and shouldn't affect your cost basis or holding period of this asset. This article outlines manual changes required to achieve such tax treatment in Koinly.

☘️➑️🌸 Symbol change

This scenario includes: VEN was renamed to VET, LEND was renamed to AAVE, etc.

Exact actions to be taken depend on what was imported - so some transactions may need to be added or adjusted. The end result should be:

  1. Create a trade from OLD_TOKEN to NEW_TOKEN

  2. If deemed not taxable, this trade can be tagged as Swap

☝️ Exception: MATIC renamed to POL

Due to the complexity of this migration, Koinly handled it in a specific way. You can read more about it in MATIC (Polygon) and POL (Polygon Ecosystem Token)

πŸ”΅ Example: Symbol change of LEND to AAVE

After importing data from Coinspot, The initial purchase of LEND was imported, along with a deposit of AAVE (when the migration happened) but nothing connects the two together:

🟒 Solution: Edit the deposit of AAVE and turn it into a trade of total LEND held. End result should look like below - Tag it as Swap afterwards if you consider this event non-taxable.

☘️➑️☘️ Seamless migration

This scenario includes situations when a token migrated from one contract to another (V1 to V2) but Koinly identifies them as the exact same token.

Contracts on most blockchains are immutable so if the token creator wants to modify the code, they need to create a new contract. Token holders then either:

  • Are issued a new token automatically, airdropped to the same wallet

  • Or need to burn old tokens and then receive new tokens back

To account for this seamless migration without affecting your cost basis or holding period, transactions related to this contract change should be deleted:

  1. Delete any airdrop deposit of the token

  2. Delete any withdrawal (burn transaction) of the token

  3. If the token was received on a different wallet - create a transfer from the old wallet to the new one (common for mainnet launches like EOS)

πŸ”΅ Example: GALA migration

You held GALA in your Ethereum wallet. When the token project migrated to a new contract, the new version of the token in the same amount was airdropped to your wallet. You can see that the "new" GALA and the "old" GALA are considered the same asset in Koinly (they both show up using one currency filter):

🟒 Solution: Delete the airdrop of the new asset. Since GALA was airdropped, there is no "burn" withdrawal to delete. End result should look like this:

☘️➑️🍁 Migration to a new token

In other cases, V1 and V2 tokens differ (e.g. both are tradable but with different prices) and they shouldn't be seen as the same token. This usually happens if V1 token was exploited and V2 was not airdropped 1:1, or if the old token remains tradable.

Since the two tokens are separate tokens in Koinly, this scenario is basically the same as ☘️➑️🌸 Symbol change:

  1. Edit the deposit of V2 token and change it into a trade

  2. Fill the "Sent" part as total holdings of the V1 token

  3. If deemed not taxable, this trade can be tagged as Swap

πŸ”΅ Example: Stratis (STRAX) migration from V1 to V2

After importing your Binance data, you notice that the migration to STRAX was imported as a deposit with Airdrop tag and there's no connection with the old STRAX:

🟒 Solution: Remove the Airdrop tag and change the deposit to a trade of the total STRAX (old) balance. Tag it as Swap afterwards if you consider this event non-taxable:

ℹ️ Unrecognized token

Sometimes, the token appears as "new" only because it's not yet recognized (has a grey logo).

If this happens but you want to treat it as the same token as V1 you can:

  • Use Change Currency to ensure V2 token is imported as the same asset in the future

  • Since now it's a seamless migration scenario - delete the airdrop/burn transactions

☘️➑️🌿 Rebase 1:x to a new token

This scenario includes: rebase of BTT (BitTorrent) 1:000 when Koinly recognizes both old and new token as separate currencies.

The token may be reissued with different denomination (e.g. you held 100.00 units of a token and now you hold 100,000.00).

πŸ”΅ Example: Redenomination of BTT (BitTorrent)

After importing data from Gate, you can see that you still hold BTT_old even though it was automatically exchanged to BTT_new in 1:1000 ratio. There is no deposit of BTT_new so later sale of BTT shows "missing purchase history"

🟒 Solution: create a manual trade of total holdings of BTT_old for total received BTT_new. Tag as Swap if deemed non-taxable:

β˜˜οΈβž‘οΈπŸ€ Rebase 1:x to the same token

This scenario includes: periodical rebases of AMPL, redenomination of BNBDOWN

The token may be reissued with different denomination (e.g. you held 100.00 units of a token and now you hold 100,000.00).

In this scenario, you cannot use the Swap as you can't trade the same asset between itself.

πŸ”΅ Example: AMPL rebase

You held AMPL on Coinbase for some time. Even though you didn't transact it, the amount of the token changed which can be seen by "missing purchase history" when you decided to sell your holdings (as you suddenly sell more AMPL than you bought):

🟒 Solution: create a withdrawal of all your AMPL before the trade and tag as Lost, then create a deposit for same amount and change the worth to match the original cost basis:

Advanced scenarios

Keeping the acquisition date in a β˜˜οΈβž‘οΈπŸ€ Rebase

To keep the acquisition date after rebase, you need to create two trades with Swap tag using a NULL1 token as an intermediary:

  • Trade old_amount of TOKEN for 100 NULL1, tag as Swap

  • Trade 100 NULL1 for new_amount of the TOKEN, tag as Swap

  • Amount of NULL1 is irrelevant and can be arbitrary, as long as it's the same amount in both transactions

πŸ”΅ Example: Modified β˜˜οΈβž‘οΈπŸ€ Rebase 1:x to the same token

Instead of a "Lost" withdrawal and a deposit, you end up with two Trades tagged as Swap using a NULL token:

πŸ‡¬πŸ‡§ UK: Turning a migration into a non-taxable event

The Swap label does not prevent gains from being realized when using Sharepooling as your cost basis method (cost basis method used in the United Kingdom). You can still remove gains (rendering the trade non-taxable) by matching worth with the cost basis:

  1. Check the cost basis of the disposed asset (fiat value on the left)

  2. Change the value (worth) of the transaction to match (fiat value on the right)

  3. You can change the worth of a transaction by clicking on it

πŸ”΅ Example: ☘️➑️🌸 Symbol change for UK

The example from ☘️➑️🌸 Symbol change of migrating LEND to AAVE would look like this:

No tag added, but worth was changed to match the cost basis. AAVE now has the same cost basis as the originally purchased LEND and no gain/loss was calculated on this migration.

Did this answer your question?