The cryptocurrency industry has seen rapid development in recent years and its application scenarios are expanding and gaining more public attention. However, decentralized wallets, which are a key means of interacting with the blockchain world, still present a high learning curve and usage barrier for the general public.
Unfamiliar technical terminology, a unique method for storing private keys, and the frequent occurrence of loss, theft, and fraudulent events has discouraged or intimidated people from engaging with it.
Moreover, user experience processes based on technical implementation have also imposed a significant learning curve on users. Therefore, helping the general public overcome these obstacles and building a user-friendly decentralized wallet experience has become the vision of imToken and many other industry players.
In the process of exploring the next generation of wallet experiences, imToken has started with user research, market segmentation, and user profiling. Beginning with user needs and pain points, we have constructed an information architecture based on usage scenarios and task priorities. The primary focus has been on novice users and newcomers, while also addressing the needs of expert users for decentralization, high security, and censorship resistance.
During the exploration of user experience optimization solutions, imToken has continually summarized corresponding design strategies. For example:
- Onboarding: Onboarding is to assist users in understanding the new product model, product value, and exploring cryptocurrency. Creating an account and backing up private keys are not the final step. The exploration process without backup or even without an account is also the process of building trust in the product and closing the knowledge gap.
- Token-Centric Information Model: Establishing an information model centered around tokens provides users with a comprehensive understanding when interacting with tokens.
- Segmenting Asset Viewing and In-Depth Analysis: Segmenting the scenarios of daily asset viewing and periodic in-depth analysis, imToken uses smart asset analysis to integrate professional insights into specific scenarios. This makes it easier for users to make decisions by providing effective information to different user types.
- Private Key Backup: Given the high threshold of private key backup, imToken is actively exploring biometric authentication, personal cloud backups, encrypted file backups, MPC, and smart contract-based backup methods. Each backup method comes with its advantages and challenges, and striking a balance between security, convenience, decentralization, and meeting the needs of different users is a critical consideration.
imToken will continue to explore the next generation of wallet products and collaborate with industry leaders to collectively optimize the user experiences of decentralized wallets.
Three Main Components of Wallets
Next, I’d like to share with you the product framework imToken has developed for next-generation Web3 wallets. I'll cover the issues that the current wallets are trying to solve, existing approaches, and their problems. Lastly, I'll share with you some future approaches that we have in mind.
I have 3.0 ETH and would like to stake the asset to earn profit
It actually covers three main components of a wallet.
Firstly, the ownership control, which represents who owns the crypto assets and how to easily and securely verify ownership and allow the owner to authorize assets when necessary.
Next, we also need to solve the account and token access issues, determining the type of assets the owner has and displaying the information in an organized manner to provide insights to the users.
Lastly, the user will need to use the assets to engage in some blockchain use cases, so we would like to understand the objectives the user has in mind and help them achieve them.
Let's look at how the current wallets are addressing these three components.
At the bottom, we have an ownership control module (also known as key management service) that uses the EOA structure with one pair of private and public keys to manage ownership. For wallets like imToken that manage multi-chain tokens, we use the HD structure, allowing users to use one pair of keys to manage wallets on different chains.
However, the assets are still managed separately on each chain, and when users try to engage in on-chain use cases, those experiences are inconsistent across chains. This approach has two main problems: firstly, we use only one pair of keys to manage the wallet, which is a new concept for Web2 users and introduces a steep learning curve. Additionally, this single pair of keys creates a single point of failure with very low fault tolerance.
At the top, assets are managed on individual chains, leading to different experiences for users across chains and restricted liquidity sharing. To address this, we propose the following future approach.
At the bottom, we are going to replace the EOA structure with a more generic ownership control module, which I will discuss later. The benefits of this include introducing more devices and accounts, allowing for risk to be spread across multiple accounts and devices, and making it more user-friendly by leveraging Web2 tools. At the top, we will introduce the idea of a universal account, which aims to provide a chain-agnostic experience to users. This includes multiple components, such as a universal identity portfolio and use case abstractions, which I will discuss later.
This is a side-by-side comparison of the two approaches, providing insights into the differences.
MPC TSS and AA
There are two popular approaches currently in the community: MPC TSS and AA. For MPC TSS, instead of using one key or pair of keys to manage ownership, the ownership is split into different pieces called shares. To claim ownership and sign transactions, the user may need to present multiple shares at the same time. While the concept seems straightforward, there are many more product implementation parameters to consider, such as the number of shares to generate and the relevant threshold setup.
A common approach is the 2-2 approach, where two shares are generated and users must present both at the same time to utilize assets. This is easy to understand but lacks redundancy, meaning if a user loses one share, they cannot recover their wallet.
To address this, some teams use the 2-3 approach, with three shares total and any two can be presented to claim ownership. This adds redundancy but increases complexity and requires user education. Theoretically, any M or N number can be chosen for flexibility, but managing more shares incurs overhead. Another key parameter is the shared storage solution. After deciding the shares and the threshold, where are you going to store the shares?
A simple answer is to store it with a platform operator such as imToken. So as a wallet operator, we are typically more professional in managing this critical information and therefore can provide a more secure service and users wouldn't have to worry about any other tasks.
However, there are platform dependencies with operators and migrating wallets across platforms lacks interoperability. Engaging with social logins is a good choice for Web2-like experiences and user-friendliness, but relying on centralized Web2 services may not be comfortable for Web3 users.
Other options include storing on hardware wallets and using social recoveries, which have minimal dependencies on centralized services. However, these concepts are complex to explain and to educate users, and social recoveries also have barriers due to the need for widespread blockchain adoption.
Overall, the situation becomes complex as there is a mix and match of different parameters, and businesses may need to consider the best combinations to suit their needs.
imToken is actively exploring different combinations to find the most optimal approach for our business context and target customers. Another approach is the AA wallet, where all wallet logic is written on chain within a smart contract, specifically ERC-4337. The benefits include a programmable ownership control module written on chain, allowing for the introduction of devices, web2 accounts, and more complex logics such as rules, thresholds, and weights design.
Additionally, more programmable use cases can be built, including having someone else authorize transactions or pay gas fees, and social recovery on chain, among other possibilities.
The question here is not about the powerfulness of AA. It's actually more about how we strategize our product to find out the killer features for our business. And therefore imToken is also exploring this approach.
Let’s take a side by side comparison between MPC TSS and AA. MPC has a flexible setup for different business contexts with most of the things happening off chain, resulting in low cost and multi-chain support due to inheriting the HD structure from EOA.
However, teaching users about multiple shares and redundancies can be complex, and each device and account must engage in signing abilities, limiting the types of servers and devices that can be used.
AA is powerful and can support many use cases, with high transparency in implementation logic and minimal dependence on off-chain infrastructure. However, there is additional cost to wallet users due to information being stored on-chain, and compatibility challenges arise when it comes to multi-chain support since each chain may implement AA differently.
There is no one-size-fits-all solution, as it depends on the use case being served. Changwu, our chief scientist, has proposed combining MPC and AA to maximize their benefits. This is also one of the directions that we are exploring.
Universal Account
The next concept is universal account, which includes universal identity, universal portfolio, and use case abstraction.
For identity, people want to use ENS, a more readable domain name, to manage wallet addresses. We plan to expand ENS capabilities by introducing different formats, such as prefixes, to manage multichain wallet addresses and Web2 identities. However, the cost of ENS domains on mainnet, currently around $5-600 per year, is too high for most users.
We are considering using the secure off-chain data retrieval EIP, where platform operators like imToken purchase a main domain, such as .imToken on ENS, and allow users to register subdomains under it. If it's Alice, she will be assigned the subdomain alice.imToken, and everything else will follow the same format.
This structure benefits both the platform operator and users, as the cost is constant for the operator regardless of the number of users and users pay nothing. We hope to use this structure to scale our products and serve our customers better.
Additionally, people want to see their universal portfolios across all their wallets, but currently asset information is stored at the chain level and is most accurate there.
We can manipulate the information at the display layer. On the right-hand side, the individual, when users choose an individual wallet view, we can present that information at the information layer. On the left-hand side, if people want to see the universal portfolio view, we can aggregate the information by token assets, so they don't have to worry about which wallet is holding the assets.
We are thinking of keeping both views and allowing users to switch between them because they have different benefits. The benefits of a universal portfolio are straightforward and work well with portfolio analytics. For the individual wallet view, experienced users may prefer it because it presents information more accurately, allowing for more accurate actions. The display layer not only presents information but also affects user interactions.
Performing actions at an individual wallet view results in use cases that are specific to that wallet. For a universal portfolio, a new way of interacting with users is needed to focus on the use case rather than execution details. This is called use case abstraction. For example, Alice is using her universal account .alice.imToken to transfer 2 ETH to Bob, who specifies his mainnet address to receive the funds.
The question is how Alice can transfer the money to Bob. There are many ways to do this, and our idea is to introduce the imToken transaction routing module, which presents only the most necessary and critical information to the user for decision-making, while handling the rest of the execution. The user can choose from typical options such as fastest or cheapest in terms of cost, or customized logic, such as paying with BTC first. Each option has details on how the assets will be executed at the bottom.
But as a user you don't have to worry about it. You can just choose the option that is most appealing to you based on your priority and your deciding criteria. And we will handle the rest of the execution for you.
Bob may not want to worry about the receiver address for this transaction, so if he chooses to use the universal account to receive the funds, the situation becomes more complex. However, the logic remains the same. Our transaction routing module is going to find out the best transaction in terms of different criterias and present it to both parties so that they can make a selection.
We are doing this because most wallet features today focus a lot on executions, helping users complete tasks. However, users today face difficulties in making decisions because they need someone to facilitate them and also present them with insightful information.
We want to delve deeper into the needs of the user and ultimately understand the key rationale behind their actions. For instance, when staking, the primary goal is to find a way to generate investment profits based on one's wealth and risk tolerance. By shielding users from the details and hassles of the execution, we can better strategize our product to fulfill their deeper needs.
The wallet framework, ownership control model, and universal account model that I have shared are the direction that imToken is exploring. The wallet is the entry point for users to the Web3 world, and we look forward to participating in this revolution and bringing a more user-friendly product experience to users.