UX possible upgrade (ASTR CONVERTER section) to convert ASTR EVM/NATIVE|NATIVE/EVM

General
1

Hi all guys, I created this post to discuss and get your opinions on a possible addition to the ASTAR portal to make easy and more clear one of the actions that every user has found themselves doing:
changing the token version from NATIVE to EVM and vice versa.

I decided to start this discussion because I see that one of the first questions and doubts of a new user when he enters the in Astar community groups (I speak for the feedbacks of the Italian side) is precisely: HOW CAN I CHANGE MY ASTR FROM NATIVE TO EVM (or EVM to Native)?

I think the operation itself is very easy though. I also believe that the way the portal is set up today is not exactly intuitive and requires that a user must first inform themselves via telegram / discord channels to discover the steps of this conversion and WHERE he has to go in the portal for this action.

Given this, my idea was to add an |ASTR CONVERTER| section (or other better name to be defined) where the user can access and convert their $astr easily and with the certainty of being in the right section to do this step.
I made a draft to better understand what I’m talking about, obviously leave aside the graphics which should be made suitable for the portal but mine is just a conceptual example graphics.

I believe that with the future prospect of an increase in new users (noob users), we must make the portal increasingly easier and more intuitive, making the most important operations clearly visible and immediate.
The mechanics are still the same, the procedure would remain the same as the current one we have now in the portal, but laid out and made more visible and clear for a NON EXPERT users.

Thanks for your attention and let me know what you think, if it seems like a good idea or useless :slight_smile:

This is the conceptual graphics:

1 PORTAL HOME with the ASTAR CONVERTER SECTION:

Home 1
Home 11570Ă—774 66.2 KB

2 ASTR CONVERTER page:

Converter 1
Converter 11574Ă—762 46.6 KB

3 Done pop up

Done
Done1562Ă—764 37.9 KB

3 Likes
2

I find this approach to onboarding new users very interesting. However, I believe there are some technical limitations that might make it challenging, as logging into an EVM wallet is necessary to receive EVM tokens.

For your suggestion to work, users would likely need to log into two wallets—Substrate and EVM—initially, which makes the process a bit less intuitive than intended.

I’m not sure how much development effort would be required to unify this operation on the frontend, but I fully support the discussion around identifying simpler ways—if any exist—to convert native tokens to EVM. This is indeed a pain point for the community.

This article by Hoon explains some technical aspects involved in the operation of Substrate and EVM.

Thanks for starting this topic.

1 Like
3

Thank you very much @pitcoin777 for your feedback :slightly_smiling_face: I will read the article that you sent for sure :heart:
What I had in mind would not need technological adjustments because I believe that it would currently require too many complications and difficulties in having to connect both the Native wallet and the EVM.
The solution I would like to discuss here instead was exactly just a UX addition, without having to change anything to the current state of things on a technical level. I’ll explain better:
My idea was to keep everything as it is now, but just show it in a more immediate way to understand. It would not be necessary to connect both wallets (native + EVM), but only 1 wallet as is currently done. In the backhand the same action would be performed as now when I go to the assets and SEND ASTR from a Native wallet to EVM (or vice versa). The same thing would happen with this new UX, it’s exactly the same thing but shown differently, so as to make the operation I’m doing clearer.
Everything would remain exactly as it is now on a technical level, and the operation would also be the same.

2 Likes
4

Hi Simon,

Thank you for creating a meaningful discussion, Kahori from the formal portal team here.

We had a lot of thinking about this actually nearly 2-3 years ago. How I wanted this instant swap! Firstly, as Pitcoin suggests, it was necessary to connect both Native and EVM accounts to establish a seamless user experience between the Native and EVM accounts in Astar Portal—at least by the standards of portal UX at the time. While there were wallet projects that made these connections, Core team rejected this approach due to the development time and focus required. I recall that a major reason was the significant load on the portal when connecting different VM accounts (even though the portal was already a fairly heavy application).

Additionally, when transferring funds from EVM to Native, the token had to be deposited into the EVM deposit account first, then withdrawn from the Native account. This was a technical blocker that prevented changes to the UX at the time. In the screen you shared is only possible from Native to EVM but not from EVM to Native.

The core team continued development and later introduced the Unified Account. This innovative feature allows linking an EVM account to a new account palette in the Native account, integrating assets within the account. It was launched on the Shibuya testnet last year but was deprioritized in the roadmap due to the simultaneous addition of the MetaMask Snap feature and after assessing the maintenance and load on the portal against the user base likely to adopt and use this feature. As a result, upgrading Astar was removed from the roadmap.

In the past year, the focus has not been on Astar Native or Astar EVM, but it is certain that more dApp Staking participants will want to transfer funds from Native to Astar EVM for future connections to Soneium. However, our current supporters likely have Native accounts and face no issues with transfers, and most new users probably start with an EVM account. Considering this, it seems better to devote time to activities that enhance and promote the ASTR Utility rather than developing new Swap features aimed at attracting new users.

However, we must be able to succinctly answer new users, such as how to transfer ASTR tokens from Binance or other centralized exchanges (CEX) using only the Native network to Astar EVM. Indeed, there is a need to reorganize and tidy up the how-to guides. Not everyone knows that with the Astar Portal, you can transfer by simply entering an EVM address from a Native account—a gap that needs to be addressed. We could add a new entry to the FAQ, place a message in the input field, or create a new video. We will discuss these options with the team. Additionally, MetaMask Snap allows adding a Substrate account to MetaMask with a single button. It may also be worthwhile to market this feature for initial onboarding, as it enables holding a Native account without a dedicated Substrate wallet, although this requires more tests and educational materials.

Apologies for straying from the original suggestion, but I hope you found some insight into how the Portal has evolved today. Thank you so much for making us aware that we have many things to prepare for new users and we promise to do so.

4 Likes
5

Thank you very much for proposing this interesting idea, and I also notice similar issues in the community that a lot of users want to convert them, I have made tutorials but of course, it would be more convinient to have that section. I remember that we have the Astar pass that would bind the native and EVM address, is that something you are thinking about? So users will need to use astar pass to bind them and then technically I think it is possible to do the conversion.

6

I really like the idea of ​​making the process more user-friendly and therefore intuitive. I read about the technical limitations mentioned here on the forum, but I think that giving space to a change to improve the UX, especially for new users, would really be an added value.

1 Like
7

Hi @Kahori. Thank you very much for your response and for taking the time to better explain all the various evolutions and past development proposals that have been designed for this issue.

I understand well the problems relating to a hypothetical combination between EVM and Nativo wallets and all the technical developments that would have to be undertaken and certainly, to date, the issue would be quite difficult and too time-consuming.

What I proposed, however, was a different solution and simpler to implement because it would only be a graphical operation. Let me explain better:
Today, to transform ASTRs from evm to native or vice versa, the operation to do is to go to the assets, and make a transfer from the portal of my ASTRs from native address to evm address. (Let’s leave aside that if I change from EVM to native I will have an additional operation to do later to withdraw the ASTRs in my native wallet, this does not interest us at the moment.)
This simple operation (ASTR transfer between two addresses) allows you to convert ASTR from NATIVE to EVM & vice versa.

What I meant with my post on the forum is exactly the same procedure, but only with a separate section in the portal and with a graphic appearance to make it look like a real version converter. The operation behind the scenes is exactly the same as when we send a transfer from native address to evm (and vice versa), nothing changes on the technical side, but only on the UX side in order to accompany the user and make him have the perception that he is doing an ASTR version conversion.
To date, a new user is unable to understand that to convert the ASTRs he must make a transfer…It would be enough to just show him the same transfer with a different mask, to make everything clearer and easier to understand.

I hope I was able to express what I had in mind.

8

Hi @DrCAO. I’m glad you also noticed the difficulty many users have in understanding this. I also made tutorials for this and they are very useful for new members, but if there was a special section on the portal it would make everything much clearer.

Regarding this, I think that, as @Kahori explained, from a technical point of view there are so many developments to be done and the team certainly has a completely different focus at the moment. But my idea was not to use any ASTAR PASS or something that connects the two wallets, just launch a transfer transaction from one Native/evm address to another, exactly as we are doing now from the portal only with an adhoc section that gives all user the experience perception that he is carrying out the conversion operation. It’s just a graphic addition, without a technical upgrade. Same action as now, different interpretation / UX

9

Thanks, @SimonB ,

I appreciate your input, so let’s delve into what User Experience (UX) really means in this context.

User Experience in Service User Interfaces generally involves guiding users towards clear calls to action that benefit both the provider and the user. This typically leads to actions such as sign-ups, purchases, or “conversions.”

Simply put, the aim is to streamline the user’s options to avoid confusion and enable straightforward navigation.

In the Astar Portal, all asset-related calls to action are centralized on the Asset page. Even though we interact differently with dApp Staking, it remains accessible from the Asset page, ensuring that users only need to visit this page to manage their assets, thereby eliminating the need to navigate elsewhere.

Adding a “Convert” option to the sidebar, as suggested, would indeed change the navigation structure. This would necessitate educating users on which option to use for their needs, potentially complicating their experience rather than simplifying it.

Next, let’s consider the terminology. For the ASTR token, we currently use “Transfer” and “Bridge,” with potential discussions about how XCM should be categorized. The term “Convert” suggests a change in form within the same address, rather than transferring to a different one. This might not immediately clarify the necessary actions for new users, emphasizing the need for a straightforward and user-friendly approach. Moreover, adding “Convert” as an option in the sidebar could lead to confusion rather than benefits, unless there is a very clear and compelling reason to include it.

Lastly, it’s important to note that the Astar Portal is open source. We welcome everyone to contribute and propose enhancements. Additionally, we can make the staging environment available to the community to test and see how proposed changes work in practice. This collaborative approach ensures that our solutions are well-vetted and meet the needs of our diverse user base.

I hope this clarifies my proposal and the considerations it entails.

1 Like
10

Thank you so much Kahori for your detailed and clear explanation! After reading your clarification, I have to say you’re absolutely right: adding a separate section labeled “Converter” could indeed create confusion. As you explained, it’s not really a conversion of the token within the same wallet but rather a transfer between two different wallets. This is a crucial distinction, especially for new users.

I really appreciate all the insights you’ve shared. I believe these discussions are incredibly valuable for continuously improving the portal. I’ll make it a priority to create even more straightforward content and tutorials to help new users navigate the portal with ease. Thank you again for your support and guidance!

1 Like
11

Thank you @SimonB ! Yes you made a good point that we may have something to work on to onboard new users, and I prioritised answering you what is actually possible but we did not enable them due to reasons. We however have things we can do as I have listed, and already working on with G and other team members. Thank you again for valuable discussion. Astar Forum shows the strength of our community!

3 Likes
12

thanks you too @Kahori ! :heart:

13

Back in the days there was an article by Hoon touching the opportunity of unifying public keys across ss58 and evm. I thought I briefly saw something in that regard being built?

In terms of mass adoption “for billions” the goal probably must be, to not require people to work in the machine room to run the machine, but to operate the machine from an abstraction layer, making it enjoyable and easy to use, which almost equals adoption rate increase.

If you are in the supermarket to buy something, would it matter if you took wallet A or wallet B to pay?

Abstracting away cross chain or cross asset functionality from the user is one of the core problems in web3. The question there is, if the average dApp users are “normie” end users with little technical experience, or “advanced” users, with knowledge about token and how they flow, e.g. from native to evm balance or even cross chain.

One of the possible solutions to enable this seemless UX is account abstraction, which enables both unification on the key level as well as removing problems like gas fee sponsoring.

Depending on the strategy, this could make either the native account including a pallet or ink contract the controller of accounts or the evm account. Either way, this would enable UX which integrates into the ecosystem in a seemless fashion.

“the art of simplicity is a puzzle of complexity.”

Marco

1 Like
14

Hi @2075 , thank you very much for your message and your suggestion for a hypothetical solution. I’m not that advanced on a technical level to be able to evaluate your solution but as explained previously by @Kahori I believe that this gap/problem can definitely be resolved in the future. In the immediate future, however, the team is full focus on the various integrations and evolutions for the imminent launch of Soneium L2 and the $ASTR adoption on the Superchain, which certainly requires a great commitment from the entire team that are working day and night. I am sure that one of the main focuses is making Web 3 simpler and more accessible to everyone and they are working precisely in that direction so I am quite confident and sure that on the Astar Network and Soneium side they will aim to make people use Web3 without realizing that they are using the Web 3.