What is Spark? The Bitcoin Layer 2 behind the new wave of self-custodial wallets

Bitcoin’s base layer is deliberately conservative. That is not a bug. It is what makes the system verifiable by ordinary users, resistant to arbitrary rule changes, and difficult to capture. But it also means Bitcoin is not designed to record every small payment in the world directly on-chain.

A global monetary network needs at least 2 different functions. The 1st is final settlement: the ability to hold and transfer value with strong guarantees, public verification and no trusted intermediary. The 2nd is everyday payments: the ability to move small amounts quickly, cheaply and with an experience that normal users can understand.

Lightning was Bitcoin’s first serious answer to this tension, it made instant payments possible by moving activity into payment channels while keeping Bitcoin as the final settlement layer. But Lightning is not simple to productize in a fully self-custodial mobile wallet. Channels, inbound liquidity, routing, backups, always-online requirements and liquidity management remain difficult to hide without introducing a service provider.

Custodial wallets solved the user experience problem by removing the self-custody problem. A user opens an app, sees a balance, receives payments and sends instantly. But the trade-off is obvious: the intermediary holds the funds. That creates regulatory exposure, operational risk, possible withdrawal restrictions, censorship risk and the familiar problem Bitcoin was built to avoid, trusted third parties.

🪙 Is Bitcoin (BTC) Really a Currency?

Spark enters this landscape as a different compromise. It aims to give wallets and applications a user experience close to a custodial Lightning wallet, while avoiding direct custody in the classic sense. Funds are meant to be recoverable on Bitcoin L1 and payments can be fast, cheap and compatible with Lightning.

But Spark should not be understood as magic, it does not totally remove trust from Bitcoin payments.

Spark is best understood as a response not only to Bitcoin’s scaling problem, but also to the regulatory and operational cost of custodial Bitcoin wallets. Its promise is attractive precisely because it lets wallets keep much of the convenience of custody while shifting part of the custody burden back toward users. That may be useful, it may even be necessary for some products, but it is not the same guarantee as holding a normal Bitcoin UTXO directly on-chain, or having a Lightning channel or an Ark VTXO.

What is Spark?

Spark is a Bitcoin Layer 2 designed for fast, low-cost payments and wallet applications. It is built around statechains, a family of protocols where the right to spend Bitcoin-linked funds can be transferred off-chain without moving the underlying coins on-chain for every payment.

In simple terms, Spark lets a user hold a balance that can move quickly inside the Spark system, while still being connected to Bitcoin through pre-signed exit transactions and to the Lightning Network through swaps. The user does not need to open a liquidity channel, manage inbound liquidity, run a node, or understand routing. Wallets and service providers can abstract most of that complexity.

Spark is not a separate blockchain, not a rollup and not a smart contract platform. Its own documentation describes it as an off-chain scaling solution built on statechains, with no VM, no sequencer and no external consensus layer. The goal is narrower: make bitcoin and token transfers fast and cheap, while preserving interoperability with Lightning and an exit path back to Bitcoin L1.

The system relies on several actors : a Spark Entity is the group of operators that runs a Spark, a Spark Operator is one participant in that group, a Spark Service Provider can help users enter and exit Spark, and may also provide Lightning connectivity.

That makes Spark different from both a custodial wallet and a simple Bitcoin wallet. In a custodial wallet, the service holds the funds. In a normal Bitcoin wallet, the user controls UTXOs directly. Spark sits between these 2 models: the user has key material and a path to exit, but normal payments depend on an operator set that coordinates signatures, updates state and remains available.

That gray zone is the whole point with Spark.

Why Spark exists: UX, custody and regulation

Bitcoin L1 is settlement, not a retail payment database

Bitcoin’s base layer is optimized for credible settlement, blocks are limited, fees rise when demand for block space increases, and confirmation takes time. These constraints are the reason a full node can verify the entire system and enforce the rules without asking permission from a company, exchange or validator set.

But this architecture does not scale everyday retail payments by simply putting every coffee purchase, social media tip or in-app transfer on-chain. If every user had to touch the base layer for every payment, fees and confirmation times would quickly make the experience unusable.

This is why Bitcoin scaling is not a single feature, it is a stack. The base layer provides final settlement; upper layers experiment with different ways to make frequent payments cheaper and easier.

Lightning works, but is hard to productize in self-custody

The Lightning Network remains the most important payment network built on Bitcoin. It is fast, widely integrated and increasingly used as the common payment rail between different Bitcoin applications.

The difficulty is not that Lightning does not work, the difficulty is making it invisible.

A fully self-custodial Lightning wallet has to deal with channels, liquidity, routing, backups and online monitoring. Modern wallets have made enormous progress, especially with Lightning Service Providers (LSP), but the user experience still depends on infrastructure that someone must operate.

For a developer building a mobile app, social platform, exchange wallet or payments product, this creates a dilemma. Custody gives the best UX, while self-custody gives the best sovereignty. Lightning gives fast payments, but it does not automatically give a clean product experience.

Custodial wallets solved the UX, but created a regulatory problem

Custodial Lightning wallets have shown what users actually want: instant payments, simple balances, easy receiving and no channel management. Wallet of Satoshi became popular largely because it made Lightning feel like a normal payment app.

But custody changes the nature of the business. If a wallet holds user funds, it may face money transmission rules, compliance obligations, geographic restrictions, withdrawal controls and direct responsibility for user balances. If regulators apply pressure, the service can be forced to leave markets, impose limits or change its model.

Spark gives wallets another path. A service can offer a similar experience, a simple balance, instant payments, Lightning compatibility, while structuring the system so that users hold keys and the service is not merely maintaining an internal custodial ledger.

That does not make the user’s security equivalent to Bitcoin L1, but it changes the product and regulatory posture. For companies running wallets and exchanges, that may be one of the most important features of Spark.

How Spark works

Statechains and shared signing

To understand Spark, start with Bitcoin’s UTXO model.

Bitcoin does not use accounts in the banking sense, a wallet balance is made of unspent transaction outputs, or UTXOs. When you spend bitcoin, you consume one or more UTXOs and create new ones.

A statechain changes the way ownership moves, instead of creating a new on-chain transaction every time a payment happens, the system transfers control over a Bitcoin-linked claim off-chain. The coins remain anchored to Bitcoin, but the right to spend them changes hands through signed updates.

In Spark, the user holds one part of the signing control, while Spark operators collectively participate in the other side. The system can be understood as a shared-signing model: users and operators cooperate to update who has the latest valid claim. Spark uses distributed signing so that the operator side is not supposed to be controlled by one single key (one single person or company).

This is where FROST enters the design, it is a threshold signature scheme: it allows several operators to cooperate in producing signatures without any single operator holding the entire operator key. For a non-technical reader, the important point is not the cryptographic detail, but the role it plays: Spark tries to avoid a single custodian by splitting the operator side of the signing process.

During a transfer, the recipient must receive a newer valid state and a path to exit ans the previous owner should no longer be able to reclaim the same funds, but that relies on a crucial assumption: old key material must be deleted or made unusable by the operator set.

The problem is, just like it is impossible to prove God doesn't exist, we cannot prove that this older key really have been deleted. If an information existed in the past, we cannot be sure it haven't been copied or backed-up.

Therefore, to use Spark, you need to trust that the operator has actually deleted its access to your funds, just as you would trust a custodian not to rug-pull you.

Leaves and balances

Spark also introduces a tree-like structure, instead of treating a deposit as one indivisible claim, balances can be represented through branches and leaves.

Leaves are the terminal parts of the tree, they are the pieces owned by users. Branches are intermediate transactions that help organize those leaves. This structure allows value to be split, recombined and transferred with fewer on-chain interactions, making those cheaper.

For the user, this can look like a normal wallet balance, but behind the scenes, however, the wallet must track a more complex off-chain state. It must know which leaves it controls, how they relate to parent transactions, and how to exit if cooperation fails.

This matters because the user experience can be simple while the recovery model remains technical. A Spark wallet may feel like a balance in a neobank app, but the guarantee depends on the wallet’s ability to preserve and use the right exit data.

Operators and service providers

Spark operators are not optional background actors. They are part of the protocol’s normal operation.

The Spark Entity coordinates signing and state transitions, individual Spark Operators participate in that entity, and Spark Service Providers help users move between Spark, Bitcoin L1 and Lightning. They may facilitate deposits, withdrawals, swaps and Lightning payments.

When everything works, the user barely sees them, the app receives, the app sends, Lightning invoices are paid and the balance updates.

When something breaks, the operator role becomes central. Are operators online? Are they independent? Can they censor? What metadata do they see? Can users exit cheaply? Can a wallet recover without the provider’s cooperation? Is the operator set large enough to make the “at least one honest operator” assumption meaningful?

According to Spark’s own FAQ, the network launched with a small operator set, initially including Lightspark and Flashnet, with the stated intention to add more operators over time. That is understandable for a beta system, but it also matters for the trust model. A 1-of-N assumption is only as strong as the practical independence, incentives and distribution of N.

How Spark interacts with Lightning

Spark does not replace Lightning, it uses it as the external payment rail that connects Spark wallets to the wider Bitcoin ecosystem and the user does not manage a Lightning channel inside Spark. Instead, Spark Service Providers, or Lightning providers connected to Spark, handle the Lightning side while the user’s balance is updated through Spark’s own statechain-style transfers.

When a Spark user receives over Lightning, the payer still pays a Lightning invoice, but the receiver does not need to run a node, open a channel, manage inbound liquidity or stay online like a traditional self-custodial Lightning wallet. The payment is bridged into Spark, and the receiver ends up with Spark funds.

When a Spark user pays a Lightning invoice, the process runs in reverse: Spark leaves are conditionally transferred, the Lightning provider pays the invoice, and Spark finalizes once the payment proof is available.

Is Spark self-custodial?

This is the most important question in the article.

Spark’s documentation and partner announcements describe the system as self-custodial. In a limited sense, that is understandable. Users have keys. Operators should not be able to move funds alone. Spark includes unilateral exit transactions that are meant to let users withdraw to Bitcoin L1 without operator cooperation.

But if “self-custody” means the same guarantee as holding a normal Bitcoin UTXO with your own private key, Spark does not meet that standard.

The user has a key, but not Bitcoin L1 guarantees

With a normal Bitcoin UTXO, the model is direct, if you control the private key, you can sign a transaction, you broadcast it to the network, you still depend on fees and block inclusion, but you do not depend on an operator to have forgotten old state.

Spark is different. The user holds a key and should have an exit path, but the system’s normal operation depends on shared signing, off-chain state, operators and correct key updates. A Spark balance is not the same object as a simple on-chain UTXO.

That does not make Spark a custodial wallet in the classic sense. A properly functioning Spark wallet is not merely an account balance on a company’s server, but it also should not be described as equivalent to direct Bitcoin self-custody.

Spark offers a self-custody-shaped user experience, but not the same self-custody guarantee as holding bitcoin directly on-chain.

The critical problem: key deletion cannot be verified

The critical weakness in Spark is not that the Spark Entity can simply move funds alone in the current state. In theory, it cannot.

Spark is built around a form of collaborative custody based on a two-of-two structure: one side is held by the current user, while the other is held by the Spark Entity. The Spark Entity’s signing power is itself distributed across several operators through FROST threshold signatures. To produce a valid spend from the current state, both the current owner and the Spark Entity must participate.

The main risk comes from the transfer mechanism used by statechains.

When Alice transfers funds to Bob, the bitcoin does not move on-chain. Instead, Spark transfers the off-chain ability to spend the Bitcoin-linked UTXO. Bob receives a new state and a new cryptographic capability, while the Spark Entity participates in a key rotation process and must delete the old operator key material linked to Alice.

That deletion is the critical step.

If a sufficient threshold of operators keeps the old operator share instead of deleting it, they may be able to collude with Alice, the previous owner, to reconstruct the old 2-of-2 state: Alice’s old user key on one side, and the old Spark Entity share retained by the operators on the other.

💡 What will happen if Bitcoin fails to become a currency?

In that scenario, the Spark Entity is not stealing alone. It needs the previous owner. But if the previous owner and a sufficient threshold of operators collude, they can attempt to revive an old state and double-spend against Bob’s newer state.

This is the precise custody distinction. Spark is not custodial in the strict sense, because the Spark Entity cannot sign alone in the current state. But it is not strong self-custody in the Bitcoin L1 sense either, because the finality of a transfer depends on old operator secrets being effectively deleted, and the user cannot cryptographically verify that this deletion happened.

This is why Spark’s 1-of-N operator model matters. If at least one operator whose cooperation would be needed to reconstruct the old Spark Entity share behaves honestly and deletes its old secret, the old state becomes unusable. But this guarantee is still based on an assumption about operator behavior, not on a proof that the user can independently verify.

The user may no longer be trusting a custodian in the classic sense, but they are still trusting the operator set to forget what the protocol requires it to forget. That is the difference between strong self-custody and self-custody as product architecture.

Why wallets and exchanges may adopt Spark

This ambiguity is not a side issue. It may be one of the reasons Spark is attractive.

Wallets and platforms want the user experience of custody without the risk of custody. They want users to open an app, receive instantly, pay Lightning invoices, send small amounts and never think about channels or liquidity. But they also want to avoid being the entity that simply holds everyone’s coins.

Spark offers a possible escape hatch, a wallet can say the user has keys, the service can integrate Lightning-like payments, and the app can keep the familiar balance-based experience. The intermediary’s role changes from pure custodian to infrastructure provider, operator, service provider or SDK integrator.

Wallet of Satoshi is the clearest example, Spark announced in July 2025 that the wallet was live on Spark with a self-custodial Lightning experience, and explicitly noted that the integration allowed the platform to serve the U.S. market again. Cake Wallet later added Lightning support through the Breez SDK built on Spark infrastructure, same for the Primal wallet.

These examples should not be read as proof that Spark gives users the same guarantee as Bitcoin L1. They show something different: Spark solves a product problem for wallets that want custodial-like UX without direct custodial architecture.

Spark may be attractive because it gives intermediaries a way to keep the user experience of custody while moving part of the custody burden back to the user.

For companies, this is not only a product argument, it is mostly a regulatory one. Spark gives wallets and exchanges a way to argue that they are no longer simply holding customer balances as a classic custodian, but providing infrastructure around a user-controlled balance with an exit path. That does not settle the legal question, and the answer will depend on jurisdiction and implementation, but it may reduce the custody-related exposure that pushed some Lightning wallets out of certain markets.

That is useful. It is also exactly why users should be careful with the word “self-custody.”

Spark vs Ark: 2 ways to avoid Lightning complexity

The Spark and the Ark protocol are often discussed together because they address a similar problem. Both are Bitcoin scaling protocols that can make payments easier without asking every user to manage Lightning channels directly. Both can connect to Lightning. Both move complexity away from the end user.

But they do not move that complexity to the same place.

Ark gives users virtual UTXOs, or VTXOs, coordinated by an operator and refreshed through rounds. Spark uses statechain-style ownership transfers, shared signing, leaves and operator key updates. In both cases, Bitcoin remains the final settlement layer, while Lightning remains the payment rail used to reach the wider ecosystem.

Ark uses VTXOs and rounds; Spark uses statechains and operator key updates

QuestionArkSparkMain unitVTXOLeaf / statechain-like claimCore mechanismRounds, VTXO refresh, exitsKey updates, shared signing, exitsFinality modelStronger after round / settlementMore dependent on the latest state and the deletion of old secretsTarget UXPayments without managing LightningCustodial-like UX with Lightning abstracted awayMain riskOperator, expiry, liquidity, round participationOperators, key deletion, privacy, false sense of self-custodyRegulatory angleLess central in the product narrativePotentially central for wallets and exchanges

Ark’s trade-offs are easier to describe in temporal terms : between rounds, the user has weaker guarantees, but after settlement, exit rights become stronger. VTXO expiry, round participation and operator liquidity are central to the model.

Spark’s trade-off is more focused on state integrity and operator behavior. The user experience can be smoother, but the security model depends heavily on old keys being deleted and on the operator set behaving as required.

What can Spark be used for?

The most obvious use case is mobile wallets. Spark can give wallet developers a way to offer fast bitcoin payments, Lightning interoperability and simple receiving without forcing users to open channels or manage liquidity.

That makes it relevant for several categories:

• consumer Bitcoin wallets;
• social apps with micropayments or creator tips;
• exchanges or fintech apps that want faster Bitcoin deposits, withdrawals or internal payments;
• merchant payment tools;
• applications that need small frequent payments;
• wallets that want Lightning addresses without becoming pure custodians.

Breez’s Spark SDK positioning is especially important here, it presents Spark as a way for developers to add instant, non-custodial bitcoin to apps, and lists many integrations or partners. This suggests that Spark may spread less as a protocol users consciously choose, and more as infrastructure hidden inside applications.

That is how most payment technology reaches mainstream users, they do not choose the protocol, they choose the app.

Stablecoins and tokens: useful, but not the core Bitcoin guarantee

Spark also supports tokens and stablecoin use cases. Lightspark’s original announcement highlighted stablecoin issuance as part of the product direction, and Spark’s documentation describes token support.

This should be treated separately from bitcoin payments.

A bitcoin balance on Spark already has a different security model from a direct Bitcoin UTXO. A stablecoin on Spark adds another layer of trust: issuer risk, freezing rules, redemption risk, regulatory constraints and compliance requirements. Even if Spark provides fast transfers, it cannot turn a centrally issued asset into bitcoin.

Stablecoins may be useful for payment applications, but they should not be bundled rhetorically with Bitcoin’s self-custody guarantees.

What are Spark’s limitations and risks?

False sense of self-custody

Spark’s biggest risk may be semantic. If users hear “self-custodial” and assume “same as holding bitcoin on-chain,” they will misunderstand the product.

Spark is not a custodial exchange account. But it is also not the same as a normal Bitcoin wallet. It is an assisted, operator-dependent model with an exit path.

That distinction matters most when something goes wrong.

Key deletion cannot be proven

The operator must forget old key material. The protocol depends on that. But the user cannot directly verify deletion.

This makes Spark different from models where incorrect behavior is punished or prevented entirely by on-chain mechanisms. Spark’s security is trust-minimized, not trustless. It depends on at least one operator behaving correctly in the relevant key deletion process.

Operator dependency

If all operators are offline, Spark’s FAQ says users cannot make new Spark transfers until operators return, although they should still be able to exit to Bitcoin L1 with pre-signed transactions.

That is a liveness issue rather than immediate theft, but it still matters. Payments systems need uptime. A wallet that only works when its operator infrastructure works is still dependent on that infrastructure.

Privacy risks

Spark payments are not automatically private just because they do not appear as ordinary on-chain payments.

Operators may see transaction information. Service providers may see flows between Spark and Lightning. Some implementations may leak metadata through addresses, invoices or explorers. Cake’s Spark announcement highlights privacy defaults such as not broadcasting Spark addresses in Lightning invoices and not publishing transactions to a public ledger, which implicitly shows that these are implementation choices, not automatic properties of every Spark wallet.

Privacy therefore depends on the wallet, operator policies and data publication choices.

Exit complexity

The exit path is essential to Spark’s self-custody claim, but a theoretical exit is not the same as a simple exit.

Users need the right data, the wallet must preserve it, and on-chain fees must be affordable. During normal operation, a Spark wallet may feel instant and cheap. During stress, exiting to L1 can become slower, more expensive and more technical.

This does not make Spark useless. It means the exit path should be tested and explained, not merely mentioned.

Regulatory ambiguity

If Spark becomes attractive because it reduces the appearance or structure of custody, regulators may eventually examine the substance of control.

Does the user meaningfully control funds? Can the service freeze, censor or prevent ordinary use? How practical is unilateral exit? How independent are operators? Who controls the user interface, recovery process and transaction flow?

These questions matter because Spark may sit in the same gray zone technically and legally: not a pure custodian, not pure self-custody.

Maturity

Spark is still young. Its own FAQ describes the environment as beta, warns that limits may apply, and says the initial operator set is small. That is not unusual for a new protocol, but it should temper claims about production-grade trustlessness.

Bitcoin L1 has been tested for more than a decade. Lightning has years of real-world usage. Spark is newer and should be treated accordingly.

Is Spark a Bitcoin Layer 2?

Spark can reasonably be described as a Bitcoin Layer 2, but only if the term is used carefully.

It is not a separate blockchain like a sidechain, it is not a rollup, it does not introduce a virtual machine or smart contract environment, it does not replace Lightning.

Spark is an off-chain coordination layer built on Bitcoin. Users move Bitcoin-linked value inside Spark through shared signing and statechain-style transfers, while Bitcoin L1 remains the final exit and settlement layer.

The label “Layer 2” is therefore acceptable, but the mechanism matters more than the category. Spark’s trust model is not Lightning’s trust model, not Liquid’s trust model and not Ark’s trust model. It is its own compromise.

Spark’s place in the Bitcoin scaling stack

Bitcoin scaling is becoming modular.

Bitcoin L1 provides monetary rules, censorship resistance and final settlement. Lightning provides fast routed payments. Liquid provides a federated sidechain model with faster settlement and asset issuance. Ark explores VTXOs, rounds and operator-coordinated settlement. Cashu offers e-cash with excellent UX but mint-based custody. Spark adds statechains, shared signing and a wallet-friendly payment layer that can connect to Lightning.

No single layer solves every problem. Each one chooses a different point in the trade-off space: UX, custody, privacy, liquidity, fees, regulation and recoverability.

Spark’s place in that stack is clear, it is not the most trustless way to hold bitcoin, it is not the simplest model to explain, but it may become one of the easiest ways for applications to offer Bitcoin payments without becoming fully custodial.

That is why Spark matters, and why it deserves scrutiny.

Conclusion: why Spark matters

Spark matters because it addresses a real bottleneck: self-custodial Lightning is too complex for many wallets, apps and users. If Bitcoin payments are going to appear inside social apps, mobile wallets, exchanges, merchant tools and consumer fintech products, developers need infrastructure that hides channels, liquidity and routing.

Spark offers one path. It lets wallets provide a familiar payment experience while reducing direct custody exposure. That may explain why projects such as Wallet of Satoshi, Cake Wallet and Primal have moved toward Spark-based infrastructure or SDKs.

But the user should not confuse regulatory convenience for strong self-custody. Spark moves custody risk into a more ambiguous zone: the user has a key, but the operator still matters; the wallet feels simple, but the guarantees are weaker than direct Bitcoin ownership; the system may be non-custodial in form, but not fully trustless in substance.

Spark is important not because it removes trust from Bitcoin payments, but because it shows how much trust users may accept when the alternative is a wallet that simply works.

FAQ

What is Spark in Bitcoin?

Spark is a Bitcoin Layer 2 built on statechains and shared signing. It lets users make fast off-chain transfers of Bitcoin-linked value while preserving a path to exit back to Bitcoin L1.

Is Spark self-custodial?

Spark is self-custodial in a weaker, assisted sense: users hold keys and should have a unilateral exit path. But it is not equivalent to holding a normal Bitcoin UTXO directly on-chain, because normal use depends on operators and on old key material being deleted.

Why are wallets adopting Spark?

Wallets can use Spark to offer a user experience close to custodial Lightning without directly holding user funds in the same way. This can reduce technical complexity and may reduce custody-related regulatory exposure, although the exact legal treatment depends on jurisdiction and implementation.

Does Spark remove custody risk?

No. Spark changes the custody model. It reduces direct custodial risk compared with a wallet that simply holds user balances, but introduces operator trust assumptions, exit complexity and state-management risk.

What happens if a Spark operator keeps old keys?

Spark’s security depends on operators deleting or forgetting old key material after transfers. If all relevant operators kept old secrets and colluded with a previous owner, the system’s protection against double-spending would be weakened. This is why Spark’s 1-of-N trust assumption matters.

Can Spark users exit to Bitcoin L1?

Yes, Spark is designed around pre-signed exit transactions that let users withdraw funds to Bitcoin L1 without operator cooperation. The practical safety of that exit depends on wallet implementation, data availability and on-chain fees.

What is the difference between Spark and Ark?

Ark is based on VTXOs, rounds, refreshes and operator-coordinated settlement. Spark is based on statechain-style transfers, shared signing, leaves and operator key updates. Both aim to reduce Lightning complexity, but Spark is more directly suited to custodial-like wallet UX, while Ark makes settlement cycles more explicit.

Is Spark safer than Ark?

Not in a simple yes-or-no sense. Ark and Spark make different trade-offs. Ark has risks around operators, liquidity, expiry and rounds. Spark has risks around operators, key deletion, privacy and false self-custody expectations.

Can Spark support stablecoins?

Yes, Spark supports token and stablecoin use cases. But stablecoins introduce issuer risk, freezing risk and regulatory risk. Their guarantees should not be confused with Bitcoin’s guarantees.

Is Spark safer than a custodial wallet?

In many cases, Spark should offer stronger user control than a purely custodial wallet, because users hold keys and should have an exit path. But it is still not equivalent to direct on-chain self-custody.

Source: Spark