You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As part of #295 two ways to transfer tokens with specifying an alternative receiver were implemented:
for scenarios where generic ERC20 tokes are involved it is necessary to use sequential pair of approve and relayTokens methods
for scenarios where ERC677 compatible tokens are used it is enough to call transferAndCall
Even if the second way is simpler from a Dapp point of view and does not require two transactions, Dapp still needs to support the first way since generic ERC20 tokens are more widespread. So, in order to operate with both type of tokens the Dapp's developers should maintain two different pieces of code to achieve similar functionality. As a proof that consistency between operations with two different tokens should be kept the following fact can be used: in the past there was a special activity to allow ERC677 tokens used by the bridge behave similarly to generic ERC20 - a user could transfer tokens through the bridge both with transferAndCall and transfer.
That's why it seems logical to support approve-and-relayTokens approach for the bridges where ERC677 tokens are involved together with transferAndCall approach for the scenarios with the alternative receiver.
As part of #295 two ways to transfer tokens with specifying an alternative receiver were implemented:
approve
andrelayTokens
methodstransferAndCall
Even if the second way is simpler from a Dapp point of view and does not require two transactions, Dapp still needs to support the first way since generic ERC20 tokens are more widespread. So, in order to operate with both type of tokens the Dapp's developers should maintain two different pieces of code to achieve similar functionality. As a proof that consistency between operations with two different tokens should be kept the following fact can be used: in the past there was a special activity to allow ERC677 tokens used by the bridge behave similarly to generic ERC20 - a user could transfer tokens through the bridge both with
transferAndCall
andtransfer
.That's why it seems logical to support
approve-and-relayTokens
approach for the bridges where ERC677 tokens are involved together withtransferAndCall
approach for the scenarios with the alternative receiver.Additional discussion can be found here.
The text was updated successfully, but these errors were encountered: