What are token migrations & stock splits?
Token migrations & stock splits are very similar. In the case of a token migration (often referred to as a token swap, rebranding, or even a hard fork), the blockchain or smart contract on which a crypto asset is based is usually upgraded. This can result in changes to the properties and total supply of the crypto-assets, which can change the ratio of one's own asset quantity in proportion to the adjusted quantity. This is also referred to as redenomination, assuming the migration does not occur at a 1:1 ratio.
Such adjustments to the total supply are also common for stock splits, although there is less of a technical background here, but instead the price of an individual share is adjusted to enable small investors to buy a full share.
Token migrations and stock splits are possible in both directions. This means that there can be both, an increase and a reduction in the total supply. In the case of a stock-share, this is referred to as a reverse stock split.
In summary, asset amounts are either increased by a certain factor, reduced or remain the same.
Example of a token migration at a ratio of 1 : 100 in Blockpit:
(image translation in process)
Not every token migration leads to a change in total supply or to a redistribution
Not every token migration leads to a redistribution, i.e. the distribution of new assets, as upgrades of the smart contract in most cases do not require redenomination and therefore no redistribution (airdrop).
Token migration or stock splits are NOT carried out by every exchange in the same way
If affected crypto assets or stocks (shares or derivatives) are already held on an exchange prior to a migration or split, the exchange itself usually handles all adjustments, i.e. distributions of new or reduction of existing asset quantities. However, it should always be checked whether this process has been correctly processed from the exchange to Blockpit at transaction level.
The aim of this check is to correct the balance, if necessary, and to ensure the transfer of acquisition costs and the acquisition date from the old asset quantity to the new asset quantity.
How to correctly enter a token migration or stock split in my transaction history?
Token migrations typically only become visible in your own Blockpit transaction history if the integration in which the affected assets are located shows a mismatched balance or transactions without a label (“Unlabeled”). Individual transactions that display the note “Unlabeled” can therefor be related to a redistribution or reduction/posting (deposit or withdrawal) to balance the asset quantities.
Some exchanges document such processes in specific articles. To find out more about the exchange's procedure, we recommend simply googling the name of the exchange and the asset in combination with the keywords “token migration/token swap/stock split/airdrop/hard fork/rebrand”.
Not every exchange performs this redistribution correctly or completely on transaction level. In some cases, withdrawals or redistribution are not carried out as a separate transaction.
Some exchanges only carry out partial bookings and therefore simply replenish the “ incorrect balance” i.e. the old asset quantity or reduce it accordingly (partial deposit or withdrawal). This can result in acquisition data not being transferred from the old to the new holding (asset quantity).
Step 1: Identify the ratio of token migration
-
Ratio 1 : 1 → Usually no adjustments within your Blockpit transaction history are necessary, but in rare cases a redistribution (usually in the form of an airdrop) of the full new asset quantity may occur. This can lead to a doubling of your holdings (mismatched balance) or occasional unlabeled transactions.
As a solution, such transactions can be excluded from the transaction list.
Example: RNDR to RENDER migration - An additional deposit (airdrop or unlabeled deposit) will double the holdings/balance in your integration. This deposit should be excluded from the transaction list to resolve the issue.
> Transaction Details Overview and Managing & Editing of Transactions
Edge case: If you still experience a doubled "Synced Balance" please reach out to our support-team. -
Ratio 1 : X or X : 1 → Adjustments within your own Blockpit transaction history necessary. High dependency on the used price data source. Can lead to a mismatched balance or in some cases unlabeled transactions. If existing price data is continued on Coinmarketcap after the migration, for example, there may be a jump within the price data graph.
As a solution, transactions can be excluded from the transaction list, added to or edited.
> Transaction Details Overview and Managing & Editing of Transactions
-
Merge multiple crypto assets or stocks → Check within your own Blockpit transaction history necessary. Usually nothing other than the above-mentioned forms of migrations / ratios mentioned, but instead of one migration, several are to be reproduced.
Example: Migration 1: AGIX → FET; Migration 2: OCEAN → FET; Migration 3: FET → ASI
2. Step: Check the token migration period in your own transaction history + adjust the Blockpit transaction history
Blockpit: Using the filter options: Asset + Integration + Date
Exchange or wallet: Use of filter options: Asset + Date, if available
The transaction label "Token Migration" is already available for users with Germany as their tax country (DE). The manual transfer of acquisition costs using the “Update asset values” function, as shown below, is therefore no longer necessary. Support for other tax jurisdictions will follow soon.
Example 1: Full withdrawal & Full redistribution
The following illustration shows the full removal (withdrawal) of the old asset quantity from MC and a redistribution (deposit) of the full new asset quantity at a ratio of 1 : 10 BEAM.
(image translation in process)
Solution: In this case, all transactions are already transmitted by the Bitpanda as they should be for each token migration that led to a change in the asset quantity. Only the cost basis (acquisition costs) of the old asset quantity must be transferred to the new asset quantity or the new asset by updating the asset values, as shown in the image below.
(image translation in process)
Example 2: Bitpanda Reverse Stock Split - Incomplete (partial) withdrawal
The following image shows the removal (withdrawal) of a partial amount (900 WEED) in order to reduce to the new asset quantity of 100 WEED. Reverse stock split ratio to be replicated 10 : 1 (1000 WEED → 100 WEED).
(image translation in process)
Solution: In this case, the withdrawal of the full old asset quantity of WEED must be replenished by editing the outgoing (withdrawal) transaction in your Blockpit transaction history (increase from 9/10 to 10/10). In addition, an Airdrop or Non-Taxable IN transaction must be created for the redistribution of the full new asset quantity (1/10, i.e. 100 WEED). The old cost base (acquisition costs) must then be added to this deposit by updating the asset values.
(image translation in process)
Example 3: Bitpanda Tokenmigration - Incomplete (partial) redistribution
Solution: Similar to example 1, however, old asset quantities are not removed by the exchange in advance in the form of an independent withdrawal transaction, which is why this transaction must be created independently in your Blockpit transaction history.
In addition, a deposit of a new incomplete (partial) quantity is generated by the exchange in the form of an independent airdrop transaction. The asset quantity of this redistribution deposit must be edited so that the complete resulting asset quantity is posted. Then, as in examples 1 & 2, the asset value of this transaction must be added for the purpose of carrying forward the cost basis.
Currently, it is not yet fully possible to transfer the acquisition date and acquisition costs in Blockpit directly using the “Token Migration” label, except for the tax country Germany (DE). Support for other tax jurisdictions will follow soon in order to fully guarantee the transfer of acquisition data in the event of both a token migration and a stock split.
As soon as the label “Token Migration” is available, both created transaction pairs can be marked and merged or relabeled to “Token Migration”.
Thank you for your understanding and patience.