When interfacing with smart contracts it’s even worse. As soon as a user has to do more than one interaction, they’re likely to switch off and stop paying attention to the specifics of what they’re doing.
It’s just like someone agreeing to the terms and conditions of installing software, they’re not interested in the specifics of what’s happening as long as they obtain the end result they’re interested in. They need a simple transaction verification process with very limited information required for them to double-check the proposed transaction.
In addition to all of the above, not only do users have a password to manage their wallet, but also a seed phrase they need to use to recover the wallet.
These multiple layers of complexity illustrate just how high the barriers to entry are for moving into Web3 proper, and until they can all be addressed or abstracted away, we’re unlikely to see the widespread adoption happen that we are all waiting for.
Just like with other parts of the rapidly evolving Web3 ecosystem, there are a lot of companies making leaps and bounds in streamlining user onboarding into Web3 and in certain respects are already solved problems.
The most forward-looking approaches use email address credentials that are tied to a Web3 wallet. Two firms that are leading here include Magic
and Web3 Auth
This email login-based approach presents a familiar interface to regular web users, behind the scenes creating a non-custodial wallet. This makes use of multi-party compute or equivalent techniques. This also has the added benefit of removing seed phrases from the user’s experience.
A downside is that users are still having to log in with usernames and passwords (social authentication mechanisms can also be used), which in itself is inefficient. However, given the majority of internet users are familiar with this approach it’s likely the best approach for a seamless migration until we can tie logins to some decentralised identity or similar.
Returning to the other challenges, such as hexadecimal everywhere. The Ethereum Name Service (ENS) does provide a solution analogous to the Domain Name Service used by websites. The issue is it’s not being embraced fast enough. You can see many proponents on Twitter who add their ENS name to their Twitter profiles which demonstrates just how popular it is. However, we need exchanges and wallet providers to push their users to use them by default.
Every time a user wants to deposit or withdraw funds they should be presented with an ENS address instead of a hexadecimal string. We see QR codes already being used for this purpose, which works well. But we really need these providers of core services to push their users to use ENS. ENS support is very well supported by the Ethereum community, but users are not being pushed to use it by default which is a shortcoming of the current adoption we see in my view.
Preventing funds from going to the wrong address is a harder problem to overcome given the immutable nature of a blockchain ledger, and I cannot envisage a solution that doesn’t involve some sort of middleman. But as human-readable addresses and identities can be tied to wallets this will help simplify the process and reduce the attack surface.
Interacting with smart contracts is also challenging, and there are various standards such as EIP-712
(this facilitates the displaying of structured type information on transactions) that help reduce the obfuscation faced by users when authorising transactions. Simplifying this experience will remain the task of the developers and designers of decentralised applications, but it’s so important that they minimise interactions from a user’s perspective. This will ensure when a user does need to double-check a detail they will have the focus required to do so and not simply be clicking a sequence of dialogues that pop up with unnecessary levels of detail.
Finally, in terms of managing all of the different networks a user needs to interact with. Views of assets across networks should be consolidated so that users have a singular view of all their assets. Networks should be viewed as sub-accounts or similar from the user’s perspective — they know there is a network associated with a source of funds, but it should all be viewed in a single place, with the network only coming into it like a routing code with a bank account, or even better automatically inferred from the ENS name or other network equivalent.
Some wallets are going down this route, but again, we need the most popular platforms to lead by example here.
There are a lot of great minds focused on improving the Web3 user experience, but if we can get the leading platforms and apps to embrace some of these changes, I believe there’ll be a much larger community feeling ready to onboard to Web3.
This will provide the following benefits for users:
- They won’t have to care what underlying network they’re using
- They won’t have to deal with hexadecimal or seed phrases
- Contract interactions are minimal
If you’re interested in learning more about Web3 UX, I encourage you to have a listen to the discussion
I had with Michael Sanders of Horizon Games, who are investing heavily in streamlining Web3 UX for gaming.