What is Spark? A Bitcoin Layer 2 Built on Statechains

The Core Idea

Spark allows you to send and receive Bitcoin without broadcasting transactions to the Bitcoin blockchain. The Bitcoin does not move on-chain when ownership changes. Instead, what changes is who can authorize spending it.

This is not a new concept. Statechains, first proposed by Ruben Somsen in 2018, introduced the idea of transferring UTXO ownership off-chain. Spark builds on this foundation with FROST threshold signatures, a leaf architecture that enables partial transfers, and native Lightning Network compatibility.

The result is a Layer 2 where transfers settle instantly, cost nearly nothing, and preserve self-custody. You can always exit to Bitcoin L1 without permission from anyone.

The Two-Piece Puzzle

To understand Spark, imagine that spending a particular set of Bitcoin requires completing a two-piece puzzle. One piece is held by the user. The other is held by the Spark Entity (SE), a group of operators. Only when both matching pieces come together can the Bitcoin be spent.

This analogy, introduced by Roy Sheinfeld, captures the core mechanic. Technically, the "puzzle pieces" are cryptographic key shares. The on-chain Bitcoin sits in a 2-of-2 multisig address: one key held by the user, one key collectively held by the Spark Operators through threshold signing.

Neither party can spend the Bitcoin alone. The user needs the operators. The operators need the user. This is what makes it self-custodial: the operators cannot move your funds without your participation.

How Transfers Work

When Alice wants to send Bitcoin to Bob on Spark, the puzzle does not change shape. The same Bitcoin stays locked in the same on-chain address. What changes is which pieces fit together.

Here is what happens:

1. Alice holds a puzzle piece that matches the SE's piece. Together, they can spend the Bitcoin.
2. Alice initiates a transfer to Bob. The SE generates a new puzzle piece for Bob.
3. The SE adjusts its own piece mathematically. Specifically, it "tweaks" its key by the difference between Alice's key and Bob's key.
4. The SE destroys its old piece that matched Alice.
5. Now only Bob's piece matches the SE's piece. Alice may still have her old piece, but it is useless because no corresponding piece exists anymore.

The Bitcoin never moved on-chain. The on-chain UTXO is unchanged. But ownership has transferred from Alice to Bob, enforced by cryptography.

Bob can repeat this process to transfer to Carol, and so on. Each transfer works by replacing the puzzle pieces, not by moving funds on-chain.

Leaves: Solving the Whole-Coin Problem

Traditional statechains had a limitation: you could only transfer whole UTXOs. If you deposited 1 BTC, you had to transfer the entire 1 BTC. You could not send 0.1 BTC to someone and keep 0.9 BTC.

Spark solves this with leaves.

Think of your Bitcoin on Spark as a tree. The root is the on-chain UTXO. The leaves are the actual balances you can spend. When you deposit Bitcoin, Spark creates a leaf representing your full balance.

When you want to send a partial amount, Spark splits your leaf into multiple new leaves: one for the recipient, one for your change. This happens off-chain, instantly. The on-chain UTXO remains unchanged, but the ownership of its value is now distributed across multiple leaves.

Leaves can be split into smaller amounts or merged back together. This flexibility enables normal payment flows: send any amount, receive any amount, manage your balance as you would with any wallet.

The tree structure

The tree has three types of elements:

• Root (Txn0): The on-chain Bitcoin UTXO. The SE destroys its key for this transaction, ensuring only one valid branch can exist.
• Branches: Internal transactions that connect the root to the leaves. These have no timelocks and can only be spent by aggregating the signatures of their children.
• Leaves: Terminal transactions owned by individual users. Each leaf has an exit transaction with a relative timelock.

The keys sum hierarchically: child keys combine to equal parent keys. This mathematical property enables flexible splitting and re-aggregation without touching the blockchain.

The Trust Model

Every Layer 2 has a trust model. Spark's is designed around 1-of-n security: as long as one operator out of n behaves honestly, user funds are secure.

The Spark Entity

The SE is not a single party. It is a group of independent Spark Operators who collectively hold the second puzzle piece using FROST threshold signatures. No single operator possesses the complete key. Replacing puzzle pieces requires cooperation among multiple operators.

Currently, Spark runs with two operators: Lightspark and Flashnet. The roadmap includes expanding to more operators from diverse jurisdictions and institutional backgrounds.

Moment-in-time trust

Spark's trust model is moment-in-time. You only need to trust the operators at the instant of each transfer. Once the transfer completes and the old keys are deleted, the operators cannot affect that transaction even if they are later compromised or turn malicious.

This is called perfect forward security. Past transactions remain secure even if future events compromise the operator set.

What operators can and cannot do

The worst case is not theft. The worst case is unavailability. If all operators go offline, you cannot make new Spark transfers, but you can still exit to Bitcoin L1 using pre-signed exit transactions.

Unilateral Exit

This is Spark's escape hatch. At any moment, you can move your funds back to Bitcoin L1 without permission from anyone.

When you receive Bitcoin on Spark, you also receive a pre-signed exit transaction. This transaction has a relative timelock and is valid for broadcasting to the Bitcoin network. If the operators disappear, turn malicious, or censor you, you broadcast your exit transaction and reclaim your Bitcoin on-chain.

How timelocks prevent double-spends

What stops a previous owner from also trying to exit? Timelocks.

Each transfer creates a new exit transaction with a shorter timelock than the previous owner's. If Alice transfers to Bob, Bob's exit transaction has a lower timelock than Alice's. If both try to exit, Bob's transaction can confirm first, invalidating Alice's.

Earlier owners have longer timelocks. The current owner always has the shortest. This establishes a clear ownership hierarchy enforced by the Bitcoin protocol itself.

Lightning Compatibility

Spark is natively compatible with the Lightning Network. You can send and receive Lightning payments from your Spark balance.

This works through Spark Service Providers (SSPs). When you want to pay a Lightning invoice, an SSP pays it on your behalf in exchange for a Spark transfer. The swap is atomic: either both legs complete or neither does. No trust required.

Receiving Lightning payments offline

One of Spark's notable features: you can receive Lightning payments while offline. The SSP holds the payment conditionally until you come online to claim it. If you never claim it, the payment returns to the sender after a timeout.

This is a significant improvement over standard Lightning, which requires your node to be online to receive payments.

Spark vs Lightning

Lightning and Spark solve different problems with different tradeoffs. Neither is universally better. Many users may use both.

Lightning architecture

Lightning uses payment channels between nodes. To pay someone, your payment routes through a network of channels. This requires:

• Opening and closing channels (on-chain transactions with fees)
• Maintaining inbound and outbound liquidity
• Finding routes through the network graph
• Being online to receive payments

Lightning is fully decentralized. There are no trusted operators. But the complexity is significant, especially for mobile wallets.

Spark simplifications

Spark removes much of this complexity:

• No channels to manage
• No liquidity planning
• Receive payments while offline
• Simpler SDK integration for developers

The tradeoff is the 1-of-n trust assumption. Lightning requires no trusted third parties. Spark requires trusting that at least one operator behaves honestly during each transfer.

The Tradeoffs

No Layer 2 is without tradeoffs. Understanding Spark's limitations is as important as understanding its benefits.

Lack of provable finality

The core risk in Spark is that you cannot cryptographically prove the SE deleted its old keys. If all operators collude with a previous owner, they could theoretically double-spend.

In practice, this requires every single operator to be malicious and coordinated with a specific previous owner. The 1-of-n assumption means just one honest operator defeats the attack. But it is a real difference from on-chain Bitcoin, where finality is mathematically provable after enough confirmations.

Operator availability

If all operators go offline, you cannot make new Spark transfers until they return. You can still exit to L1, but the Layer 2 functionality requires operator availability. This is a liveness requirement, not a safety one.

Exit costs

Exiting to L1 requires an on-chain transaction, which costs fees. During high-fee periods, small balances may be uneconomical to exit. This is true of all Layer 2s that settle to Bitcoin.

Who Is Building on Spark

Spark launched in 2025 with over 20 live integrations across wallets, infrastructure, and trading platforms.

Wallets

Infrastructure

Trading and DeFi

The protocol supports native token issuance using the BTKN standard. Stablecoins like USDB already exist on Spark, enabling dollar-denominated payments with Bitcoin settlement.