Wallet-as-a-Service (WaaS) Provider Selection Guide: Comprehensive Evaluation of Technology, Features, and Performance
TechFlow Selected TechFlow Selected
Wallet-as-a-Service (WaaS) Provider Selection Guide: Comprehensive Evaluation of Technology, Features, and Performance
This guide will explore the factors to consider when selecting a WaaS service, helping you make an informed decision.
Navigating Web3 tides with focused insightsWritten by: Carlos Maximiliano Cano, Ethan Francis
Compiled by: TechFlow
As the Web3 ecosystem intensifies efforts to develop mass-market products, the demand for friendly and engaging applications and user experiences has become increasingly urgent. In this context, Wallet-as-a-Service (WaaS) tools have emerged to address critical challenges on both sides. For developers, they simplify dApp development through customizable tooling, enabling the embedding of highly optimized in-app Web3 wallets tailored to specific product needs. These wallets can integrate with other tools—such as social and Web2 login features—to streamline Web3 interactions for users, reducing friction associated with wallet setup, transactions, signing, interoperability, and complex interfaces.
If you're a developer, WaaS tools can make your life significantly easier. However, choosing a provider can still be challenging due to numerous factors involved. This guide explores key considerations when selecting a WaaS service, helping you make an informed decision.
Private Key Management Mechanisms
WaaS tools make using dApps and creating associated wallets highly practical via social logins and embedded wallets—especially for mobile products. However, this must align with core Web3 principles such as user sovereignty and decentralization. How these values are upheld determines whether a wallet is custodial or non-custodial, influences user signature flows, and ultimately affects how close or distant users feel from true Web3.
Whether a specific WaaS service is considered custodial or non-custodial ultimately depends on how it handles user private keys. Different private key management mechanisms involve varying trade-offs in security, reliability/efficiency, and custodial risk. As a developer, your goal should be to understand these mechanisms to best protect user data and assets while meeting specific application needs.
Let’s examine the main approaches available in the market—KMS, MPC-SSS, MPC-TSS, and combinations of KMS with MPC-TSS—including their characteristics. Note that although we aim to provide comprehensive coverage of each method, different providers implement them differently. Therefore, treat this information as a starting point for forming your own assessment of individual providers.
Key Management System (KMS)
KMS is a solution for storing and managing cryptographic keys. It refers to an environment where encrypted private keys are stored—often in full. KMS mechanisms use strong encryption standards and controlled access protocols to maintain security. While their implementation offers straightforward operation, certain trade-offs exist.
When evaluating systems using only KMS, consider the following:
-
Custodial risk: If configured as custodial, KMS may leave users without full control over their keys—an important risk in decentralized environments. For example, solutions like Magic use KMS and claim to be non-custodial, but storing keys via services like AWS means those providers ultimately retain control. Technically, this gives the provider the ability to decrypt keys by changing key policies.
-
Centralization risk: Relying on a KMS provider introduces a single point of failure—if the provider goes down, so does access. Using KMS-dependent solutions requires high trust, as the business relationship between the WaaS provider and the KMS provider means the former may still have access to keys. Additionally, providers may discontinue support for various reasons, causing issues for end users.
Multi-Party Computation - Secret Sharing Scheme (MPC-SSS)
MPC-SSS combines the advantages of distributed computing and key sharding. It allows multiple parties to jointly compute functions while distributing key shares among them. This enhances security, as operations require a threshold of key shares without exposing the original key to any single party.
Importantly, MPC-SSS reconstructs private keys on the client side during generation and usage, creating a narrow single point of failure. This could allow someone else to obtain a user's private key without their knowledge, posing a custodial risk under the guise of decentralization.
One popular service using MPC-SSS is Privy, which embeds self-custodied wallets protected by hardware and managed through isolated iframes. Privy stores private keys only in memory, minimizing exposure. This ensures private keys are never exposed to Privy or the integrated app, making the solution fully non-custodial (though keys are still reconstructed during use and creation).
Web3Auth V1 also uses MPC-SSS, though it employs MPC-TSS for certain products (like its core SDK). Its MPC-SSS implementation is often referred to as "shallow MPC," used in plug-and-play SDKs.
MPC-SSS systems can be combined with KMS systems.
KMS + MPC-SSS
Combining KMS with MPC-SSS aims to balance user control with administrative convenience. While this system doesn't necessarily affect the custodial nature of the service, it may offer enhanced security at the cost of efficiency.
For hybrid solutions, developers need to assess potential complexity arising from interactions between independent systems, measuring latency through key retrieval and computation times. Popular solutions like Venly use MPC-SSS to shard passwords for accessing KMS services that store user private keys.
KMS + MPC-SSS solutions inherit the risks of pure KMS setups, as they do not fundamentally resolve the centralization issues inherent in KMS. The same concerns about MPC-SSS also remain, and developers should stay vigilant.
Multi-Party Computation - Threshold Signature Scheme (MPC-TSS)
MPC-TSS enables multiple parties to collaboratively sign transactions or compute functions, distributing responsibility across participants. This improves security by ensuring no single party has full control over the key. In WaaS use cases, it also ensures no third party can spend user assets, offering the highest level of security when properly implemented, while avoiding the complexity of hybrid methods or custodianship. Most MPC-TSS implementations achieve non-custodial status without sacrificing efficiency.
For MPC-TSS, developers should test overall latency. Understanding the threshold settings and security model of a particular implementation is crucial to ensure alignment with project requirements.
Particle Network provides an advanced TSS approach, ensuring private key security isn't centralized within a single entity. This method splits the key into two parts stored separately, with neither part revealing any information about the complete key. One share is stored locally by the user, and the other in Particle’s Trusted Execution Environment (TEE). All cryptographic operations are performed without combining the shares, preserving key integrity.
Particle also allows users to create a master password to encrypt the local key share, which can then be securely stored. This enables fully secure wallet recovery across devices. The robustness of this system is further enhanced by continuous key share refreshing, making attacks nearly impossible.
Note that interoperability and latency vary across all the above methods. It's essential to verify that the intended solution covers at least your most relevant blockchain networks and provides reliable information on potential latency. We've also created the diagram below to illustrate the strengths and weaknesses of each method:
Evaluating Documentation Completeness
Developers using WaaS services typically adopt one of two distinct approaches:
- Quick Start: These developers prioritize diving into the codebase quickly, favoring rapid understanding, fast action, and readily available tools, learning as they go.
- Comprehensive Understanding: Others prefer thoroughly reviewing documentation before writing any code, seeking a deep understanding of system architecture, capabilities, and limitations.
If you fall into the first category, finding a balance between both approaches during development can streamline the process. The gold standard would be being able to start using the SDK within 10 minutes, yet having enough information to understand what lies ahead. Beyond reading this guide, some additional points to consider when evaluating relevant WaaS scenarios include:
- Debugging Information: Do you have all the necessary information to debug when needed? For instance, when a transaction fails, does the WaaS SDK provide detailed error logs to help identify the issue?
- Useful and Comprehensive Guides: Does the documentation include simple, practical guides? Are there step-by-step instructions for integrating the WaaS SDK across various blockchain networks?
- Accessibility of Answers: Are answers to common work-related questions easily accessible (with examples)? Is there a FAQ section or community forum where user questions are publicly and promptly answered by team members? Is the FAQ current and well-maintained?
- Interactive and Navigable Documentation: Is the documentation interactive and easy to navigate? Is it engaging and informative? Does it include interactive code snippets to demonstrate real-world behavior, or sandbox environments for live testing?
- Engaging Content and Information Depth: Can the documentation guide you through the entire process? Does it include quick-start guides? Are the guides engaging, with visual aids (such as diagrams explaining transaction flows) and video tutorials for complex integrations?
- Comprehensive Guidance: Does the documentation include beginner guides for setting up wallets, as well as guidance on more advanced features like managing multiple wallets or interacting with various blockchain networks?
- Quick Start Guide: Is there a quick start guide to help you set up a wallet, send and receive transactions within minutes?
Building a solid foundational understanding and evaluating available tools early is crucial to avoid future complications. By quickly checking the above points, you can acquire necessary knowledge while progressing at your preferred pace.
Richness of Feature Integration
When assessing the strengths of a Wallet-as-a-Service (WaaS) platform, the richness of upstream and downstream feature integration is a significant factor. This reflects the platform’s ability to deliver powerful, versatile, and user-centric services. It's also important to understand whether these integrations are native or require additional third-party services. Such integrations can greatly enhance user experience and ease transitions between fiat and crypto ecosystems.
Below are key areas where rich feature integration shines:
Support for Account Abstraction
Native compatibility with AA, whether through dedicated modules or direct SDK partnerships, is crucial. Integrating AA demonstrates a platform’s adaptability to diverse use cases and its commitment to seamless user experiences. The diversity and depth of integration matter, as they ensure developers have the tools and support needed to build intuitive and user-friendly dApps.
For developers, WaaS platforms with native AA implementation enable better utilization of different components within the AA stack without needing manual configuration of third-party tools—simplifying the experience and improving implementation efficiency.
Particle Network offers a vertically integrated solution, having independently developed both its WaaS and AA stacks, directly incorporating AA into its WaaS product. Particle also supports using Biconomy’s AA stack while maintaining cross-compatibility with other providers. By supporting AA, WaaS providers can transform rigid wallet interactions into flexible, programmable experiences, resulting in smoother end-user experiences.
On the WaaS side, some ideal AA tools and components that can make your dApp more user-friendly include:
1. Smart Contract Wallets: AA enables programmable smart contracts to act as non-custodial wallets, unlocking advanced automation features. This leads to more flexible and user-centric digital asset management.
2. Session Keys: This simplifies transaction flows that don’t require repeated signatures, enhancing UX. It also allows pre-approved transactions, making the system more user-friendly.
3. Paymasters: One prominent use case of AA is allowing dApps to sponsor user gas fees, enabled by paymasters. This is particularly valuable for L2-based solutions, which are typically low-cost for users. Paymasters allow your dApp to accept gas payments in any native (non-bridged) token.
4. Bundler: A bundler can aggregate user operations for efficient blockchain interaction, potentially reducing transaction costs and speeding up confirmation times. This improves cost-effectiveness for end users and performance for developers.
5. Social Recovery: AA can enable social recovery, allowing users to recover wallets with the help of whitelisted accounts instead of relying on seed phrases—potentially improving both security and user experience.
Particle has also developed its own bundler and paymaster, which projects can integrate to simplify blockchain interactions. Particle is also working toward cross-chain account abstraction, aiming to create a unified framework across AA solutions deployed on different chains.
Fiat On-Ramps
Various fiat on/off-ramp integrations are highly attractive in a WaaS platform. Using fiat ramps is especially appealing because it allows users to directly deposit USDC/USDT without needing to buy native crypto tokens or rely on centralized exchanges—enabling a smooth transition from Web2 to Web3.
It’s important to investigate whether these integrations are native or require additional third-party services. Either way, they can significantly enhance user experience and make switching between fiat and crypto ecosystems much easier.
Cross-Chain Bridges
Facilitating cross-chain bridging reflects the versatility of a WaaS platform. Evaluating the underlying services used for cross-chain interactions (e.g., Particle uses li.fi) and their integration quality is crucial. Strong bridge functionality opens up new capabilities and reduces friction as the blockchain ecosystem evolves toward multi-chain, scalable roadmaps—improving experiences for both users and developers now and in the future.
Swap
Some wallets may integrate trading functionality directly into their UI. Whether through native features or partnerships, exchanges are among the most fundamental Web3 capabilities. It's important to evaluate supported swap types, underlying services (e.g., Particle uses 1inch), ease of execution, and overall user experience.
Other API Endpoints
Ensure you investigate other API endpoints provided by the WaaS platform for Web3 interaction or UX impact. Also assess the level of customization these endpoints offer. For example, they might provide access to contract locking, log retrieval, token management, analytics, managing certain DeFi interactions, and interfacing with various markets.
Multi-Chain Support
Support for multiple blockchain networks is a hallmark of a robust WaaS platform. It signals adaptability and readiness for an expanding ecosystem. Developers should check the number of supported chains, ease of switching between them, and the level of support offered per chain.
Modularity Assessment
A modular stack resembles a toolbox, with each tool designed for a specific task. Modular systems empower developers to select and implement only the modules they need, customizing the solution to meet unique requirements. In contrast, monolithic systems bundle tools into a single inseparable unit—integration may be easier, but flexibility is minimal or nonexistent.
A well-designed modular approach offers flexibility and scalability, allowing developers to easily replace or update individual modules without affecting the rest of the system. The gold standard for modularity should strike a balance—easy to integrate while allowing maximum flexibility. Developers should look for independent modules matching their intended use cases, designed in a way that supports such flexibility. Examples of use cases supported by modularity include:
- Authentication: Modular systems may offer various authentication modules such as multi-factor authentication, biometric authentication, or social login. This closely relates to the project’s ability to link user identity to their wallet.
- Cross-Compatibility: The easier it is to access different networks or switch between them, the more flexible and developer-friendly the service. Web3 wallet services can also support cross-chain and interoperability modules.
- Account Abstraction: As discussed, implementing AA is important. A modular WaaS platform may offer an AA module that can be easily integrated, separating AA from the core product and making it optional. The AA module itself can also be modular, supporting different functionalities within a stack. Particle Network’s WaaS supports a modular AA stack, allowing developers to choose either Particle’s own AA stack—including bundler, smart accounts, etc.—or build their own or integrate SDKs from other providers like Biconomy, ZeroDev, StackUp. Below is a schematic illustration of Particle Network’s modular AA WaaS design:
- Product Customization: Through custom UI modules, developers can ensure brand consistency by integrating color schemes, logos, and other graphical elements. But this isn’t limited to design—it can extend to functional aspects like transaction limits, custom fee structures, or special approval workflows.
- Interoperability with Other Services: A modular WaaS platform can include modules that facilitate easy integration with third-party services or platforms. For example, it could enable interaction with exchanges and cross-chain platforms, or even allow you to customize your own integrations.
Web3 Wallet Performance Metrics
When integrating services, it’s important to recognize that different providers may perform differently across various dimensions. Two key metrics are wallet creation time (from clicking “Connect” to wallet availability) and repeat user login time. These performance indicators may be influenced by the underlying management system of each solution.
To illustrate, we measured the time required for different WaaS tools to create a Web3 wallet via Google authentication, shown in the chart below. We encourage you to test various providers’ products firsthand to understand the user experience.
Web3 Wallet Performance Metrics
When integrating services, keep in mind that different providers may perform differently across various areas. Two key points are wallet creation time (from the moment a user clicks “Connect” to when the wallet becomes available) and repeat login time. These performance metrics may be affected by the underlying management system of each solution.
To illustrate this, the chart above shows our measurements of different WaaS tools creating a Web3 wallet via Google authentication. We encourage you to test different providers’ products to understand the user experience.
The chart below shows a horizontal comparison of connection time and steps required when connecting wallets via Particle versus MetaMask and other WaaS tools.
Social Proof and Market Presence
Other social proof indicators can provide tangible evidence of a solution’s viability and market acceptance. Metrics such as SDK download counts and active users can reflect trust and adoption levels. A direct way to access these metrics is searching individual SDK packages on Npm-stat. Note that download numbers may be influenced by PR, incentives, and other marketing activities, so these figures should not be used in isolation for decision-making, but rather as part of a broader, deeper analysis.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@ParticleNtwrk
