It's day 4 of ERC-777 week! π°π
While I believe ERC-777 is the best standard for fixing ERC-20, it's certainly not the only one.
Today I'll cover the pros & cons of some other standards:
- ERC-2612 permit()
- ERC-3009 transferWithAuthorization()
- ERC-677 transferAndCall()
While I believe ERC-777 is the best standard for fixing ERC-20, it's certainly not the only one.
Today I'll cover the pros & cons of some other standards:
- ERC-2612 permit()
- ERC-3009 transferWithAuthorization()
- ERC-677 transferAndCall()
https://twitter.com/dmihal/status/1367099219002146817
The most popular of these is permit(), which was originally created for Dai, and popularized in Uniswap V2.
Permit allows a the user to sign a message before their transaction, giving another contract permission to "pull" tokens. This signature gets included in the main tx.
Permit allows a the user to sign a message before their transaction, giving another contract permission to "pull" tokens. This signature gets included in the main tx.
This is a big improvement over the standard ERC-20 behavior.
First of all, users don't need to send an extra approve() transaction, saving them time and money.
Also, users typically don't give infinite approval, which avoids the recent security issues.
First of all, users don't need to send an extra approve() transaction, saving them time and money.
Also, users typically don't give infinite approval, which avoids the recent security issues.
https://twitter.com/dmihal/status/1367099224882622466
I've been a big supporter of permit(), I think I was even the one that pushed for @MartinLundfall make it an ERC-standard.
Yet, permit still feels like a band-aid on top of the underlying problem, and it still introduces many challenges.
Yet, permit still feels like a band-aid on top of the underlying problem, and it still introduces many challenges.
https://twitter.com/dmihal/status/1249377176073449478
Let's start with the user experience:
While permit() is a big improvement over normal ERC-20 approvals, it's still far from ideal.
Users still need to sign a somewhat-confusing message before their main transaction.
While permit() is a big improvement over normal ERC-20 approvals, it's still far from ideal.
Users still need to sign a somewhat-confusing message before their main transaction.
Permit uses the EIP-712 signature standard, which has somewhat limited wallet support. @Ledger recently added support for these signatures, but @Trezor still doesn't support it.
Furthermore, contract wallets like @argent can't create these signatures.
Furthermore, contract wallets like @argent can't create these signatures.
This brings me to my next point:
Building front-ends with permit() is complicated.
The frontend needs to first pull data from the contract (nonce, etc) and prepare the ERC-712 signature.
I built a library to simplify this, but it's still difficult. π©
npmjs.com/package/eth-peβ¦
Building front-ends with permit() is complicated.
The frontend needs to first pull data from the contract (nonce, etc) and prepare the ERC-712 signature.
I built a library to simplify this, but it's still difficult. π©
npmjs.com/package/eth-peβ¦
And as I mentioned, many wallets don't support permit, so you need to build a fallback system to use normal approvals.
Some apps like @yield have a permit() mode and an approve() mode.
Some apps like @yield have a permit() mode and an approve() mode.
Not only are frontends difficult, but writing contracts with permit is difficult as well.
You must add separate functions for with & without permit. That means permit can double the number of functions needed in a smart contract.
Look at the duplicate functions in Uniswap:
You must add separate functions for with & without permit. That means permit can double the number of functions needed in a smart contract.
Look at the duplicate functions in Uniswap:
Plus, the MakerDAO/Dai implementation of permit() is different than the ERC-2612 version used by most other apps.
So if you want to support Dai + other tokens, then you need even more functions in your contract!
So if you want to support Dai + other tokens, then you need even more functions in your contract!
There are even more difficulties around building using permit, but I'll try not to get too into-the-weeds.
Permit is a great band-aid on top of ERC-20, but it's far from the ideal solution.
Permit is a great band-aid on top of ERC-20, but it's far from the ideal solution.
The most recent version of USDC introduced transferWithAuthorization. @petejkim standardized this as ERC-3009.
It's another useful standard, but it suffers some of the same drawbacks as permit(), so I won't spend to much time on it.
It's another useful standard, but it suffers some of the same drawbacks as permit(), so I won't spend to much time on it.
https://twitter.com/petejkim/status/1311452054242557952
Finally, there's transferAndCall, standardized by ERC-677 & ERC-1363.
This function is pretty self-explanatory: you transfer a token and the token contract will execute a callback hook on the recipient contract.
This function is pretty self-explanatory: you transfer a token and the token contract will execute a callback hook on the recipient contract.
This approach is my favorite out of these 3, but it has pretty limited adoption, $LINK is the only major coin I know that implements it.
https://twitter.com/ChainLinkGod/status/1198447058841026560
While I support any effort to fix ERC-20's issues, all 3 of these approaches are incremental improvements.
When we move to L2, let's not take the problems of the past with us.
Let's jump into the future with ERC-777.π₯π
Check back tomorrow, when I'll cover ERC-777 for devs!π»
When we move to L2, let's not take the problems of the past with us.
Let's jump into the future with ERC-777.π₯π
Check back tomorrow, when I'll cover ERC-777 for devs!π»
β’ β’ β’
Missing some Tweet in this thread? You can try to
force a refresh
γ
