The case against Spark

01

Power over ordinary use

The concentration begins with the published deployment. Spark names three signing operators: Lightspark, Breez and Flashnet. The reviewed SDK configurations use a two-of-three operator signing threshold, select Lightspark as the default coordinator and configure Lightspark's hosted Lightning service. No automatic coordinator failover was found in those SDK snapshots. Integrators can change configuration, but changing a setting does not transfer existing funds, signing shares and recovery state into an independent network. A choice available to a developer also does not establish a choice available to the person using the finished wallet. Configuration and coordination evidence.

The two-of-three description can obscure a more restrictive operational dependency. In several reviewed flows, all three operators must participate in preparing a new operation before it can complete. One refusing operator can therefore block the covered Spark sends, incoming transfer claims, deposit finalization, Lightning swap operations, cooperative withdrawals and leaf renewals. Two honest signing shares do not bypass a failed preparation stage. These findings concern the specified API paths and fresh operations; already committed operations and some retries differ. Nevertheless, the central weakness is clear: a single operator can have veto power over important wallet functions without possessing a signing majority. Action-by-action operator analysis.

Selective refusal is explicitly implemented. Spark's operator code contains a control keyed to a wallet's persistent identity that rejects relevant state-changing operations while leaving read access available. The client-facing error is deliberately the same as an ordinary session-identity mismatch, while operator logs retain the actual reason. That makes a targeted denial harder for the affected user to diagnose from the response alone. The control defaults to allowing wallets, and the research does not establish its activation against a production user. The criticism concerns the capability: a wallet can remain readable while operations needed to move its money are refused. Wallet refusal implementation.

The power to refuse also creates the power to demand concessions. An operator whose cooperation is required could condition it on identification or other eligibility rules. Spark's lack of protocol-level KYC does not remove that operational possibility. Ordinary Lightning payments do not inherently require UMA, so compulsory UMA should not be presented as an existing universal restriction. But a user has little practical protection against new service conditions if the alternative is an expensive recovery procedure their app cannot execute. This is an inference from documented refusal powers, not a claim that every Spark wallet currently requires KYC. Policy capabilities and their conditions.

Lightspark's own account products illustrate why signing authority and service policy must be examined separately. Its Global Accounts presentation describes accounts built on Spark, user authorization of outgoing funds, and Lightspark handling identity checks, sanctions screening and compliance operations. Those are statements about a particular product, not the rules of every Spark wallet. They nevertheless demonstrate that retaining a user's signing contribution is compatible with extensive control over the services through which the user moves money. A claim of self-custody does not, by itself, answer the question of who decides which transactions receive service. Lightspark's account description.

02

A provider users depend on

Lightning access introduces another dependency. Both reviewed SDK defaults point to Lightspark's SSP, the service that executes the Lightning side of payments. If that provider refuses or becomes unavailable, the configured path cannot be assumed to continue working. Publicly available clients and schemas expose parts of the interface, but the referenced Lightspark SSP server implementation was not publicly accessible in the review. Users and wallet developers therefore lack the same visibility into its complete decision logic. A successful integration with a hosted API is a dependency on that service's continued availability and willingness to act. Default provider configuration, SSP implementation visibility.

Independent SSP software is possible. The open-ssp project is meaningful evidence of that. Its reviewed test environment, however, used forks and disabled operator authorization; it did not establish admission, liquidity or automatic failover on the existing mainnet deployment. Operator code also contains an optional allowlist for Lightning receive senders, checked by every participating operator. It defaults off, and its production setting is unverified, but it creates a mechanism for excluding an unapproved provider from the covered flow. Operators cannot prohibit someone from writing competing software. They can withhold the cooperation that software needs to serve users on their deployment. Independent SSP evidence and limits, receive-sender allowlist.

03

Visibility without permission

Privacy is another substantial weakness. The reviewed wallet authenticates a persistent identity to every operator, and transfer processing distributes participant information and records beyond the operators selected to sign. In the reviewed Lightning receive flow, operators store the invoice and payment hash with the wallet identity. Splitting signing authority does not split this information into unreadable fragments. One malicious operator can disclose the records available to it without obtaining a majority's permission. Private mode restricts ordinary queries to the server; it does not conceal the database from the operator running it. Public mode can expose exact holdings and raw Bitcoin transaction material, and some transfers remain readable when a counterparty is public. Operator visibility and public-query boundaries.

This creates a direct connection between surveillance and censorship. An operator can associate a stored invoice with a wallet identity and use that identity to target covered operations. A public observer cannot necessarily do the same from any arbitrary invoice: the identity embedding decoded by spark-invoice-doxxer is optional and disabled in the reviewed SDK defaults. A wallet public key is also not automatically a person's name. Those limits matter, but they leave the operator-side problem intact. Once identifying information is attached through a counterparty or another service, the existing financial records may become attributable. Rotating a deposit address does not rotate the operator-side wallet identity. Invoice-to-wallet records, invoice embedding defaults, address rotation.

Additional copies of payment information can arise outside the core operator database. Dated SDK and wallet reviews found payment-object logging, diagnostic forwarding and local plaintext logs. These findings establish code paths, not that every record was uploaded or disclosed. Separately, the reviewed Breez cloud sync encrypts record contents but exposes deterministic record identifiers, which can support correlation for a party with the necessary record access and prior knowledge. It also omits exit trees and unilateral-exit state. A feature presented as synchronization or backup therefore needs scrutiny for both what it reveals and what it fails to preserve. Diagnostic paths, cloud-sync scope.

04

Security that depends on deletion

The security model contains a separate trust requirement around old signing material. Spark's forward-security argument depends on operators deleting obsolete key shares after transfers. Its code includes concrete storage separation, rotation and cleanup measures, but a user cannot verify that an operator has destroyed every historical copy. If two operators retain matching historical shares and collude with a former owner holding the corresponding old user key, they can potentially construct a conflicting spend of a still-spendable output with the necessary ancestry. One honest operator does not neutralize two retained shares under the reviewed threshold. This is a conditional theft scenario, not evidence that anyone has performed it. It is also precisely the kind of assumption that becomes important when operators are treated as potentially hostile. Spark's trust model, historical-key threat conditions.

Current operator shares alone do not give even all three operators the missing current user's signing contribution for an arbitrary Bitcoin spend. That protection should be stated accurately. It does not eliminate the historical-key scenario, and other secrets have their own thresholds: two matching operator shares can reconstruct a pending ordinary receive payment's preimage before its authorized release. Exploiting that secret to collect a Lightning payment also requires a party able to redeem it; this is not an automatic ability to drain arbitrary wallets. The broader concern is that different safeguards fail at different thresholds, which a simple self-custody label does not explain. Signing and preimage analysis.

05

An exit the user has to prepare

Unilateral exit is real, but its existence is only the beginning of the recovery question. A prepared user can publish a valid presigned Bitcoin exit without obtaining new operator signatures. An operator's wallet refusal setting cannot invalidate those transactions. The user must still possess the appropriate recovery material. A seed does not encode the current leaves, transaction ancestry and presigned transactions created during later wallet activity. If required data was never saved and no remaining source can provide it, possession of the seed does not reconstruct it. Independence during a failure depends on work completed before that failure. Recovery-state requirements.

Our optimized mainnet experiment exposed how easily that preparation can fall short. After a successful optimization, the stock export lacked complete ancestry for two of the ten available leaves, including the largest. Custom parent queries repaired the export while an operator remained reachable. This was a result for a particular wallet and pinned implementation, not proof that every backup is incomplete. It nevertheless demonstrates why an export button or a successful file write is insufficient assurance. The useful test is whether the saved material actually supports recovery after the services that supplied it disappear. Observed backup repair.

There is also a substantial gap between SDK functionality and a recovery feature a wallet user can operate. The current Breez SDK builds and signs exit transactions, including sweeps, and checks confirmations and timelocks. The application must still provide fee funding, broadcast the transactions, persist the evolving recovery state and resume the process across interruptions. These are implementable responsibilities, including on a phone. They are also essential parts of the product. Crediting a wallet with independent recovery because its dependency contains the necessary primitives gives it credit for work that may not have been integrated. Breez's exit guide.

Our September 11 review found no complete in-app operatorless recovery flow in the inspected material for twelve primary consumer products: nine source reviews, one APK surface review and two documentation reviews. The two documentation-only products remain unverified internally; the result does not prove their private code lacks recovery. Nor was this a runtime outage test of every wallet. Partial implementations deserve precise credit. Blitz's reviewed stable source exports a recovery bundle and directs users to external tooling, but its exporter excludes leaves below 16,348 sats and no complete in-app executor was found. That threshold is an application policy, not a universal Bitcoin minimum. These distinctions make the implementation gap more concrete, not less consequential. Dated wallet audit.

06

The cost of getting out

Exit economics add another obstacle. Spark balances are distributed across leaves whose transaction ancestry must be considered during recovery. The number, size and history of those leaves affect the work and fees required. The balance displayed by an app therefore does not tell its owner how much can be economically recovered through a particular exit route. In our historical approximately 100,000-sat case, a full plan exceeded 900 Bitcoin transactions. That figure describes a particular history and plan, not a universal price of using Spark. Five selected leaves were subsequently found recovered as 72,370 sats; the record must acknowledge that outcome. The remaining criticism is that ordinary wallet balances can conceal a much more complicated emergency settlement obligation. Mainnet case study and follow-up.

Optimization improved the later experiment without removing the problem. A live swap reorganized 38 leaves into ten in 23.7 seconds while preserving 89,569 sats. At a planned fee rate of 1 sat/vB, the new selection covered two leaves totaling 81,920 sats and left 7,649 sats outside the economical selection. Our signed plan contained 29 Bitcoin transactions and planned Bitcoin fees of 4,335 sats before any optional later sweep. The selected paths retained relative waits of 1,200 and 3,200 blocks: roughly 8.3 and 22.2 days at average block intervals, plus earlier confirmation dependencies. These were planned costs and waits, not a completed recovery result at the recorded checkpoint. Optimization measurements, funding and timing details.

Those numbers expose two practical weaknesses. First, the tested route required Bitcoin outside Spark to fund recovery of Bitcoin inside Spark. A user whose money is all in the affected wallet cannot assume the displayed balance will pay those upfront costs. Second, optimizing the leaves required a functioning SSP and operator cooperation. The reviewed optimization must complete an incoming claim that uses all-operator preparation, so one refusing participant can prevent completion. A favorable reorganization performed during normal service cannot be assumed available after censorship begins. The user then faces the leaves and backup they already have. Funding requirements, optimization's operator dependency.

This is the defensible scaling criticism. Cheap off-chain activity does not establish affordable independent settlement for every resulting wallet history. More small leaves can improve routine payment handling while making emergency recovery less economical, a tradeoff the SDK documentation expressly describes. Shared ancestors, optimization and alternative exit paths can reduce costs; no fixed transaction multiplier applies to every balance. But a widespread service failure could place many users in the same position at once, seeking block space while losing access to cooperative preparation. Our research has not measured a network-wide mass exit. It does show why normal-operation throughput is an inadequate measure of the system's ability to return control during a crisis. Leaf policy and exit cost.

07

When services fail

Data loss produces a related set of risks. Two offline operators leave only one signing share available, below the reviewed threshold; permanent loss of two matching current secret shares, without recoverable copies, prevents further signing for the affected keys. Wiping metadata is a different event, and an honest surviving operator or independent backup may still supply useful records. An outage does not force everyone to exit immediately: users can wait for service restoration. But waiting is itself dependence on that restoration, while independent recovery remains conditional on retained state and a usable Bitcoin path. Operator-provided watchtower assistance can also be withdrawn; independent watchtowers remain separate. Operators do not gain the power to erase a separately held backup or rewrite Bitcoin ownership merely by editing their databases. Availability, deletion and recovery scenarios.

The cumulative problem is how much the user must infer from a reassuring label. Spark's short-form documentation describes exit in terms of broadcasting a presigned transaction and recovering at any time. Its more detailed recovery material and the reviewed implementations involve state collection, fee funding, dependent broadcasts and waiting. The FAQ also calls the system highly experimental. Users should be shown these conditions where they decide to entrust the wallet with a balance. A recovery capability that is affordable only for some leaves, requires preparation the app has not demonstrated, or depends on external engineering support is a material limitation of the product. Spark FAQ, practical recovery assessment.

08

The standard we should demand

Our judgment is that Spark leaves too much authority over everyday financial life with its operators and default service provider. They can observe sensitive activity, refuse important operations and make continued service conditional, while effective independent recovery demands more than possession of a key. The conditional risks from retained historical secrets add a further reason to reject assurances based on operator behavior that users cannot verify. For a wallet intended to preserve its owner's independence under hostile conditions, these are fundamental shortcomings. We would not choose Spark as its backend on the strength of the current evidence. The standard should be demonstrated control when cooperation ends, including complete recovery data, usable software and a clear account of the money and time required to leave.