Spark is a variant of Statechains. Statechains are an original second-layer protocol originally developed by Ruben Somsen in 2018. Statechains are a proposed off-chain system that allows a user (such as Alice) to delegate the ability to spend a UTXO to another user (Bob), who can then further delegate the spending authority to a third user (Carol), and so on. The off-chain delegation operations are all performed using signature adaptors and the cooperation of a trusted third party who employs the eltoo mechanism—and their knowledge of every previous delegation—to ensure each new delegation uses a state number higher than any previously used state number. These incrementing state numbers ensure that an on-chain spend by the most recent delegate (Carol) can take precedence over spends by previous delegates (Alice and Bob), provided the trusted third party hasn’t colluded with a previous delegate to cheat. Beyond collusion with a delegated signer (such as Alice or Bob), there is no way for the trusted third party to steal funds. A delegated signer can always spend the UTXO on-chain without needing permission from the trusted third party, arguably making Statechains less trusted than federated sidechains. We can think of Statechains as a digital version of Opendime. We know that Statechains can’t provide the same trustless self-custody as the Lightning Network, but we still like them. Statechains can be part of the Lightning Network. https://medium.com/@RubenSomsen/statechains-non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39 https://bitcoinops.org/en/topics/statechains/ https://opendime.com/ https://bitcoinmagazine.com/technical/bitcoin-layer-2-statechains https://www.spark.money/ View quoted note →

If you operate your own Lightning channel, that’s the best case — you can use a fully native Lightning wallet. If not, the five wallets mentioned above, each with their own tradeoffs, can still be used to send and receive Lightning payments by leveraging the service provider’s inbound liquidity. The difference lies in how “bitcoin” is stored under the hood — each takes a different form. When both sender and receiver use the same provider and system, payments are typically settled internally without touching the Lightning Network. But if they’re on different providers, the payment is routed through the Lightning Network. View quoted note →

The counterparty risk for Wallet of Satoshi and Cashu users is that the server operator might run away with the funds. Liquid users face the risk that multiple federation members might collude to steal the funds. Spark users face the risk that the service providers might collude with the previous sender to double-spend the received funds. The counterparty risk for Ark is that if the user stays offline for too long and their VTXO expires, the service provider may be able to take control of it. You could imagine a wallet that works like this: for balances under 1,000 sats, it uses Cashu; for amounts over 10,000 sats, it switches to Spark; for over 100,000 sats, it uses Ark; and once the balance exceeds 500,000 sats, it sets up a self-managed Lightning channel. View quoted note →

The Lightning Network remains the most secure option. From a purely technical perspective, many so‑called Layer 2 designs aim to perform more actions off‑chain from a single on‑chain UTXO operation, thereby reducing the burden on the base layer. This is likely one reason they are grouped under the “Layer 2” label. However, my view comes from another angle. When it comes to Bitcoin usage, most alternatives to Lightning require introducing a pre‑defined third‑party trust model. These third parties are ultimately legal entities, which means that the assets flowing within such systems are only nominally Bitcoin. Service providers in these designs often have the ability to censor or freeze transactions under certain circumstances. Even if users retain some form of unilateral exit, Bitcoin itself is inherently supra‑sovereign, whereas the security of these systems falls below that threshold. In contrast, Lightning transactions represent actual Bitcoin, and the risk of attack is highly localized. By comparison, centralized service providers present larger attack surfaces. From this perspective, I see non‑Lightning solutions more as on‑chain extensions that trade some security for additional functionality, whereas Lightning is the only true Layer 2. For most users, the majority of their Bitcoin will likely remain either on‑chain or in Lightning channels, rather than locked in these alternative systems, which act more like specialized functionality bridges. In terms of design, compatibility with Lightning atomic swaps exists mainly for interoperability; in practical payment use cases, these solutions tend to operate around Lightning rather than replace it.