By Ryan Yi

Disclosures and footnotes: Coinbase Ventures portfolio company backed projects are denoted with an asterisk (*) when first referenced in the article below.   

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 5 years wallets will change dramatically – marking crypto’s “iPhone” moment. In this part, we will cover the various wallet technologies. In the future parts, we will cover related trends like how data and identifiers will be attached to wallets.

TL;DR

• 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 on how users interact with crypto apps, application adoption, and positioning of various wallet providers.

If we start at the core – wallets are new identity primitives.

• Wallets are identifiers on a public-key level [0x…] but are 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

Era of Self-Custody
How It Works

• 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, Dapps need to enable connections to the wallets via various SDKs. These SDKs are either native to the wallet or open-source (WalletConnect*). This is important because it’s critical in surfacing the viable options in the user’s journey. We equate this similar to the ability for a web2 app to surface “Log In With” via Okta Auth0. 

• Dapps can define a set of approvals either offchain or onchain for the user who then starts transacting.

  

Observations on Self-Custodial Wallets

• Superapps: Wallets are adding multiple features so users can access the entire crypto ecosystem from their core wallet. Examples: Send / Receive; Swap; Bridge; Message; Notify

• Distribution is usually application-led. Recently, popular web3 apps are deciding that given they own the user's attention and mindshare – it’s a natural segue into offering a wallet directly. Examples: MagicEden*, Aave, Uniswap*. 

• Ecosystem: Wallet providers might choose to claim ground in new ecosystems in order to enshrine their first-mover advantage. This allows them to build out the relationships + tech integrations to be successful. Examples: Phantom on Solana or Keplr on Cosmos.

Era of Embedded Wallets and Wallet-As-A-Service

How It Works

• In the embedded (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 3rd-party (centralized or decentralized). The Dapp utilizes a 3rd-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 / Auth live in the back-end and are implicitly approved.

• Dapps + embedded wallet provider can also see a CRM-style dashboard of the keys + related social log-in data of the users. 

Observations on Embedded Wallets

It is still extremely early days of the embedded wallet trend – but the UX improvement, particularly for non-crypto native early adopters, speaks for itself.

• User Opt-Out: For embedded wallets, the user still has full control over their wallet. A user can choose to “export” their keys, and can transition back to a fully self-custodial wallet, or can transition to a Smart Account (see below). While many non-crypto native users might not use this function, this allows users the opt-out that is important to mitigate the centralization risk that is commonly associated with web2 data silos.

• Wallet “Linking”: If multiple Dapps are onboarded onto a single embedded wallet provider, and a user is logs into those Dapps with a similar log-in method, the embedded wallet provider can associate that those disparate wallets belong to the same user and can 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. 

• Data Foundation: Dapps 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.

Era of Smart Accounts

How It Works 

Smart Accounts are smart contract wallets with “Account Abstraction” features. These allow users to define transactions to be executed by 3rd-parties.

Observations

For a full breakdown on Smart Accounts – we will cover this in a future Coinbase Ventures blog post. 

• 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 and so forth.

Takeaways / Implications

Auth / Data: The path dependency of wallet adoption will have implications on 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. Whomever emerges will have won the race to build + leverage a distribution network effect and productized around that network effect.

• Today: Wallet / Auth / Data are all separated. User downloads wallet, connects to OpenSea*, via an auth flow.

  • Wallet providers generally know nothing about the user's identity beyond what is onchain on Etherscan.

  • The auth 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 – example is OpenSea will have a user fill in their email / twitter / social data stored in OpenSea’s server. OS knows that [0x…] = John Doe, but the auth layer will only know that [0x…] interacted w/ OpenSea. 

• Future: Embedded wallets bundle all three. User logs into OpenSea via the embedded wallet provider. 

  • The embedded wallet solution takes care of the key + auth layer – they are bundled together. You don’t need to log-in to the Dapp via a separate auth, it just gets done / abstracted when you sign in via WaaS. Dapp can also see this in their interface with the embedded wallet partner. 

  • The embedded wallet solution may own the data and may surface it to Dapp if needed. For example – I logged into OpenSea with my Twitter OAuth (powered by WaaS) – both should see the associated keys and the social log-in. 

  • The embedded wallet solution can then see a consolidated view of keys across their 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.

Paths of Adoption: To date, self-custody has been the primary wallet option for consumers. That said, new technologies present viable alternatives and have major implications on wallet adoption. Ultimately, we believe that the result will depend on the first Dapp or use-case that a user is exposed to and the corresponding wallet technology.

• User Type: 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. 

• Geographic: 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. 

Business Models: Wallets can structure monetization in different ways. For embedded wallets, it is likely operating at a freemium or SaaS model – but we expect that over time as their positioning between the user and the actions will allow them to have direct exposure to the growth of onchain actions.

Wallet Form Factors: Will we have 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 vs. the other, we believe 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 – “john@gmail.com” OAuth’d across multiple Dapps can be a common identifier.)

Closing

We believe the number of crypto-enabled wallets will grow exponentially over the next decade. Since inception almost a decade ago, the total unique ETH addresses hover around ~250M (5 years to reach 100M uniques, and only another 2 years to reach 200M uniques). This was in an era of expensive blockspace, and self-custodial wallets. 

Looking forward, we believe the advent of embedded “Wallet As A Service” (or WaaS) + Smart Accounts should lower the onboarding friction and cost of wallet creation to near-zero, and 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. 

In the next piece, we will cover “Smart Accounts”in detail.

Coinbase offers various products such as a self-custodial Coinbase Wallet (self-custody), Coinbase Wallet-As-A-Service (embedded wallet), and Base is supportive of Smart Accounts. If you are a builder exploring the mind maze of the future of wallets like us, we'd love to hear from you.  Ryan Yi’s DMs are open!