As the number of game studios choosing to build on Immutable zkEVM continues to grow, we’ve experienced a massive spike in inquiries from existing games asking how they can transition their game and assets to Immutable zkEVM.
This blog aims to answer the key question: "How do I migrate my game from my current chain to Immutable zkEVM?"
We will explore the reasons why games are interested in migrating to Immutable zkEVM and discuss different migration approaches, featuring example scenarios.
Why are games migrating to Immutable zkEVM?
Immutable zkEVM, combined with Immutable’s suite of platform products, is the first end-to-end zkEVM solution dedicated exclusively to making games successful. In contrast to general purpose chains - which are designed to support a broad set of applications and smart contract functionality - Immutable zkEVM is designed specifically for games.
Regardless of where games are migrating from, Immutable zkEVM offers a unique combination of high throughput, low transaction fees, network reliability, smart contract composability, and security. Furthermore, the powerful ecosystem surrounding Immutable zkEVM allows studios to tap into the combined network of Immutable and Polygon, making acquiring gamers, tools, and funding easier than ever.
For a detailed analysis of the features and benefits of Immutable zkEVM, you can read more here.
How to migrate to Immutable zkEVM
While there isn’t a one-size-fits-all approach to migrating existing assets from another blockchain or rollup to Immutable zkEVM, we want to make it as easy as possible for you. Immutable can provide guidance and help you along the way, but it’s important that you do what’s best for your game and your community. Here are some common approaches we often recommend:
- Freeze and Move: under this scenario, the game ‘copies’ the assets onto Immutable zkEVM, while freezing trading and in-game interaction/visibility of the original assets.
- Burn and Move: under this scenario, the game ‘copies’ the assets onto Immutable zkEVM, while coordinating a burn of the original assets. The main difference between burning and freezing is that burned assets will be removed from circulation permanently.
- Read-Only Linking: a non-migration option where existing game assets are treated as read-only.
If none of these options suit you, there’s always the fallback for games to manually bridge their assets using our Ethereum to Immutable zkEVM asset bridge. This fallback is only recommended for Ethereum-native assets. If your asset is natively minted on another chain (alt-L1, sidechain, or L2), we usually recommend one of the first three options. This is to minimize the security risks and liquidity fragmentation associated with cross-chain bridging.
- Manual Bridging (Fallback Option): under this scenario, the user manually bridges each asset to Immutable zkEVM via Ethereum.
- The asset retains the same address as the original asset.
- This is expected to be the most expensive option, as bulk operations are limited to assets owned by a single user. Coordination beyond a single user will be difficult to manage.
- Currently, this option is only available for ERC-20s. We are working towards providing an ERC-721 bridge in the future. Additionally for ERC20s, there’s an opportunity to provide a liquidity bridge for “fast bridging”
- For more information, please refer to Immutable zkEVM’s bridging documentation.
Migration Scenarios
Now that we’ve provided some context, let’s take a closer look at these migration options.
Freeze and Move:
Under this scenario, the game ‘copies’ the assets onto Immutable zkEVM, while freezing trading and in-game interaction/visibility of the original assets.
Step 1 - The original assets are frozen so players and traders don’t engage with the original assets on the other chain. Some considerations for this first step:
- For assets on Immutable X, Immutable can assist with placing a non-custodial trade lock on migrated assets. For other blockchains, you will need to ask marketplaces and other third-party ecosystem tools to delist assets from the old contract. You should provide plenty of notice of this upcoming freeze to reduce the chances your players accidentally purchase old contract assets after the migration. Here are some actions you should consider: cancel all open orders, prevent new orders, freeze all trading, and restrict P2P transfers.
- If the user is using two different wallets for the different blockchains, your game will need to offer an interface (in-game or on the web) where the user can consolidate assets into a single wallet on zkEVM. We recommend that you encourage players to use Immutable Passport on Immutable zkEVM, as that provides the most seamless in-game experience for games in the Immutable ecosystem. Immutable is looking into providing a tool to make this multi-wallet consolidation to Immutable Passport easier in the future.
Step 2 - Assets are bulk minted on Immutable zkEVM. Some considerations for this step:
- To minimize gas fees as you re-mint assets on Immutable zkEVM, you could consider using the bulk minting functionality of the Immutable Platform.
- We recommend that the game should read/import all metadata from the old contract assets and ensure that the newly minted asset includes any information that helps track the item's provenance. Immutable’s Blockchain Data APIs will continue to serve metadata even for frozen assets; this provides sufficient time for the game to read all metadata.
- If your EOA wallet address between networks is the same, you will have the data you need to airdrop the new asset.
- To calculate the gas cost for the re-minting of assets, you could use this formula as a base: Total gas = #mint transaction x mint gas estimation on the destination chain.
(mint gas estimation ($) = price per unit of gas ($/gas) x units of gas consumed (gas) in a single mint transaction.
For a typical game using our gas-efficient bulk minting tools, with average to low utilization of our network, it is expected that 100,000 assets will be able to be minted for a few hundred dollars worth of gas.
Once the migration is complete, your game should consider Immutable zkEVM as the source of truth for assets and ignore what has been left on the other chains.
Freeze and Move Example: Guild of Guardians
Guild of Guardians (GoG) is an example of a game that launched on Immutable X that has decided to pursue a Freeze and Move strategy. The game is able to make this move despite having some L2-minted assets withdrawn and minted on L1 (i.e. there is now a GoG NFT contract on Ethereum L1). This option requires a relatively low amount of user involvement and coordination. GoG will fund the bulk minting cost to migrate the assets as GoG expects to recoup this in the long-run through increased player activity on Immutable zkEVM.
Burn and Move:
Under this scenario, the game ‘copies’ the assets onto Immutable zkEVM, while coordinating a burn of the original assets. The main difference between burning and freezing is that burned assets will be removed from circulation permanently.
Step 1 - Assets are bulk minted to Immutable zkEVM. Some considerations for this step:
- To minimize gas fees as you re-mint assets on Immutable zkEVM, you could consider using the bulk minting functionality of the Immutable Platform.
- We recommend that the game should read/import all metadata from the old contract assets and ensure that the newly minted asset includes any information that helps track the item's provenance. Immutable’s Blockchain Data APIs will continue to serve metadata even for frozen assets; this provides sufficient time for the game to read all metadata.
- To calculate the gas cost for the re-minting of assets, you could use this formula as a base: Total gas = #burn transactions x average burn gas estimation on the original chain + #mint transactions x mint gas estimation on the destination chain
The burn transaction will happen on the original chain and the cost will depend on the implementation of the contract and the chain’s VM/protocol.
For a typical game using our gas-efficient bulk minting tools, with average to low utilization of our network, it is expected that 100,000 assets will be able to be minted for a few hundred dollars worth of gas.
- Care should be taken to ensure that no double spend will occur on the original chain, given the asset will temporarily “live” on two chains. You could consider a pre-requisite step to freeze all in-game and trading functionality for safety.
Step 2 - Original assets are burned and removed from circulation on the original chain. Some considerations for this step:
- This step requires careful consideration and coordination because it requires interaction from the user who owns the assets being burned.
- As the assets being burned are owned by an individual, you will need to carefully explain what is happening to the user and they will be required to sign the burn transaction (or sign a transaction to delegate permission for a smart contract to burn on their behalf).
- As the mint and burn actions are happening on different blockchains, you cannot create an atomic transaction within a single smart contract. We often recommend creating a backend solution which can manage the mint and burn with the necessary checks and balances to ensure that the burn doesn’t happen unless the mint is successful and the asset can be seen as associated with the correct user’s wallet.
- If the user is using two different wallets for the different blockchains, currently your game will need to offer an interface (in-game or on the web) where the user can consolidate assets and migrate to Immutable Passport on Immutable zkEVM. We recommend that you encourage players to use and migrate to Immutable Passport, as that provides the most seamless in-game experience for games in the Immutable ecosystem. Immutable is looking into providing a tool to make this multi-wallet consolidation to Immutable Passport easier in the future.
Burn and Move Example: Meta Toy City
Meta Toy City is an example of a game that will migrate their assets from Polygon PoS to Immutable zkEVM. Due to the liquidity and security risks associated with cross-chain bridging, they are working towards implementing a Burn and Move strategy to ensure that all existing circulating assets will be frozen from third-party tools and wholly removed from circulation. This is intended to ensure they will not have any residual liability on the original chain. We’re working closely with developer Sandbox Network to ensure a smooth transition.
Read-Only Linking:
While not necessarily a true migration process, this option allows existing game assets to be treated as read-only assets on Immutable zkEVM. These assets cannot be combined (e.g. crafted or composed) with other assets native to Immutable zkEVM, but users’ ownership is acknowledged and their assets can still unlock in-game benefits.
While this option sounds simple, there will be complexity that a game studio has to manage to ensure that asset ownership on the original chain is accurately reflected close to real-time in-game and on Immutable zkEVM. This is necessary to avoid potential ‘double spend’ risks (as explained in Burn and Move above), as the original assets are technically still liquid and tradable both inside and outside the Immutable ecosystem.
Decision Matrix
To help you make a decision between the three commonly recommended migration approaches, the following matrix outlines some of the key decision criteria that could impact your game:
Please note: The table above outlines general guidance only, and you will need to consider what is right in your circumstances
As a general rule of thumb, we’re aware that many existing Immutable X games are planning to undertake a Freeze and Move strategy, while games from other chains are often considering a Burn and Move strategy to make a clean and smooth transition.
Conclusion
Migrating your game to Immutable zkEVM presents exciting opportunities for enhanced gameplay, reduced costs, and access to a thriving gaming-specific ecosystem. We recognize and appreciate that the migration process will require work on your end, but we’re here to support you on that journey. By choosing the right migration approach and carefully considering the player experience, game studios can seamlessly transition their games to zkEVM. Let’s make Immutable zkEVM the gold standard of web3 gaming together.
