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:
Create a trade from OLD_TOKEN to NEW_TOKEN
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
π΅ 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:
Delete any airdrop deposit of the token
Delete any withdrawal (burn transaction) of the token
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
π΅ 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:
Edit the deposit of V2 token and change it into a trade
Fill the "Sent" part as total holdings of the V1 token
If deemed not taxable, this trade can be tagged as
Swap
π΅ Example: Stratis (STRAX) migration from V1 to V2
π΅ 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)
π΅ 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
π΅ 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
π¬π§ 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:
Check the cost basis of the disposed asset (fiat value on the left)
Change the value (worth) of the transaction to match (fiat value on the right)
You can change the worth of a transaction by clicking on it
π΅ Example: βοΈβ‘οΈπΈ Symbol change for UK
π΅ 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.