Migrate your assets to Immutable zkEVM
Even if you've launched a pre-sale or your game on another blockchain, it's not too late to migrate to Immutable zkEVM and take advantage of these benefits.
The assets covered in this guide are Non Fungible Tokens (NFTs) as defined by ERC-721 or ERC-1155. For help migrating in-game currencies (ERC-20 tokens) to Immutable zkEVM checkout our guide Using your existing ERC-20 token on Immutable zkEVM.
Choosing when to migrate assets to Immutable zkEVM
Ideally you should start your project by minting assets on Immutable zkEVM in the first instance. If this is not possible because your game has already run a pre-sale your might want to consider migrating the assets to Immutable zkEVM before your game launches.
If this is also not possible or your game has already launched, there are some different migration strategies you want to consider which will be explained in more detail below.
There are even some types of assets which you may not want to migrate at all.
For example, if your game only needs to verify the asset's ownership read it's metadata then then you may want to simply leave legacy assets where they are and start minting your new assets on Immutable zkEVM moving forward. If you think this approach will work for your game, check out our guide How to view all assets across multiple blockchains.
Migration types to consider
There are different types of migrations you can perform and each has their own benefits and disadvantages.
Soft migration
With a soft migration you would leave the legacy assets where they are on the old blockchain and issue players the equivalent asset on Immutable zkEVM.
You would also need to make sure the legacy assets no longer have any utility or value. This can be achieved by ensuring your game no longer recognizes the legacy the assets and only uses the new from Immutable zkEVM.
You may also need to effectively freeze your collection on the old chain, preventing orderbook executions, halting transfers, delisting collections from marketplaces and even altering the metadata to mark the assets as discontinued.
Benefits:
- A soft migration is reversible in case you need to roll back for some reason.
- There is no player interaction required, everything is managed by you.
- Players do not incur gas fees since they dont need to move or burn their assets.
Disadvantages:
- The legacy assets will still exist in some shape or form, which could potentially cause confusion.
- Since assets minted on one blockchain can potentially be bridged to other platform, it may not be easy or possilbe to deactivate all assets across all chains.
- If any assets have been bridged to other blockchains they may still appear on marketplaces those chains, leading to potential confusion and complaints.
Hard migration
With a hard migration the legacy assets are actually burned or returned before the equivalent asset is issued to players on Immutable zkEVM.
Benefits:
- It's less confusing for players as they are effectively trading in their legacy asset for a new one rather than having two, one of which is useless.
- The legacy assets are actually removed from circulation which prevents the trading of devalued assets.
Disadvantages:
- Typically a one-way migration, which means there may be some player drop off during the process.
- Because an on-chain action is required to burn or return the asset, players will incur gas fees.
- It's best suited for individual asset migrations and games where users may only have a small number of assets each to migrate.
Migration timelines
There are different approaches to managing migration timelines, and you will need to decide which approach is best for your current situation.
Batch Migration
Batch migration is a structured approach that requires players to take specific actions within a designated timeframe. This method is suitable for communities with high engagement levels and typically follows a defined workflow:
- Communication: The game studio informs players about the migration process, including details and deadlines. Clear communication is essential to ensure players understand the requirements and timeframe for migration.
- Registration: Players are required to register for migration to confirm their desired destination wallet. This step ensures that assets are transferred to the correct location during the migration process.
- Migration Process: Migration takes place within the specified timeframe, during which players are categorized into two paths based on their compliance with the migration instructions:
- Happy Path: Players who followed the migration instructions within the allotted time are migrated smoothly to the new destination without any issues.
- Unhappy Path: Players who did not complete the required actions within the specified timeframe are categorized into the unhappy path. They may require additional support or actions post cut-off to complete the migration successfully.
- Post-Migration Support: The game studio continues to communicate with and support players who are on the unhappy path, assisting them in transitioning to the happy path post-migration. This support may involve providing guidance, addressing issues, or facilitating additional steps required for successful migration.
By following this structured approach, you can effectively manage batch migrations, ensure player compliance, and support a smooth transition to the new destination for all players involved.
Long Tail Migration
Long tail migration allows players to migrate their assets at their own pace without the need to adhere to a strict timeline. This method offers a user-friendly workflow but entails additional costs (limited batch minting and operational support) and requires ongoing support from the game studio. The typical workflow for a long tail migration includes the following steps:
- Communication: The game studio communicates the migration process to players, including any relevant deadlines or timelines. If the long tail migration has a cut-off point, this should be clearly communicated to players, along with the duration of the migration support period (e.g., Studio will support the process for 1 year).
- Player Migration Details: Players are required to register their desired destination wallet before the migration begins. This step ensures that assets are transferred to the correct location during the migration process.
- Migration Process: The migration occurs either instantly or may be batched overnight, depending on the game studio's implementation. Details collected from the previous step are utilized to guide the migration process, ensuring assets are transferred accurately.
- Post-Migration Support: Following the migration period, the game studio provides ongoing support to players who have not yet migrated their assets. While this support does not need to be real-time, it should offer a way for disengaged players to initiate the migration process at their convenience, albeit gradually. This support may involve manual assistance or a slow-paced migration process to accommodate players who have been inactive for an extended period.
Recommended approach
Key decision points
Our recommendation may not always be suitable for every situation, so here are some key decision points to consider.
- Live Game: If a game is already live, it is advisable to opt for a long tail migration to mitigate the risk of players encountering an "unhappy path." This approach aims to prevent situations where players have their assets migrated to an undesirable state, potentially resulting in the loss of hard-earned acquired players.
- Games Yet to Launch: In the case of games that have not yet launched, a Batch migration may be preferable to reduce the game's costs. Since the assets are not currently usable, the unhappy path resulting from a Batch migration typically poses less friction for users. Additionally, in scenarios where games have not yet launched but require a migration, players must complete steps to activate the asset, minimizing any significant friction caused by the unhappy path.
- Token ID Persistence: In certain cases, the value of specific NFTs can be directly influenced by the asset’s Token ID. In such instances, the community may anticipate that the Token IDs of their assets remain consistent across different blockchain networks. If this expectation exists, employing minting methods such as mintBatchByQuantity() or utilising the Minting API without Token ID inputs becomes unfeasible. Consequently, the migration process may incur higher minting costs as mintBatch() or Minting API with Token ID incurs higher gas fees.
- Minting API: Immutable's ERC721 presets are fully compatible with the Minting API. However, it's worth noting that ERC1155 is currently not compatible with the Minting API, although it is on the Asset’s Team roadmap for future integration.
- ERC721 → ERC1155 Contract Migration: Some game studios may opt to migrate their ERC721 assets from legacy chains to Immutable's ERC1155 contract. This transition can offer several advantages for specific use cases. However, it's important to be aware of certain limitations:
- Token ID Preservation: During the migration from ERC721 to ERC1155, the preservation of Token IDs is not possible. Game studios should anticipate this change and its potential impact on asset management and user experience.
- Minting API Support: Unlike ERC721, ERC1155 does not currently support the Minting API. Game studios should factor in this limitation when planning their migration strategy and consider alternative approaches for asset minting on the new contract.
By considering these limitations and planning accordingly, game studios can effectively manage the migration of their assets from ERC721 to ERC1155 while optimizing their user experience and asset management processes.