Support of simple transfers for OmniBridge

[akolotov]

Consider to develop a way how the oracle, monitor and ALM should be changed as so the end user could transfer the tokens through the OmniBridge (former multi-token extensions) from the Foreign chain to the Home chain just by performing the ordinary ERC20 transfer call.

This issue is an epic for the changes required to be implemented in all components of the bridge.

[k1rill-fedoseev]

What happens at the oracle?

When user performs a simple call to the transfer/transferFrom method on any ERC20 compatible token, interaction with the AMB bridge is omitted. However, the transferred tokens are being locked in the contract in a similar way as if a user called a relayTokens method, except that UserRequestForAffirmation is not emitted. So, oracle cannot process such transactions in a usual way.

Proposed solution guidelines

• Create a new worker for AMB oracle on the foreign side that does the following: 1) Listens to all Transfer events where the receiver is the omni-bridge mediator. This can be done either by all transactions scanning, or by using the existing Etherscan API. 2) For each valid transfer, checks that the participating token is indeed an ERC20 token, not an ERC721. 3) For each valid transfer, requests transaction receipt and checks that the bridge interaction didn't happen (neither transferAndCall or relayTokens were used) 4) For remaining transactions, generates an executeAffirmation call on the Home side. Message id should contain a fixed nonce (e.g. 0xff..ff). Passed message should also contain the token address, name, symbol and decimals. It makes sense to also include the transaction hash and a block transaction index, so that bridge can handle multiple transfers occurred in a single transaction.
• Create a new method in ForeignMultiAMBErc20ToErc677 contract which does one of the following: 1) Calls deployAndHandleBridgedTokens, if a token was not transferred before. 2) Calls handleBridgedTokens, if a token was already seen.
• Add a detection logic in the monitor for the following events: 1) ERC20 transfer events on foreign side, where receiver is a OmniBridge mediator and tokens were not transferred using transferAndCall or relayTokens. 2) Message processing events on the home side, that include a fixed nonce (0xff..ff) in their message ids.
• Consider simple ERC20 transfers as a bridge requests on the ALM as well. Search for bridge operation completion on xDai chain by using a fixed nonce, passed txHash and transaction index.
• Remove claimTokens and fixMediatorBalance functionalities from ForeignMultiAMBErc20ToErc677, since any token transfer will be correctly processed by the bridge.
• Allow to initialise a new token pair, when a request comes from the xDai chain.