Dialogue UniPass: How to Open the Door to Web3 for Ordinary Users?

Original Title: “BinaryTalks｜Dialogue with UniPass, Opening the Door to Web3 for Ordinary Users”

This issue is planned by: Kylo (Tw: @kylohanks_eth), BinaryDAO

This issue is hosted by: Jenny Huang (@Jennyhuang727), BinaryDAO This issue's guest: Frank Lou | Founder of UniPass

"The original intention of UniPass is to create a low-threshold, user-friendly Web3 account. When you use it to manage assets, it belongs to the wallet track; when you use it for authorization and authentication, it belongs to the DID track. In my view, these are all one thing."

---- Frank

Jenny: Recently, smart contract wallets have become a hot topic in the market. What kind of narrative is behind this wave of interest? Please explain from the development history of wallets, the classification of wallet tracks, the current issues in the wallet track, or any logic you think is relevant.

Frank: I think the popularity of smart wallets is a superficial phenomenon. If we dig deeper, the reason is actually a shift in narrative focus; everyone is aiming for mass adoption, which requires a lot of users to come in.

Currently, the attraction for new users to enter is clearly insufficient. The prerequisite for users to come in is the need for new scenarios, and these new scenarios require new infrastructure support. When the wealth effect of your scenario is not strong enough, we need to establish some low-threshold infrastructure to attract users. Because the threshold for crypto is already too high, the resistance for users to enter is significant, and if your attraction is insufficient, users will definitely not come in. Smart contract wallets can lower the entry barrier for users to a very low level, making them similar to Web2 account systems.

Additionally, new scenarios have more diverse functional requirements for infrastructure, so user-end facilities need to become more flexible and user-friendly. For example, in gaming, there might be a requirement called a Session Key, which allows users to authorize a key that is valid for a specific time and can only perform specific operations. Current infrastructure lacks this capability, which is why new infrastructure like smart wallets is needed.

Smart wallets act as enablers for Web3, allowing certain events to occur, somewhat like the relationship between smartphones and mobile internet. Smartphones are enablers for mobile internet.

Without the interaction upgrades provided by smartphones, including operating system upgrades, sensor upgrades, camera upgrades, etc., the common scenarios we use on phones today would not be possible. For example, the popular Douyin (TikTok) relies on the infrastructure that many smartphones provide.

Another analogy is that Layer 2 solutions expand capacity, reduce costs, and increase processing speed, which is similar to how we want to speed up and reduce costs in the internet. We can liken it to the 4G network; only with the costs and speeds of 4G can scenarios like Douyin emerge. The role of Layer 2 is similar; it is preparing the infrastructure for large-scale applications.

This is my summary of why smart wallets have become a hot topic.

Jenny: Okay, the next question is about the classification of wallets, such as MPC wallets, low-threshold wallets, and smart contract wallets. What are the development thresholds for these wallets? Additionally, I have heard that the development threshold for MPC wallets is relatively low; is this true?

Frank: The distinction of high or low thresholds depends on who you compare it to. The threshold still depends on the breadth and depth of what you are doing. Breadth refers to how many chains are supported. For example, when your wallet supports Bitcoin, it is much more complex than an Ethereum wallet because Bitcoin lacks an account model. There is no way to request how much BTC an address has from a Bitcoin full node; you must have a Cache Server to process all Bitcoin blocks and then re-index them to create a queryable dataset. Therefore, whether it is MPC or other wallets, as long as it involves multiple chains, the difficulty is very high because each chain has a different architecture. I remember that Maizi Wallet supports over 50 chains, which is very broad.

If we only talk about EOA wallets, the current development threshold is indeed not high because there are purely open-source solutions like Alpha Wallet and MetaMask to refer to, and MPC also has ZenGo and Binance as references. In short, such open-source project libraries will continue to increase. If the requirements are not very high and you are not doing particularly complex customizations, the overall difficulty is indeed not high. However, if users need to perform 2-3 signatures using a mobile phone or webpage, it becomes very difficult because it requires 7 interactions, which the network cannot handle. So unless it is for a specific scenario, like creating a multi-signature collection or a cross-chain bridge MPC solution, doing a 2-2 or 2-3 solution is not particularly difficult.

In our solution, we actually used a 2-2 MPC, the simplest one, as our SDK key solution. The reason we use this is that we are not afraid that the 2-2 MPC key will break; it is not a single point of risk like MetaMask. A 2-2 setup has a double point of risk, meaning that if any one point fails, it is not usable. The reason it works is that users are still using smart contracts; we are just a tool.

We used the ZenGo-X open-source library. The reason we chose it was that we needed to use it in a web environment, and the library needed to compile well into Wasm. After determining various limitations and solutions, we spent about a month completing the library, including porting and front-end and back-end debugging. That’s about it; of course, this is just our case.

Jenny: I know that UniPass should have a very strong presence in the market. I want to ask, what was your original intention when you created UniPass? What is the principle behind UniPass's implementation? Currently, smart contract wallets are not actually integrated with the Ethereum underlying layer, right? What impact does this have on smart contract wallets?

Frank: There is still one point I haven't finished discussing regarding the development difficulty of smart wallets, which I think is related to this question. Let me first talk about the development threshold for smart wallets.

The development threshold for contract wallets is actually quite high. For example, Gnosis Safe, which we all know is a multi-signature wallet, is also considered a smart contract wallet. So the threshold mainly depends on what functions you want to implement. If you just want to create a multi-signature wallet, it is very simple; the easiest way is to fork Gnosis Safe and use it directly.

If you want to create a custodial Seedless wallet, that’s also simple; you just need to pair a custodial solution with a smart wallet. If you want to create a non-custodial Seedless wallet, you need to add social recovery, which is a bit more challenging.

If you want to create a Gasless wallet where users can use any token, or even pay gas fees through additional means like fiat, that becomes more difficult. Because you need a Relayer to handle the gas part, you will need to have a Relayer, whereas Gnosis does not require a Relayer. If you are doing Gasless, you will need to add a Relayer.

If you also want to create a multi-chain smart contract wallet that is fully EVM compatible, such as multi-chain state distribution and gas fee estimation on different chains, that is very difficult. People should not think that EVM-compatible chains are all the same; they are not. The gas estimated for the same operation on different EVM chains can vary significantly. If anyone wants to do this, they should do more research.

Returning to the third question, which is about our original intention in creating this. The UniPass product is quite early; if anyone was aware of it in early 2021, UniPass was working on UniPass ID, and our current domain is still https://unipass.id/. This mainly stems from our understanding of ID and the concept of Web3 accounts. What we are doing now is wallets, but we actually see ourselves as creating Web3 accounts. The original intention of UniPass is to create a low-threshold, user-friendly Web3 account. When you use it to manage assets, it belongs to the wallet track; when you use it for authorization and authentication, it belongs to the DID track. In my view, it is all one thing.

Smart wallets, due to their flexibility, can manage permissions within the wallet. The simplest way is to divide permissions into two types: execution permissions and management permissions.

Execution permissions refer to the normal use of the MPC key, while management permissions are what we call email-based social recovery. Normally, when users use the MPC key, they use it as intended. If they forget their password, it means that one of the key fragments cannot be decrypted, and the MPC key will break. At this point, they can use email to recover, and after putting the email on-chain, the contract will verify whether the email is genuine. This is a protocol called DKIM. Once verified, it will follow the actions specified in the email to replace the broken key with a new one, which is the normal password reset process for users.

People often ask us what the private key of UniPass is and how to export it. In fact, smart wallets do not have private keys; they are contract addresses. Unlike EOA, which has a public key and a corresponding private key, the address of a smart wallet is essentially a name, comparable to a class name, which corresponds to the permissions for managing the account. These permissions can be managed with keys.

For example, if a user says they do not like UniPass and do not want to use our MPC, they can directly trade using normal means. Even if we stop responding, the user can transfer control to a MetaMask using social recovery, and then use their original contract wallet, similar to using a single-signature Gnosis Safe, where there is only one key to control the Gnosis Safe. The benefit is that the user's address does not need to change.

As I often illustrate, losing a key means you have to throw away the house; that is EOA. However, smart wallets allow you to just change the lock if you lose a key, or if you feel that the current key might be lost or you want to change to a more secure and preferred lock, you can replace that key through your management permissions. This is the simple principle of UniPass.

Jenny: Will the ERC4337, which will be implemented in 2023, have any impact on your future plans?

Frank: ERC4337 is a proposal that allows for account abstraction to be achieved without making improvements to the consensus layer. It is a protocol that aims to implement account abstraction at a higher level without integrating with the underlying layer. This is one of the reasons why ERC4337 has gained so much attention compared to previous concepts of account abstraction.

The concept of account abstraction has been around for a long time; it was proposed in 2015. Around 2021, there was a proposal to add a new transaction type called AA Transaction, where the term AA first appeared. However, AA Transaction has a significant impact on the consensus of accounts, potentially rendering many old contracts unusable and even leading to asset losses, making it difficult to implement.

We are already compatible with ERC4337. In my view, ERC4337 is not much different from ERC-20; it mainly defines some contract interfaces. ERC4337 may include more foundational infrastructure for smart contract wallets, meaning that if you are compatible with this interface, you can achieve interoperability. The same goes for ERC-20 tokens; as long as a wallet is compatible with ERC-20, you can import the private key and see the token balance and perform token transaction operations.

ERC4337 is indeed a very good thing; it can promote recognition of smart wallets and unify the community's understanding in this direction.

It is also very friendly to entrepreneurial teams working on smart wallets. For example, the thresholds I mentioned earlier, such as creating Relayers and estimating gas, are all designed within the ERC4337 protocol.

Once the infrastructure for ERC4337 is established, teams developing smart wallets will not need to handle these two parts; they just need to connect to the ERC4337 P2P network. Our support method for ERC4337 is similar to that of Gnosis Safe, which is to make it an extension of UniPass.

There is no need to create a new wallet; you can think of it as a plugin or a feature. This feature allows you to send a transaction to the chain to modify something, and you can attach this logic to it, making it compatible with the ERC4337 system.

If at any point you no longer want it, for example, if you feel that the Entry Point has too much authority or that it seems to lack the functionality of UniPass's Relayer, you can turn it off at any time, allowing users to make choices.

Jenny: So ERC4337 defines an industry standard that everyone follows, making future wallet development simpler, right?

Frank: Yes, interactions will also become simpler. Of course, ERC4337 does not address interactions. One thing we want to do next is to propose a standard for interactions as well, so that the market can use this standard, similar to how Wallet Connect is widely used.

Jenny: Next question, who is the target user group for UniPass? What special features do you provide for users? Compared to other smart contract wallets, what advantages does UniPass have?

Frank: The user group is very clear; we are targeting novices or Web2 users, and our features are mainly designed for them, such as Seedless, Gasless, Self-Custody, and batch transactions.

First of all, everyone knows that Seedless or mnemonic-free solutions are not a requirement of smart contract wallets; they are a feature we developed within the framework of smart contract wallets because they need to work with email-based social recovery. As for others, everyone will have a Seedless solution, but each implementation is different. After achieving Seedless, there may be some compromises in certain areas, but it is feasible in different scenarios.

Secondly, regarding Gasless, it seems that we are currently the only ones using it. The pursuit of Gasless is because we are targeting ordinary users, ideally without them needing to know what gas is. The benefit of account abstraction is that it allows the initiator of an action and the person paying for the gas to be two different people. Some new public chains, like Flow, have a dedicated Payer role, so the gas issue is already resolved at the underlying level. This is also why the EVM ecosystem is pushing for account abstraction, as it has become a standard feature on other chains.

The principle of Gasless is to find a third party to pay for the gas. For example, we can allow users to earn a few cents by watching an advertisement, and advertisers can pay for 10-20 gas fees for our users on Polygon or Arbitrum. During this process, users may not even know what gas is; they just need to know that performing an action consumes a certain number of action points, which we call Action Points. They can then exchange various means to obtain Action Points, such as completing tasks, watching ads, or even purchasing them.

This process is not called depositing funds because I am not selling you crypto; I am selling you a service to pay for gas, and it cannot be redeemed for cash, only used for directed consumption. This way, gas can completely disappear from the user side.

Of course, if there are sufficient business models on the scenario side, they can also cover the directed gas costs using their own business models. For example, we are collaborating with Izumi Finance to create a new generation DEX, which you might see in some time. Users interacting with Izumi's contracts can enjoy gas fee subsidies or even gas-free transactions on-chain. For instance, if a trading pair is launched on the DEX, I can temporarily waive gas fees to boost trading volume. Recently, we did something similar with a brand for an NFT Free Mint; this is a very good scenario that significantly enhances user experience.

Thirdly, regarding Safe Custody, I haven't figured out how to explain it well. This is not the common concept of custody. I mean that smart wallets can provide both custodial and non-custodial options as a feature for users, rather than as a setting. For example, you start by applying for a custodial wallet, and later you can still choose to switch to non-custodial with one click. The underlying principle is that the keys of the smart wallet can be changed. Initially, the custodial key is fully controlled by the custodian, and when I claim it, I add my key and remove theirs, completing the transfer.

This is something EOA wallets cannot do because once the EOA key is exposed, it cannot revert to a non-exposed state, and this key is strongly bound to the address. You cannot continue using this address while changing the private key.

Fourthly, batch transactions are also a feature I particularly like. Currently, using EOA for transactions is very much like buying one item at a time on Taobao; you can only continue buying after completing the payment for the first item. However, we are more accustomed to an experience where we can add items to a shopping cart, and smart wallets can achieve this by completing all operations at the contract level and then sending a single transaction to the chain. Here, there is only one signature, resulting in only one transaction on Layer 1, which is both convenient and saves gas.

Many people think that smart wallets consume a lot of gas, but this statement may not be entirely accurate. In some cases, it may be higher, but at least in terms of batch transactions, as long as the batch size exceeds two, it saves gas.

Additionally, ACL (Access Control List) is a more niche term, referring to permission control. The capabilities derived from permission control, in addition to the social recovery we implemented earlier, can also include Session Keys, which I briefly mentioned earlier—keys that are time-limited and function-limited, allowing only specific operations during that time.

A good example is if you have a BAYC in your wallet and you frequently use that wallet to sign transactions. If you accidentally sign incorrectly, that monkey could be taken away. At this point, the smart wallet can have multiple keys; some keys can manipulate the BAYC, while others cannot. They only prove your control over the contract, but they cannot perform other actions.

Another direction for expansion is that I can base it on assets. For example, if I still have a BAYC, I can require that this BAYC has three keys, one of which is my Ledger. Only after signing together can the NFT be transferred out, while I can use any key to transfer my USDT and other assets freely. This way, I feel secure; I am not afraid that a single signature from MetaMask will lead to my BAYC being stolen. After all, the permission to manipulate BAYC is quite high; as long as no one asks me to produce my Ledger, this BAYC will not be transferred out. These are all new features derived from permission control.

The last point is stronger expansion, where this expansion can allow arbitrary signatures. This signature can declare who can give me 100 ETH or who can take my BAYC. Anyone holding this signature can call the contract to send you 100 ETH, and at the same time, the BAYC will go into their wallet. This operation is somewhat like a flash loan; it is completed in a single transaction without relying on a third party. Moreover, once you have the signature commitment, you can post it anywhere on the web, like on social media or second-hand marketplaces, wherever you think someone might be willing to buy it. Essentially, when the transaction occurs, it uses your own contract rather than OpenSea's contract.

Jenny: Today I've learned a lot; I need to experience this myself. Moving on to the next question, is there a relationship between smart contract wallets and account abstraction? You also mentioned the concept of account abstraction earlier. In other words, can the implementation of account abstraction promote the development of smart wallets? What challenges do smart contract wallets face in their development before the complete implementation of account abstraction?

Frank: This question seems to be reversed; it is not that the implementation of account abstraction promotes the development of smart wallets. Rather, it is using smart wallets to promote the implementation of account abstraction. This is indeed a concept that is easy to confuse. I remember I wrote an article on Mirror titled "Account Abstraction Explained," which discusses the relationship between account abstraction and smart wallets.

Account abstraction has two layers of meaning. Its original intention refers to a capability, specifically whether a blockchain's account system can perform certain internal structures, such as separating keys and accounts or cryptographic replacements. It describes a standard for evaluating the flexibility of an underlying chain's account system. Additionally, there are many distinctions in the degree of abstraction, such as the not-fully-abstract BTC, the completely non-abstract EVM, the highly abstract Flow, and the fully abstract Starknet and CKB, which all represent different levels.

The second meaning specifically refers to the EVM ecosystem. Since EVM does not have account abstraction, everyone wants to enable account abstraction for EVM. Thus, this has become a movement to achieve account abstraction in EVM, which is what we commonly refer to in our context.

So how is account abstraction achieved?

Since 2015, there have been various proposals. Besides the most famous ERC4337, there are also several important ones, such as EIP-3074, which allows all EOAs to delegate their account unlocking rights to another contract; and EIP-5003, which is even more ambitious, aiming to allow all EOAs to become smart wallets with a single line of code, effectively turning them into contract wallets. So you will find that what they are discussing is the desire to achieve account abstraction, and the standards they define or the things they want to promote are to make smart wallets more user-friendly, easier to develop, and even optimize the underlying layer to reduce costs.

The concept has become a bit muddled. If we simply answer this question, yes, there is a relationship, but it is the opposite; smart wallets are the means to achieve account abstraction, not that account abstraction will lead to the development of smart wallets.

Jenny: Can you summarize what account abstraction is in one sentence?

Frank: Account abstraction, if we do not refer to the Ethereum EVM, refers to the flexibility of blockchain accounts.

Jenny: Okay, I understand. Now let's talk about one of the most important core functions of wallets: security. Everyone knows that there have been several issues with wallets recently. Can smart contract wallets reduce the risk of wallet theft in terms of security?

Frank: Security is a broad topic, and we can discuss it from two perspectives: interaction security and key security. Key security is straightforward; it is about how to protect my private key from being stolen. Interaction security is also common, for example, through approve; if the key is in your hands, a hacker can deceive you into signing an authorization and then transfer your assets away.

The security model of contract wallets differs from that of key wallets. Theoretically, contract wallets are very secure, even at a ceiling level, but they rely on one premise: that your contract itself has no vulnerabilities. The security of the contract itself requires time and events to accumulate for verification. We all know that Compound initially had security issues with its contract, but over time, it has gradually improved and now holds over a billion dollars without any problems. Gnosis Safe's contract has stored over 1.7 million ETH without any issues.

EOA wallets involve cryptographic security; if the key is not stolen but the assets are transferred away, it means there is a problem with the chain where the assets are located or with the consensus layer.

When discussing the security model under the premise of contract security, the advantage of smart wallets is that they can provide flexible and complex permission settings. In a broader range of use cases, for more general users, they can offer a relatively moderate level of security because it is very dangerous for ordinary users to store their private keys and mnemonics.

Thus, features like Seedless, multi-signature, and the asset-based permission control or key security we discussed earlier mean that users do not have to come into contact with private keys, significantly reducing the likelihood of losing them. Additionally, with MPC splitting the private key into several pieces, the risk of users losing one piece is further minimized. So I believe that the combination of these two factors will be better.

Smart wallets provide meaningful protection for interaction security. As mentioned earlier, whether it is multi-signature or asset-based permission control, if I am only asked to sign a single signature, I might accidentally sign it. However, if I have this asset-based permission control and you suddenly require me to sign two signatures, that raises a red flag. Or a hacker may not even know that you need to sign two signatures to move the assets, causing their transfer attempt to fail. These measures can enhance user interaction security.

Most importantly, I believe that smart wallets are actually a growing product. Their security model can evolve alongside users at different stages. Initially, a novice user may have no assets and little knowledge, so the focus is on user experience. As they start using hardware wallets and transfer contract management rights to a hardware wallet, or even add several keys to create a multi-signature setup, this also corresponds to the increase in their assets and the accumulation of their DID, as well as their time spent in the industry. They can configure their wallets to a higher security level.

It is somewhat like in gaming, where the main character starts with nothing, but as they level up, their equipment improves. Therefore, in my view, smart wallets are a more practical and sufficiently secure solution, a more realistic approach than pursuing absolute security.

Jenny: Returning to the customer perspective, looking at the broader category of wallets, the market generally views wallets as the entry point for Web3 traffic. Do you agree with this narrative? Is a wallet a tool or an entry point for traffic?

Initially, we thought of wallets merely as tool components, with the real traffic being attracted by the DApps themselves?

Frank: Yes, I completely agree. The explosion of scenarios and innovation in scenarios will definitely be the engine for the next bull market. We are just the green leaves, making it easier and safer for everyone to come in; traffic will not come in just because there is a more convenient wallet.

Regarding whether wallets are entry points or tools, I think it depends on the situation. First of all, pure key-based wallets like EOAs, especially within the EVM framework, are primarily tools. Whether it is MetaMask or MPC wallets, they mainly serve as key management tools, and their relationship with actual on-chain scenarios and the chain itself is not that significant. Users can easily export their private keys to another wallet, with a migration cost close to zero. They can even use their keys to generate addresses on other chains, which is unrelated to Ethereum, so they are more tool-like.

However, smart wallets emerge as products combined with services. The contracts users interact with are closely related to the chain, and these contracts do not have corresponding private keys, so they cannot be migrated in that way. Users can switch service providers; this service provider refers to their own service, using MetaMask, or they can add a third party, such as OpenBlock, which can also serve as a key solution for UniPass. Our collaboration with MetaMask reflects this two-layer relationship. No matter how they switch service providers, they are still using this contract, and the longer they use the contract, the more interactions accumulate, which increases its value.

Whether it is UniPass itself or the future extensions based on the UniPass ecosystem, or applications built on top of UniPass, everyone is centered around this foundational infrastructure service. I prefer to liken it to smartphones. Do you think smartphones are entry points or tools?

Jenny: They are both entry points and tools; a product can have dual attributes.

Frank: Yes, WeChat is the same; it is an instant messaging tool, but as more people use it, it becomes an entry point. On smartphones, you can have WeChat, Douyin, as well as Taobao and Pinduoduo. It is closer to users than these apps; it is the infrastructure closest to users. Therefore, the model behind smart wallets is also about co-building ecosystems, where you develop various apps on your phone to become an entry point. This is what we hope to see.

Jenny: So this is what UniPass truly aims to achieve. Now, I want to ask a question I am particularly concerned about: what is the profit model for wallets? The market generally claims that apart from a few leading wallets in the track, most others are burning money and not profitable. Is this the case? What are the profit models for wallets?

Frank: Before MetaMask made money, it was useless to say anything. I entered the industry in 2017, and throughout the years, wallet products have had their own ways of making money at each stage. In 2017, there were ICOs, and by the end of 2018, there were rebates for DApps. Later, there were swaps, deposits, and wealth management, etc. The essence of this question is that you have created a tool with a lot of traffic; how do you monetize that traffic?

Monetizing traffic depends on user labels. I am quite familiar with this because we used to be in the traffic business, and different types of traffic have different monetization methods.

When it comes to profit models for wallets, I think wallets are quite similar to banks. Whether it is wealth management or trading, or even custody, banks also provide custody services, wealth management services, and charge transaction fees for stock trading. I could even create an enterprise wallet solution for internal use, which is what MetaMask does.

These are all current ways wallets can make money, and we can pursue these, but we still position ourselves more towards accounts. We are discussing what Web3 will do as an account in the future. For example, I can offer premium account services, similar to Meituan membership. Why would you want to buy a Meituan membership? It can provide you with vouchers and member red envelopes. I can also offer you a monthly gas fee exemption and some additional quick response services.

Essentially, I am still providing services to users around this foundational infrastructure. When you need premium services, or even high-level Guardians for multi-signatures, we will need to incur costs to provide that Guardian service. Even during email social recovery, we will need to provide ZK for users. In the future, all of this can be packaged into a subscription-based profit model.

Additionally, when using the Gasless feature of smart wallets, the service fees from advertisers or other service providers paying for gas are also a source of profit.

Looking further ahead, there are automated services where you need some Session Keys to perform automation at specific times. For example, automatically executing transactions for Ethereum land auctions or even automatically sniping NFTs. Smart wallets can create a Session Key that only allows interaction with the NFT contract; it can only help you mint NFTs and cannot do anything else. We can provide this service, which EOA wallets cannot achieve because they cannot hand over keys to service providers.

Lastly, there is a long-term vision: when our user base grows to a certain extent, people will be willing to add a plugin directly from the UniPass user base, similar to how they use WeChat technology to create a mini-program instead of developing an app. This way, we can control which logic can be added to the user's extension list. It is somewhat like how an app store on a smartphone can control which applications can be listed. We are truly building smart wallets according to the logic of smartphones.

To elevate the discussion on traffic, user attention and mental space are always valuable, whether in Web3 or even before the web existed. Whether it is print media, magazines, television, or radio, anything that captures user attention and mental space is valuable.

I believe that in a sunrise industry, it is essential to do B2C; doing B2B is somewhat limited because I know that once B2C businesses grow, their momentum can be substantial.