What is Spark? A Bitcoin Layer 2 Built on Statechains

Spark allows sending and receiving Bitcoin without blockchain transactions. Rather than moving funds on-chain, what changes is who can authorize spending it. The protocol builds on statechain concepts introduced by Ruben Somsen in 2018, enhanced with FROST threshold signatures and a leaf architecture supporting partial transfers.

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

The mechanism uses a two-of-two multisig model. One cryptographic key belongs to the user; operators collectively hold the other via threshold signing. Neither party alone can spend funds: self-custody is maintained because operators cannot move assets without user participation.

How Transfers Work

When Alice transfers to Bob, the same Bitcoin remains in the identical on-chain address. The Spark Entity generates a new key for Bob and adjusts its own key mathematically. The old key matching Alice is destroyed, making Alice's piece cryptographically useless while Bob's aligns with the operator's tweaked key.

Key deletion is critical: The security of this model depends on the SE actually destroying its old key share after each transfer. If the SE kept old keys, it could collude with a previous owner to double-spend. This is where the trust model becomes important.

Leaves: Solving the Whole-Coin Problem

Traditional statechains required transferring entire UTXOs. Spark introduces leaves, off-chain representations of partial balances within a tree structure.

Tree components

• Root (Txn0): The on-chain UTXO with permanently destroyed operator keys
• Branches: Internal transactions connecting root to leaves without timelocks
• Leaves: Terminal transactions owned by users, each with relative-timelock exit transactions

Leaves split instantly for payments and merge back together. Child keys mathematically combine to equal parent keys, enabling flexible value distribution without blockchain interaction.

The Trust Model

Spark operates on 1-of-n security: as long as one operator behaves honestly, user funds remain secure. The Spark Entity comprises multiple independent operators using FROST threshold signatures, with no single operator possessing complete key material.

Currently two operators (Lightspark and Flashnet) manage the system, with plans to expand to diverse jurisdictions.

Moment-in-Time Trust

Trust is required only during each transfer. Once complete and keys destroyed, operators cannot affect transactions even if later compromised, demonstrating perfect forward security.

Operator Capabilities

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

Users receive pre-signed exit transactions upon receiving Spark funds. These timestamped transactions enable broadcasting to Bitcoin without operator permission, establishing an escape route if operators become unavailable or malicious.

Relative timelocks establish ownership hierarchy: current owners have the shortest timelocks, preventing previous owners from invalidating exits through competing broadcasts.

Watchtowers: Spark operators also function as watchtowers, monitoring the blockchain for fraudulent exit attempts by previous owners. Unlike Lightning, exit transactions are not "toxic". Multiple parties can broadcast simultaneously, and the valid one with the lowest timelock wins.

Lightning Compatibility

Spark integrates natively with Lightning through Spark Service Providers. When paying Lightning invoices, SSPs execute atomic swaps: either both transfer legs complete or neither does, eliminating trust requirements.

A distinctive feature: users receive Lightning payments while offline. SSPs hold payments conditionally until the recipient comes online; unplucked payments return to senders after timeout, improving upon standard Lightning's online-requirement constraint.

Spark vs Lightning

Both networks address different problems with distinct tradeoffs.

Lightning uses payment channels requiring channel management, liquidity planning, and online status for receiving. It achieves full decentralization without trusted operators but introduces complexity, especially for mobile implementations.

Spark eliminates channel management and liquidity planning while enabling offline receiving. The tradeoff involves trusting that minimum one operator remains honest during transfers.

Complementary, not competing: Spark includes native Lightning support. You can receive Lightning payments to your Spark balance and send Lightning payments from it. The two networks are interoperable, not in conflict.

The Tradeoffs

Lack of Provable Finality

Key risk: operators cannot cryptographically prove key deletion. Theoretically, if all operators collude with previous owners, double-spending becomes possible. Practically, the 1-of-n assumption means one honest operator prevents this. Finality differs fundamentally from on-chain Bitcoin's mathematical certainty after confirmations.

Operator Availability

When all operators go offline, new Spark transfers cannot proceed, though L1 exits remain available. This represents a liveness requirement rather than safety issue.

Exit Costs

L1 exits require on-chain transactions with associated fees. Small balances may become uneconomical to exit during high-fee periods: a limitation affecting all Bitcoin Layer 2 solutions.

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.

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.