Discussions from: AIP-ERC20 interface support for ETH
Previous discussion: ERC20 Interface for ETH · Discussion #325 · aurora-is-near/aurora-engine · GitHub
Awesome improvement. Was always weird how this worked.
1 Like
The original WETH contract system has serious flaws.
However, an existing WETH contract has already been created on Aurora, I believe by Trisolaris.
This WETH is now an integrated component of DeFi on Aurora.
It is used by:
- Trisolaris
- NearPad
- Wannaswap
- Vaporwave
In particular, Vaporwave uses 0xc9bd WETH as a central component of all our yield-optimizing strategies, as well as our central tokenomics for VWAVE and ETH rewards.
If a provided-for wrapped ERC20 contract for ETH is used instead of the existing contract developed and deployed by Trisolaris (which has become defacto WETH), and used by all of Aurora’s current DeFi protocols as the standard WETH, it could cause more than a headache.
Vaporwave’s entire protocol will need to be re-deployed to fit the new WETH contract.
1 Like
@James_Vaporwave got it. This was one of the feedbacks we were expecting tbh. I understand migrating from one WETH address to a different one can be a complex task if not impossible (for non-upgradable contracts). We did something similar in the past when we were discouraging the use of bridged wETH from Ethereum to Aurora/NEAR, in support for bridge native ETH.
I don’t think this initiative has had enough traction to be considered accepted, though I believe this can improve usability for users greatly (avoiding wrap/unwrap txs, plus avoiding the fragmentation of their balance).
In addition, if we were to keep the current status quo, it is important that original deployer of current wETH contract verifies the source code in Aurorascan so it can be auditable.
A raw idea: Replace current wETH contract with the native contract. I can see how some things can go wrong this way if balances are trivially merged, but maybe a good solution exists.
I’m definitely with you on the importance of using clear native tokens. I think one reason that Aurora has been able to grow the way it has is exactly because the Rainbow Bridge tokens have acted as the standard for each asset, thereby avoiding the situation where a plethora of different bridge tokens act as disconnected clones of the original (usdc1 usdc2 usdc3). This situation is a problem on other chains. It’s not only confusing for the user (and the devs!) but leads to comically bad capital efficiency (multiple pools for different USDCs for example).
Also 100% on the current WETH contract needing to be verified and public. Maybe one of the Trisolaris devs can speak on that.
1 Like
Hey a Trisolaris Dev here 
The Weth contract deployed by Trisolaris team is here: Address 0xC9BdeEd33CD01541e1eeD10f90519d2C06Fe3feB | Aurora
Unfortunately the WETH address is hardcoded in our AMM and cannot be replaced without redeploying the all the AMM contracts and performing a migration which will be super painful.
It has not been verified because it was deployed before 19th Oct 2021 and aurorascan does not identify contracts/contract code deployed before that date. So we cannot verify the contract till aurorascan fixes the issue: Contracts - Trisolaris Docs
@marcelo.near how will the raw idea work?
:star: A raw idea: Replace current wETH contract with the native contract. I can see how some things can go wrong this way if balances are trivially merged, but maybe a good solution exists.
2 Likes
how will the raw idea work?
@baboobhaiya I answered long time ago, and I think the answer was lost through forum migrations.
The idea is to upgrade aurora contract in a way, that current address where wETH lives today is used as the precompile address proposed in this AIP. The current contract code is “removed” and instead the address points to the precompile.
This will require merging the balance of ETH and wETH for all users. And exposing a very similar interface to the one that exists today for ERC20 interactions with native Aurora ETH.
This is possible in an upgrade of Aurora, but replacing a living contract is something that devs can’t do on their own, it requires approval from DAO and most importantly community.