Token names in the Sovryn UI

There was some debate on a call recently about how tokens should be named in the token interface. I want to continue the conversation here so that we might come to consensus about this. Also continuing the discussion in the forum provides the opportunity for input from other community members and Sovryn users who might have opinions or insights about this.

On one side of the debate there are folks who think that the token names should be abstracted so that users just see an asset they are familiar with. For example, RBTC would become BTC and USDT would become USD. There is some precedent for this kind of abstraction, although not in the exact way mentioned here. dydx is a derivatives trading platform on Ethereum that uses BTC and USD in their trading interface:

Screenshot_2021-04-07 dYdX

However what is different about dydx is that the BTC and USD being traded are not tokens, they are derivatives backed by USDC collateral, which is specified in their FAQ:

Screenshot_2021-04-07 dYdX(1)

On the other side of this debate are those (including myself) who argue that because Sovryn users are actually trading specific tokens, those tokens should be clearly identified in the user interface so that users don’t end up holding a token that they do not want. One example of a trading platform that comes close to following the UI pattern I advocate for is Uniswap, which shows the exact token name when users are selecting the tokens they want to trade:

Screenshot_2021-04-07 Uniswap Interface(1)

While Uniswap does not show the contract address in the UI, they do offer the ability for users to paste in a contract address so users can be sure they’re getting the exact token they want. I should note that this is how virtually all DEXes that trade multiple tokens show the token names. This is also what users expect, according to a (admittedly low sample size) poll I ran on Mastodon and Twitter. It would be my preference that in the Sovryn dropdown menu where users select what tokens to trade/lend/borrow they see the token name and contract address, so they can be sure right away that they are selecting the right token and don’t end up holding something they don’t want.

I am not in principle opposed to the abstraction method, where RBTC is shown as simply BTC in the UI, as long as there is some visual indicator of which BTC-pegged token is being abstracted. However, I do note that regardless of how the token name is abstracted a challenge arises when there are multiple pegged tokens being traded in the system that represent the same asset. For example, today Sovryn lists USDT and DOC, both dollar-pegged stablecoins. Under token abstraction, would these both be shown as USD in the UI? Even with visual indicators of the underlying token, I can imagine users easily getting confused about which is which if we don’t spell it out for them like “USD (USDT - 0xef213441a85df4d7acbdae0cf78004e1e486bb96)” and “USD (DOC - 0xe700691da7b9851f2f35f8b8182c69c53ccad9db)”. In the future, there may be multiple BTC-pegged tokens listed as well, RBTC and SovBTC. And there could be more such like-pegged tokens coming.

What do others think of this? Do you prefer abstracting the token names in some way? Do you prefer the more detailed way of showing token names? Do you have some other ideas for how tokens should be displayed in the Sovryn interface?

I’ll close by sharing some relevant tweets and a link to the Chain Agnostic standards repo which is attempting to standardize token addressing and naming in our brave new world of pegged tokens and multichain bridges.

https://twitter.com/MyCrypto/status/1369402543625932803

https://twitter.com/iang_fc/status/1369655614964645890

https://github.com/ChainAgnostic/CAIPs

2 Likes

mine as well - emphasis on

token name and contract address

6 Likes

From a community management perspective, clearly labeling RBTC and RUSDT (maybe RUSD?) would clear up confusion among new users. I have lost count how many times a user thinks they can use BTC or USDT(eth) in Sovryn, and each user needs the explanation of being on RSK/needing RBTC etc etc.

From a general POV, using just BTC can make sense and would be ideal since it IS bitcoin, just on RSK. It would follow the decentralised BTC platform… defi for BTC etc theme.
Using just BTC with the rsk logo as currently in the dapp works just fine, but for all others like USDT it would make sense to properly label them as RSK tokens → RUSDT.

4 Likes

This issue has confused me on quite a few occasions so there needs to be something done about it.
I agree with having a more detailed description, with a simple way to see the actual contract address. In my thinking rBTC if it’s pegged in BTC. rUSDT if it’s USDT on RSK etc. DOC is native to RSK so should have no prefix.
Easy access to a single table which shows all the mappings should be available somewhere.

Another issue regarding the user interface is that I believe that having a pool described as DOC or USDT on the market making tab does not give enough information. Here is a link to where the drop down describing the pool exists is Sovryn

I feel that the pool drop down should display DOC/rBTC And rUSDT/rBTC etc.

I agree with light. I believe that the token names should be differentiated.
i.e. rBTC, rUSDT

  1. The UI should provide clarity and minimize the probability of confusion. rBTC makes it clear, there is no confusion. There are already enough new nuances for the future userbase to learn and understand. Too many quirks will create confusion, anxiety and mistrust.
  2. The FastBTC functionality means that many users will be converting from BTC to rBTC. To utilize BTC for both makes all these transactions unnecessarily confusing when looking at the transaction details.
  3. I would presume that other platforms and wallets will be utilizing rBTC, so consistency across platforms, while not mandatory, is better.

Just my two sats.

2 Likes

Replied here, since it’s a separate topic :slight_smile:

1 Like

I agree with light.
Tokens should be called by their original name and by their identity (address) for the most technical.
New users get confused if they see BTC or USDT, but if they see rUSDT or rBTC they investigate or at least ask before making mistakes. Imagine explaining the same thing over and over again when mass adoption hits.
It is a good standard that allows all future token integrations and also maintains cross-platform naming convention.

4 Likes

I also think that every token must be displayed with its full name and details to minimize confusion, mostly on new users that are not familiar with abstractions. We should aim to simplify things, but not at the expense of creating confusion for newcomers.

1 Like

I’d also be in favor of displaying real/correct names, like rBTC along contract address.

We have way too much (not that much, but still) users who are not used to RSK, MetaMask, correct gas settings, and so on.

Further confusing with “non-standard” naming for the sake of “meaning the right thing” isn’t the way to go. (Like we call it BTC, but users need rBTC).

Lets call/display it the most exact/standard way possible.
It will help on support questions, users are enabled to simple research eg “MetaMask rBTC”, and will keep errors as minimal as possible.

3 Likes

I believe that clearly identifying each token would definitely improve user experience for the less advanced users, otherwise there might be confusion and worry.

1 Like

I agree the name and contract address should be shown clearly.

And i can understand why the confusion rises, this confusion rises in many users mainly at two events i.e; Deposits and Withdrawals.

So a simple solution would be to do a small UI improvement, not like giving false names to assets but like to improve the logic and to ease the thought flow of the users.

The change i propose is : To remove the bridge tab and integrate it to Wallet Balance page a.k.a, My Portfolio page a.k.a, My Wallet etc.

Details

Here we already have deposit, withdraw, trade and some other important buttons.

So when the user click the withdraw button, i suggest to show an window asking the users if they wanted to withdraw to the same chain or different chain or, simply a drop down to choose the chain or any variations of these simple logic to ease the thought flow and, in the same window or in the next page or below the area to choose the chain they can choose the amount and gas and then the user can continue with their normal lifes.

When the user finish choosing the chain, it would be better to show an estimated time to complete the transaction and then the user can click withdraw. A prompt will show up in their wallet as usual to confirm the transaction.

Same for deposit.

Simple life.

  • Yes.
  • No.

0 voters

1 Like