Review of Spark Trust Model and Risks

Editorial disclaimer: This research is presented as an unbiased and factual review of public evidence. This homepage summary and the expanded note below—and only these sections—state an opinionated conclusion about Spark. The remainder of the publication reports evidence, methodology, limitations, and bounded conclusions without editorial opinion.

The case in plain English

Spark asks users to trust a centralized service while calling the result non-custodial

Spark may be “non-custodial” under a narrow technical definition: the wallet holds key material and the protocol contains a path that can eventually move coins without asking an Operator to sign again. That description leaves out nearly everything that determines whether an ordinary person actually controls their money.

Spark is not private in the ordinary meaning of the word

A normal Spark wallet identifies itself to every Operator with the same durable wallet identity. The reviewed transfer paths give every Operator the participants and transaction records, not merely an unreadable fragment of a signature. In the reviewed Lightning flow, every Operator receives the full invoice, amount, direction, payment hash, and affected wallet identities. The default hosted service can attach that same identity to Lightning requests and exact Bitcoin withdrawal destinations.

Changing apps or rotating a deposit address does not create a new identity. Public participation can expose complete transfers, and the reviewed public interfaces can reveal exact holdings and raw Bitcoin transaction material for wallets in public mode. Spark may hide activity from casual blockchain observers, but it replaces public-chain visibility with visibility inside a small service network. That is a different privacy model—not privacy from the parties operating the system. Review the privacy evidence.

Spark is centralized where users actually feel it

The published design names three Operators, but the ordinary software path does not behave like a neutral market of independent providers. The reviewed SDKs fix Lightspark's SO0 as the default coordinator without automatic failover, and both expose the same Lightspark hosted service by default. Integrators can change those defaults, but users of finished wallet products generally receive the configuration chosen for them.

The signing threshold is two of three. Under this review's stated threat model, Lightspark and Flashnet coordination is treated as a core assumption, so those two roles form an effective quorum without Breez. That is not proof that they have colluded or share keys. It is the security assumption users must evaluate: the advertised three-party structure offers little comfort if two closely connected roles can act together. Review the quorum analysis.

Spark can censor a wallet

The Operator code contains a wallet-specific refusal control—a kill switch keyed to the wallet's durable identity. Relevant state-changing operations check it, including transfers, claims, cooperative exits, deposit operations, renewal, and privileged service paths. The control can preserve read access while refusing the actions needed to move money, and one reviewed provider can update it live and selectively.

The public evidence does not show that every Operator has enabled this control in production or that it has been used against a particular customer. It does show that selective censorship is a designed and tested capability, not an outside speculation. Concentration at the default coordinator and hosted Lightning service creates additional places where ordinary payments can be delayed or refused even before a network-wide block is considered. Review the censorship evidence.

As a consumer safeguard, unilateral exit is a farce

The marketing version sounds simple: if Spark disappears, broadcast a pre-signed transaction and recover the bitcoin. The documented procedure is nothing like that. A mnemonic does not contain the wallet's current leaves or their transaction ancestry. The wallet must preserve a fresh, complete exit-state backup while Operators are still available and update it whenever the wallet changes. If the outage arrives first, the seed alone cannot reconstruct what needs to be broadcast.

Even with that state, the user needs separate on-chain bitcoin to pay fees, software that can build and sign parent-and-child transaction packages, a package-relay-capable Bitcoin service, exact root-to-leaf ordering, confirmation monitoring, retry and resume logic, relative-timelock calculations, and later sweep transactions to a separately verified address. The operation can span days or weeks and must survive app termination, provider failures, fee changes, stale transactions, and chain reorganizations.

Our sanitized mainnet case began with approximately 100,000 sats. Ordinary wallet use produced more than 30 leaves and a full plan exceeding 900 Bitcoin transactions. Economic triage meant deliberately abandoning part of the balance; even the selected recovery needed roughly three dozen ordered packages, separate fee funding, long waits, and final sweeps. After more than two dozen packages had confirmed, the coins still had not reached a destination. Read the complete case study.

Software could automate these steps, including software running on a phone. But none of the eleven reviewed consumer-wallet surfaces provided the complete flow. A hypothetical future recovery system is not a recovery feature available to today's user. Calling the exit “available at any time” while leaving the user to build an incident-response system is, in practical consumer terms, a farce. Review the wallet implementations.

For all practical purposes, the user experiences custody

There is a real technical distinction between holding every signing key and depending on a threshold protocol. That distinction does not settle the consumer question. Control over money means being able to access it, move it, and recover it when the normal service refuses or disappears. If the app cannot perform the independent recovery, if the seed cannot reconstruct the required state, and if spending normally depends on a small set of identifiable operators and hosted services, then the user does not possess practical, independent control.

That is why “non-custodial” may be technically defensible yet deeply doubtful in context. It describes the key arrangement while omitting the operational reality. For the ordinary mobile user—not a protocol engineer with a current recovery bundle, external fee coins, custom tooling, a reliable Bitcoin package relay, and days to supervise the process—Spark behaves like a custodial wallet: private operators can observe activity, normal use depends on centralized infrastructure, transactions can be refused, and the advertised escape hatch is not actually delivered by the product.

The bottom line: Spark moves custody risk around rather than making it disappear. Its marketing emphasizes the cryptographic possibility of eventual escape. The evidence shows that privacy, availability, censorship resistance, and usable recovery remain concentrated in systems the user does not control.