Should we retain the feature that ETH can be used as an ERC20 token?

[smartcontracts]

The OVMv1 made ETH accessible via two methods:

1. Normal ETH transfer methods (msg.value, {address}.tranfer, etc etc)
2. ERC20 token transfers (ERC20(0x42....06).transfer(to, amount))

However, community consensus over this feature has not yet been reached. Although some of you have expressed that you think this is a great idea, others have also expressed concern. For the moment, it seems prudent to disable ETH ERC20 features for the next release while we have a wider discussion about the features. I'm hoping that we can have the majority of that discussion here.

So... let's discuss! Do you think we should retain the ETH ERC20 feature? Do you think we should drop it? Please give reasoning for your answer.

[transmissions11]

A RESOUNDING YES

Devs want to use WETH because it's safer. Sending ETH is dangerous because the recipient can reenter, and revert which causes all sorts of security and DoS issues.

But if you use WETH you force users to wrap and unwrap which is a massive pain.

The pain of having to wrap and approve WETH is even worse on a rollup where execution is cheap, and calldata is expensive.

Hence, native ETH also being WETH lets devs get the best of all worlds: security, good UX, and cheap txs!

[rajivpo]

Yes to all the points above, but especially from the UX side. I think the UX gain of not having to wrap/unwrap and/or deal with approvals from an end-user perspective is understated as it reduces substantial friction.

It might be biased, but one of the frustrations new people onboarding have expressed to me is having to deal with wrapping/unwrapping ETH/WETH and approvals. While some frustration comes from a lack of understanding as to why those steps are necessary, I think removing frictions around ETH specifically will provide a substantially better (simpler/more intuitive and cheaper) user experience, especially for those who are starting to interact with dapps for the first time.

[platocrat]

As much as this comment my seem like I'm trolling at first, I am trying to play devil's advocate so that we don't fall into a trap of groupthink.

---

A RESOUNDING NO

Devs want to use WETH because it's safer. Sending ETH is dangerous because the recipient can reenter, and revert which causes all sorts of security and DoS issues.

Devs want to use ETH because it's less of a headache for their users! ETH as an ERC-20 has come with minimal UX gain, if any at all. Instead, the net effect of ETH as an ERC-20 has been a significant decrease in an easy onboarding experience.

But if you use WETH you force users to wrap and unwrap which is a massive pain.

This is a familiar pain, so I think you're overexaggerating how much of a pain point WETH is.
On the contrary, since WETH has been broadly used across the L1 ecosystem, most users are already accustomed to using WETH. Introducing ETH as an ERC-20 on OE is a new experience for everyone and has come with several hiccups along the way:

1. L2 ETH is not the default ETH address provided by Metamask when you add the Optimism network
2. Self-transfers on OE from an ETH address other than the L2 ETH (as an ERC-20) address result in "bricking" your account.
3. Having to keep track of another L2 address, like ETH as an ERC-20, is just another thing that users DO NOT want to think about.

The goal of all L2s should be 1:1 EVM compatibility primarily because THAT IS WHAT MOST USERS ARE USED TO.

Attempting to nudge users behavior while they're also trying to focus on getting familiar with L2 apps, not trying to learn how to use an L2 sounds like we're trying to have users focus on two different parts of the L2 experience at once.

The pain of having to wrap and approve WETH is even worse on a rollup where execution is cheap, and calldata is expensive.

Users care most about accessing new opportunities on L2. They could care less about whether execution or calldata is more expensive.

Users want a brain-dead easy experience where they can explore L2 apps with minimal technical hiccups along the way.

---

hint:

• The answer to this question can be found by talking to your users

[transmissions11]

Devs want to use ETH because it's less of a headache for their users!

I said that. But as I also said it comes with security tradeoffs. Hence allowing ETH as an ERC20 lets them everyone to get the best of both worlds: security and UX.

ETH as an ERC-20 has come with minimal UX gain, if any at all. Instead, the net effect of ETH as an ERC-20 has been a significant decrease in an easy onboarding experience.

How?

On the contrary, since WETH has been broadly used across the L1 ecosystem, most users are already accustomed to using WETH.

Sure people can understand WETH, but it's a pain to have both ETH and WETH in your wallet. And if you need to pay gas you need to unwrap, etc. People can get adjusted to bad UX, that doesn't mean we should get complacent.

L2 ETH is not the default ETH address provided by Metamask when you add the Optimism network

What does this mean?

Self-transfers on OE from an ETH address other than the L2 ETH (as an ERC-20) address result in "bricking" your account.

What?

Having to keep track of another L2 address, like ETH as an ERC-20, is just another thing that users DO NOT want to think about.

But they don't? RPC calls for account balance and stuff now return your proper ETH balance. You don't need to add ETH as an ERC20 to your wallet.

Users care most about accessing new opportunities on L2. They could care less about whether execution or calldata is more expensive.

Uhh yes they certainly do care when their transactions are expensive?

Users want a brain-dead easy experience where they can explore L2 apps with minimal technical hiccups along the way.

This can still be provided with ETH as an ERC20. All the issues you listed sound like early hiccups? At least from my experience using OE I've never had to think about ETH being an ERC20, shit just works. Again, keeping ETH as an ERC20 improves UX because they don't have to think about WETH— UX would actually degrade otherwise.

[smartcontracts]

Current sentiment seems to be leaning towards disabling this feature for the moment and continuing this discussion during the months leading up to system upgrade after this next one. Once we introduce this feature it will be very hard to turn it off, so we need to be 100% certain that this is a good idea. That said, we will leave this discussion page up so that people can give feedback + make arguments that can inform this decision in the meantime.

[smartcontracts]

ERC20 features would be disabled by this PR: #1450

[maurelian]

That said, we will leave this discussion page up so that people can give feedback + make arguments that can inform this decision in the meantime.

I marked this as the answer to prevent confusion from people who think it's still open.
IMO we can revisit this or create a new discussion when the time comes.

[C0deMunk33]

I say yes based on the utility of WETH.

WETH has proven itself useful in 2 ways:

1. it offers a workaround for Eth's native security vulnerabilities (reentry attacks and gas stipends)
2. it simplifies the coding of asset-agnostic smart contracts as the dev doesn't have to support the special-case that is ETH

[jaglinux-eth]

Curious, what happens to payable fallback function for weth? (assuming folks still use payable fallback function in contracts)

[smartcontracts]

The fallback function would not be triggered when sending via ERC20 transfer functions. It would still be triggered if you sent ETH normally via addr.send(...) or addr.transfer(...)

[C0deMunk33]

not relying on the fallback (and possible stipend snafu) is a benefit of the erc20 wrapper IMO.

[transmissions11]

oh ye definitely pls do not have it trigger fallback on ERC20 transfer

[platocrat]

@smartcontracts @transmissions11 @rajivpo just read this thread that these two users, YYY and KEMIO, had last night and feel their pain as users having to use ETH as an ERC20:
https://discord.com/channels/667044843901681675/667044844366987296/887249410235465779

[platocrat]

do you think they care that ETH is an ERC-20?

[jaglinux-eth]

@platocrat my understanding is that both the mechanism (using eth or weth) will be available for users to chose. Is it not the case ?

[platocrat]

hi @jaglinux-eth, from my understanding, no. It is only either/or, which is why I'm trying to defend the case of using regular ETH in this discussion 🙂.

However, since you brought it up, I think giving users the option to choose whether or not they want to use ETH or WETH is an interesting idea.

wdyt @smartcontracts @transmissions11? Is this feasible?

[smartcontracts]

@platocrat in this scheme you would be able to interact with ETH regularly as well as interacting with it as an ERC20. You would have the option to choose whichever one you want.

[smartcontracts]

General reminder that under this scheme you would be able to choose which way you want to interact with ETH. You could still use the standard methods like msg.value, addr.send(...) etc OR you could use ETH as an ERC20 token.

[platocrat]

If users are given the option to choose, then I think we're good fam 😌

[jaglinux-eth]

Ha ha, my question related to fallback function was also related to the same. I thought if we are gonna disable regular eth transfer then how will we support fallback function.

[novam77]

when everyone has their own choice, this is one of the important things that should not disappear

[aloisklink]

No, due to infinite approves on unsafe contracts

No idea if this topic is still on the table, especially with the new EVM equivalence update to Optimism (which is super cool btw, props to all the smart engineers who worked on that), but I just saw this tweet from DC Investor (famous NFT guy on Twitter) on why they like to keep WETH separate to ETH.

Essentially, it's because of infinite approve-ing WETH on potentially risky contracts. NFT folks are often also less technical than DeFi folks and programmers, so they're at a higher risk of doing infinite approves.

Hopefully, it'd be less of an issue on Optimism with lower gas costs, but all it takes is one badly written Dapp that ask for infinite approve, and I'm sure at least some users won't bother going on Metamask and manually reducing the infinite approve.

https://twitter.com/iamDCinvestor/status/1446958378715123716

Edit: Added screenshot of tweet in case tweet gets deleted or for privacy-conscious folk that don't use twitter

[smartcontracts]

This is a very good point that I hadn't previously considered. Thank you for the input here!

[belikji]

not an obvious moment, thanks for the input