Current implementation of the erc20-to-erc20 bridge mode assumes that pure ERC20 token is used on the Foreign side. So, when the tokens are relayed to the Home side, the method transfer is invoked by the user and the relay request is handled by the TokenBridge oracle without involvement the bridge contract on the Foreign side. It is inconvenient due to following:
there is no way to revert the request if it exceeds the limits.
there is no way to halt the bridge operations
Historically, such kind of functionality was suggested for already deployed ERC20 tokens to enhance them through the bridging ability and described shortcomings were considered as insignificant in comparison with the value such solution could bring. But for there are the cases for the bridge when it is going to be used with just deployed tokens. In this case the token could be extended by ERC677 standard in order to address issues described above.
In order to allow the Token Bridge UI to work with new contracts, it is necessary for the erc-to-erc mode consider an option to call transferAndCall on the token contract instead of transfer. The apporach to work with token could be identified by checking whether the ERC20 token contract has the bridgeContract method and it points to the same bridge contract the UI must work with.
If the ERC677 is discovered to work with the erc-to-erc bridge the UI should also display statistic related to limits on the Foreign side.
Current implementation of the
erc20-to-erc20
bridge mode assumes that pure ERC20 token is used on the Foreign side. So, when the tokens are relayed to the Home side, the methodtransfer
is invoked by the user and the relay request is handled by the TokenBridge oracle without involvement the bridge contract on the Foreign side. It is inconvenient due to following:Historically, such kind of functionality was suggested for already deployed ERC20 tokens to enhance them through the bridging ability and described shortcomings were considered as insignificant in comparison with the value such solution could bring. But for there are the cases for the bridge when it is going to be used with just deployed tokens. In this case the token could be extended by ERC677 standard in order to address issues described above.
That's why the PR https://github.com/poanetwork/poa-bridge-contracts/issues/175 was created in the bridge contracts repo.
In order to allow the Token Bridge UI to work with new contracts, it is necessary for the
erc-to-erc
mode consider an option to calltransferAndCall
on the token contract instead oftransfer
. The apporach to work with token could be identified by checking whether the ERC20 token contract has thebridgeContract
method and it points to the same bridge contract the UI must work with.If the ERC677 is discovered to work with the
erc-to-erc
bridge the UI should also display statistic related to limits on the Foreign side.