Wallet-as-a-Service (WaaS)

What Is Wallet-as-a-Service?

Wallet-as-a-Service (WaaS) is a category of cloud infrastructure that enables businesses to create, manage, and integrate cryptocurrency wallets through APIs and SDKs. Instead of building wallet infrastructure from scratch, companies can plug into a WaaS provider to handle key generation, transaction signing, balance tracking, and policy enforcement. The provider manages the underlying cryptographic complexity while the business focuses on its application logic.

Think of WaaS as the crypto equivalent of embedded finance: just as Stripe lets any app accept payments without building a payment processor, WaaS providers let any app offer wallet functionality without building a secure key management system. The pattern follows the broader infrastructure-as-a-service trend where specialized providers handle security-critical components at scale.

The WaaS market has grown rapidly alongside the push for mainstream crypto adoption. Enterprise-grade providers like Fireblocks process trillions in annual transfer volume, while developer-focused platforms like Privy (acquired by Stripe in June 2025) have onboarded over 75 million accounts. The market was valued at approximately $9.6 billion in 2025, with projections reaching $25 billion to $38 billion by the mid-2030s.

How It Works

At its core, a WaaS platform abstracts the three hardest problems in wallet infrastructure: key generation, transaction signing, and key recovery. The specific implementation varies by provider, but the general architecture follows a common pattern.

1. The application calls the WaaS API to create a wallet for a user, triggering secure key generation
2. Key material is generated and stored according to the provider's security model (MPC shares, TEE enclaves, or smart contract deployment)
3. The application uses signing APIs to construct and broadcast transactions on behalf of the user
4. Policy engines evaluate each transaction against configurable rules: spending limits, allowlists, approval workflows, and role-based access controls
5. Webhooks notify the application of balance changes, confirmations, and other wallet events

Security Models

WaaS providers differentiate primarily by how they secure private key material. Three approaches dominate the market:

• MPC (Multi-Party Computation): key shares are distributed across multiple parties so that no single entity can produce a valid signature alone. Providers like Fireblocks, Dfns, and Web3Auth use this approach. Fireblocks implements the MPC-CMP protocol for single-round signing, reducing latency compared to older MPC schemes.
• TEE (Trusted Execution Environment): key material is sealed inside hardware enclaves that prevent extraction even by the infrastructure operator. Turnkey uses secure enclaves to achieve signing times of 100 to 150 milliseconds. The provider's servers hold the keys but cannot access them outside the enclave.
• Smart contract wallets: spending policies are enforced on-chain through account abstraction patterns like ERC-4337. Coinbase's Smart Wallet and Crossmint use this model, where the wallet itself is a contract with programmable access controls, recovery mechanisms, and transaction validation logic.

Some providers combine multiple approaches. Privy uses 2-of-3 Shamir Secret Sharing alongside TEE infrastructure. Coinbase offers both MPC-based wallets and smart contract wallets with passkey authentication. The choice depends on the application's security requirements, chain support needs, and regulatory constraints.

Typical API Integration

A basic WaaS integration involves wallet creation, balance queries, and transaction signing. While APIs vary by provider, the interaction pattern is consistent:

// 1. Create a wallet for a new user
const wallet = await waas.createWallet({
  userId: "user_abc123",
  chains: ["bitcoin", "ethereum"],
  policy: "standard-consumer"
});

// 2. Get the wallet's deposit address
const address = await waas.getAddress({
  walletId: wallet.id,
  chain: "bitcoin"
});

// 3. Sign and broadcast a transaction
const tx = await waas.sendTransaction({
  walletId: wallet.id,
  chain: "bitcoin",
  to: "bc1q...",
  amount: "0.001",
  asset: "BTC"
});

Behind this simple interface, the provider handles key derivation using HD wallet standards, constructs the transaction, routes it through the policy engine for approval, signs it using the configured security model, and broadcasts it to the network.

Policy Engines

Enterprise WaaS platforms include policy engines that evaluate every transaction before signing. These engines enforce rules such as:

• Spending limits per transaction, per day, or per user
• Address allowlists and blocklists for outbound transfers
• Multi-party approval workflows requiring sign-off from multiple administrators
• Time-based restrictions on high-value transactions
• Sanctions screening and compliance checks integrated with chain analysis providers

Policy engines are what separate WaaS from raw key management libraries. They add the business logic layer that regulated entities need to operate compliantly.

The Self-Custody Spectrum

One of the most important distinctions among WaaS providers is where they fall on the custody spectrum. The key test: can the provider produce a valid signature without the user's participation?

• Fully custodial: the provider holds all key material and can move funds unilaterally. This is the traditional exchange wallet model. Simple to implement but creates custodial risk and regulatory burden.
• Non-custodial MPC/SSS: key shares are split so that the provider alone cannot sign. The user or a third party holds a required share. Fireblocks, Dfns, and Web3Auth offer this model.
• TEE-isolated: the provider's infrastructure holds key material, but it is sealed in hardware enclaves that prevent extraction. Turnkey and portions of Coinbase's infrastructure use this approach.
• Smart contract enforced: on-chain logic governs spending regardless of who holds the signing keys. Recovery, spending limits, and session keys are enforced by the contract, not by the provider.
• Full self-custody: the user holds complete key material locally with no provider involvement in signing. Some WaaS platforms support this as an option for advanced users.

Most modern WaaS providers position as non-custodial by design, letting businesses choose their custody model based on regulatory requirements and user sophistication. This configurability is a major selling point: a neobank serving retail customers might choose a more managed model, while a DeFi application might default to full user control. For a deeper comparison, see the research on self-custodial vs. custodial wallets.

Leading Providers

The WaaS landscape includes both enterprise-focused platforms and developer-first tools:

Use Cases

Fintech and Neobanking

Neobanks and fintech platforms use WaaS to add crypto features (stablecoin savings, Bitcoin purchases, cross-border transfers) without building wallet infrastructure. The WaaS provider handles key management, compliance tooling, and multi-chain support while the fintech retains control over the user experience. This is a core pattern in embedded finance: financial capabilities appear native to the app, with infrastructure partners invisible to the end user.

Gaming and Loyalty

Web3 games need wallets for in-game assets but cannot ask players to install browser extensions or manage seed phrases. WaaS enables embedded wallets that are created automatically during account signup, often authenticated via social login or passkeys. Players interact with tokens and NFTs without knowing they have a wallet. The same model applies to loyalty programs that tokenize rewards points.

Enterprise Treasury

Institutional teams managing crypto treasuries use WaaS for its policy engine and audit capabilities. Multi-party approval workflows, spending limits, and compliance integrations provide the operational controls that institutional risk teams require. Fireblocks alone supports over 2,400 institutional clients managing assets across its platform.

AI Agent Wallets

An emerging use case is wallets for AI agents that need to transact autonomously within defined boundaries. WaaS policy engines are well-suited for this: they can enforce per-transaction limits, restrict which contracts an agent can interact with, and require human approval above certain thresholds. Crossmint and Circle have both shipped agent wallet products.

Build vs. Buy

Building wallet infrastructure in-house requires deep expertise in cryptographic engineering, secure key storage, transaction construction across multiple chains, and ongoing maintenance as protocols evolve. Estimates for a production-grade in-house wallet system range from $1.5 million to $5 million over three years, requiring a dedicated team of 20 to 30 engineers for institutional-grade security.

WaaS integration typically costs $100,000 to $400,000 with per-wallet and per-transaction fees. The total cost of ownership is estimated at 50% to 70% less than in-house builds, excluding the opportunity cost of delayed market entry. However, WaaS introduces vendor dependency and may limit customization for teams with unique requirements.

For Bitcoin-specific wallet development, Spark's SDK offers a middle path: developers get the infrastructure benefits of a managed platform while building on Bitcoin's L2 stack. The SDK abstracts away Lightning channel management, routing, and liquidity operations, letting wallet developers add Bitcoin L2 support without operating their own nodes. For a comparison of SDK options, see the research on Bitcoin wallet SDK comparison.

Risks and Considerations

Vendor Lock-in

Migrating wallet infrastructure between WaaS providers is difficult. Key material may be stored in proprietary formats, MPC key shares may not be portable, and smart contract wallets are tied to specific chain deployments. Before choosing a provider, teams should evaluate key export capabilities and assess whether the provider supports open standards for wallet portability.

Security Concentration

WaaS concentrates security risk at the provider level. A compromise of the provider's MPC infrastructure, TEE implementation, or API authentication could affect all clients simultaneously. This is the fundamental tradeoff of shared infrastructure: operational simplicity in exchange for concentrated risk. Evaluating a provider's security architecture, audit history, and insurance coverage is critical.

Regulatory Uncertainty

Whether a WaaS provider qualifies as a custodian depends on its security model and jurisdiction. MPC providers argue that holding one key share does not constitute custody, but regulators have not uniformly agreed. The EU's MiCA framework and the US GENIUS Act are bringing more clarity, but the legal classification of different WaaS models remains an active area of regulatory development.

Latency and Availability

Because signing operations run through external APIs, WaaS adds latency compared to local signing. TEE-based signing (100 to 150 milliseconds) is faster than multi-round MPC protocols, but both add overhead. API availability becomes a hard dependency: if the WaaS provider experiences an outage, the application cannot sign transactions. Redundancy strategies and fallback signing paths are important for mission-critical applications.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.