Define mechanics of POA token to be used with the bridge

[akolotov]

1. Will it be a pre-minted token (hardcoded totalSupply) or Mintable token?
2. If the token is Mintable then possible two options:
   • the bridge contract mints value of tokens every time it receives deposit() and burns value tokens every time it receives a request to transfer tokens to the PoA network (exchange to coins). This functionality is used now by the original Parity bridge.
   • the needed number of tokens is minted just after the contract deployment (the same applicable to the scenario when the amount of tokens is hardcoded by totalSupply) and ownership of all minted tokens is passed to the bridge contract. So, when coins are deposited, tokens owned by the ForeignBridge contract transfered to the user, and if user would like to withdraw coins, he/she transfer tokens to the bridge contract. If such apporach is chosen, the value of minted tokens must be set in the HomeBridge contract as so it could control that amount of all deposits is not greater than the amount of all tokens. If this mechanism is not introduced the situation with user's funds locked on the HomeBridge contract could happen since the ForeignBridge contract will try to transfer more tokens than it owns and will fail.
3. What the interface for the user to request exchange tokens to coins (withdraw) is?
   • it seems to be logical to use ERC677 which describes usage of transferAndCall() method. If a user invokes transferAndCall of the token contract, it will call tokenFallback() of the ForeignBridge contract to complete transfer of tokens and proceed with withdraw. Disadvantages of this approach are that the user needs to know the address of the bridge and also the standard requires to specify 'data' in the method call which is unnecessary in our case.
   • another way is to define our own method in the token contract (e.g. the original bridge specifies transferHomeViaRelay) and inform all users for ABI and the correct procedure to withdraw funds. Advantages are the following: no need to specify the bridge address (since the token will know it) and 'data', only value to withdraw is required.
   • The next option is to use ERC223 token but it's support by exchanges is not clear.

[rstormsf]

1. I don't see a value of using Pre-minted token because it can trigger unnecessary concerns by our contributors of doubling up the total supply. I believe using Mintable strategy is useful with tight security mechanism so that if 1 relay node is compromised, it still requires 51% of all relay nodes in order to submit mint without actual Deposits. I have to evaluate the current security model of this approach.

2. I don't believe there should be any hard coded/minted token at the time of deployment. Both should be 0. The start of the process will be from HomeBridge that will start minting tokens when first Deposit event will be received.

2.1. I'm curious under which condition the value of left side could be lower than the amount minted? I believe it's a problem that shouldn't exist only if some exploitation is applied. There is no simple solution to that problem since it requires 3rd party oracle that will update contracts on both sides in order to check the POA balance on HomeBridge and totalSupply on ForeignBridge

2.2. That is definitely great question which token design we should use. I am leaning towards ERC677 approach since I don't like to deviate from standards and don't want people to know what our custom method is.

2.3 ERC223 hasn't gotten wide public adoption hence I would like to stay away from it.

[akolotov]

Ok. After discussion on the meeting and investigation of cases with upgradable tokens listed on exchanges we have the following:

1. we need a ERC20 (or any another supportable by exchanges) token
2. the token contract must exists separately from bridge contract
3. if the standard. we chose, does not support safe transfer tokens to contracts we need to implement this in the POA token (e.g. ERC677 - transferAndCall()) in order to allow customers to transfer tokens to another contracts.

then we dedicate two phases in the token life time.

Phase I

Besides the functionality dictated by the standard we need the ability to mint the token in order to support deposit tokens by the bridge. The bridge contract is only the address which has the right to mint tokens.

Phase II

In order to have POA tokens swappable to POA coins, the token must be burnable: as soon as the transferAndCall() (or similar functionality) is called with the bridge contract as recipient, the token bridge will burn tokens. This functionality must be disabled by default on Phase I (the bridge token must revert in any scenario when receives tokens). It is assumed that the bridge contract will be upgraded on Phase II to enable this functionality. In any case the bridge contract is only the address which has the right to burn tokens.

Ownership

Since we have to manage the token contracts to provide rights for minting or burning tokens by the bridge address, it makes sense to consider multisig approach for applying new configuration to the token: several authorities (M) will be listed as approvers in the token contract and the configuration will be changed if N approvers (e.g. N > M/2 + 1 or any another appropriate scheme) confirmed this.

@rstormsf @igorbarinov, if you agree with the comment above I will create separate issues to address needed changes.

[rstormsf]

@akolotov I agree with this strategy

[rstormsf]

@akolotov I'd probably use ERC827 vs ERC677 https://github.com/OpenZeppelin/zeppelin-solidity/tree/master/contracts/token/ERC827

The reason is simple: it's audited by OpenZeppelin and already included into their code

[akolotov]

OK. I am not an expert in how users work with exchanges, so do you @rstormsf have any idea how the end user will generate _data for such kind of transfer?

[akolotov]

Could be closed since all contracts already implemented in https://github.com/poanetwork/poa-parity-bridge-contracts