Deployment with existing ERC20 token on Home side

[akolotov]

Current version of the bridge contracts deployment in erc20-to-erc20 mode assumes that a new ERC20/ERC677 token contract is deployed in Home network together with other bridge contracts.

It make sense to have an address of existing ERC20/ERC677 token on Home side configurable in .env file.

For example, we introduce HOME_ERC677_TOKEN_ADDRESS parameter as so, if it exists in .env file, the new token will not be deployed and the configured token address is used in Home bridge contract, otherwise (if the parameter is not specified) Home bridge contract will use a new token deployed as part of the bridge contracts initialization.

[rstormsf]

use case?

[akolotov]

Use case is the following: An application would like to use it own version of token on Home (probably a modification of our token). Most probably they will use their own procedure to deploy and initialize token as so the token contract will be available in the chain before the bridge contracts will be deployed. At the current moment there is the ability to change the token address in the bridge contract after the bridge contracts deployment: some dummy token will be deployed as part of run deploy.js and then its address replaced by another token. It does not seems rational - much more logical to have the ability to provide the token address on the deployment stage in order to reduce 'garbage' appeared in the chain.

Let's say that this issue is low priority and will be addressed when we have free resources.

[akolotov]

As it was mentioned in https://github.com/poanetwork/poa-bridge-contracts/pull/71#discussion_r211768506 it makes sense to consider the following enhancement:

we add the following configuration parameters in .env-file:

HOME_ERC677_TOKEN_ADDRESS 
HOME_ERC677_TOKEN_NAME
HOME_ERC677_TOKEN_SYMBOL
HOME_ERC677_TOKEN_DECIMALS

and

FOREIGN_ERC20_TOKEN_ADDRESS 
FOREIGN_ERC677_TOKEN_NAME
FOREIGN_ERC677_TOKEN_SYMBOL
FOREIGN_ERC677_TOKEN_DECIMALS

where FOREIGN_ERC20_TOKEN_ADDRESS will be used instead of ERC20_TOKEN_ADDRESS.

They will be used by deployment script: In native-to-erc mode we expect:

• either FOREIGN_ERC20_TOKEN_ADDRESS which will link the bridge contract to an existing ERC677 token;
• or set of FOREIGN_ERC677_TOKEN_NAME, FOREIGN_ERC677_TOKEN_SYMBOL, FOREIGN_ERC677_TOKEN_DECIMALS which will be used for deployment of new ERC677 token.

HOME_ERC677_... parameters will be skipped even if they exists in env-file.

In erc-to-erc mode we expect:

• either HOME_ERC677_TOKEN_ADDRESS which will link the bridge contract to an existing ERC677 token;
• or set of HOME_ERC677_TOKEN_NAME, HOME_ERC677_TOKEN_SYMBOL, HOME_ERC677_TOKEN_DECIMALS which will be used for deployment of new ERC677 token.

AND

• either FOREIGN_ERC20_TOKEN_ADDRESS which will link the bridge contract to an existing ERC20 token;
• or set of FOREIGN_ERC677_TOKEN_NAME, FOREIGN_ERC677_TOKEN_SYMBOL, FOREIGN_ERC677_TOKEN_DECIMALS which will be used for deployment of new ERC677 token.