Embedded Wallet

What Is an Embedded Wallet?

An embedded wallet is a cryptocurrency wallet provisioned and operated entirely within a host application. Instead of connecting an external wallet like MetaMask or plugging in a hardware device, the app itself creates, stores, and uses cryptographic keys on the user's behalf. The wallet is created silently during signup (often via email, social login, or passkey), and the user may never realize they have a wallet at all.

The core motivation is onboarding friction. Traditional crypto wallets require users to install browser extensions, write down 12- or 24-word recovery phrases, understand gas fees, and manually approve every transaction in a popup. Each step loses a significant percentage of potential users. Embedded wallets remove these barriers by abstracting cryptographic complexity behind familiar authentication flows.

This pattern mirrors what happened in embedded finance more broadly: ride-sharing apps embed payments, e-commerce platforms embed lending, and now any application can embed a crypto wallet. The wallet becomes infrastructure rather than a product the user consciously manages.

How It Works

Every crypto wallet ultimately needs a private key to sign transactions. The challenge for embedded wallets is: who holds that key, and how is it protected? Several approaches have emerged, each with different security and custody tradeoffs.

MPC Key Sharding

Multi-party computation (MPC) splits a private key into multiple shares distributed across independent parties. A typical 2-of-3 scheme distributes shares to the user's device, the wallet provider's server, and a recovery backup. No single party ever possesses the complete key. During signing, two shares collaborate through a cryptographic protocol to produce a valid signature without reconstructing the full key.

This approach gives providers a strong custody argument: they cannot unilaterally move user funds because they hold only one share. The user retains meaningful control, and the backup share enables recovery if a device is lost.

Passkey Authentication

Passkeys use the FIDO2/WebAuthn standard to bind wallet access to device-level biometrics (fingerprint, face scan) or hardware security keys. The cryptographic key material lives in the device's Secure Enclave or TPM and cannot be extracted. Passkeys are phishing-resistant by design: the browser verifies the origin domain during authentication, preventing fake sites from intercepting credentials.

For embedded wallets, passkeys serve as both the authentication mechanism and (in some implementations) the signing key itself. The user taps their fingerprint, and the wallet signs a transaction: one gesture, no passwords, no seed phrases.

Trusted Execution Environments

Some providers store key material inside trusted execution environments (TEEs) such as AWS Nitro Enclaves. Private keys exist only during signing operations inside isolated hardware. The provider's own engineers cannot access the keys, and the enclave's code can be independently attested. Turnkey pioneered this approach, where raw keys are never exposed to the provider, the app backend, or any internal team.

Server-Side Co-Signing

In a co-signing model, the provider holds one key share and enforces policy checks before participating in signing. These policies can include per-transaction limits, daily spending caps, velocity checks, allowlisted addresses, and session timeouts. The user's device holds the other share and initiates signing requests. This creates a programmable approval layer: the provider acts as a policy engine rather than a custodian.

Social Recovery

Traditional wallets rely on seed phrases for recovery: lose the phrase, lose the funds. Embedded wallets replace this with social recovery mechanisms. Common patterns include guardian networks (trusted contacts who can collectively approve recovery), passkey backup across devices, MPC share redistribution, and timelocked secondary keys. The user never needs to write down or store a recovery phrase.

Typical Integration Flow

From a developer's perspective, integrating an embedded wallet SDK typically follows this pattern:

// Initialize the wallet provider
const wallet = await EmbeddedWallet.init({
  authMethod: "passkey",  // or "email", "oauth"
  network: "bitcoin",
  recoveryMethod: "social"
});

// User signs up — wallet created silently
const user = await wallet.authenticate();
// user.address is now available

// Send a transaction — signed behind the scenes
const tx = await wallet.sendTransaction({
  to: recipientAddress,
  amount: 50000  // sats
});

The developer never handles raw private keys. The SDK manages key generation, storage, signing, and recovery. For a detailed comparison of Bitcoin wallet SDKs, see the Bitcoin wallet SDK comparison.

Embedded Wallets vs. Other Wallet Types

Understanding embedded wallets requires comparing them with the two other major wallet categories: browser extension wallets and hardware wallets.

For a deeper analysis of custody tradeoffs, see the self-custodial vs. custodial wallets research article.

Use Cases

Consumer Applications

Gaming platforms, social apps, and loyalty programs can add token-based features without forcing users through crypto onboarding. A gaming app might reward players with tokens they can trade or redeem: the embedded wallet handles everything in the background. The user sees "You earned 500 coins," not "Sign this transaction with your private key."

Payments and Commerce

Merchants and payment processors can embed Bitcoin and stablecoin wallets into checkout flows. A customer pays with a tap, and the embedded wallet handles address generation, signing, and settlement. This is especially powerful for cross-border payments where traditional rails are slow and expensive.

Neobanks and Fintech

Financial apps can offer Bitcoin savings, stablecoin yields, or instant remittances by embedding wallet functionality alongside traditional banking features. The user sees a unified balance sheet rather than juggling separate apps for fiat and crypto.

Developer Platforms

Wallet-as-a-service providers package embedded wallet infrastructure as SDKs and APIs. Developers integrate a few lines of code and get key management, transaction signing, and recovery out of the box. This has driven rapid growth in the embedded wallet market: by 2026, major providers include Privy (acquired by Stripe), Dynamic (acquired by Fireblocks), Turnkey, Thirdweb, Magic, Crossmint, and Coinbase WaaS.

Embedded Wallets on Bitcoin

Bitcoin presents unique challenges for embedded wallets. The UTXO model is more complex than account-based chains, fee estimation requires mempool awareness, and there is no native equivalent to Ethereum's account abstraction (ERC-4337). Most early embedded wallet providers focused on Ethereum and EVM chains, leaving Bitcoin underserved.

Spark addresses this gap. As a Bitcoin Layer 2, Spark uses FROST threshold signatures in a 2-of-2 scheme where the user holds one key and Spark Operators collectively hold the other. This enables instant transfers without Lightning channel management, native Lightning invoice payments, and non-custodial guarantees: users can perform a unilateral exit to reclaim funds on-chain even if operators become unresponsive.

The Spark SDK (available in TypeScript and React Native) lets developers embed Bitcoin and stablecoin wallet functionality with minimal code. Tether has integrated Spark into its Wallet Development Kit (WDK), and Wallet of Satoshi has partnered with Spark for self-custodial Lightning. For a comprehensive look at how embedded wallets work in the Bitcoin ecosystem, see the embedded wallets on Bitcoin research article.

Risks and Considerations

Provider Dependency

The critical question for any embedded wallet is: what happens if the provider disappears? If the provider holds an MPC share or manages the TEE infrastructure, their shutdown could lock users out of funds. Genuinely non-custodial solutions must support unilateral exit: the user can recover funds without provider cooperation. Before choosing a provider, developers should verify the recovery path works independently.

Custody Ambiguity

The line between custodial and non-custodial blurs with embedded wallets. An MPC wallet where the provider holds one of two required shares is technically non-custodial (the provider alone cannot move funds), but if the provider can freeze signing or deny service, users face practical custody constraints. Regulatory frameworks like the GENIUS Act are still catching up to these nuanced custody models.

Security Surface Area

Embedded wallets introduce additional attack vectors compared to self-custody. The provider's infrastructure becomes a target: a breach of MPC signing servers or TEE attestation could compromise many wallets simultaneously. Server-side policy engines add complexity, and each integration point (OAuth, email verification, passkey sync) is a potential vulnerability. Defense in depth: combining MPC with TEE isolation, scoped signing permissions, and comprehensive audit logging is the current best practice.

Portability

Users of traditional wallets can export their seed phrase and import it into any compatible wallet. Embedded wallet users typically cannot: their keys are sharded across provider-specific infrastructure. Switching providers may require on-chain transfers rather than simple key export. Some providers are adopting standards for portable key shares, but no universal standard exists yet.

Regulatory Uncertainty

Depending on how much control the provider exercises over signing and fund movement, an embedded wallet service may be classified as a money transmitter or custodian in some jurisdictions. The regulatory landscape varies by country and is evolving rapidly. Developers building on embedded wallet infrastructure should consult legal counsel about the licensing implications of their specific architecture.

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.