You want to add a crypto wallet to your product. You start researching and hit three terms that all overlap: white-label wallets, embedded wallets, and wallet as a service. Marketing pages from infrastructure providers blur the lines. Most
By Team MoonPay
Published on Jun 5, 2026
Last modified on Jun 5, 2026
You want to add a crypto wallet to your product. You start researching and hit three terms that all overlap: white-label wallets, embedded wallets, and wallet as a service. Marketing pages from infrastructure providers blur the lines. Most explainers stop at the definition. The cost question gets dodged.
This article is the reference that sorts it out.
We will cover what wallet as a service actually is, the three implementation models you will choose between, how custody works under the hood (including MPC), what providers cost in 2026, what the regulatory map looks like across major jurisdictions, and how to evaluate a vendor without falling for the marketing.
The goal: by the end you have enough to make a build-or-buy decision, pick an implementation model, write a real RFP, and know which questions catch a weak provider.
Key takeaways
Wallet as a service (WaaS) is infrastructure that lets companies offer crypto wallets to their users through APIs or SDKs without building the underlying key management, blockchain connectivity, and compliance plumbing in-house. A WaaS provider runs the cryptographic engine, node infrastructure, and (often) the custody layer. You integrate at the API or SDK level and focus on your product.
Shipping a wallet from scratch is more work than founders expect. A real production wallet needs cryptographic engineers who understand threshold signatures and key derivation. It needs multi-chain node infrastructure with reliable RPC providers. It needs a custody design that holds up under realistic attacker models. It needs recovery flows that actually work when users lose their phones, ongoing security audits, and in many jurisdictions a custody license. Even teams that could build this usually decide their engineering time is better spent on the product layer.
WaaS exists because every consumer crypto company hit the same wall between 2021 and 2023, and the infrastructure layer broke off into its own market. Today, most new crypto-touching products plug in WaaS for the wallet layer instead of writing one.
Fintechs adding crypto features without becoming crypto-native companies. Gaming and iGaming platforms that need wallets for in-game asset ownership or payments. Marketplaces with two-way value flow between buyers and sellers. Payments companies extending into stablecoin rails. Brands launching loyalty tokens or branded stablecoin products. Exchanges spinning up secondary brands without rebuilding their custody stack. MoonPay’s embedded wallet infrastructure sits in this last category, giving builders a wallet layer they can drop into a product without taking on the custody stack themselves.
This is where most builders get confused. WaaS providers package their offerings in three distinct shapes, and the right pick depends on how much UX control you want and how much engineering time you have.
A white-label wallet is a pre-built wallet you brand and ship. The provider hands you a working app or web interface. You change the logo, colors, and copy. You publish under your brand. Time to launch is short, typically two to four weeks.
The trade-off is UX flexibility. You get what the provider built. Custom flows, unusual asset types, and deeply embedded checkout experiences are usually outside scope. White-label fits brands launching a consumer wallet product without wallet engineering on the team, or operators who want a working product fast and will iterate later.
Embedded wallets live inside your existing product. The wallet is a component woven into the auth and account flows your users already know, often without a separate seed phrase or password step. The wallet UX is yours; the underlying infrastructure is the provider’s.
This is the dominant model for fintech apps adding crypto features, gaming platforms wrapping wallets around player accounts, and any product where the wallet is one feature among many. Integration runs four to eight weeks for the typical case, longer if your auth model is unusual.
API-first WaaS gives you the raw primitives: create a wallet, manage keys, sign a message, broadcast a transaction, monitor balances. You build the user interface and flows yourself. UX control is total. Engineering investment is the largest of the three.
API-first is the right pick when wallet flows are part of your product differentiation, when you have specific compliance or UX requirements an off-the-shelf product cannot meet, or when you are building a wallet-native product (a product where the wallet is the product, instead of a product with a wallet feature).
Model | Time to launch | UX control | Engineering effort | Key custody | Typical use |
White-label | 2 to 4 weeks | Low | Low | Provider (custodial or MPC) | Brand launching a consumer crypto product |
Embedded SDK | 4 to 8 weeks | Medium to high | Medium |
Custody is the question of who can move the funds. Every WaaS implementation answers this question, and the answer drives most of the second-order trade-offs: recovery UX, regulatory exposure, who is liable when keys are lost.
The provider holds the private keys. Users authenticate to your product (or directly to the provider) and authorize transactions. The provider signs.
Recovery is simple. A lost password becomes a reset flow. The counterparty risk is real: if the provider is compromised or goes under, funds are exposed. Regulatory treatment is heavier because the provider is a custodian. In some jurisdictions, you may also count as a custodian depending on how the relationship is structured.
The end user holds the keys. The wallet generates a seed phrase or private key, the user backs it up, and the provider never sees the secret. Counterparty risk drops to near zero. Recovery becomes the hard part because if the user loses the backup, the funds are gone.
Non-custodial fits crypto-native audiences who understand seed phrases. It struggles with mainstream users because the recovery UX is genuinely bad. For a deeper read on the trade-offs between custodial and non-custodial wallets, see our Learn explainer.
MPC splits the private key into shards distributed across multiple parties: the user’s device, the provider’s servers, sometimes a backup location. No single party ever holds the complete key. Transactions get signed collaboratively through a cryptographic protocol that produces a valid signature without anyone reconstructing the full key.
The practical upshot: you get most of the security of non-custodial (no single point of compromise) with most of the UX of custodial (provider-assisted recovery). This is why MPC dominates consumer-facing WaaS in 2026.
Multi-sig is an on-chain alternative. A smart contract requires multiple signatures to authorize a transaction, typically from multiple parties or devices. It is verifiable on-chain, protocol-specific (so each blockchain needs its own implementation), and adds gas costs because every signature lives on-chain.
Multi-sig fits institutional treasury operations and DAOs where governance is the point. It is less common in consumer wallets because of the cost overhead.
Model | Who holds keys | Recovery UX | Counterparty risk | Liability when keys lost |
Custodial | Provider | Easy (password reset) | High (provider failure exposes funds) | Provider (usually) |
Non-custodial | User | Hard (seed-phrase based) | Low | User |
MPC sounds abstract. The practical version is short.
A normal wallet generates one private key and stores it somewhere. MPC generates two or more key shards that, together, can produce signatures for one address. The shards live in different places, typically the user’s device and the provider’s server, with optional backup shards. Signing happens through a cryptographic protocol where each party contributes their shard’s computation without revealing the shard itself. The output is a standard signature that any blockchain validator accepts. The address looks like any other address on-chain.
The full key never exists as a single object. There is nothing to steal. For the deeper academic background, see the NIST threshold cryptography project.
If a user loses their device, the user-side shard is gone. The provider’s shard alone cannot sign anything. Recovery happens through one of several patterns: a backup shard held by the user (often encrypted with a password or biometric), a social recovery model where trusted contacts approve new shard generation, or a provider-assisted recovery where the provider regenerates a user shard after verifying identity through some other channel.
Each pattern is a trade-off between UX simplicity and trust in the recovery channel. Builders should pick the model that matches their user base. Consumer products lean toward provider-assisted recovery with strong identity verification. Power-user products lean toward backup shards or social recovery. For a fuller treatment of MPC and key management, see our Learn explainer.
MPC is the right pick when you have mainstream users who cannot be expected to manage seed phrases, when you need recoverable wallets without taking on full custody liability, and when you want to keep the option of upgrading custody behavior over time without forcing users to migrate to a new wallet address.
MPC is overkill when you are serving crypto-native users who prefer holding their own keys outright, or when you are building a custodial product where the provider holding keys is fine.
This is the section providers do not love writing about. The numbers matter, so here they are.
Per-wallet creation fees. The provider charges you when a wallet is created, regardless of whether it ever holds funds. Common range in 2026: a few cents to a few dollars per wallet, depending on volume and custody model. MPC wallets cost more than custodial wallets because of the cryptographic overhead.
Monthly active wallet (MAW) pricing. You pay a flat fee per wallet that touches the network in a given month. This is becoming the default for serious WaaS providers because it aligns cost with usage. Common range: $0.10 to $1.00 per MAW depending on tier.
Per-transaction signing fees. Some providers charge per signature. This is common for API-first products. Pricing varies. Expect anywhere from $0.01 to $0.50 per signed transaction.
Platform minimums. Most enterprise WaaS contracts have monthly minimums starting in the low four figures. If you are building anything serious, expect to commit.
Volume tiers. Pricing drops at predictable steps: 10k, 100k, 1M wallets. Negotiate the next tier before you hit it.
RPC and node infrastructure fees, if your provider does not bundle them. Multi-chain support across Ethereum, Solana, Bitcoin, and others can quietly run thousands of dollars a month at scale.
Gas sponsorship. If you absorb user transaction fees (most consumer products do), this is a meaningful operating cost. At scale it is the largest line item.
Compliance tooling. Sanctions screening, transaction monitoring, Travel Rule messaging. Sometimes bundled with WaaS, often sold separately, sometimes required for the provider to onboard you at all.
Premium support. A response-time SLA for incidents usually costs extra. If wallets are revenue-critical, you will want it.
SOC 2 attestation pass-through. Some providers charge to share their audit documentation.
White-label: two to four weeks of integration time. One engineer plus a designer.
Embedded SDK: four to eight weeks for the typical case. One to two engineers, a product manager, and a security review.
API-first WaaS: twelve weeks and up. Three to five engineers depending on scope. Add time for security review, regulatory review, and load testing.
Engineering time is usually a bigger cost than the provider fees through year one.
A rough heuristic: if you have four or more wallet engineers with shipped cryptographic experience, twelve months of runway dedicated to the wallet layer, and a regulatory plan, building can pencil out by year two. Below that threshold, buying is almost always faster and cheaper for the first two years.
Regulation around wallets is uneven by jurisdiction. Here is the practical map.
WaaS providers that hold customer keys generally register with FinCEN as money services businesses (MSBs) under the Bank Secrecy Act. State money transmitter licenses are layered on top, and the patchwork of state requirements is the slowest part of getting fully licensed in the US.
Travel Rule obligations kick in above the $3,000 threshold for transactions between regulated entities. The provider may handle this for you, or may push it back to you depending on how the integration is structured. Get this written into the contract.
If the provider holds keys, you are usually classified as an agent of the provider rather than a money transmitter yourself. If you hold any keys directly (in an API-first model), you may be classified as a transmitter in your own right.
The Markets in Crypto-Assets (MiCA) framework took full effect in 2025. WaaS providers operating in the EU register as Crypto-Asset Service Providers (CASPs). Custody is a separate authorization category from exchange or advisory services. For the official position, see ESMA guidance on MiCA.
The Transfer of Funds Regulation (TFR) brings Travel Rule obligations into EU law with no transaction-size threshold. Every transfer between CASPs requires originator and beneficiary information.
If you are using a CASP-authorized WaaS provider for the wallet layer, you generally do not need your own CASP authorization for custody. You may still need authorization for other services you offer (exchange, advisory, transmission).
The Monetary Authority of Singapore (MAS) regulates wallet providers under the Payment Services Act. The Digital Payment Token (DPT) services license is the relevant category for custody. Requirements include capital adequacy, KYC programs, AML/CFT controls, and Travel Rule compliance.
Singapore’s regulatory bar is high but predictable. WaaS providers operating there are typically well-documented.
The Virtual Asset Regulatory Authority (VARA) in Dubai oversees virtual asset service providers. Custody is a category with its own license. The UAE has positioned itself as a fast-onboarding jurisdiction for new wallet products, which makes it a popular base for WaaS-powered consumer products targeting MENA and Asia.
Compliance area | Provider’s perimeter | Your perimeter |
Custody license | Yes, if they hold keys | Only if you hold keys directly |
KYC on end users | Sometimes (depends on contract) | Usually yours |
Sanctions screening on transactions | Often offered as an add-on | Yours if not contracted in |
Travel Rule messaging | Provider for inter-CASP transfers | Yours for transfers outside the provider network |
For wallet products supporting stablecoin payments, the compliance perimeter often expands to include payment-specific obligations layered on top of wallet custody rules.
Most provider evaluation comes down to asking concrete questions and reading the answers carefully.
No SLA in the contract. No SOC 2 attestation. Custody license unclear or unprovable. Marketing claims of “MPC” without published technical documentation. No production-fidelity staging environment. Pricing only available by sales call without published tiers. No clear data export story.
Any single red flag is not disqualifying. A cluster of them is.
Nobody plans to migrate off a WaaS provider. Some companies end up doing it anyway, usually because pricing changes, the provider’s chain coverage stops matching the company’s needs, or the provider gets acquired and the relationship changes.
Public addresses are portable in the sense that they are already on-chain. Transaction history is recoverable from blockchain explorers. User account identifiers are yours if you stored them.
Private keys held by the provider in a custodial model do not transfer. The destination provider has to generate new wallets and your users have to migrate funds. For MPC wallets, key shards may or may not export depending on the implementation; many providers do not support exporting their shard at all, which means user-side migration is the only path.
Recovery state, webhook configurations, signing infrastructure, and compliance attestations stay with the original provider. The realistic migration window for a serious WaaS implementation is three to nine months.
Pick providers with documented export tooling, even if you never use it. Negotiate data portability into the contract. Avoid deep coupling between your authentication system and the provider’s user IDs. Maintain your own record of which wallets belong to which users.
Honest section. Buying is not always right.
Building can pencil out when wallet UX is genuinely a core product differentiator and you have wallet engineering depth on the team with shipped cryptographic experience. It can also work when you already hold the regulatory licensing for custody, and when your unit economics cannot support per-wallet pricing at the volumes you will hit.
These conditions are rare. Companies that meet them are usually wallet-native businesses where the wallet itself is the product.
If you are in that group, building is correct. If you are not, WaaS is almost always faster and cheaper through your first two years, and it lets your engineering team work on the product layer where the differentiation actually lives.
Wallet as a service is infrastructure that lets companies offer crypto wallets to their users through APIs or SDKs. The provider runs the cryptography, key management, and blockchain connectivity. You integrate at the API or SDK level and ship a wallet experience without building the underlying plumbing.
A WaaS provider exposes APIs (or SDKs) for wallet creation, key management, transaction signing, and blockchain broadcasting. Your application calls those APIs when a user creates a wallet or sends a transaction. The provider handles the cryptographic operations and infrastructure. You handle the user interface and product flows.
An MPC (multi-party computation) wallet splits the private key into multiple shards stored across different parties, typically the user’s device and the provider’s servers. No single party holds the full key. Transactions get signed through a cryptographic protocol that produces a valid signature without reconstructing the full key.
It depends on the provider and the custody model you pick. WaaS supports custodial setups (provider holds keys), non-custodial setups (user holds keys), and MPC (keys split between parties). Most consumer-facing WaaS in 2026 uses MPC because it balances security and recoverability.
Two to four weeks for a white-label wallet. Four to eight weeks for an embedded SDK with custom UX. Twelve weeks and up for an API-first integration with a fully custom wallet product. Engineering complexity, security review, and regulatory review drive the timeline.
If you take one thing from this, take the three-model framing: white-label for speed, embedded SDK for fit, and WaaS API for control. Pick the model that matches your product, then evaluate providers against the concrete question list in section 7.
The evaluation checklist is the artifact to take with you. Print it out, run it past three vendors, and pick the one whose answers do not dodge.
Mixed (often MPC with user-side shard) |
Existing app adding crypto features |
WaaS API | 12 weeks and up | Total | High | Configurable | Wallet-native product or differentiated UX |
MPC
Distributed shards |
Medium (provider-assisted) |
Low |
Shared, defined by terms |
Multi-sig | Multiple parties on-chain | Defined by contract | Low | Shared by signers |
SOC 2 or ISO 27001 audits | Provider, for their systems | Yours, for your systems |
Consumer disclosures | Yours | Yours |
