Spark brings together several concepts introduced to the Bitcoin community over the past few years and is heavily inspired by Statechains. With a lot of empathy, since we've gone through the same process ourselves, we'll take the time to explain each concept, making it as clear and enjoyable to read as possible. This section is still relatively high-level. For the technically savvy, we invite you to read our technical overview which gets into the weeds of Spark.

The general idea of Spark is that it allows assets on Bitcoin to be spent off-chain instantly. In Spark, the user sends funds into a shared-signature address, where the user retains full control of their funds and the ability to exit without any interaction from any other party. The participants of this address are the user and the Operators of Spark. When a user wants to transfer ownership of these funds, the Spark Operators adjust their keys so the new owner takes control, while the overall signature key remains static. The beauty of this is that at every moment, the current owner remains in full control of their funds and can exit at any time without needing permission from anyone. While users look to SOs to validate transactions by adjusting keys to reflect those transactions, the SOs do not assume control over users funds.

There are several ways to interact with Spark:

1. Move funds in and out of Bitcoin
2. Move funds within Spark to other users
3. Move funds in and out of Lightning

Key Definitions

To fully understand how these transactions work, it helps to know who's doing what and how everything fits together.

Moving funds into, within, and from Spark

Now that you're familiar with the key terms, we can dive into Spark and see how everything comes together. As mentioned earlier, there are a few ways to move funds in and out of Spark.

Bitcoin -> Spark

From your existing wallet, all you have to do is send some BTC to a deposit address shared by both you and the SE.

Before you transfer funds into Spark, you and the SE will sign an exit transaction. This is so that if the SE ever goes offline, you can reclaim your funds on L1 to your preferred address. Once your deposit is confirmed on-chain, you're all set—congratulations, you now have funds on Spark!

Spark <-> Spark

You can transfer ownership of a leaf to other users within Spark by coordinating with the SE. A transfer is only considered valid when the receiver holds a fully signed Bitcoin transaction they can use to unilaterally exit.

Lightning <-> Spark

Users within Spark can always send and receive payments directly via existing Lightning Network rails.

Importantly, Spark users don't need to run a node, manage Lightning channels, or lock up liquidity themselves. This eliminates almost all the overhead associated with traditional Lightning operations while providing true offline receive, which isn't available in typical Lightning.

All Lightning payments are facilitated by SSPs, who accept funds on Spark to send Lightning payments or receive Lightning payments in exchange for funds on Spark. These transactions are executed through atomic swaps, ensuring that neither the SSP nor the user is at risk of losing funds.

Spark -> Bitcoin

Spark is designed in a way that ensures users are able to exit to Bitcoin L1 whenever they want, without needing permission from anyone. There are two ways to exit Spark to L1:

The Cooperative Exit

This is the cheapest and fastest way to exit Spark. Similar to Spark-Lightning transfers, cooperative exits are executed through atomic swaps with an SSP, exchanging Spark funds for on-chain Bitcoin.

The Unilateral Exit

This represents the most pessimistic scenario and can occur at any time. While there doesn't need to be a specific reason to unilaterally exit, users might choose this option if a set of Spark Operators (SOs) goes offline or if they've lost confidence in the Spark Entity (SE) itself. Unilateral exits are more expensive than cooperative exits because more than one transaction needs to be published to prove ownership of the most recent state.

This solution requires no cooperation, and can be done by any user at any time. This is core to the design of Spark.

Tokens on Spark

Spark enables any assets on L1 to be spent off-chain instantly. This means that LRC-20s, BRC-20s, and Taproot Assets can be used on Spark, enabling the fastest and cheapest token experiences on Bitcoin, paving the way for stablecoins and novel applications.

Tokens on Spark are moved just like any other asset, with the same level of trust and security.

Risks

As you've probably understood by now, Spark Operators play a crucial role in Spark. They facilitate the sending and receiving of funds on the network.

It's important to understand that the trust model in Spark is time-bound and specific to each transaction. In a non-threshold setting, the system requires only 1 honest operator out of

participants at the time of transaction. With a threshold configuration, this increases to a minimum number of honest operators, represented by , which is still a minority of SOs.

Crucially, once a transaction is complete, the risk dissipates. If the minimum number of operators (or 1/n in a non-threshold setting) delete their last key after a transaction, the user is completely protected from any potential loss of funds or malicious actions. This means that while there is a trust requirement at the moment of transfer, it doesn't persist indefinitely.

The threshold configuration offers a balance: it increases the number of operators that need to be trusted momentarily, but it also enhances the network's robustness by reducing the need for every single SO to be online at all times. This makes the system more resilient from a network perspective while maintaining strong security guarantees for users.