For over a decade, wallets have been the most daunting barrier to entry into the world of cryptocurrency. Conversely, they are also the most annoying bottleneck when promoting web3 applications. For the past seven or eight years, while I should have been explaining decentralized publishing, I’ve actually spent far more time helping newcomers set up wallets than introducing LikeCoin itself.
Have you ever wondered why using various applications on the internet is as simple as opening an account, yet using cryptocurrency requires going through the great hassle of setting up a wallet, learning a host of new concepts like seed phrases, private keys, and addresses?
Words Misunderstood — The Wallet Edition
Before we dive deeper, let’s clarify a few misconceptions.
First, the wallet. Among the many terms in the blockchain lexicon, “wallet” is one of the most misleading. It helps users manage private keys, making its function more akin to a keychain. Apple’s iCloud offers a similar feature, aptly named Keychain, which is much clearer. Because controlling the wallet means controlling the private key, and controlling the private key allows you to use all assets at the corresponding address, the effect is similar to an “asset container”—he who holds the container holds the assets. This has led to the use of the misleading “wallet” analogy.
Next is the account. Many people misunderstand the difference between an account and a wallet, believing the former manages data while the latter manages assets. In reality, the difference lies in the fact that an account is custodially managed by a service provider, whereas a wallet is self-managed by the user. Therefore, when using digital banking or centralized exchanges, you only need to register and log in to an account, even when managing assets. Conversely, in a decentralized publishing ecosystem, although you are managing data like books, you use a wallet.
The misunderstandings don’t stop there. Some applications, which are thoroughly custodial, also call themselves “wallets.” Common examples include Alipay Wallet and LINE Wallet. There’s not much to be done about this; calling oneself a bank might be illegal, but calling oneself a wallet requires no license. Merchants are not driven by the goal of public education, so allowing users to mistakenly believe their assets are in their own pockets aligns perfectly with business logic.
Let’s summarize: An account is a long-standing identity verification mechanism since the rise of the internet, familiar to most users for managing data or assets entrusted to an application provider. A wallet, in the context of blockchain, is a private key manager that is self-managed by the user. It not only involves a learning curve but also has a more severe problem: if you lose it, you lose all your assets and data, making the potential cost of self-sovereignty extremely high.
Wanting Both Convenience and Self-Sovereignty
Accounts are convenient but custodial; wallets are self-sovereign but troublesome. Thus, someone thought of “embedding” a wallet into an account to achieve the best of both worlds: convenience and self-sovereignty. This is the starting point for embedded wallets.
An embedded wallet, also known as “Wallet as a Service” (WaaS), as the name suggests, embeds the wallet into an application. Users do not need to install a browser extension or a separate wallet app on their phone. They simply register with an email address or a Google or Apple account, and a wallet is generated at the same time. Up to this point, the process is largely the same as for an online bank or a centralized exchange account—nothing special. But the key part comes next.
Taking WaaS provider Magic.link as an example, the private key of an embedded wallet is stored in Hardware Security Modules (HSMs). Unlike traditional custody, even internal employees at Magic.link cannot read the user’s private key. After logging in via email or other methods, the user can use a session key to sign transactions on behalf of the private key stored in the HSM for a limited time.
Don’t be intimidated by the terminology above. You can think of it this way: it’s like using a bank’s safe deposit box. Although your valuables are stored at the bank, the box can only be opened with the key you hold. Not even bank staff can steal or peek at your valuables. Magic.link calls this mechanism, which is neither fully self-sovereign nor traditionally custodial, the Delegated Key Management System (DKMS), and has protected it with a patent.
Distributed systems are most vulnerable to a single point of failure. The astute among you must have considered: what if Magic.link goes out of business? Wouldn’t all users’ private keys be lost forever? Therefore, Magic.link provides a private key export feature. In addition to logging in with their account to sign transactions, users can also export their private key and import it into wallet software like MetaMask to manage it in the standard web3 way.
Although Magic.link has a patent for its DKMS, it is not the only provider of embedded wallets, and the implementation details of each vary slightly. For instance, Privy uses the Shamir’s Secret Sharing (SSS) mechanism (a cryptographic algorithm that splits a key into multiple parts) to store the user’s private key in several “Dragon Ball” parts. However, the principle is largely the same: to prevent the service provider from reading the user’s private key while allowing the user to log in with a regular account to sign transactions.
3ook.com Adopts Embedded Wallets
Many readers have used it, but few know that since 2018, before the term “embedded wallet” even existed, LikeCoin (before Liker Land was established) began using related technology. We used a system called Authcore to allow users to create wallets with email or social accounts. The key point was that neither Authcore’s nor LikeCoin’s technical staff could read the users’ private keys. Authcore was a Hong Kong startup with solid, no-frills technology and was ahead of its time. Unfortunately, due to various factors, it couldn’t go further. This time, with the upgrade of Liker Land to 3ook.com, we had to switch to Magic.link as our embedded wallet provider.
Decentralized publishing is a convergence of web3 and publishing—the former is disruptive, the latter traditional. For seven or eight years, many users have walked alongside LikeCoin, overcoming the learning curve to become permanent residents of web3. Asking this loyal group of users (including myself) to go back to logging in with email would be unreasonable. Therefore, 3ook.com retains the “traditional” wallet login, allowing these authors and readers to continue using their original wallet addresses.
At the other extreme, many book lovers still linger in the fragrance of paper books and have reservations even about e-books, let alone web3. Asking these users to learn how to use a wallet just to read a book is a Mission: Impossible that even Tom Cruise would surrender to (and we challenged it for several years!). Therefore, to break out of our niche and reach the “real world,” new users only need to register with an email—they don’t even need to set a password—to freely use 3ook.com through an embedded wallet.
However, the advantage of decentralized applications (dApps) was originally the ability to use a single identity across various applications, allowing for collaboration and composability. Although embedded wallets solve the onboarding pain point for new users, they can only be used for a single dApp, lacking the convenience of a standard wallet that uses the same address across all dApps.
Last week, I encouraged “muggles” to register on 3ook.com with their email, and 107 readers responded, receiving an airdrop of DHK and a small amount of ETH. In this case, since the embedded wallet can only be used on 3ook.com, readers who want to use their DHK and ETH on dApps like Uniswap must first export their private key and import it into a wallet like MetaMask. For specific instructions, you can refer to the DHK dao’s tutorial.
Embedded wallets simplify the process of creating a wallet and signing transactions by 99%. Although they cannot replace standard wallets in terms of flexibility, they allow users to enjoy the application’s features immediately. Users can learn to use a standard wallet later when they need to interact with other dApps, drastically pushing back the learning requirement. This effectively solves the old web3 phenomenon of “getting spanked fifty times before even seeing the magistrate”—forcing users to jump through hoops before they can even use a feature.
Leave a Reply