(2) Composability Series: Wallets - Access, Security, Integration
Understand the history of Ethereum wallets, what Access Legos are, and the implications of both on the future of dapp development and usability.
I’ve talked about product composability of decentralized applications (dapps) before, but with a fairly simplified diagram of the tech stack:
In reality, there are two layers I skipped (wallets and SDKs) and some added complexity with multi-chain (layer) dapps:
In this article, I will talk about why this extra complexity will lead to a large focus on how composable wallets will matter more and more to both users and developers. Usually, wallets come to mind in the last mile of development when the team decides to embed as many wallet connections as possible (assuming this is a single team tackling both the frontend and smart contract layers of a product). And this is fine since right now most dapps are fairly simple in user interaction (i.e., approve + deposit, bid/buy, or swap). There isn’t much to manage or compose pre/post-interaction.
But what happens as our ecosystem grows more complex? In the not-so-far future, we’ll start to manage our own digital identity in the form of proof tokens such as skills, credit scores, social circles, and more. This leads to new marketplaces of interaction a step before getting to the typical protocols we use today, and complex networks and user relationships to manage. Thinking about this led me to the question: Does it make sense to have specific frontends to manage each of these? The web 2.0 approach would be to create another aggregator platform/website, but I’m not sure I like the idea of a website tracking how I manage my identity and my network. I believe something this personal should be handled at the wallet level where personal sovereignty and privacy are highest.
While I don’t mind going to different sites for different protocols, I don’t want to have to use multiple wallet providers to manage different aspects of my on-chain interactions. That’s clunky and adds security risk each time. But having a single wallet means I’m locked into the inherent risks from the development team behind it — not to mention the features they have or haven’t added yet. Remember, we currently live in a rapidly evolving ecosystem that no single team can keep up with (more on this later).
Here’s where wallet composability starts to come in. Or I’d like to say that, but I haven’t even talked about what really composes a wallet. We already have money legos when it comes to DeFi and many Ethereum dapps, so I’m going to call wallet composability access legos instead:
Each of the four layers should allow for flexible user choice of product, and each layer should offer customizable legos by the product provider.
This is a lot to take in, so let’s take a quick detour into crypto wallet history to help us better understand all these legos and how we arrived at the modern wallet.
A Brief History of Ethereum Wallets
The first Ethereum wallets were inspired by the Bitcoin Qt Wallet, and came from providers like Mist.
Mist looked very similar and came in the form of downloaded software with exportable transaction data and block explorer/sync:
This wallet app was essentially trying to bundle everything Ethereum into one app — that’s a lot of dependencies and an overall poor UX. In comes MetaMask in 2016, as one of our first browser-based wallets. With this, dapps could now be decoupled from the wallet through wallet connection embeddings instead. This became important as the ecosystem grew, as it was (and still is) extremely difficult for a single team to keep up with all evolutions of EIPs and tokens/protocols developed. I do want to note that while this adds to the composability of the dapp product, this is not yet the smart contract integration that sits within the wallet shown in the access legos diagram earlier. This part doesn’t really change for a while besides new integrations like WalletConnect.
Now that some responsibility and overhang left the wallet, its new focus was on transactions building, signing, and maintaining the connection to the blockchain. I won’t get too deep into it, but transaction building means accepting some transaction parameters from the dapp but having others under the control of only the wallet. This gets into the available RPC calls to the wallet (also called the provider) defined initially by EIP-1193. The dapp can send transaction parameters like address to, data, gas limits/price, and value, but cannot control chain id, address of the sender, and nonce for wallet security reasons.
Now with this new wallet, we have two more user experience complications:
Memorizing other friends/users’ addresses is difficult, and can be unsafe and prone to human error.
Bytecode data is not readable by humans, unless you are very familiar with function selectors and data/parameter hashes. Good luck if you don’t have the contract ABI!
For the first point, ENS comes in 2016/2017 with EIP-137 and with it our first social lego. This allows anyone to represent their ethereum address with a web domain (like a username: vitalik.eth) and use that in messages/transfers instead of the long address. This is only one part of the social smart contract layer; the others get much more complicated to decouple/make composable.
On the second point, Parity created a method registry that is fairly widely used to give human-readable messages in the wallet signing interface. EIP-712 played an important role in readable message signing, though it has only recently picked up more traction. However, even with all this it is hard to guarantee your browser has not been hacked or tricked to show a different transaction/message. This is one of the larger problems of having a hot wallet (a wallet that is always connected to the internet and not securely separated from the rest of your computing environment).
The common solution for this is a hardware wallet, pioneered by Ledger starting in 2014. MetaMask first added hardware wallet support with Ledger in 2018, which officially decoupled the security layer from the transactions/connection layer. We’ll come back to this later, as Ledger works well as a cold storage but there have been new products with great improvements.
At the same time, we started seeing many complex protocols leading up to defi summer in 2020 (many of which were built over 2–3 years). This gave us an ever-growing number of tokens with larger and larger valuations to learn to manage securely. To help keep up with this, an RPC endpoint for the dapp to add tokens to the list tracked by the wallet was created. More tools for managing assets were created, such as Argent vaults and Gnosis multi-sig safes (I count these two towards the social layer given its multi-user and DAO nature). Permissioned connections (EIP-2255) for sharing data for dapps were also created to prevent unwelcome calls to the wallet. Portfolio management/asset aggregators and analytics were decoupled from the wallet using Zerion and Zapper (we’ll come back to these two in the next section).
Since 2019, we’ve also seen a rise in mobile wallets. Rainbow wallet is one of the best examples, as they’ve done a great job designing for user experience. However, they are just beginning when it comes to designing seamless integrations.
Most other mobile wallets (like MetaMask mobile and Coinbase Wallet) try and build a dapp browser within the app, and rely on deeplinks instead of direct integrations. These deeplinks don’t provide great UX, and there are too many products built on Ethereum for one wallet team to design an interface that can accommodate all of them. Let’s say each wallet app team optimizes UX for a specific use case (messaging, NFT/marketplaces, defi, etc.). Then, I now have security concerns multiplied by the number of wallets I’m using. And maybe that’s minimized if security is decoupled for each one of them — but within each niche, dapp developers will now have to deal with lead times of getting into that system. The Rainbow team actually started as a wallet aggregator/manager (based on their early GitHub repo from 2019), so I believe they already thought about this issue. That said, we can observe that smart contract interfaces are semi-decoupled, but the integrations are not composable yet as the wallet team is the bottleneck. Put another way, all dapps can push to a wallet but wallets can’t push to all dapps.
Now that the layers of a wallet have been more or less defined, we can go back to talking about access legos. These legos and the following analysis partially hinge on my belief that we’re moving more towards dapp in wallet products, like MetaMask swaps and Rainbow showcase features.
This was a summary based on a few weeks of research and my personal experience in the space, so it is completely possible I messed up the timeline of some items. If so, please reach out so I can edit the article and make the necessary fixes/additions.
Analyzing Access Legos
Now that we have a better understanding of Ethereum wallets, let’s talk about what I mean by “access.” Access here generally stands for users’ access to funds and protocols, and protocols’ (permissioned) access to users and data they reveal. With access legos, I have five key features in mind that help better define the base requirements of wallet composability:
Security can be decoupled from the user interface into any hardware or software solution without sacrificing customization.
Users should be able to access any apps they want without worrying about deprecation or integration time.
Protocols should be able to access users without worrying about being deprecated or pushing for integration.
No one should own the marketplace of integrations.
User and developer experience should not be sacrificed.
Let’s go deeper ⬇️:
Security Customization
I believe hardware-to-wallet connections are becoming more and more standard for almost every wallet I’ve seen out there, whether that connection is by USB, wireless, or Bluetooth method. So decoupling is not usually the issue; instead, the issues remain on the hardware wallet itself.
Seed storage, generation, and recovery are all fascinating topics to read about, but remain just one facet of hardware wallets as we move away from pure “cold storage.” Contract ABI and message decoded signing and transaction limits/flexibility add customization (and readability) for the user, which I mentioned before as important within each layer.
A great product example here is the Lattice1 from the GridPlus team; here you have one hardware wallet with interchangeable addresses handled with SafeCards. This wallet has a 64GB firmware environment and allows you to import ABIs from any contract to help decode the transaction data you are signing.
I believe integrations like this will become more and more important as the value and identity/reputation tied to your wallet continues to increase.
Marketplace of Integrations
Features two, three, and four can all be bundled into one concept — creating a marketplace for dapp integrations for your wallet. In a sense, the main “wallet” is the platform where security and all integrations can plug into. This is likely to always be the “transactions and connection” layer.
I believe MetaMask snaps is a step in the right direction, allowing dapp developers to plug into the existing MetaMask wallet UI by building the interfaces and integrations themselves and users to pick and choose the combination of niches they want — forming a marketplace within the wallet. If I like a certain set of products for investment, collection, or social identification, then I can source them from the dapp team themselves and use them privately within my wallet. There is no need for the wallet team to manually build in the next ENS, BrightID, or proof tokens; or any of the dozens of new defi protocols that pop up each month. The marketplace is important for long-tail communities and DAOs that may all have their own list of (or more likely start building their own) most-used dapps/products. If integrations are always built or waved in by the wallet team, only the most mainstream dapps will make the cut 99% of the time.
On the topic of marketplace ownership, I optimistically believe that these plugins should all be listed on an open-source repository (similar to how Dune Analytics showcases all of the behind-the-scenes views in a repo). I would hate to see a repeat of the Google Play or Apple App store in Web3.0 regarding both access limitations and cost implications. On top of that, if for some reason MetaMask were to be deprecated one day, no one would want all those dapp plugins to go to waste.
User and Developer Experience:
Integration speed/missing dapp features should not limit the user experience. I think this point has already been made fairly clear. Developer experience currently suffers from two issues:
Because of product composability, anyone can build anything. But who is responsible for building what?
What are the criteria for becoming integrated with a wallet or an aggregation platform?
I think we suffer from a lack of protocol SDK standardization, leading to many frontend/wallet developers having to figure out and build their own connections. On top of that, most wallets don’t have a clean dapp integration method (deeplinks don’t count), and Zapper relies on an opaque requests system. This is pretty painful for all parties.
But there are positive examples, too. Some protocols like Uniswap and Superfluid do have their own great Javascript SDKs. I already mentioned MetaMask snaps on the wallet integration side, but Zerion (though not a wallet) also has a great integration SDK and open adapter marketplace. Having quick and independent integration methods from protocol to wallet leads to a superb developer experience, where any developer can realistically put together the pieces. I want to emphasize this applies to base protocol interfaces, and that extensive features like analytics and education should be built directly onto a dapp page (outside the wallet) to provide a stronger or niche user experience that can’t be captured in the wallet. I think is fine that way as those features aren’t core to access.
With all this in mind, wallet teams can focus on building the composable platform and marketplace and dapp developers can focus on the SDK and plugin development for easy integration. Having more standardization could be as helpful as the many EIPs created for wallets and libraries (if anyone wants to work with me on that, please do reach out).
Final Thoughts
The ideas for this article came about as I was researching for and conversing with wallet builders for Build With Consensys (every Thursday at 1 pm EST in discord!). During my research, I came across some of Dan Finlay’s (founder of MetaMask) old videos from DevCon5 in 2019. I felt that his thoughts on wallet composability hadn’t caught the same firey passion dapp composability got. He’s been pushing this since much earlier in time, as Dan mentioned in this article:
“At Devcon 2, I went on stage and I called for a decentralized standards body. I begged the other web3 wallet developers to come together, rally around a shared test suite, and give developers a platform that is stable across clients. While there was some real passion and interest (shout out to Casey Detrio), ultimately inaction and coordination costs relegated this dream to the space of fantasy.”
So while this article is partially informative, it is also a plea for us (as users and developers) to spend more time thinking and building out this important space before the new applications I spoke about arrive. In Dan’s words, it will help us provide a more secure, usable, and useful Ethereum experience. In my words, it means that everyone has composable access to Ethereum.
Thanks to Thomas Rush for the edits