The evidence-led thesis
Spark does not eliminate third-party trust; in ordinary default use, it redistributes that trust across Lightspark’s hosted SSP, a three-member Operator set, and an operatorless exit process that none of eight reviewed consumer wallets implements end to end. These systems can observe durable wallet and payment metadata and refuse hosted operations. If a former owner and an Operator threshold retained matching old keys, they could also authorize a fresh conflicting spend. Privacy, payment liveness, post-transfer safety, and practical self-custody therefore depend on operational behavior users cannot independently verify.
What the public record establishes: Reviewed transfer and Lightning paths replicate participant identities and payment data to every Operator. Lightspark’s default SSP authenticates the same wallet identity, receives full invoices and Bitcoin withdrawal addresses, and can decline hosted requests; each Operator also has a wallet-specific state-change gate. The published mainnet client makes Lightspark the default SSP, fixed coordinator, and one of three Operators at a two-of-three threshold. In the reference inbound-Lightning flow the SSP is the former leaf owner, so retained matching keys from the Lightspark SSP, Lightspark Operator, and Flashnet Operator would be sufficient to sign a fresh conflicting spend. None of the eight reviewed wallet surfaces supplied the complete in-app fallback; the documented process instead requires current recovery material, external on-chain fee funds, and a multi-stage Bitcoin procedure.
Critical boundary: This dossier establishes architecture, capabilities, and conditional attack requirements—not abuse. No public evidence reviewed shows that old keys were retained, Operators colluded, a conflicting signature was made, available datasets were combined in practice, sanctions logic was wired into the SSP or wallet gate, or that gate was used against a production wallet. The retained-key conclusion requires matching historical keys and the published configuration, which is not a live-server attestation. Privacy mode can suppress covered public reads, integrators can change the default services, and a user who already holds complete current recovery state and external fee funds may still exit without Operator cooperation.
The strongest evidence
Selected for evidentiary force and practical consequence. Each analysis reproduces the relevant technical details, available source excerpts, and limitations, with links to the originals for verification.
Key finding · Privacy, control, and safety
In Spark's reference inbound-Lightning flow, the SSP is the former owner of the leaf. Under the published two-of-three configuration, retained matching keys from the Lightspark SSP, Lightspark Operator, and Flashnet Operator would be sufficient to sign a fresh conflicting spend; no evidence shows retention or collusion.
Read the full analysisKey finding · Unilateral exit
The reviewed snapshots and public interfaces for Blink, Primal, Cake, Blitz, Radar, Club Orange, Wallet of Satoshi, and Bringin exposed no complete in-app sequence for preserving current exit state, supplying CPFP funds, ordered broadcasting, durable resume, timelock handling, and final sweeping. Closed-source findings are limited to public claims and observed interfaces.
Read the full analysisKey finding · Privacy, control, and safety
Spark grants public transfer access when any sender or receiver is readable, and its test suite preserves full participant detail in that case. Because outgoing Lightning leaves go to one fixed, publicly indexed SSP identity, this is a concrete privacy limitation rather than a hypothetical two-wallet edge case.
Read the full analysisKey finding · Unilateral exit
Blink's published case study states that a seed cannot rediscover current leaves after Operators are offline. Its documented procedure requires complete, current, validated leaf and ancestor state, represented by a recovery bundle saved while Operators are reachable; with that state, the seed still supplies signing authority.
Read the full analysisKey finding · Privacy, control, and safety
Spark distributes the complete Lightning invoice, payment hash, amount, fee, direction, and wallet identities to every Operator while dividing only the cryptographic shares. Each Operator stores the original invoice beside the affected Spark identity.
Read the full analysisKey finding · Unilateral exit
Spark's FAQ says a user can exit at any time by broadcasting a pre-signed transaction. Its dedicated beta manual separately requires Bitcoin Core v29, external L1 UTXOs, economic leaf selection, exact package ordering, mainnet signing and timelock handling, and warns that the wallet is unusable until completion.
Read the full analysisKey finding · Privacy, control, and safety
The reviewed Operator snapshot defines a per-wallet, per-Operator control named as a wallet kill switch and keyed by the wallet identity public key. Relevant state-changing handlers enforce it while read-only calls remain available; a network-wide freeze requires configuring every Operator.
Read the full analysisKey finding · Unilateral exit
Blink's published method evaluates each leaf against the CPFP cost of its full exit chain plus final sweep. As fee rates rise, costs rise while leaf value does not, so additional leaves can fall below the economic threshold. This is an economic limit, not a cryptographic one.
Read the full analysisKey finding · Privacy, control, and safety
The default wallet authenticates Lightspark's SSP with the same identity signer used at the Operator layer. The SSP model attaches that identity to request history containing full Lightning invoices and exact cooperative-exit Bitcoin destinations, creating a deterministic join key.
Read the full analysisKey finding · Unilateral exit
Blink's documented workflow advances packages confirmation by confirmation, pauses for CSV refund timelocks, and later requires separate sweeps. Under the documented standard-mempool relay path, automation can resume and parallelize independent leaf chains, but it cannot remove within-chain confirmation ordering or the CSV timelock.
Read the full analysisComplete public record
The full collection covers source code, product behavior, contracts, public claims, exit mechanics, and the limits of what those materials can establish.
Showing all findings
Metadata, policy, and Operator trust
Protocol code, published configuration, provider interfaces, live public observations, and trust assumptions. The findings distinguish visibility and cryptographic capability from unproved claims about data use, key retention, collusion, or private compliance wiring.
Privacy, control, and safety
Spark's public repository directs local SSP work to a separate Lightspark Sparkcore path that was not publicly accessible when checked. The public repository exposes the SSP schema, clients, and flow documents, but not the referenced Python handlers or full server-side decision logic. [10 sources]
Privacy, control, and safety
Spark defines an IP-restricted, Lightspark-only SSP interface for cross-wallet node, transfer, static-address, and tree queries. Reviewed handlers and a pinned commit explicitly bypass ordinary wallet-privacy checks for SSP calls. [4 sources]
Privacy, control, and safety
The reviewed Operator snapshot defines a per-wallet, per-Operator control named as a wallet kill switch and keyed by the wallet identity public key. Relevant state-changing handlers enforce it while read-only calls remain available; a network-wide freeze requires configuring every Operator. [2 sources]
Privacy, control, and safety
When the wallet gate fires, the affected client receives the same PermissionDenied response and message used for a session-identity mismatch. Tests enforce that external indistinguishability; internal logs, metrics, and error codes retain the actual reason. [3 sources]
Privacy, control, and safety
The receiver-side task applies the wallet gate before completing pending transfers, expressly including SSP-funded incoming transfers. The source covers a freeze set after transfer creation but before task pickup. This establishes code behavior, not a known production compliance block. [1 source]
Privacy, control, and safety
Spark's reviewed V2 preimage-share consensus path applies the wallet gate to the affected user even when an SSP, LNURL provider, or another hosted actor makes the call. The source says each Operator checks the identity during the Prepare phase. [1 source]
Privacy, control, and safety
Public Spark code applies the wallet gate to cooperative exits, ordinary and static deposit-address operations, deposit-tree creation, leaf renewal, transfer claims, and privileged token broadcasting. Privileged broadcaster authorization expressly does not bypass the target wallet's gate. [8 sources]
Privacy, control, and safety
When Spark's Kubernetes knob provider is enabled, Operators watch a ConfigMap for live changes. An integration test freezes one wallet while preserving reads, leaves a second wallet unaffected, and restores the first wallet when the value is cleared; public evidence does not establish production activation. [3 sources]
Privacy, control, and safety
Grid's common account schema permits the EMBEDDED_WALLET type and FROZEN status to appear together. EMBEDDED_WALLET is Spark-backed; FROZEN is defined as unable to send or receive and may follow compliance or fraud signals. The record is a schema capability, not an observed freeze. [4 sources]
Privacy, control, and safety
Lightspark describes Grid Global Accounts as running on Spark wallets. In the same product presentation, it says Lightspark handles identity verification, sanctions screening, risk review, and corridor compliance for the regulated movement layer. [1 source]
Privacy, control, and safety
Lightspark's published Grid agreement template assigns Lightspark responsibility for end-user KYC, KYB, AML, and sanctions screening. It also assigns Lightspark control over its onboarding, verification, transaction-execution, suspension, and termination decisions. [1 source]
Privacy, control, and safety
Lightspark's published Grid agreement template permits it to refuse, delay, reverse, or freeze a Grid transaction because of law, suspected illegal activity, sanctions-screening results, or other identified risk. This is direct Grid evidence; it does not establish the enforcement path for ordinary non-Grid Spark users. [2 sources]
Privacy, control, and safety
Lightspark's sanctions explainer describes sender and receiver address checks when a transaction begins and immediate blocking when a match occurs. Its Grid description says compliance checks are integrated into transactions, including Bitcoin reward payments. [2 sources]
Privacy, control, and safety
Spark grants public transfer access when any sender or receiver is readable, and its test suite preserves full participant detail in that case. Because outgoing Lightning leaves go to one fixed, publicly indexed SSP identity, this is a concrete privacy limitation rather than a hypothetical two-wallet edge case. [6 sources]
Privacy, control, and safety
Lightspark's official Connect SDK exposes screenNode for sanctions screening of a Lightning node using a configured provider token. The same SDK names Chainalysis, and archived official documentation describes screening a recipient node public key. This does not establish mandatory screening or Spark SSP use. [3 sources]
Privacy, control, and safety
Spark distributes the complete Lightning invoice, payment hash, amount, fee, direction, and wallet identities to every Operator while dividing only the cryptographic shares. Each Operator stores the original invoice beside the affected Spark identity. [6 sources]
Privacy, control, and safety
Spark permits multiple SSPs and Lightspark announced that Breez would operate one. The reviewed current Spark and Breez default configurations nevertheless identify the same single Lightspark SSP URL and identity. [4 sources]
Privacy, control, and safety
The reviewed Spark and Breez SDK snapshots each configure three Operators with a 2-of-3 threshold but select Lightspark SO0 by fixed identifier or index. No automatic coordinator rotation or failover was found in either snapshot; integrators can supply custom configurations. [3 sources]
Privacy, control, and safety
Spark expressly excludes tokens from privacy mode, permits anonymous token queries with no wallet filter, and paginates the complete token-transaction table. Returned records expose owner public keys, exact amounts, outputs, status, and timestamps. [6 sources]
Privacy, control, and safety
Spark identifies Flashnet as one of its three Operators. Flashnet's published service terms exclude sanctioned users and state that its compliance policies may result in transaction rejection, service restriction, or fund freezing within Flashnet's application services. [2 sources]
Privacy, control, and safety
Spark's reviewed V3 transfer paths distribute participant identities and transfer records to every configured Operator. Operators outside a signing subset still persist the transfer rows, so threshold signing does not make transfer metadata Operator-blind. [4 sources]
Privacy, control, and safety
A normal wallet authenticates the same durable identity to every Operator and queries each for that identity's leaves. Operator code can associate that pseudonym with connection metadata; structured request logging, when enabled, can also record request bodies and client details. [8 sources]
Privacy, control, and safety
The default wallet authenticates Lightspark's SSP with the same identity signer used at the Operator layer. The SSP model attaches that identity to request history containing full Lightning invoices and exact cooperative-exit Bitcoin destinations, creating a deterministic join key. [9 sources]
Privacy, control, and safety
For a publicly readable wallet, Spark's unauthenticated client can calculate its exact available balance and enumerate leaves. Returned records include ownership keys, tree relationships, exact values, timestamps, and multiple raw Bitcoin transaction fields. [4 sources]
Privacy, control, and safety
Spark describes static-address rotation as useful for privacy, but the implementation archives the old address and creates its replacement under the same immutable owner identity. That linkage is retained and distributed across the Operator set. [4 sources]
Privacy, control, and safety
Spark's own research calls deletion of historical Operator shares an unverifiable operational promise. The implementation contains real ephemeral-storage and cleanup controls, but it permits brief version coexistence, best-effort deletion, and a documented legacy main-database fallback. [5 sources]
Privacy, control, and safety
The published mainnet SDK inherits a two-of-three Operator threshold. Because the user side combines with any two Operator shares, one honest or nonparticipating Operator cannot by itself prevent two matching retained shares from satisfying the Operator quorum. [4 sources]
Privacy, control, and safety
In Spark's reference inbound-Lightning flow, the SSP is the former owner of the leaf. Under the published two-of-three configuration, retained matching keys from the Lightspark SSP, Lightspark Operator, and Flashnet Operator would be sufficient to sign a fresh conflicting spend; no evidence shows retention or collusion. [9 sources]
Recovery requirements and wallet support
SDK and wallet surfaces, state prerequisites, the published Blink mainnet case, time, and economics. These materials distinguish a protocol primitive from a completed consumer recovery product.
Unilateral exit
The reviewed snapshots and public interfaces for Blink, Primal, Cake, Blitz, Radar, Club Orange, Wallet of Satoshi, and Bringin exposed no complete in-app sequence for preserving current exit state, supplying CPFP funds, ordered broadcasting, durable resume, timelock handling, and final sweeping. Closed-source findings are limited to public claims and observed interfaces. [11 sources]
Unilateral exit
Blink’s exit mechanics separate the amount eventually swept from the Spark wallet, leaf value excluded by economic triage, and independent on-chain bitcoin spent on CPFP and funding transactions. A destination amount is therefore not the same measure as net economic recovery. [3 sources]
Unilateral exit
Breez still does not expose a public mobile unilateral-exit API. Its open draft implementation begins by listing live leaves and reaching the coordinator-backed service; neither the shipped path nor the proposal starts from an offline recovery bundle. [4 sources]
Unilateral exit
Blink's published case study states that a seed cannot rediscover current leaves after Operators are offline. Its documented procedure requires complete, current, validated leaf and ancestor state, represented by a recovery bundle saved while Operators are reachable; with that state, the seed still supplies signing authority. [2 sources]
Unilateral exit
The reviewed Breez mobile configuration stores ordinary wallet data in SQLite but supplies no persistent tree store, falling back to an in-memory tree store. The lower-level exit service requires tree nodes that this default mobile path does not durably retain. [3 sources]
Unilateral exit
Spark exit state can change when leaves are created, transferred, split, renewed, claimed, or spent. Blink's proposed mobile design therefore refreshes its recovery state after balance-changing events; a mnemonic backup made once cannot encode later tree mutations. [1 source]
Unilateral exit
Spark's current CLI begins with live leaf discovery and requests external fee UTXO data. In normal mainnet mode it emits transactions and unsigned CPFP PSBTs with manual ordering instructions, but lacks a complete durable broadcast, resume, timelock-monitoring, and sweep workflow. [1 source]
Unilateral exit
Spark's FAQ says a user can exit at any time by broadcasting a pre-signed transaction. Its dedicated beta manual separately requires Bitcoin Core v29, external L1 UTXOs, economic leaf selection, exact package ordering, mainnet signing and timelock handling, and warns that the wallet is unusable until completion. [4 sources]
Unilateral exit
Blink's published 100,000-sat wallet contained 22 leaves and 253 root-to-leaf package steps. When all packages were first submitted together, 252 were rejected because the transaction graph could not enter the mempool in that form. [1 source]
Unilateral exit
In Blink's 100,000-sat case, 18 of 22 leaves holding 9,888 sats cost more to recover than their value at 1 sat/vB. Only four leaves holding 90,112 sats were selected for the documented attempt. [1 source]
Unilateral exit
Blink's first documented mainnet recovery bundle omitted a legacy root required for offline construction. The tool initially failed without Operator access and was changed to fetch missing roots explicitly and reject open chains before producing a corrected bundle. [2 sources]
Unilateral exit
Breez 0.19.0's exit status walker omitted the SplitLocked state even though Spark renewal handlers create that intermediate parent. The resulting package can omit a required unbroadcast parent; the reviewed correcting pull request remained open. [3 sources]
Unilateral exit
Normal Spark use can split and re-split wallet state into multiple leaves, each with an independently sequenced exit chain. The workload of an emergency exit therefore depends on the wallet’s tree history as well as its displayed balance. [3 sources]
Unilateral exit
Blink's published method evaluates each leaf against the CPFP cost of its full exit chain plus final sweep. As fee rates rise, costs rise while leaf value does not, so additional leaves can fall below the economic threshold. This is an economic limit, not a cryptographic one. [3 sources]
Unilateral exit
Blink's documented workflow advances packages confirmation by confirmation, pauses for CSV refund timelocks, and later requires separate sweeps. Under the documented standard-mempool relay path, automation can resume and parallelize independent leaf chains, but it cannot remove within-chain confirmation ordering or the CSV timelock. [3 sources]
Unilateral exit
The documented independent exit requires external on-chain fee funding before the Spark value becomes spendable on chain. A third party could sponsor the UTXO, but doing so replaces the user's funding requirement with a service dependency. [4 sources]
Unilateral exit
Blink's Weekly Brief said the exit used only the seed with no Operators online and that 89,668 sats reached the destination. Its linked case study requires previously saved recovery state and records the selected exits as still awaiting refund maturity and final sweeping. [4 sources]
Unilateral exit
Cake Wallet describes unilateral exit as publishing a pre-signed transaction. In the reviewed Cake snapshot, the pinned Breez version had not shipped its public mobile exit API and no complete recovery-bundle or unilateral-exit product flow was found. [5 sources]
Unilateral exit
Club Orange's published 4.1.8 Android artifact bundled Breez Spark's lower-level unilateral-exit primitives, but its 46 exported BreezSdk method names contained no unilateral-exit or recovery operation and the targeted DEX search found no corresponding user-flow strings. [3 sources]
Unilateral exit
Blitz's separate recovery site describes recovery without third parties, but its implementation restores a Spark wallet through live services and calls cooperative withdrawal. It does not construct or broadcast unilateral-exit packages. [3 sources]
Unilateral exit
Across Primal, Radar, Wallet of Satoshi, and Bringin, public control or recovery claims were not matched in the reviewed surfaces by a demonstrated complete user-operated exit. Closed-source findings are limited to published claims, instructions, and observed interfaces rather than unseen implementation code. [18 sources]