USDN, created by Nerite is the first native super-token which uses the Superfluid protocol without the need for wrapping. We want more tokens like this.
One unique feature this enables is access to the Permit function, which is not present in wrapped SuperTokens. Permit improves the token’s UX and ability to be added to more lending protocols and be integrated in more places, etc…
The protocol should be upgraded to add the permit function to the superfluid ERC-20 implementation
Cost: some dev time + an audit should be done on this before upgrading which also includes not breaking things in existing tokens.
While Permit may improve the UX in some cases, it also enables a major new vector for phishing attacks. Millions have been lost via Permit exploits. I think this deserves serious consideration before being adopted.
(PS: there seems to be a bug for tokens with 18 digits, it shows spending cap “unlimited” if the amount is >= 0.01. But in other places (incl. mouseover tooltip) it’s correct)
While the human readability varies a lot, all wallets render the request in a way which makes it possible for the somewhat educated user to understand what they are signing.
In some cases there is dedicated support for permit while in some cases it just renders the plain EIP-712 view.
In my opinion the biggest remaining challenge is the user’s ability to verify whom they are giving an allowance. That’s difficult if the wallet just shows the address hex string.
I noticed that Rabby shows labels (e.g. “Superfluid” or “Superboring”) for a lot of our contracts. They seem to have a curated list of deployer accounts and auto-label contracts deployed by those.
Hopefully going forward ENS will have a bigger role when it comes to address labeling.
As for the risk of phishing attacks, I don’t currently see the addition of permit to make a meaningful difference.
Most wallets do a decent job at explaining what’s being signed. As long as the user doesn’t just blindly sign whatever pops up, they should be fine.
The site Entries related to permit phishing doesn’t explain how the attacks took place. It is my guess that with USDC having support for it and thus millions being exposed, it’s just statistically a given that there will be instances of people failing to verify what they are signing.
My personal opinion after doing this exercise is that I don’t see any significant increase of the (phishing related) attack surface if adding permit.
