Define mechanics of POA token to be used with the bridge about poa-bridge HOT 6 CLOSED

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.

from poa-bridge.

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.

from poa-bridge.

@akolotov I agree with this strategy

from poa-bridge.

@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

from poa-bridge.

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?

from poa-bridge.

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

from poa-bridge.