What malicious operators can do

One operator can censor without a signing majority

Suppose operator B wants to freeze Alice's ordinary Spark activity while serving everyone else. In the listed all-participant flows, B sees the affected identity and can refuse preparation. Every selected participant must succeed, so two willing signers do not by themselves get that operation through. [S02] [S03] [S04] [S06]

The built-in wallet refusal control has different enforcement points. A transfer claim checks it at the coordinator; merely changing a non-coordinator's switch does not establish a universal claim freeze. Storing receive-preimage shares checks the wallet at every participant. A malicious participant can also refuse beyond the places where the built-in control is wired. [S26] [S13] [S25]

Changing the coordinator does not remove a refusing operator from a flow that still requires every participant. Making identification a condition of cooperation is therefore a credible censorship scenario. Restoring service by reconfiguring operators is a separate intervention, not an established ordinary-wallet bypass. [S01] [S02] [S04]

An independent SSP still depends on operator cooperation

An SSP supplies services such as Lightning swaps and liquidity; it need not be run by a signing operator. The reviewed open-ssp implementation has its own wallet and Lightning backend, but calls the operator receive-swap API to deliver Spark funds. [S30] [S29]

The official operator code includes an optional allowlist of senders allowed to initiate Lightning receive swaps. Every participant checks it. One operator could enable the gate, exclude a competing SSP's sender identity and continue admitting another provider. The gate defaults off; its production setting and any actual exclusion were not verified. [S27] [S28] [S14]

That power can obstruct the SSP's normal receive service on this operator set. It does not prohibit someone from hosting the software, running their own Lightning node or using another operator deployment. Separate private RPC permissions found in the open-ssp fork are identified as fork evidence in the grid. [S30] [S31]

An invoice can lead to a wallet identity, then a refusal

If a BOLT11 invoice embeds a Spark address, anyone holding the invoice can extract that identity: zero malicious operators are needed. That is the scope of spark-invoice-doxxer. Not every invoice includes the address; the reviewed Breez SDK defaults do not prefer Spark over Lightning. [S35] [S34]

For an ordinary receive invoice stored by the operators, one operator can instead look up the invoice or payment hash alongside the owner's Spark identity. Public embedding is unnecessary for that correlation. An operator can then use the identified wallet as the target of refusal on the affected flows. Possessing the invoice alone does not give an outside observer the operator's refusal power. [S13] [S25] [S04]

A merchant or service that already knows Alice can supply the outside information connecting that wallet identity to a person. A public key by itself is not a legal name. Private mode restricts API readers; it does not prevent an operator from disclosing its own database. Proxies may hide a user's direct IP without removing the wallet identity fields. [S32] [S33] [S06] [S13]

Two operators control a threshold, but which secret matters

When A and B withhold their matching signing shares, C alone cannot produce the operator contribution for a new Bitcoin signature. When A and B cooperate, they can supply that contribution. Spark still requires the user contribution: even all three current operator shares alone cannot create an arbitrary Bitcoin spend. [S01] [S07]

A different threshold protects ordinary receive preimages. Two operators with matching stored non-HODL shares can reconstruct the preimage outside the intended release sequence. This can compromise the swap's secret-release condition. Collecting a Lightning payment additionally depends on a party able to use that preimage; this is not a demonstration that SO processes can drain arbitrary Spark balances. [S36] [S37] [S38] [S39]

Former-owner collusion is the conditional theft scenario

Suppose Carol transfers a leaf to Alice. Carol retains her old user key, and operators A and B retain their matching historical shares. Ownership rotation changes the split between the user and operator keys while preserving the combined Bitcoin key. Together, those retained components can form a complete historical signing key without Alice revealing her current key. [S40] [S07]

A fresh conflicting spend is theoretically possible if the relevant output is still spendable and its required ancestry is available. C deleting its old share does not remove the two matching shares retained by A and B. One retained operator share plus Carol's old key alone is insufficient under the stated two-share model. Existing signed stale exits have separate timing and monitoring conditions. [S01] [S40] [S44]

This scenario requires historical retention and the former-owner contribution. If the former owner was an SSP, access to that SSP's corresponding wallet key could supply the latter; control of its SO process alone does not establish that access. Spark includes separate secret storage and deletion mechanisms. Reading the code cannot prove that every historical copy was erased in a deployment. [S41] [S30]

Three operators can remove every operator source of recovery help

All three can withhold every operator copy of recovery records and stop their watchtower assistance. One or two cannot control the copies held by honest survivors, although record completeness and a usable retrieval path still matter. None acquires the power to erase an independent user backup simply by controlling operator servers. [S44] [S42] [S43]

A freeze does not itself invalidate complete, valid, already-signed Bitcoin recovery transactions. Using them still depends on the necessary keys and transaction graph, fee funding, Bitcoin access, timelocks, chain state and monitoring. A seed alone cannot recreate a missing co-signed graph. This technical boundary does not establish that a consumer wallet offers a usable exit flow. [S42] [S43] [S44]

An outage and permanent share loss have different outcomes

If two operators go offline with valid state intact, ordinary signing stops. Users can wait for service to recover; an outage does not force everyone to exit immediately. Even one offline participant can obstruct fresh all-participant preparation. [S07] [S02] [S04]

A wiped metadata database is different from permanent loss of secret shares. Spark separates ordinary state from versioned secret storage. Restoration must recover compatible shares and ownership state; a backup's mere existence does not establish a tested recovery procedure. [S41]

If two matching current shares are permanently lost without recoverable copies, the remaining share cannot sign for the affected existing keys. Starting replacement operators with new keys does not recreate that authority. Users needing access would depend on existing valid Bitcoin recovery paths. If the required graph is also unavailable from every accessible source, funds can become inaccessible. [S07] [S42] [S43]

Reproducible references

Code versions and evidence

Each code link points to the reviewed commit. Official documentation is a dated, mutable reference. The SSP fork is identified separately from official operator code.

• Spark operator code0b3a32a05c9ac06cc411683551dd1f1bde9d0caa

  Official source; deployed binaries and runtime settings were not verified.

• Breez Spark SDK61d5b0b494e0c18dd71c2859bed1e946c24b62b1

  Published wallet configuration, preimage sharing, privacy defaults, and recovery-state handling.

• open-ssp25eec4a8c492a16a4d1962b7115430181a8200ad

  Independent SSP implementation; its existence does not establish compatibility with the founding mainnet operator deployment.

• open-ssp operator fork83cca565c3cce1a4692cedef601fef553ed0249b

  Fork-specific private RPC permissions; not evidence of the official mainnet permission settings.

• spark-invoice-doxxerab88dd0b3334d0ff46dbf97c20f838f0f11fb1be

  Public invoice parser; extraction requires an invoice containing the Spark address.