search

near / near-wallet

Web wallet for NEAR Protocol which stores keys in browser's localStorage
https://wallet.near.org
MIT License
214 stars 174 forks source link

Display of ETH token balance in Wallet #2233

Open paouvrard opened 2 years ago

paouvrard commented 2 years ago

Is there a delay in the display of ETH token balance received in NEAR wallet ?

Some users who transferred ETH from Ethereum to NEAR mentioned that their ETH tokens are not displayed in NEAR Wallet. I checked their balance from near cli and their account actually has the tokens. Those users often also didn't have $NEAR in the wallet before receiving ETH tokens (not sure if there can be a link there) and are often accessing from mobile browsers. Example accounts: alex0907.near, strudel.near

stefanopepe commented 2 years ago

How the tokens were transferred? Do you have screenshots or the specific CLI command showing the wETH balance inside a NEAR account?

sept-en commented 2 years ago

@stefanopepe the tokens are being minted to the user account, during the execution of the deposit method (with provided proof as an argument) in aurora contract. And also note that we are talking not about nETH (not wETH).

CLI command to query the balance of nETH for the account:

NEAR_ENV=mainnet near view aurora ft_balance_of '{"account_id" : "alex0907.near"}'

View call: aurora.ft_balance_of({"account_id" : "alex0907.near"})
Log [aurora]: Balance of nETH [alex0907.near]: 2380000000000000000
'2380000000000000000'

P.S. strudel.near most likely has already transferred his tokens to ref.finance. CC @paouvrard

stefanopepe commented 2 years ago

The issue here is to let the wallet know that there's an available balance, under its name, inside the aurora state. This is not too different from other view methods we are using, e.g. staking pools and (stretching a bit) lockup accounts, but requires some additional thinking to avoid parasitic queries to the indexer.

Would you be available to work together on a PR that solves this issue, adding a small "Aurora widget" that can be enabled on demand by the user?

sept-en commented 2 years ago

The issue here is to let the wallet know that there's an available balance, under its name, inside the aurora state.

@stefanopepe Yes, this is correct.

Would you be available to work together on a PR that solves this issue, adding a small "Aurora widget" that can be enabled on demand by the user?

Sure, could you please explain what exactly is required from our side?

stefanopepe commented 2 years ago

Sure, could you please explain what exactly is required from our side?

Taking one step back, I don't really have a clear "external PR machine" in place, so I have to mitigate the risks of adding a feature that is functionally and technically perfect but doesn't work well from a product&strategy standpoint (feature creep). On the other hand, this is an invaluable opportunity to structure and test this "external PR machine" right away. We now have a reliable suite of e2e automated tests, plus very solid QA by @ihaid, so the execution shouldn't be too problematic.

Product-wise, I see these main blockers:

  1. Discuss the UX and customer journey implications with @corwinharrell .
  2. Assess the impact/size/value of this feature on the userbase, to give thumbs up from a product standpoint. In this case, 2 is quite straightforward and aligned with the wallet goals, so it's just a matter of "scoping down" what we need to build.

Once I completed this high-level ack , we move to the engineering side, such that our PR respects the existing frontend and backend architecture, avoiding "antipatterns" in classes and frontend behavior. My main goal is to enable "anyone" to maintain this new part of our codebase, as long as they have familiarity with the overall codebase patterns of the frontend. I'll use this opportunity to think of high-level guidelines, launching a solid CONTRIBUTING.md file, together with your valuable feedback.

Since we don't have "forever", we can increase our velocity on your end, building this feature as a tunnel, "excavating on both ends." So, to answer your initial question, I can see three tasks:

  1. assume that you got the "product ack" and build a set of tests+functions parsing ETH balances, pretty much as you do with near-cli. This would be put in the codebase as a shadow feature
  2. build a shadow page in the wallet, available only via custom route (e.g. wallet.near.org/pr1234) or via custom URL (e.g wallet.pr1234.near.org) from a specific branch, replicating the current dashboard layout, but with the additional ETH balance
  3. Do QA testing, validate UX design and performance, and flip the switch!

Before moving on, I need to rope in @MaximusHaximus for a quick check on my plan above, so as soon as we get his green light we begin!