ERC20 Interface for ETH

[mfornet]

This is a proposal to create an special contract on Aurora that implements the ERC20 interface, and allows developers and users to interact with their real ETH balance (i.e no wrapping / unwrapping).

Motivation

wETH exists on Ethereum for a practical reason, contract developers implement a consistent interface to interact with all types of tokens, and ETH doesn't has this interface. Hence the wrapping offer this feature, at the cost of creating extra hassle to wrap and unwrap the tokens in certain moments, and add more cognitive load to the end users which should keep track of this difference.

Aurora is a separate environment that requires a bridge to move tokens from Ethereum. We decided to discourage all type of wrapped tokens going through the bridge, given the main functionality is lost, and we can end up with different types of the same token on the Aurora / NEAR side. This means that eventually wETH won't be used anymore on Aurora. But still developers and users will need to have an ERC-20 interface to deal with ETH within Aurora contracts.

Proposal

Create an special contracts that implements the ERC20 interface, but under the hood it manage directly ETH tokens, without requiring users to wrap or unwrap any token. At Aurora we are in a unique position (with respect to Ethereum itself) where we can create such contract, using a new precompile that allows to run code outside of the EVM scope. There is already a protocol upgrade proposal for Ethereum to add support for accessing ETH as an ERC20 [cite needed].

We should create a new precompile that allows sending X ETH from address A to address B, and can only be called by one contract (the one offers this interface). Security is provided on the basis that this contract implements ERC20 interface properly and secure.

Pros

• Remove wrap / unwrap interface
• Remove cognitive load for users to keep track of yet another token (also no need to make distinction between this and wETH on Ethereum)
• Easier for applications to interact with it since there is no need to wrap or unwrap first.
• Native ERC20 support for ETH in Aurora

Cons

• It can take some time to implement (Though conceptually is very straight forward)
• We must get it right from a security point of view. Both design and implementation should be robust to avoid any attack / hack that ends with users loosing money.

Alternative

wETH code can be deployed as well on Aurora (with a different name to avoid confusion with "real wETH" from Ethereum). And use this contract instead.

Pros

• Simple to execute this idea
• Developers/Users are already familiar with this approach (not very big win over previous approach)

Cons

• Wrap / Unwrap is still required as with wETH contract on Ethereum
• We should make a big effort to avoid developers/users getting confused between this token and wETH on Ethereum (they are not the same and should not be bridged)
• Fragment ETH balances into two different places.

[antonpaisov]

👍 for the suggested approach, I think it's the only legit way to go. However, we need to have a clear timeline for the implementation with many projects aiming to go full speed within the next 1-2 months.

As for the wETH:

• We already have it deployed, Trisolaris did it, they use it.
• There's a lot of liquidity among chains in wETH, so some customers are pushing for us to have wETH regardless
• Generally, we can't stop users from using wETH once they're on Aurora, as they can swap to it, for us right now it's a matter of not having it on our bridge

[mfornet]

We already have it deployed, Trisolaris did it, they use it.

Can you share the address of current deployment of wETH on aurora. (Also here is one of the problem happening, I would not to name this contract wETH, since it is different from the one on Ethereum.)

There's a lot of liquidity among chains in wETH, so some customers are pushing for us to have wETH regardless

What is the interest of customers for having wETH on other chains, for example in NEAR where ERC20 interface has no value, since all are NEP-141? On Aurora I may understand the motivation, which is to have ERC20 interface, and it is exactly what I'm trying to address with this proposal.

This is not meant to be an open ended question, but just to understand if there is any extra motivation we are missing here (i.e marketing, habit, other?).

On Nearcon @djsatok proposed to avoid using wrapped token on non native chains (i.e. bridged) and I agree this is a good idea. In the past wETH has only created some confusion, and the big problem is that for trading wETH into ETH on Aurora you need to bridge it back to Ethereum and return again (or trade it in some platform).

Generally, we can't stop users from using wETH once they're on Aurora, as they can swap to it, for us right now it's a matter of not having it on our bridge

Yes, we can only discourage its use, being explicity about pros and cons.

[RomanHiden]

[mfornet]

This is definitely possible, though they should be empty functions right? I expect that balanceOf function will return the exact balance you have in ETH.

[birchmd]

Thanks for writing this up @mfornet ! I also agree that the precompile approach looks the cleanest.

@antonpaisov RE: timeline. If projects are launching in 1 - 2 months, and would want the wETH-like address to test against, does that mean you want this feature rolled out (at least to testnet) in two weeks?