Consider using the same token names between networks

[dafacto]

Currently, the bridge, and perhaps the wallet, display ERC-20 tokens as the Ethereum name, prefixed with an "n", e.g. "nALCX". This exposes in the UI the underlying mechanics of what's happening, i.e. that the token they are using on NEAR is a different token than what they had on Ethereum.

An alternative, currently in use by BSC and Terra, would be to use the original name of the token, e.g. just "ALCX". This has some benefits:

• We hide the underlying mechanics from the user, and reinforce that "transferring" across the bridge is actually "moving" their tokens.
• Interacting on NEAR has some familiarity (they're using the same tokens they are used to).
• The UI of the Rainbow Bridge could be simplified, dropping the "Received as" row.

[heycorwin]

My biggest hesitation here is that the bridge isn't the only place where these tokens will appear. They will appear in wallet, exchanges, etc... many places we don't control. It's also pretty standard for things like wrapped tokens to be denoted with a prepended character (eg wETH, xDAI, etc.) Without a way to indicate a token that has been bridged, it's too easy to mistake a bridged token with the original. This could result in missteps like sending tokens to invalid addresses. I think if we are going to denote a bridged token via it's namespace in one place, we should do it across the board. I know @chadoh and @potatodepaulo have done quite a bit of thinking around this, I would love for them and others with opinions about this to weigh in here.

cc @djsatok

[chadoh]

Maybe in a future where bridges are more-or-less instantaneous and there is reliable across-the-ecosystem support for sending from a NEAR account to an Ethereum address transparently, it would make sense to me to drop the prefix. But that doesn't seem like the world we live in now.

For now, I think it's important to train people that nDAI is a separate currency from DAI, but they are 1:1 exchangeable with each other. You can send nDAI around freely within one blockchain, but when you want to send it to the other, you need to convert it to DAI first.

[dafacto]

If I had to guess what the world will look like in a few years, I would imagine that we—as end users—will just be interacting with apps, unaware if they live on Ethereum, BSC, NEAR, etc. The blockchain will ideally, to end users, be analogous to TCP/IP. (Emphasis on the end-user here; not developers.)

In that world, as they hop from app to app, USDT will just be USDT. It would feel confusing to land on an app and see nUSDT.

We seem to be heading towards that world. When I interact with Terra and BSC, I just see UST, USDC, DAI, MIR, etc. It’s only if/when I see a transaction report on Etherscan or BSCScan that I see it’s “wrapped MIR” or “B-pegged USDT”.

Exchanges are moving in this direction, too. At Binance, you just trade USDT. And when you send USDT out (same with NEXO), you send USDT and choose the network. The name of the token on BSC, Binance Chain, etc. is hidden from the user, and between networks, bridges handle the conversions transparently (the Terra bridge is a good example.)

[heycorwin]

And when you send USDT out (same with NEXO), you send USDT and choose the network.

I think this is key here. This is a great user experience, but is unique in this scenario considering that when you send from an exchange, you may have numerous wallets from various chains with balances tied to your account. The risk still remains for users of dedicated wallets that if they see DAI in their NEAR wallet, might think it's ok to send it to an Ethereum address, when in fact the DAI that lives in the NEAR wallet is actually nDAI (an NEP141 and not an ERC20) and will be lost if they attempt this.

I agree that in the future, all of this will likely be abstracted. For this to happen though, multicoin wallets will need to be more common. The tricky part is displaying these tokens in non-multicoin wallets/exchanges (like the NEAR wallet or most Ethereum wallets)

[dafacto]

The scenario that a user loses their tokens by accidentally sending to a different network is not one I had considered, and I agree it’s important. As far as I can tell, that would be the only reason to backtrack from the direction I was taking in terms of displaying DAI rather than nDAI. (Can you think of others?) The following is more just thinking out loud than arguing for one approach or the other (although, having written them, I see they seem to support the direction I’d like to take. Unsure how much of that is bias! Feel free to push back of course! ;-) - What would be reasoning process of someone holding nDAI in their NEAR wallet, when wanting to send to Ethereum? Would it fundamentally be something like, “I see nDAI in my NEAR wallet, and so I know that’s something different than DAI on Ethereum. Seeing different token names, I’ve learned that that reflects the underlying technology, in that my DAI on NEAR is not the same as my DAI on Ethereum, and therefore I need to bridge this token, rather than send it from the wallet?” - In our own decision process here, how much should we weigh the tendencies of networks such as BSC and Terra, in which they have taken the decision to display unified token names? - Ultimately, protection of sending to the wrong network should be the responsibility of the wallet. For example, in the Terra wallet, I just tried to send UST on Ethereum to an Ethereum address on the Terra network, and the wallet alerted me to the incompatibility. In MetaMask, connected to BSC, I tried to send BNB to an Ethereum address, and same thing—the wallet alerted me to the incompatibility. If it were possible, the ideal solution might be to: 1. Use unified names for tokens in the UIs of our products. 2. Include in our specifications to wallet developers, that the wallet should protect against sending NEAR/EVM tokens to incompatible networks. Thoughts?

…

On Apr 8, 2021, at 6:30 PM, Corwin Harrell ***@***.***> wrote: And when you send USDT out (same with NEXO), you send USDT and choose the network. I think this is key here. This is a great user experience, but is unique in this scenario considering that when you send from an exchange, you may have numerous wallets from various chains with balances tied to your account. The risk still remains for users of dedicated wallets that if they see DAI in their NEAR wallet, might think it's ok to send it to an Ethereum address, when in fact the DAI that lives in the NEAR wallet is actually nDAI (an NEP141 and not an ERC20) and will be lost if they attempt this. I agree that in the future, all of this will likely be abstracted. For this to happen though, multicoin wallets will need to be more common. The tricky part is displaying these tokens in non-multicoin wallets/exchanges (like the NEAR wallet or most Ethereum wallets) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#163 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJO3QQDK6HGUGGLVD7HAG5DTHXK2ZANCNFSM42CCPAIQ>.

[heycorwin]

@dafacto the recent bridging of NEAR to ETH reminded me to chime back in on this convo.

In summary, I'm in total agreement with you on just about everything. What you are championing here is an ideal UX, where on the surface, there is no discernable difference between ETH on NEAR and ETH on Ethereum for example, and where the risk of sending "non-native" ETH (nETH) directly to an Ethereum wallet is addressed by errors surfaced in the wallet itself.

Ultimately, protection of sending to the wrong network should be the responsibility of the wallet. For example, in the Terra wallet, I just tried to send UST on Ethereum to an Ethereum address on the Terra network, and the wallet alerted me to the incompatibility. In MetaMask, connected to BSC, I tried to send BNB to an Ethereum address, and same thing—the wallet alerted me to the incompatibility.

While I certainly hope to attain this ideal UX, my concern is this:

• This solution depends on all participating wallets to agree on and implement a standard approach to handling the scenario where a user may attempt to send what appears to be ETH from their NEAR wallet to their Ethereum wallet. Are we confident enough at this point in time that participating wallets will prioritize this?

• If not, is it better to assume the responsibility ourselves and to label non-native tokens in such a way that the user is able to distinguish between them in order to avoid the risk outlined above?

It's hard to measure how big of a risk this actually is without facilitating some testing around it or until someone makes the mistake for the first time and validates our concern. My arguments against are purely motivated by wanting to err on the side of caution to avoid the disaster scenario of lost funds than they are arguments against the ideal UX that you've laid out.