This article by Ryan Yi has been edited and was first published on February 26, 2024, on Coinbase.
Summary
- Changing wallet technology has major implications for how users interact with crypto apps and application adoption.
- The advent of embedded wallets and smart accounts takes things well beyond the current use of self-custody wallets.
- The change is being likened to an “iphone moment”, revealing the enormity of the expected shift.
The crypto ecosystem’s infrastructure is converging on a state that is ready to service everyday mainstream applications. While most of the attention has been on innovations in blockspace (lower fees and higher throughput with L2s and alternative L1s), there has been an equal step-up in the wallet infrastructure space as well.
To date, self-custody wallets have been the primary form factor of interacting with crypto/Web3 applications and networks. Going forward, the wallet landscape is going through a major shift in technology innovation with the advent of embedded wallets (also known as MPC or WaaS (Wallet as a Service)) and smart accounts.
These advances will have major implications for how users interact with crypto apps, application adoption, and positioning of various wallet providers.
The two most important technologies created in crypto/Web3 are the concept of blockspace and cryptographic keys/wallets. Wallet technologies have now expanded beyond self-custodial wallets, and we believe within the next five years wallets will change dramatically – marking crypto’s “iPhone” moment.
What are wallets?
Wallets are identifiers on a public-key level [0x…] but are a cryptographic-secured guarantee of ownership.
With a wallet, you can sign an onchain transaction or an offchain transaction.
- Onchain = requires gas → this will pop up on a block explorer like Etherscan
- Offchain = no gas required → this is a signature (ex. to “sign into” a session on a dApp’s front-end) → this will not pop up on a block explorer like Etherscan
How does self-custody work?
In the self-custodial world, users are responsible for key custody, transaction signing, and recovery.
Popular wallets include Blockchain.com*, Trust Wallet, Coinbase Wallet, Metamask*, Rainbow Wallet*, and Phantom.
From there, dencentralized applications (dApps) need to enable connections to the wallets via various software development kits (SDKs). These SDKs are either native to the wallet or open source (WalletConnect*).
This is important because it is critical in surfacing the viable options in the user’s journey. We equate this as being similar to the ability for a Web2 app to surface “login with” via Okta Auth0.
DApps can define a set of approvals either offchain or onchain for the user who then starts transacting.
How are wallets developing?
Wallets are adding multiple features so users can access the entire crypto ecosystem from their core wallet. Examples include: send/receive, swap, bridge, message, notify.
Distribution is usually application-led. Popular Web3 apps are deciding that given they own the user’s attention and mindshare, it’s a natural progression to offer a wallet directly. Examples: MagicEden*, Aave, Uniswap*.
Wallet providers might choose to claim ground in new ecosystems to take advantage of their first-mover advantage. This allows them to develop the relationships and tech integrations to be successful. Examples: Phantom on Solana or Keplr on Cosmos.
What are embedded wallets and WaaS?
In the embedded – multi-party computation (MPC)/WaaS – wallet world, a user can log-in with their Web2 credentials (email, sms, Twitter, etc).
The keys themselves can be split between the dApp, the user’s device, and/or a third-party (centralized or decentralized). The dApp utilizes a third-party service that handles various parts of the keys/SDK/auth experiences. User devices can leverage passkeys under-the-hood.
Because the dApp manages the user flow, the SDK/authentication live in the back-end and are implicitly approved.
DApps and the embedded wallet provider can also see a CRM-style dashboard of the keys and related social login data of the users.
How are embedded wallets developing?
It is still extremely early days for embedded wallets, but the user experience (UX) improvement, particularly for non-crypto native early adopters, speaks for itself.
For embedded wallets, the user still has full control over their wallet. A user can choose to “export” their keys and can either transition back to a fully self-custodial wallet or to a smart account (see below).
While many non-crypto native users might not use this function, this offers users an opt-out, which is important to mitigate the centralization risk that is commonly associated with Web2 data silos.
If multiple dApps are onboarded onto a single embedded wallet provider, and a user logs into those dApps with a similar login method, the embedded wallet provider can associate that those disparate wallets belong to the same user and expose that in an interface to the user. As a result, for an embedded wallet provider, winning as many Day 1 mandates can be an important wedge.
DAapps can now leverage the database of their user-set and tie in other digital footprints, further transitioning the Web2 datalake into Web2.5 utility. Example: A dApp might want to run a DevRel campaign and can see the users who have OAuth’d their Github and track their PRs/commits.
What are smart accounts?
Smart accounts are smart contract wallets with account abstraction features. These allow users to define transactions to be executed by third parties.
We consider smart accounts/account abstraction as complementary to the above trends.
Self-custodial wallets can join/mint smart accounts and “link” to other wallets/keys that the user owns.
Embedded wallet providers can surface smart account options as a service to the dApps that want to provide benefits like gasless experiences.
What are the implications of these developments?
The path dependency of wallet adoption will have implications for how authentication/authorization play out. The authentication/authorization layer defines a user session, data read/write interactions, and security parameters. The stakeholders are the wallets, the authentication layer, and the dApps themselves. Whoever emerges will have won the race to build and leverage a distribution network effect and created a product around that network effect.
Wallet/auth/data are all separated. The user downloads the wallet, connects to OpenSea*, via an authentication flow.
Wallet providers generally know nothing about the user’s identity beyond what is onchain on Etherscan.
The authentication layer will collect various pieces of information, such as the address, the session data, and other related disclosed data (IP address etc).
DApps likely have the best idea on who the user actually is. One example is OpenSea, which will have a user fill in their email/Twitter/social data stored in OpenSea’s server. OS knows that [0x…] = John Doe, but the authentication layer will only know that [0x…] interacted with OpenSea.
Embedded wallets bundle all three. The user logs into OpenSea via the embedded wallet provider.
The embedded wallet solution takes care of the key and authentication layer, which are bundled together. As a result, the user doesn’t need to login to the dApp via a separate authenticator, it just gets done/abstracted when signing in via WaaS. The dApp can also see this in its interface with the embedded wallet partner.
The embedded wallet solution may own the data and may surface it to dApp, if needed. For example – if I logged into OpenSea with my Twitter OAuth (powered by WaaS) – both should see the associated keys and the social login.
The embedded wallet solution can then see a consolidated view of keys across its data store – dApp 1 might not care who dApp 2’s users are – but the WaaS provider sees all the overlapping user socials and can surface the common interface. This is assuming the user has provided data permissioning when he or she has authenticated using recognizable credentials.
To date, self-custody has been the primary wallet option for consumers. That said, new technologies present viable alternatives and have major implications for wallet adoption. Ultimately, the result will likely depend on the first dApp or use-case that a user is exposed to and the corresponding wallet technology.
To date, users of crypto apps only had one viable option, which was self-custody. With the emerging wallet technologies described above, there will be multiple options available. This should also help onboard net new users (who may be non-crypto native users) who are already familiar with an “OAuth” style onboarding.
Potential regulatory hurdles on self-custody in certain geographies may pose an insurmountable cost for users to adopt the self-custody option. Conversely, it is unknown whether embedded wallets (who hold a piece or shard of a key) might be classified as a custodial service.
Wallets can structure monetization in different ways. For embedded wallets, it is likely operating at a freemium or SaaS model, but over time, their positioning between the user and the actions will allow them to have direct exposure to the growth of onchain actions.
One user per wallet, or one wallet per dApp?
One wallet to rule them all: Self-custody wallets have taken on a form factor of one person → one wallet ←→ superapp. Users can create another wallet within the same interface, but the vision stays the same.
One wallet for every app: Because embedded wallets are hidden in the back-end of the application, the form factor looks/feels like a dApp (similar to an app on your iPhone). This ends up resulting in one wallet for each dApp.
Linking wallets – somewhere in the middle: Rather than one outcome versus the other, a middle ground is the most likely outcome. Wallets can be “linked together” as long as there are common identity identifiers.
The onchain version can be manifested through smart accounts, which can delegate control across wallets. The offchain version may be common identifiers that live behind an embedded wallet’s API. Example: “[email protected]” OAuth’d across multiple dApps can be a common identifier.
Outlook – wallets to enjoy their iPhone moment soon
The number of crypto-enabled wallets is likely to grow exponentially over the next decade. Since inception almost a decade ago, the total unique ETH addresses hovers around 250 million (five years to reach 100 million uniques, and only another two years to reach 200 million uniques). This was in an era of expensive blockspace, and self-custodial wallets.
Looking forward, the advent of embedded WaaS plus smart accounts should lower the onboarding friction and cost of wallet creation to near-zero. The emergence of L2 and related low-cost blockspace technologies will lead to greater usage in crypto-enabled actions and wallets will be the primary method of engaging with these use cases.
A version of this article first appeared on Coinbase.
