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
{{ message }}
This repository has been archived by the owner on Apr 12, 2021. It is now read-only.
Is your feature request related to a problem? Please describe.
With the current design of the ERC20 Gateway, the user have to first approve the gateway to allow it to transfer the token on its behalf.
Describe the solution you'd like
If the gateway would support ERC677 function onTokenTransfer(address, uint, bytes calldata) external returns (bool); then users could simply call transferAndCall and be done
Describe alternatives you've considered
An alternative that would also be great to have is for the deposit function to accept a signature so it can call EIP-2612 permit if needed
The text was updated successfully, but these errors were encountered:
Permit is great so I would also vote to get it supported.
But I think as a generic gateway, it should dictate as less as possible what is accepted and let developers chose what is best for them. Hence why I vote for both :)
I would also vote for having it in the L2 generic ERC20 token but that is another issue.
In term of UX they are ultimately equivalent (metamask could batch the signature and tx in one popup and ERC677 could be supported so that wallet show the actually data being encoded) but as it stands, both have disadvantage and advantages.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Is your feature request related to a problem? Please describe.
With the current design of the ERC20 Gateway, the user have to first approve the gateway to allow it to transfer the token on its behalf.
Describe the solution you'd like
If the gateway would support ERC677
function onTokenTransfer(address, uint, bytes calldata) external returns (bool);
then users could simply calltransferAndCall
and be doneERC677 is a defacto standard being used by WETH10
Describe alternatives you've considered
An alternative that would also be great to have is for the deposit function to accept a signature so it can call EIP-2612 permit if needed
The text was updated successfully, but these errors were encountered: