Embedded Bitcoin Wallets: Non-Custodial Wallets Inside Apps

Embedded wallets are wallet functionality built directly into an application. Instead of asking users to install a browser extension, download a separate app, or write down a seed phrase, the wallet exists invisibly inside the product they already use. Authentication happens via email, social login, or passkeys. The user may never know they have a wallet at all.

For Bitcoin specifically, embedded wallets solve a persistent adoption problem: the gap between wanting to accept or send Bitcoin and being willing to manage keys, channels, or on-chain fees. By integrating self-custodial Bitcoin functionality into any app through an SDK, developers can offer Bitcoin payments, stablecoin balances, and Lightning connectivity without requiring their users to understand any of it.

What Makes a Wallet "Embedded"

The term distinguishes embedded wallets from standalone wallet applications. A standalone wallet like BlueWallet or Sparrow is a dedicated product: the user downloads it, creates keys, and manages everything themselves. An embedded wallet is created silently during app signup, funded through the app's own flows, and used without leaving the app's interface.

The distinction matters for user experience and for architecture. Embedded wallets must handle key management on behalf of users who may not know what a private key is, while still preserving meaningful custody guarantees. They must work across platforms (web, mobile, desktop) with consistent behavior, and they must integrate with the host application's authentication system rather than introducing a separate login flow.

How Embedded Wallet Key Management Works

The core challenge for any embedded wallet is reconciling two opposing requirements: the user should not need to manage cryptographic keys, but no single party should have unilateral control over funds. Several architectures address this, each with different trust assumptions and tradeoffs.

MPC: Multi-Party Computation

MPC wallets split a private key into multiple shares distributed across independent parties. The complete key is never assembled in one place. The most common model is 2-of-3 threshold signing: one share on the user's device, one held by the provider in a secure enclave, and one encrypted backup for recovery. Transaction signing happens collaboratively and off-chain without ever reconstructing the full key.

Providers like Dynamic and Fireblocks use TSS-MPC (Threshold Signature Scheme) with support for ECDSA, EdDSA, and BIP-340 (Taproot) signature schemes. This makes MPC wallets chain-agnostic: the same architecture works for Bitcoin, Ethereum, and Solana.

Passkey-Based Key Management

Passkeys use the WebAuthn/FIDO2 standard to generate unique public-key cryptographic credentials stored in device hardware. When applied to wallets, passkeys can serve multiple roles: gating access to encrypted key material, authorizing transaction signing, or even deriving wallet keys directly from the passkey credential.

Turnkey uses a passkey-first architecture where keys live exclusively inside AWS Nitro Enclaves and never leave the TEE (Trusted Execution Environment). Users authenticate with biometrics to authorize signing operations. No passwords or seed phrases are involved. Recovery works through the device's passkey manager: iCloud Keychain on Apple devices, Google Password Manager on Android.

TEE-Based Enclave Storage

Trusted Execution Environments provide hardware-isolated processing where code and data are encrypted and inaccessible to the host operating system, hypervisor, or any other software. Private keys stored in a TEE exist only during signing operations and are protected by cryptographic attestation that verifies the enclave is running trusted code.

Privy combines TEEs with distributed key sharding, splitting key material across multiple enclaves so that no single enclave compromise can expose the complete key. This layered approach provides defense in depth: TEE isolation protects against software attacks, while sharding protects against hardware attacks on any individual enclave.

Key distinction: MPC splits the key across parties so it never exists in complete form. TEE-based approaches may store the complete key but protect it with hardware isolation. The strongest architectures combine both: key sharding within TEEs, so compromise requires breaking both the cryptographic scheme and the hardware simultaneously.

The Self-Custody Spectrum for Embedded Wallets

Not all embedded wallets provide the same custody guarantees. The term "non-custodial" is often used loosely: what matters is who controls the key material, whether the user can exit without the provider's cooperation, and what happens if the provider disappears.

Fully Custodial

The provider holds all private keys. Users have an account, not a wallet. Exchange-hosted wallets (Coinbase, Kraken accounts) operate this way. The provider can freeze funds, comply with seizure orders, or lose funds in a hack. This is the simplest model for developers but offers users no meaningful self-custody.

Semi-Custodial (Shared Control)

Keys are split between user and provider using MPC or threshold signatures. Neither party can act unilaterally. The user's key share typically lives on their device; the provider holds its share in a TEE. Self-custody strength depends on whether the user can reconstruct or use their funds if the provider goes offline. Most embedded wallet providers (Privy, Dynamic, Turnkey, Para) aim for this model.

Non-Custodial with Unilateral Exit

The strongest guarantee: the user can always recover funds on the base layer without any third party's cooperation. On Bitcoin, Spark achieves this through pre-signed exit transactions. Users receive these transactions when they receive funds on Spark, and they can broadcast them to Bitcoin L1 at any time without operator permission. Even if every Spark operator goes offline, the user's funds are recoverable.

The test for self-custody: Ask what happens if the provider disappears tomorrow. If the answer is "the user can still access their funds," it is genuinely non-custodial. If the answer involves waiting for the provider to come back, it is not.

How Developers Integrate Embedded Wallets

From the developer's perspective, an embedded wallet SDK abstracts the complexity of key generation, secure storage, transaction construction, and network communication behind a small API surface. Integration typically involves three steps: install the SDK, initialize a wallet during user signup, and call transfer methods when the application needs to move funds.

Wallet Creation

When a new user signs up, the SDK generates keys behind the scenes. Depending on the provider, this might involve creating MPC key shares, generating a passkey credential, or deriving keys within a TEE. The user authenticates with email, social login, or biometrics. They never see a seed phrase.

With the Spark SDK, wallet initialization requires a single function call. The SDK handles key generation, operator communication, and the FROST signing setup:

import { SparkWallet } from "@buildonspark/spark-sdk";

const { wallet, mnemonic } = await SparkWallet.initialize({
  options: { network: "MAINNET" }
});

The returned mnemonic can be encrypted and stored as a backup, or the developer can manage it through their own recovery flow. For a developer-custodial model, the mnemonic is stored server-side. For self-custodial, it stays on the user's device.

Sending and Receiving

Once the wallet exists, transferring value is straightforward. The SDK constructs the transaction, coordinates signing with the operator network, and handles confirmation:

// Spark-to-Spark transfer
await wallet.transfer({
  receiverSparkAddress: "sp1q...",
  amountSats: 10000
});

// Pay a Lightning invoice
await wallet.payLightningInvoice({
  invoice: "lnbc10u1p..."
});

// Withdraw to Bitcoin L1
await wallet.withdraw({
  onchainAddress: "bc1q...",
  amountSats: 50000,
  exitSpeed: "FAST"
});

The SDK supports Spark-to-Spark transfers (instant, near-zero fees), Lightning invoice payments (interoperable with the entire Lightning network), and on-chain withdrawals to any Bitcoin address. Developers do not need to run a Lightning node or manage payment channels.

Platform Support

The Spark SDK is available as a TypeScript package for web and React Native for mobile. For native mobile development, the Breez SDK provides Rust bindings with Swift, Kotlin, Python, Flutter, Go, C#, and WebAssembly support. The Tether Wallet Development Kit also integrates Spark, providing another path for developers building stablecoin-focused applications.

Embedded Wallet Providers Compared

The embedded wallet market has matured rapidly. Stripe acquired Privy in June 2025, and Fireblocks acquired Dynamic in October 2025, signaling that embedded wallet infrastructure is becoming a standard part of the fintech stack. Here is how the major providers compare:

Most general-purpose providers focus on EVM chains first, with Bitcoin support added through Taproot signature schemes. The Spark SDK is Bitcoin-native: it was built for Bitcoin from the ground up, with Layer 2 transfers, Lightning interoperability, and on-chain exits as first-class features.

Use Cases for Embedded Bitcoin Wallets

Embedded wallets are not just a better way to build a wallet app. They enable Bitcoin functionality inside applications that are not wallets at all.

Gaming

In-game economies can use embedded wallets for microtransactions, item purchases, and reward distributions without interrupting gameplay. Players authenticate with their existing gaming credentials (Discord, Steam, or a game account), and the wallet is created silently. Session keys can authorize a series of transactions without repeated confirmation prompts, enabling sub-second micropayments for in-game actions.

Social Applications

Social platforms can integrate tipping, creator payments, and peer-to-peer transfers. A Telegram bot or a social feed can embed Bitcoin payments without redirecting users to external apps. Bitbit, a Telegram-based wallet in the Spark ecosystem, demonstrates this pattern: users send and receive Bitcoin within Telegram conversations.

Commerce and Checkout

E-commerce platforms can offer Bitcoin and stablecoin checkout alongside traditional payment methods. The embedded wallet handles settlement in the background. For merchants, this means accepting Bitcoin without managing wallets or exchange rate risk: payments can settle in dollar-denominated stablecoins on Spark while the customer pays in BTC.

Fintech and Neobanking

Neobanks and fintech applications can embed Bitcoin and stablecoin balances alongside traditional banking features. Deblock, a European neobank built on Spark, combines fiat banking with Bitcoin functionality in a single interface. Users hold euros and Bitcoin in the same app, moving between them seamlessly. The embedded finance model extends to savings features, where stablecoin balances can generate yield without requiring users to interact with DeFi protocols directly.

Rewards and Loyalty Programs

Bitcoin rewards programs can use embedded wallets to accumulate and distribute satoshis without the friction of external wallet management. Users earn Bitcoin through cashback, referrals, or engagement, and the embedded wallet holds their balance until they choose to withdraw or spend it. The wallet infrastructure is invisible: users see a points balance that happens to be real Bitcoin.

Bitcoin-Specific Challenges for Embedded Wallets

Building embedded wallets for Bitcoin involves constraints that do not exist on account-based chains like Ethereum or Solana.

The UTXO Model

Bitcoin uses UTXOs (Unspent Transaction Outputs) rather than account balances. Every payment consumes existing outputs and creates new ones. For embedded wallets, this means managing UTXO sets, handling dust (outputs too small to spend economically), and constructing transactions that optimize for fee efficiency. Layer 2 protocols like Spark abstract this complexity: the SDK handles UTXO management internally, exposing a simple balance-and-transfer API to the developer.

Fee Volatility

On-chain Bitcoin fees fluctuate based on block space demand. Fee market dynamics can make small transactions uneconomical during high-demand periods. Embedded wallets that operate on Layer 2 avoid this for most transfers: Spark transfers and Lightning payments cost a fraction of a cent regardless of L1 fee conditions. On-chain withdrawals still incur L1 fees, but the SDK can expose fee estimates and let the application choose the appropriate fee strategy.

No Native Account Abstraction

Ethereum's ERC-4337 enables smart contract wallets that can sponsor gas, batch transactions, and define custom authentication logic at the protocol level. Bitcoin has no equivalent. Embedded wallet providers on Bitcoin must implement these features at the SDK or Layer 2 level. Spark's approach handles this through the operator network: the protocol itself provides gasless transfers, offline receiving, and flexible authentication without requiring Bitcoin script changes.

Security Considerations

Embedded wallets introduce a new trust surface compared to traditional self-custody. Understanding the security model is essential for developers choosing an SDK and for users evaluating applications.

Provider Risk

If the embedded wallet provider goes offline, can users still access their funds? With MPC-based wallets, the answer depends on whether the user can reconstruct the key from their device share and their backup share alone. With Spark, the answer is unambiguous: pre-signed exit transactions allow broadcasting to Bitcoin L1 at any time, with no provider involvement.

Key Backup and Recovery

Traditional wallets use seed phrases for backup: 12 or 24 words that reconstruct the complete key. Embedded wallets replace this with provider-managed recovery (encrypted cloud backups, social recovery, or passkey sync). The tradeoff is convenience versus control: seed phrases are robust but error-prone; managed recovery is seamless but introduces dependencies on the provider's infrastructure and the cloud platform's availability.

Supply Chain and SDK Integrity

An embedded wallet SDK runs inside the host application, with access to key material and transaction signing. Developers should audit SDK dependencies, verify package integrity, and monitor for malicious updates. Open-source SDKs allow independent verification: the Spark SDK is published on GitHub, and the Tether WDK is fully open-source.

Spark's Embedded Wallet Architecture

Spark takes a different approach from most embedded wallet providers. Rather than layering wallet infrastructure on top of an existing chain, Spark provides a Bitcoin Layer 2 where the wallet SDK and the transfer protocol are the same system. The SDK does not translate between the application and a separate network: it is the client to Spark's operator network directly.

FROST Threshold Signatures

Spark uses a 2-of-2 multisig model with FROST (Flexible Round-Optimized Schnorr Threshold) signatures. One key belongs to the user; Spark Operators collectively hold the other via threshold signing. Neither party can move funds alone. This differs from MPC in that the scheme is purpose-built for Schnorr signatures on Bitcoin, enabling efficient cooperative signing without the overhead of general-purpose MPC protocols.

Instant Transfers Without Channels

Unlike Lightning, Spark does not require payment channels or inbound liquidity management. Transfers happen by rotating key shares between sender and recipient: the same on-chain UTXO backs the funds, but the cryptographic authority changes. This means transfers settle instantly, cost nearly nothing, and work regardless of network topology. Developers using the Spark SDK get these properties without managing any infrastructure.

Lightning Interoperability

The Spark SDK includes native Lightning support. Applications can pay and receive Lightning invoices without running a Lightning node. Zero-conf receiving is supported: users can accept Lightning payments even while offline, with Spark Service Providers holding payments conditionally until the recipient comes online.

Evaluating an Embedded Wallet SDK

For developers choosing an embedded wallet solution, here are the questions that matter:

• Can users exit without the provider? If the SDK vendor disappears, can your users still access their funds?
• What custody model does it enforce? Understand where key material lives and who can initiate transactions.
• What chains and Layer 2s does it support natively? Bolt-on Bitcoin support via bridging is different from native Bitcoin integration.
• What platforms are supported? Web, React Native, native mobile, and server-side SDKs each serve different use cases.
• How does recovery work? Test the recovery flow before deploying. A recovery mechanism that requires the provider to be online is not truly non-custodial.
• Is the SDK open-source? Closed-source wallet SDKs require trusting the vendor's implementation of key management and signing.

Getting Started with Embedded Bitcoin Wallets

The barrier to adding Bitcoin payments to an application has dropped significantly. A few lines of code can create a non-custodial wallet, fund it via Lightning or on-chain deposit, and send instant transfers. For a working example of what this looks like in production, Bread demonstrates a Spark-powered wallet with stablecoin balances, instant swaps, and merchant payments: all built on the same embedded wallet infrastructure available to any developer.

The Spark documentation includes quickstart guides, SDK references, and integration examples for TypeScript and React Native. For developers already using Privy for authentication, the Privy integration guide covers adding Spark wallets to an existing Privy-based application. For a broader comparison of Bitcoin wallet SDK options, see the Bitcoin Wallet SDK Comparison.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.