Deciphering Wallet Infrastructure: Choosing Your Ideal Solution
Looking at the transformative journey of Wallet-as-a-Service (WaaS) from 2022 to now. All needed insights into selecting the right provider for streamlined blockchain interactions.
One of the largest barriers to adopting web3 is the complexity of the onboarding process. Using a web3 application requires a wallet, the setup of which can involve understanding complex concepts like seed phrases, transaction signing, and gas fees.
However, the wallet sector is undergoing significant transformation, with innovative technologies aiding in user acquisition for our decentralized application and simplifying the user experience.
When we began the Bloom journey in early 2022, the wallet landscape was quite different from today. Wallet-as-a-Service (WaaS) offerings were just starting to appear, but the user experience was lacking. Fast forward two years, and although we've made substantial progress, there's still a lot more to achieve.
Before delving into the current wallet experience, it's crucial to understand its origins and why such complex concepts are needed in the user journey.
Here's what the process of setting up a traditional wallet for decentralized application interactions typically looks like:
Some of you may have been lost by step two. This shows how complex the process can be for beginners.
At its core, a wallet is a software tool that handles your secrets (the seed phrase mentioned above) and keys required to create signatures. Why are these signatures important? It's simple. Whenever a user interacts with the blockchain, to write or change data, a signature is needed. This signature is made using the specific secrets or keys managed by your wallet. Therefore, the safety and security of these keys are vital, as they validate and authorize your blockchain account transactions. Essentially, the primary function of a wallet is to protect these secrets while making interactions with the blockchain easier. If your wallet ends up in the wrong hands, your keys are at risk, and your assets are exposed.
Unveiling the Emergence of Gen1 WaaS (Wallet-as-a-Service)
In 2022, several pioneering companies introduced what we now call the first generation of Wallet-as-a-Service (WaaS). Their goal was simple: to make the process outlined earlier a bit easier.
The user experience with Gen1 WaaS
As shown in the table above, Gen1 WaaS significantly improves the previous web3 onboarding experience.
Let's explore this further.
The first WaaS solutions addressed a key problem: the need to download an external wallet app or browser extension. Without going into technical details, these solutions included built-in wallet features. This smart move saved developers from having to make a wallet for their applications, while also saved users from having to leave their main interface. The result was a smooth user experience with built-in wallets, allowing users to manage transactions and assets without leaving the app.
The real breakthrough in the first wave of WaaS was the new way of backing up secrets and managing keys. These new solutions cleverly introduced an abstraction layer that simplified these critical steps. This layer made the user experience easier by letting users use familiar methods like email or social logins to access their keys and sign transactions.
Authentication through Familiar Web2 Methods
Let's delve deeper into some of the authentication options and weigh their pros and cons.
Social Login
Social login authentication is widely popular in web2 applications as it simplifies user onboarding by eliminating extensive registration forms. Notable social login options include Google, Facebook, and Twitter. Using these social login providers offers the benefit of their existing security measures. Most enforce two-factor authentication (2FA) and often include additional layers like geolocation tracking and IP filtering. However, there are some downsides to consider. Some users may have concerns about sharing their social profile data, and by using social logins, we give tech giants more control over user data. This contradicts the principle of blockchain – giving users control over their data (I know I light sound a little idealist here 😅).
PIN Code/Password
Another common authentication method involves the use of PIN codes or passwords. While familiar to most users, this method raises significant concerns. The main problem is recovery – the likelihood of users forgetting their code is far from negligible. When a user is locked out due to a forgotten PIN, two scenarios emerge:
The wallet provider can recover the PIN: This raises a major red flag (🚩), indicating that the wallet provider likely operates as a custodial wallet, where the provider takes custody of the user's private keys.
The wallet provider cannot recover the PIN: This shows the risks of giving users full control. If a user forgets their PIN here, they cannot recover it (unless they have another way to authenticate). They lose access to their account and funds.
Moreover, this authentication is susceptible to brute force attacks unless extra security layers are added.
Passkey
Let me start by stating that I'm a strong supporter of passkeys. I believe they are the future of authentication, not only for web3 applications but also for web2 applications. Passkeys are part of the WebAuthn standard, using device and operating system capabilities to generate and secure cryptographic key pairs.
Have you ever authenticated into your Google account using touch ID or used face ID to access your bank account app? You may not realize it, but you're using what's technically known as a passkey!
What if I told you that you could also authenticate into your wallet and sign transactions using biometrics, such as touch ID or face ID? What a seamless user experience, right? It's no wonder I'm a fan. However, despite its allure, passkeys come with their own set of drawbacks (and believe me, our tech team has grappled with these).
Before diving headlong into passkeys, it's crucial to understand that a passkey is tied to a specific device and domain. While this association with a particular device enhances security by making unauthorized access more challenging, it can also pose significant challenges to user experience. For instance, if Bob creates an account and passkey on his computer, he won't be able to log in later using his phone, as the passkey is tied to his computer. There are potential workarounds, such as requiring users to create at least two passkeys or mandating passkey creation on a mobile device for cross-device compatibility. Another alternative is cloud synchronization, which works seamlessly for users leveraging platforms like iCloud or Google Cloud but may not be available on all platforms.
Don't overlook the second association – the association with a domain. Let's revisit Bob's scenario. Suppose he creates an account and passkey to access alice_cats.com. Later, you launch another application, alice_dogs.com, and want users to access it using the same account from alice_cats.com. Unfortunately, Bob won't be able to log in using his existing passkey, as it's tied to alice_cats.com. Workarounds exist, like creating passkeys in a separate tab (creation from iFrames will be available soon), that can be used across different applications. However, careful planning is crucial from the beginning.
The WebAuthn standard, although still under development and facing some initial issues, is supported by major industry players. Enhancements to address these challenges are anticipated in the near future.
Decrypting key management
It sounds smart, doesn't it? However, while this abstraction layer provides convenience, it's essential to look behind the scenes to ensure the security of these precious keys.
Cryptographic key management mechanisms
Below this abstraction layer is a complex world of cryptographic methods for managing keys. Each method presents a unique balance of security, reliability, efficiency, and conservation. Grasping these subtleties is crucial for navigating the ever-changing WaaS landscape.
KMS (Key Management Systems)
KMS systems are environments in which encrypted private keys are stored in their entirety. These mechanisms employ strong encryption standards and controlled access methods to ensure security.
Risks
Custody - Technically, the provider has the ability to recover the keys by modifying their key policy.
Centralization
Risk of a Single Point of Failure (SPOF): This can occur if the provider ceases operations.
Trust in the provider's storage provider is also necessary (for instance, AWS).
Market solutions using this technology
Magic
Turnkey
Dynamic
MPC-SSS (Multi-Party Computation Shamir’s Secret Sharing)
Mechanisms of MPC-SSS combine the advantages of distributed computations and secret sharing. Such configuration enhances security by necessitating a threshold of shares to execute actions, without exposing the original secret to any single party.
Risks
These solutions generate and use private keys on the client side, which could potentially lead to a user's private key being obtained by others without the user's knowledge.
Market solutions using this technology
web3auth v1
Privy
Capsule
KMS combined with MPC-SSS
In KMS+MPC-SSS systems, the keys reconstructed from MPC-SSS are temporarily stored in the KMS system. This combines centralized key management with fractionation. This setup provides increased security compared to a basic Key Management System (KMS), though it might potentially affect efficiency. It's worth noting that this system does not necessarily impact the level of service custodianship when compared to KMS.
Risks
Same risks as the solution for centralized storage of the entire key.
Same risks as the solution managed through distributed computations and fractionation of the key.
Market solutions using this technology
Venly
MPC-TSS (Multi-Party Computation-Threshold Signature Schemes)
MPC-TSS enables multiple parties to co-sign transactions or compute functions, thereby distributing the responsibility among them. It ensures that no single party maintains total control over the secret (key). The most significant innovation of MPC-TSS is that the key is never reassembled.
Risks
According to the implementation there is a risk of efficiency loss.
Market solutions using this technology
DFNS
web3auth v2
Particle Network
Portal
Choosing the Right WaaS Provider
WaaS providers may seem similar at first glance. But as you've found, there are vital differences to keep in mind. Each option can greatly affect your platform's functionality, security, and user experience.
There's no one perfect solution, as different platforms have unique needs. So, we can't outright say which provider is the best.
We think that cryptographic key management and authentication methods are the main things to consider when choosing a WaaS provider. Drawing from our experience at Bloom, here are some key points to think about when comparing providers on these factors.
Legal Aspects on Custodianship
The web3 ecosystem can feel like the Wild West soimetimes, but digital asset custody is a serious matter in most regions. If you're providing a wallet solution from your platform to your users, it must comply with the legal frameworks in your region.
Understanding the difference between custodial and non-custodial wallet solutions is key to comparing available providers effectively.
Custodial wallets
In a custodial setup, the wallet provider retains control over the secrets enabling funds transfer on behalf of the user.
Depending on the jurisdiction, custodial wallets can fall under financial regulations due to their nature, potentially subjecting them to banking laws, anti-money laundering (AML) rules, and know-your-customer (KYC) procedures.
Non-Custodial wallets
In a non-custodial setup, the user maintains control over their secrets. The wallet provider cannot execute a valid transaction without specific user-held signatures, which may be facilitated through authentication methods like Google Authentication or passkeys, for example.
Therefore, before making any decisions, ensure you understand the legal aspects of custodianship and pay attention to potential developments in the near future.
Interoperability with other applications
Another critical aspect that is often overlooked until it's too late is interoperability with other applications. It's crucial to consider from the outset if the assets your users acquire from your application will need to be used in other decentralized applications.
There are different possibilities for ensuring interoperability. The easiest one is to make the wallet available through platforms like WalletConnect or RainbowKit, but whether this is feasible depends on how the WaaS has been implemented. Another "last-resort" option would be to include transfer functionalities in your application, allowing users to transfer their assets to an external wallet. However, this may not offer the best user experience, and users would need native tokens to cover transaction fees (🤯).
User’s opt-out
Another crucial consideration before it's too late is contemplating the possibility that a user might desire to switch to another wallet for a different experience. For instance, as they gain a better understanding of the web3 ecosystem, they might prefer transitioning to a classic web3 wallet such as Metamask or a cold wallet like Ledger. If offering this flexibility to your users aligns with your objectives, it's imperative to ensure that your solution allows for the export of their keys.
Considering a Switch to a New WaaS Provider?
Considering a switch to a different Wallet-as-a-Service (WaaS) provider? Proceed with caution. Such a switch will likely necessitate action from your users and could potentially result in financial implications for them, as they might have to cover the gas fees to transfer their assets to the new solution.
At Bloom, we strive to provide the best user experience while ensuring users keep control and security over their assets. We regularly check the market to see what's out there. While a different solution might seem appealing because of its new features, any change must provide significant value to users to justify the potential disturbance.
The decision gets even more complex with the ongoing changes in wallet infrastructure, especially the move towards Smart Accounts, the next step in this field.
Smart Accounts are a new way to manage wallets and assets. They improve the user experience significantly compared to the first generation of WaaS. By using smart-contracts to separate the control of digital assets from account management, Smart Accounts offer a lot of new possibilities in the web3 world.
However, the adoption of Smart Accounts is still new, and the industry is waiting to see if it's a good fit. The recent standardization through ERC-4337 is a big step forward, allowing everyone in the ecosystem to work together on its development. But it's still unknown whether Smart Accounts will strictly follow the ERC-4337 specification or if there will be customizable plugins or specifications that achieve a good product-market fit.
We're keeping a close eye on these changes, and our next article will focus on this important subject. So, if you're thinking about changing your WaaS provider, wait for now and keep an eye out for our upcoming article on Smart Accounts 🔥.