Continuation from https://github.com/OpenZeppelin/openzeppelin-solidity/issues/795.
ERC20Migrator is one of our unstable contracts. It would be nice to stabilize soon but we need more people to review the API and the mechanism itself.
The contract implements a mechanism for migrating/upgrading an ERC20 token in an opt-in way. This allows upgrading even when an upgrade mechanism like ZeppelinOS isn’t available. There are no requirements on the original token contract other than a working standard ERC20 interface. This means it can be used even when upgrading wasn’t a consideration when deploying the first version of the token.
The way it works is: a new token contract is deployed, an
ERC20Migrator instance is deployed, and the instance is given the ability to mint the new token. Once that is set up, each token holder can decide to migrate by using ERC20
approve to give the migrator instance the ability to transfer their tokens on their behalf. Then the migrator can be triggered to take those tokens and mint the equivalent amount of the new token. The last part can be done by anyone, not only the token owner.
The balance from the legacy token will be transferred to the migrator, as it is migrated, and remain there forever.
Although this contract can be used in many different scenarios, the main motivation was to provide a way to migrate ERC20 tokens into an upgradeable version of it using ZeppelinOS. To read more about how this can be done using this implementation, please follow the official documentation site of ZeppelinOS: https://docs.zeppelinos.org/docs/erc20_onboarding.html
Example of usage:
const migrator = await ERC20Migrator.new(legacyToken.address); await newToken.addMinter(migrator.address); await migrator.beginMigration(newToken.address);