We recently announced that ARK will be moving to Polygon. We know that there are still a lot of questions and we will continue to provide clarification as we get closer to the official migration. In this post, we will dive deeper into how the migration process works and provide insight into the technical aspects involved.
Introduction
Migrating the ARK Coin to an ARK Token on Polygon has a lot of moving parts. Our primary goal was to make the process as seamless as possible for users and ensure that it would be a smooth and painless experience. To accomplish that feat, we had to make several changes to both ARK and our surrounding suite of products, as well as build a new backend system to handle the migration from both the ARK and Polygon sides of the process.
Today we are going to cover the more technical aspects relating to ARK Core and the backend infrastructure that was built for the migration. We will post additional blogs to cover the user experience from the perspective of both ARKVault and ARKScan and the changes that were made to the front end.
Let’s dive in.
General
The diagram below will give you a glimpse of the mechanics that will take place during each step of the migration process:
From a high level, the process of migrating ARK from Devnet/Mainnet to Mumbai/Polygon consists of the following steps:
Step 1. Send a Migration Transaction on ARK
For the burn transaction, we utilize a normal transfer transaction. In order to ensure that the burn was irreversible, we have made changes to the Core to allow a true “burn” address that will make it impossible to get tokens back out. We have more details on this in the “ARK Core Changes” section later on.
The Migration transaction will contain specific information that will be automatically added during the Migration process using ARKVault. Transactions sent directly on the network from methods outside of ARKVault that do not follow the same format will not be accepted.
Step 2. Monitor ARK for Migration Transactions
Much like our original concept for encoded listeners and ACES, the migration process uses a separate backend process that monitors the ARK blockchain for migration transactions.
Each ARK migration transaction must meet the following requirements or it will be completely ignored:
- A minimum of 1 DARK/ARK has been sent to the migration/burn address.
- A set fee of 0.05 DARK/ARK has been paid to the validator who forges the transaction on the network.
- The DARK/ARK has been sent to the designated burn address.
- The SmartBridge (Memo) has been set to a valid Polygon wallet address.
Note: Each migration transaction is treated independently, meaning that even if you burn less than the minimum amount per transaction and all of your transactions in total would exceed that minimum - none of your transactions would be valid.
For a migration transaction to complete, it requires that more than 24 hours have passed from the time the burn transaction was forged on the ARK blockchain. This check is a general precautionary measure to increase security and provide time to react to any malicious incidents that may occur. While we don’t expect any issues, it is always better to be prepared.
As a side note; on our upcoming Devnet release, this check will not require the full 24 hours, and the migration process wibe almost instantaneous to provide a better testing environment.
Step 3. Queue a Submission on Polygon
Upon meeting the above requirements, your burned DARK/ARK will be enqueued for submission to the Mumbai/Polygon network via an OpenZeppelin Relayer.
Please understand that your DARK/ARK might not be minted immediately even upon meeting the requirements due to network conditions and the required timeframe for transaction completion.
Step 4. Receive Your DARK/ARK on Polygon
Once the queued transaction is mined on the Polygon network, the migration is complete and your tokens will be available in your Polygon wallet.
Note: ARK Migration is a one-way process and cannot be reversed. It is not possible to go back from Mumbai/Polygon to Devnet/Mainnet once a transaction is submitted.
ARKVault will allow you to monitor your transaction once submitted. You will be able to see full details on a pending transaction through several new additions to the ARKVault UI which we will have more details on in a separate blog post. Transactions will also be visible in ARKScan in a new Migration section to make it easier to track migration activity on the network.
Disclaimer: ARKVault will require you to sign a message with MetaMask to ensure you own the Polygon address being used for migration. If users attempt to circumvent the process or manually alter the information in the SmartBridge, funds can be permanently lost.
Technical Details
Contract Addresses
-
Mumbai (Polygon Testnet):
-
Polygon (Polygon Mainnet):
- ARK Migrator: TBD
- ARK Token: TBD
We will be using two contracts on Polygon to facilitate the migration.
- The ARK Token contract (ERC20)
- The ARK Migrator contract
All contracts have been written using the OpenZeppelin framework and are owned by a multisig wallet. After deployment, a separate temporary MINTER_ROLE is granted to the ARK Migrator contract in order to be able to mint ARK.
Minting ARK on Polygon is only possible via the ARK Migrator contract. Our backend submits mint requests through an OpenZeppelin Relayer to the ARK Migrator contract which can bundle one or more ARK migration transactions to save gas costs.
The ARK Migrator emits an event with the signature MigratedArk(address recipient,bytes32 arkTxHash,uint96 amount,uint256 timestamp) for each distinct transaction in the mint request. Additionally, it exposes a public view function getMigrationsByArkTxHash to check the status of given ARK transactions.
Both ARKVault and our backend make use of these features to keep track of user migrations.
ARK Core Changes
While ARK was built to allow custom transactions, we wanted to create as little friction as possible for users during the migration. By avoiding a new transaction type, we were able to utilize a normal ARK transaction and a custom element in the SmartBridge to facilitate the process. ARK migration will rely upon normal transfer transactions, with a few slight changes that we’ll outline below.
Core Changes for Migration:
- Hardcoded burn addresses on Testnet, Devnet, and Mainnet with distinguishable address patterns that pass checksum for ARK networks (you can check addresses here ). This approach simplifies things as there will be no need to update Ledger App and thus users who are using the Ledger hardware wallet won’t have to take any additional steps.
- Due to how those addresses have been constructed no one at any point had passphrases for these addresses. To make things even more secure we have implemented a protocol-level change that will allow the migration address to only receive ARK coins, but that address is prevented from sending anything out, essentially burning coins sent to those addresses.
-
/api/blockchainendpoint will now return 3 different supply-related numbers:- supply -> current supply (generated - burned)
- generated -> all created supply (initial/genesis supply + block rewards)
- burned -> burned supply
You can see all changes related to migration in the pull request on Core GitHub .
What’s Next?
Our team will be preparing the ARK Core update for Devnet so that it will be ready for the initial Devnet testing period.
The team at Ardent is currently finalizing the changes to ARKVault and ARKScan which will both receive updates to facilitate the upcoming Devnet release. Along with the updates to the ARK products, they will also release a migration guide to help get everyone familiar with the entire process.
More information on an official Devnet release date will be coming soon.
Follow us on Twitter to stay up to date on all of the upcoming news and we hope that you will join us in testing the new migration process on Devnet very soon!
