Social Logins & Embedded Wallets In Web3: Choosing A WaaS Provider

As the Web3 ecosystem doubles down on its intention to create mass-consumption-ready products, there is a pressing need for friendly, attractive applications and user experiences. 

Central to this shift is the rise of embedded wallets, which allow users to interact with dApps without a complex setup. As such, Wallet-as-a-Service (WaaS) tools are critical to facilitate the adoption of the embedded wallets paradigm. For developers, they simplify the creation of dApps via customizable tools to build their projects, allowing them to embed highly UX-optimized in-app Web3 wallets that adapt to their product’s unique needs. 

Embedded wallets can be integrated with other tools, such as email or social Web2 login methods, in a way that makes interactions with Web3 smoother for users, reducing the friction created by setting up wallets, transactions, signatures, interoperability, and complex interfaces. 

If you're a developer, WaaS tools can make your life easier. However, it might still be tricky to choose a provider, as there are a multitude of factors involved in this decision. In this guide, we’ll explore the different considerations to keep in mind when picking a WaaS service, helping you make an informed decision.

Private key management mechanisms

WaaS tools make the process of using dApps and creating wallets linked to them very practical through social logins and embedded wallets, particularly for mobile products. However, this needs to happen in line with user autonomy and decentralization, two core tenets of Web3. Whether these values are upheld can result in either a custodial or a non-custodial wallet, and different processes for user signatures –ultimately driving users closer or farther from Web3. 

Whether a particular WaaS can be considered custodial or non-custodial ultimately depends on their treatment of users’ private keys. There are different mechanisms for private key management, all with different strengths and trade-offs in security, reliability/efficiency, and custodianship. As a developer, your goal should be to understand these mechanics so that you can best protect your users’ data and assets while adapting to your unique needs.

Let’s take a look at the different approaches available in the market –KMS, MPC-SSS, MPC-TSS, and KMS combined with MPC-TSS– and some of their main representatives, as well as their characteristics. Note that, while we aim to present you with comprehensive information on each approach, different providers have different implementation styles. As such, you should consider the information here as a starting point to form your own opinion on individual providers.

Key Management Systems (KMS)

A KMS is a solution for storing and managing cryptographic keys. It is an environment in which encrypted private keys are stored, usually in whole. KMS mechanisms use robust encryption standards and controlled access mechanisms to preserve security. Their implementation results in a straightforward operation, albeit subject to the trade-offs we’ll explore below.

When reviewing a system that only utilizes KMS (others might combine it with other approaches, as you’ll see below), keep the following in mind:

Custodial risk: If the KMS is configured to be custodial, your users might not have full control over their keys. This can be a significant risk in a decentralized setting. Solutions like Magic use KMS and, although they advertise their solutions as non-custodial, it’s important to keep in mind that, by using services like AWS to store keys, they ultimately retain control over them. Such a solution where a WaaS retains full control over control technically gives a provider the ability to decrypt keys by changing their key policy.

Centralization risk: Reliance on a KMS provider could result in a single point of failure, creating issues should a provider stop working for any reason. There is also a lot of trust involved in using solutions relying on KMS, as the nature of their business relationship with a KMS provider (e.g. AWS) results in, even if indirectly, the WaaS provider retaining full access to keys. It’s also important to keep in mind that a given provider might choose to end support to a given service for whatever reason, leading to problems for end users. 

Multi-Party Computation Shamir’s Secret Sharing (MPC-SSS)

MPC-SSS mechanisms combine the benefits of distributed computations and secret splitting. They allow multiple parties to jointly compute functions over inputs, distributing the secret (key) into shares. This setup enhances security by requiring a threshold of shares to perform actions, without revealing the original secret to any single party. 

It’s important to consider that MPC-SSS recovers private keys on the client side, constructing them both during generation and use, creating a narrow single point of failure. This could lead to a user’s private key being obtained by others unbeknownst to them, resulting in custodianship risks sometimes disguised as decentralized solutions.

One popular service using MPC-SSS is Privy, which offers embedded wallets that are hardware-secured, self-custodial, and managed via an isolated iframe that handles wallet operations. Privy only stores private keys in-memory, minimizing exposure. This means that private keys are never exposed to either Privy or the integrating applications, making the solution fully non-custodial (although these keys are still re-constructed during usage and creation). 

Web3Auth V1 also uses MPC-SSS, although it also uses MPC-TSS for certain products (e.g. their core SDKs). Their implementation of MPC-SSS is typically characterized as a "shallow MPC", and it’s used in their plug-and-play SDKs.

MPC-SSS systems can be combined with KMS ones (see below).

KMS + MPC-SSS 

Combining KMS with MPC-SSS merges centralized key management with distributed secret sharing, seeking to balance user control with ease of management. While this system does not necessarily have an impact on the service’s custodianship degree, it does provide for higher security, although potentially at the cost of efficiency.

With hybrid solutions, developers need to evaluate the potential complexities caused by the interaction of separate systems. They should also evaluate latency by measuring key retrieval and computation times. One popular solution with this system, Venly, uses MPC-SSS to shard passwords to access the KMS service that stores users’ private keys. Their system is represented below.

KMS + MPC-SSS solutions retain the risks of pure KMS solutions, given that the solution does not intrinsically solve the above-mentioned KMS centralization issues. The same applies to the issues with MPC-SSS identified above, something that developers should be aware of. 

Multi-Party Computation-Threshold Signature Schemes (MPC-TSS)

MPC-TSS (Multi-Party Computation with Threshold Signature Scheme) enables multiple parties to collaboratively sign transactions or compute functions, distributing the responsibility among them. This enhances security and ensures no single party has full control over the secret. In WaaS use cases, this also ensures that no third party ever is able to spend users’ assets. It also provides the highest security when properly implemented, while avoiding the complexities or custodianship of a hybrid approach. This also makes most MPC-TSS implementations non-custodial while retaining efficiency.

For MPC-TSS mechanisms, developers should test the system’s overall latency. It's essential to also understand the threshold settings and the security model of any given implementation to ensure it fits the project’s needs.

Particle Network provides a 2/2 advanced TSS approach that ensures that the private key's security is never concentrated in a single location or entity throughout its lifecycle. This method involves splitting the key into two independent shares stored separately, ensuring that each share reveals nothing about the full key. Of these shares, one is stored locally by the user, and the other by Particle’s Trusted Execution Environment. All cryptographic operations are executed without combining these shares, maintaining key integrity. 

Particle also opens the possibility for the user to create a Master Password to encrypt their local key fragment, which can then be stored safely. This makes users’ wallets accessible across devices with full security. The system's robustness is also reinforced by a continuous key share refresh mechanism, enhancing security and making an attack virtually impossible.

Note that, with all the above, interoperability and latency will vary. As such, it’s important that you review and ensure that your intended solution covers at least the blockchain networks you’re most interested in. Also, make sure that you’re able to find reliable information regarding potential latency. For easy access, we have also created the following chart demonstrating the strengths and weaknesses of each approach:

Evaluating documentation completeness

Developers setting out to use a WaaS service often align with one of two distinct approaches:

• Rapid initiation: This kind of developer aims to dive into the codebase as swiftly as possible. They prioritize a rapid understanding, a quick path to action, and readily available tools, learning as they go.
• Comprehensive understanding: On the flip side, some developers favor a thorough examination of documentation before writing code. They seek a solid understanding of the system’s architecture, capabilities, and limitations.

If you fall within the first kind, finding a balance between both approaches can smoothen the development journey. A golden standard could be gauged by the ability to get started using a Software Development Kit (SDK) in under 10 minutes with sufficient information to understand the road ahead. Besides reading this guide, some other points to assess, each paired with a relevant WaaS scenario, could be:

• Debugging information: Do you have all the information you need to debug if needed? Example: in a scenario where a transaction fails, does the WaaS SDK provide detailed error logs to help identify the issue?
• Useful and comprehensive guides: Do the docs contain straightforward, useful guides that you can rely on? Does the documentation offer a step-by-step guide on integrating the WaaS SDK, covering various blockchain networks?
• Accessibility to answers: Is there a way for you to find the answers to the questions you may have (with examples) during your work? Is there a FAQ section or a community forum where issues from other users have been publicly and timely addressed by a team member? Does the FAQ section seem current and well-maintained?
• Interactive and navigable documentation: Are the docs sufficiently interactive/easy to navigate? Are they engaging and information-rich? Are there interactive code snippets in the documentation that allow you to understand the code in action, maybe a sandbox environment to test in real time?

• Engaging content and information richness: Can these docs guide you through the whole process? Do they include quick start guides? Are the guides engaging, with visual aids like diagrams explaining the flow of transactions, and possibly video tutorials for complex integrations?
• Comprehensive guidance: Does the documentation include a start guide for setting up a wallet, and does it guide you through to more advanced features like managing multiple wallets, or interacting with various blockchain networks?
• Quick start guides: Are there quick start guides that can help you set up and perform basic operations like creating a wallet, sending, and receiving transactions within a short span?

Forming a solid foundation of understanding, and assessing the tools available down the road can be crucial to avoid headaches down the road. By running a quick check on the points above, you can make sure your knowledge is relevant while still progressing at your desired speed.

Feature integration richness

When assessing the merits of a Wallet-as-a-Service (WaaS) platform, the richness of feature integration upstream and downstream is a significant factor. This points to the platform's capacity to provide a robust, versatile, and user-centric service. It’s also important to understand which of these integrations happen within the embedded wallet and which, if any, require users to leave your dApp.

Here are some key areas where feature integration richness shines:

Support for account abstraction

Whether this happens via dedicated modules (see below) or not, the native compatibility with AA through direct SDKs and partnerships is crucial. Integrating AA signifies the platform's ability to mesh with various use cases and ensure a smooth user experience. Diversity and depth of integrations are vital, as this can ensure that developers have the necessary tools and support to create intuitive and user-friendly dApps.

For developers, a WaaS natively implementing AA can create a better foundation for using different components of the AA stack without having to incur manual configuration of third-party components. This results in a streamlined experience and higher implementation efficiency.

Particle Network has a vertically integrated solution, offering a self-developed WaaS and AA stack, integrating AA directly into its WaaS offering. Particle also supports the usage of Biconomy’s AA stack while also providing cross-compatibility with Openfort, Pimlico, Alchemy, and others, which can be found in our product documentation. Via AA support, WaaS providers can turn the current rigid wallet experience into a more flexible one through programmability, making the user experience smoother.

When it comes to WaaS, some desirable AA tools and components that a provider could incorporate to make your dApp friendlier could be:

1. Smart contract wallets: AA enables the creation of programmable smart contracts acting as non-custodial wallets for advanced automation capabilities. This can allow for a more flexible and user-centric approach to managing digital assets​. 
2. Session keys: This facilitates transactions that do not require signatures, simplifying the transaction process and enhancing user experience​. This feature also allows transactions to be pre-approved, streamlining the transaction process and making the system more user-friendly​.
3. Paymasters: One of the prominent use cases of AA is the ability for dApps to sponsor gas fees for users, which Paymasters enable. This makes particular sense in solutions hosted in L2s, which typically have low costs for users. Paymasters can allow your dApp to accept gas fee payments in any native (not bridged) token, preventing users from constantly needing to acquire gas tokens.
4. Bundlers: Bundlers aggregate user actions for efficient blockchain interactions, potentially leading to reduced transaction fees and faster transaction confirmations​. Bundlers can result in better cost-efficiency for end-users and better performance for developers. Check out the announcement of Particle’s open-source Bundler’s release for more details on bundlers’ capabilities.
5. Social recovery: AA can enable social recovery features, allowing users to recover their wallets with the help of whitelisted accounts instead of seed phrases, potentially improving security and user experience​.

In the case of Particle, we also have developed a proprietary Bundler and Paymaster that projects can integrate to make interactions with the blockchain simpler. Particle is also working on an Omnichain implementation of account abstraction, aiming to create a unified framework between AA solutions deployed in different chains, a feature currently overlooked by the Web3 ecosystem due to the nascent nature of the AA field.

Fiat ramps

A variety of integrations concerning fiat onboarding and offboarding are also attractive in a WaaS platform. Usage of fiat on-ramps is particularly attractive because it means that users can onboard directly USDC/USDT and never have to buy native crypto tokens or rely on CEXs, creating a smooth transition from Web2 to Web3.

 It's essential to investigate whether these integrations are native or require additional third-party services. These can all significantly enhance user experience, and make it easier for users to transition between fiat and crypto ecosystems. 

Cross-chain bridging

Facilitating cross-chain bridging speaks of a WaaS platform's versatility. Assessing the underlying services (in Particle’s case, li.fi) and integrations in place for enabling cross-chain interactions is essential. Strong cross-chain bridging capabilities can open doors to more functionalities and reduce friction as the blockchain ecosystem develops towards a chain-abstracted roadmap, smoothening the experience of users and developers in the present and future.

Swaps

Some wallets might integrate the ability to support swaps directly within their wallets’ UI. Whether through native functionalities or through partnerships and integrations, swaps are one of the most basic Web3 features. It's crucial to look into the types of swaps supported, underlying services (Particle uses 1inch), ease of execution, and user experience involved in these. 

Additional API endpoints

Make sure to investigate other API endpoints the WaaS platform utilizes to interact with Web3 or influence the user experience. You may also look into the level of customization these endpoints offer. For example, they may provide access to contract locking, retrieving logs, token management, analytics, managing certain DeFi interactions, interaction with various marketplaces, etc.

Support for multiple chains

The capability to support multiple blockchain networks is a hallmark of a robust WaaS platform. It signifies the platform's adaptability and readiness for an expanding ecosystem. Developers should examine the number of chains supported, the ease of transitioning between these chains, and the level of support provided for each chain.

Once again, the keyword in this section is customization, a key point that we’ll fully explore next.

Modularity assessment  

A modular stack is akin to having a box of tools, each designed for specific tasks. A modular system empowers developers to choose and implement the modules they need, tailoring the solution to their unique requirements. Its opposite are monolithic systems, which have tools bundled into a single, indivisible unit that can be easier to integrate, but with little to no flexibility. 

Well-designed modular approaches can result in flexibility and scalability, allowing developers to easily replace or update individual modules as needed without affecting other parts of the system. The gold standard of modularity would be a system that strikes a fine balance—easy to integrate while allowing for maximum flexibility. Developers should look for systems with standalone modules that serve their intended use cases, while designed in a way that supports this flexibility. Some examples of use cases supported by modules can be:

• Authentication: A modular system might offer various authentication modules such as multi-factor authentication, biometric authentication, or social login. This goes hand-in-hand with the project’s ability to manage users’ info and link it to their wallet, a point we addressed in “Private key management mechanics”.
• Cross-compatibility: The easier it is to plug into different networks or switch from one to another, the more flexible and developer-friendly the service is. The Web3 embedded wallet service can also support cross-chain and interoperability modules.
• Account abstraction: Above, we detailed the importance of implementing AA. Modular WaaS platforms might offer an Account Abstraction module that can be easily integrated to handle this ability, separating AA from the main product and making it optional to implement. AA modules can be modular themselves, supporting different functionalities within a stack. Particle Network's WaaS supports a modular AA Stack, allowing developers to choose the AA Stack developed by Particle Network itself, including Bundler, Smart Account, etc. Developers also have the option to develop their own or integrate SDKs from other providers, such as Biconomy, ZeroDev, StackUp, etc. The design schematic of Particle Network's Modular AA WaaS is shown below:

• Product customization: Through a custom UI module, developers can ensure brand consistency by integrating their brand's color scheme, logos, and other graphic elements. However, customization of the embedded wallet is not necessarily limited to design components, as it can also impact functional product aspects, such as transaction limits, custom transaction fees, or special approval workflows as per the business needs.

• Interoperability with other services: A modular WaaS platform could have a module that facilitates easy integration with other third-party services or platforms. For instance, it could enable the interaction with swapping and bridging platforms or even allow you to customize your own integrations.

Web3 wallet performance metrics

While integrating an embedded wallet service, it’s important to understand that different providers might perform differently in different areas. Two key areas to analyze are the time to generate a wallet (from the time a user clicks “Connect” to the wallet being usable), as well as the time for repeating users to log in. These performance metrics can be impacted by the underlying management systems of each solution.

To showcase this, we measured the time that different WaaS tools take to create a Web3 wallet using authentication through Google in the chart below. We encourage you to test different embedded wallet providers’ products to understand the experience of your users.

Social proof and market presence

Other social proof metrics can provide tangible evidence of the solution's viability and acceptance in the market. Metrics such as the number of SDK downloads and active users can indicate the level of trust and adoption for a service. A straightforward way to access these is by searching individual SDK packages at https://npm-stat.com/. Note that downloads might be influenced by PR, incentives, and other marketing campaigns. In other words, these numbers shouldn’t be solely considered to make a decision, only to be used as a part of a nuanced analysis.

About Particle Network

Particle Network powers chain abstraction, addressing Web3's fragmentation of users and liquidity. This is enabled by Particle's Universal Accounts, which give users a unified account and balance across all chains.

Website | Docs | Discord | Twitter