One Wallet, Two Assets: How Spark Unifies BTC and Stablecoin UX

Using Bitcoin and stablecoins today usually means managing separate wallets on separate networks. A user who wants to hold BTC for savings and USDB for daily spending typically downloads one app for Bitcoin (often a Lightning wallet), a second for stablecoins (on Ethereum, Solana, or Tron), and navigates bridges, swap interfaces, and multiple sets of credentials between them. The result is friction that pushes mainstream users toward custodial platforms where a single company holds everything.

Spark eliminates this split. As a Bitcoin Layer 2 built on statechains and FROST threshold signatures, Spark natively supports both BTC and tokenized assets like stablecoins within the same protocol layer. A single wallet, a single key, and a single balance view: Bitcoin and dollar stablecoins coexist without bridging, chain-switching, or separate infrastructure.

Why Wallets Are Fragmented Today

The multi-wallet problem is not hypothetical. A 2025 survey by Reown and Nansen found that 62% of active crypto users manage two or more wallets, up 15% from the previous year. Nearly half of respondents said they needed different wallets for different networks, and 41% reported difficulty managing and navigating between them.

For Bitcoin users specifically, the fragmentation is worse. Bitcoin L1 wallets handle on-chain transactions but cannot hold stablecoins natively. Lightning wallets handle fast BTC payments but have no stablecoin support at all. And stablecoin wallets on Ethereum or Solana cannot hold native Bitcoin: they rely on wrapped versions that introduce bridge risk and custodial dependencies. Users who want both BTC and stablecoins end up straddling at least two ecosystems.

The cost of fragmentation

Each additional wallet a user manages introduces operational overhead: another set of keys to secure, another interface to learn, another potential point of failure. But the deeper cost is transactional. Moving value between a Bitcoin wallet and a stablecoin wallet requires bridging or exchanging on a third-party platform, with fees, delays, and counterparty risk at every step. A user who receives BTC on Lightning and wants to convert some to stablecoins for rent must: withdraw from Lightning to an exchange, swap BTC for USDC, withdraw USDC to a stablecoin wallet, and pay network fees on the destination chain. Each step takes time and leaks value.

The core tension: Bitcoin is the asset most users want to hold long-term. Dollar stablecoins are what they need for daily spending and payments. The infrastructure that serves one has historically been unable to serve the other, forcing users to choose between ecosystems or juggle both.

How Spark Supports Both BTC and Stablecoins

Spark's ability to handle both BTC and tokenized assets within a single protocol stems from its architecture. The protocol tracks user balances in a tree structure where each leaf represents a spendable balance secured by a 2-of-2 multisig: one key held by the user, the other collectively managed by Spark Operators via FROST threshold signatures. Transfers happen by rotating key shares between sender and recipient, not by broadcasting on-chain transactions.

This same mechanism works for both native BTC and tokens issued on Spark using the BTKN token standard. When a token issuer creates an asset on Spark, the token's metadata (amount, token ID, and properties) is embedded into Token Transaction Outputs that live alongside BTC leaves in the same tree structure. The Spark Operators validate token transactions and attest to state changes just as they do for BTC transfers.

USDB: a native dollar stablecoin on Bitcoin

USDB is the flagship stablecoin on Spark, issued by Brale, a U.S.-licensed stablecoin infrastructure provider, in collaboration with Flashnet. It is backed by U.S. Treasury bills and dollar reserves, and it exists natively on Spark: no wrapping, no bridging from another chain. USDB transfers on Spark are instant and near-zero cost, identical in speed and settlement mechanics to BTC transfers on the same network.

Beyond USDB, Spark also supports USDC and USDT natively. This means a wallet built on Spark can offer users a choice of stablecoin denominations alongside their BTC holdings, all within one interface, one key pair, and one set of self-custodial guarantees.

The User Journey: One Wallet for Everything

The practical impact of Spark's unified architecture becomes clear when you trace a typical user flow. Consider a user who wants to receive Bitcoin from a friend, convert a portion to stablecoins for expenses, and send a stablecoin payment to a merchant.

Step 1: Receive BTC

The user opens their Spark wallet and shares their Spark address. The sender transfers BTC directly on Spark (instant, near-zero fee) or pays via a Lightning invoice (the wallet's Spark Service Provider handles the conversion atomically). Either way, the BTC arrives instantly and appears in the same balance view as any stablecoins the user already holds.

Step 2: Swap BTC for USDB

Within the same wallet, the user converts a portion of their BTC to USDB. Because both assets exist on the same protocol layer, the swap executes on Spark itself: no withdrawal to an exchange, no bridging to another chain, no waiting for block confirmations. DEX infrastructure on Spark (such as Flashnet) facilitates these trades natively.

Step 3: Send stablecoins

The user sends USDB to a merchant or another wallet. The transfer uses the same statechain key-rotation mechanism as BTC transfers: instant settlement, near-zero fees, self-custodial throughout. The recipient does not need to be on the same wallet app: any Spark-compatible wallet can receive the payment.

What the user never sees: key rotations, FROST signing rounds, tree rebalancing, token transaction outputs, or operator coordination. The protocol complexity is entirely abstracted. The user sees a balance go down, a confirmation appear, and a recipient's balance go up.

Under the Hood: Leaves, Tokens, and a Single Key

Understanding why this unification works requires a closer look at Spark's data structures. In traditional Bitcoin, a user's funds are represented as UTXOs on the blockchain. In Spark, funds are represented as leaves in an off-chain tree whose root is anchored to an on-chain UTXO.

BTC leaves

When a user deposits BTC into Spark (or receives a Spark-to-Spark transfer), their balance is recorded as one or more leaves in the tree. Each leaf is secured by the 2-of-2 multisig between the user and the Spark Operators. Leaves can be split for partial payments and merged to consolidate balances, all without touching the Bitcoin base layer.

Token leaves

Tokens issued via the BTKN standard occupy their own leaves within the same tree structure. A USDB leaf carries additional metadata: the token identifier, amount, and issuer attestation. But it is secured by the same cryptographic mechanism as a BTC leaf: the same user key, the same operator key shares, the same FROST signing protocol.

This architectural symmetry is what makes the unified wallet possible. A wallet SDK interacting with Spark does not need separate code paths for "handle BTC" and "handle stablecoins." The underlying transfer primitive: rotating key shares on a leaf: is the same. The only difference is whether the leaf carries BTC value or token metadata.

Comparison: Unified Wallet vs. Multi-Wallet Setup

To appreciate what the unified model eliminates, compare the user experience of common tasks across a Spark-based unified wallet and the typical multi-wallet approach where a user manages separate Bitcoin and stablecoin wallets.

The multi-wallet approach is not just inconvenient: it is a security surface. Each bridge interaction introduces smart contract risk. Each additional wallet is another seed phrase to lose. Each exchange withdrawal is a counterparty exposure window. By collapsing both asset types into a single protocol, Spark reduces the number of trust boundaries a user must cross.

Lightning Compatibility: Reaching the Broader Network

A unified BTC-and-stablecoin wallet would be less useful if it could only transact within the Spark ecosystem. Spark addresses this through native Lightning Network interoperability.

Spark Service Providers (SSPs) handle Lightning routing on behalf of wallet users. When a user pays a Lightning invoice from their Spark wallet, the SSP executes an atomic swap: the user's Spark BTC is locked, the SSP pays the Lightning invoice, and both legs settle atomically. If either side fails, neither executes. The user does not manage channels, provision liquidity, or worry about routing failures.

Incoming Lightning payments work the same way in reverse. An SSP receives the Lightning payment and credits the user's Spark balance through an atomic swap. Notably, Spark users can receive Lightning payments while offline: the SSP holds the payment conditionally until the recipient comes online, a capability that standard Lightning wallets lack because they require the receiving node to be online to complete the HTLC handshake.

General Bread: The Unified Wallet in Practice

General Bread (also known as Bread) is the most complete implementation of Spark's unified wallet vision. Developed by SatRepublic Technologies, it is a mobile app that supports BTC, USDB, USDC, and USDT natively on Spark, with fiat on-ramps via Apple Pay, debit cards, and bank transfers. For a deeper look at its architecture, see our analysis of General Bread's design philosophy.

What makes General Bread a useful case study for the unified wallet concept is that it treats BTC and stablecoins as equal citizens. The home screen shows a combined portfolio value. Sending works the same regardless of asset type: tap a contact, choose an amount in BTC or USDB, confirm. There is no "Bitcoin tab" and "stablecoin tab" because there is no underlying architectural reason to separate them.

Beyond basic payments

General Bread extends the unified model into features that traditionally required separate specialized apps. It offers a Visa debit card that spends directly from stablecoin balances, yield on holdings paid in Bitcoin, and AI-powered portfolio management. These features work across both BTC and stablecoins because both live on the same protocol layer: there is no bridging step to move between "the Bitcoin side" and "the stablecoin side" of the app.

The seedless onboarding (via email, social login, or passkeys) means a new user can hold both BTC and stablecoins within minutes of downloading the app, without writing down a seed phrase or understanding what a statechain is.

What This Means for Developers

The unified asset model is not limited to General Bread. Any wallet built on the Spark SDK inherits the same capability. The SDK exposes a consistent API for both BTC and token operations.

A developer building a wallet calls transfer() for BTC payments and transferTokens() for token payments. Balance queries via getBalance() return both BTC and token balances from the same wallet instance. Lightning integration is available through createLightningInvoice() and related methods. The underlying statechain mechanics, FROST signing rounds, and operator coordination are fully abstracted.

This means a developer can ship a unified BTC-and-stablecoin wallet without running nodes, managing channels, or integrating separate token infrastructure. The same SparkWallet instance handles everything. Multiple wallets in the Spark ecosystem have already taken this approach: Wallet of Satoshi, Blitz, Deblock, and others.

For builders: The Spark SDK documentation covers wallet initialization, BTC and token transfers, Lightning integration, and token issuance. For a walkthrough of the integration process, see our SDK integration guide.

The Tradeoffs

Spark's unified model involves real tradeoffs that users and builders should understand.

• Trust assumption: Spark requires that at least one operator in the FROST signing group remains honest. This is weaker than Bitcoin L1's trustlessness but significantly stronger than custodial models.
• Operator visibility: Spark Operators can observe transfer metadata (amounts and participants). Users prioritizing privacy should weigh this against the convenience of a unified wallet.
• Token issuer controls: stablecoins like USDB include compliance features (freeze/unfreeze) that the token issuer can invoke. This is common across regulated stablecoins but differs from native BTC, which has no issuer authority.
• Exit costs: withdrawing any asset to Bitcoin L1 requires an on-chain transaction. During high-fee periods, small balances may be uneconomical to exit. This affects all Bitcoin Layer 2 solutions.
• Ecosystem maturity: Spark launched in 2025 and its network effect is still growing. Spark-to-Spark payments work only with other Spark wallets, though Lightning interoperability extends reach to the broader Bitcoin payment network.

Why It Matters

The separation between "Bitcoin wallet" and "stablecoin wallet" is not a fundamental constraint: it is an artifact of how different protocols evolved on different chains. Bitcoin L1 was designed for BTC. Ethereum became the default home for stablecoins. Lightning scaled BTC payments but had no token model. Users inherited the fragmentation because no single layer could do both.

Spark changes the equation by handling BTC and tokens within the same statechain architecture, the same custody model, and the same transfer primitive. The implication is straightforward: a user no longer needs to choose between Bitcoin and stablecoins at the wallet level. They hold both, send both, and convert between them without leaving a single self-custodial environment.

For the broader Bitcoin ecosystem, this addresses one of the key barriers to mainstream adoption. Most people need dollar-denominated stability for everyday transactions and Bitcoin for long-term savings. A wallet that serves both use cases from a single interface, with instant settlement and no bridging, eliminates the complexity that has kept non-technical users on custodial platforms.

To experience the unified wallet model firsthand, download General Bread or explore the Spark SDK to build your own. For more on how Spark's architecture enables this, read our technical overview of Spark or explore the full list of stablecoins on Bitcoin.

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.