Operators, hosted services, and refusal controls
How the published Operator set, coordinator, hosted SSP, wallet gate, and adjacent compliance systems shape default-path control.
How to read this topic: 5 principal evidence groups organize 19 supporting records by the question they answer.
Critical boundary: The record documents defaults and capabilities. It does not show common ownership of Operator keys, coordinated enforcement, production use of the wallet gate, or a private compliance call wired into Spark.
Threat-model assumption TM-1: Lightspark–Flashnet coordination is treated as sufficiently likely to be a core adversarial assumption, creating one effective two-role quorum under the published threshold. Documented relationships make that risk material; they do not prove that collusion or shared key access has been observed.
Evidence group 01
The reviewed SDK defaults fix Lightspark SO0 as coordinator without automatic failover and expose one Lightspark SSP, while allowing integrators to supply different configuration.
Scope boundary: Defaults shape the ordinary path but are not protocol-level exclusivity. A custom integrator can choose another coordinator or SSP.
Centralization
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]
Centralization
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]
Evidence group 02
The threat model treats Lightspark–Flashnet coordination as sufficiently likely to be a core adversarial assumption. The published two-of-three set then lets those roles form a threshold without Breez; in the cited SSP-funded receive scenario, matching retained historical keys would be sufficient for a conflicting spend.
Scope boundary: Coordination is a core adversarial assumption, not an observed event. The record documents working and personnel ties as context; the additional key-retention condition is also unobserved. No evidence shows a conflicting signature or loss.
Centralization
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]
Centralization
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]
Centralization
Blitz initializes an auto-authenticated Flashnet client around its ordinary Spark wallet, while Flashnet authentication uses that wallet's exact Spark identity. Under TM-1, Lightspark and Flashnet records are therefore directly joinable by pseudonym rather than only by timing inference. [4 sources]
Evidence group 03
A per-wallet, per-Operator gate is implemented, tested, live-updatable under one provider, and enforced across several state-changing protocol paths.
Scope boundary: Each Operator controls its own gate. The public record does not show production activation, a network-wide value, its operator, or a sanctions-specific purpose.
Centralization
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]
Centralization
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]
Centralization
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]
Centralization
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]
Centralization
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]
Centralization
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]
Centralization
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]
Evidence group 04
The reviewed Operator policy defines a Lightspark-only, IP-restricted service surface with an application-anonymous subset for cross-system coordination.
Scope boundary: Application-anonymous does not mean publicly reachable. Method names and policy establish privileged access, not misuse or the live allowlist configuration.
Centralization
The pinned Operator policy defines a Lightspark-only SSP coordination surface. Nineteen operational methods use an anonymous application policy behind an internal IP restriction; newer SSP flows additionally require a session. This identifies a privileged network security boundary, not public access or misuse. [1 source]
Evidence group 05
Grid schemas, Grid product material, Connect screening code, and Flashnet terms document compliance and refusal capabilities around the Spark ecosystem.
Scope boundary: These records do not establish a private Grid, Connect, or Flashnet compliance decision wired into the Spark Operator wallet gate. They remain context, not proof of protocol enforcement.
Centralization
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]
Centralization
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]
Centralization
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]
Centralization
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]
Centralization
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]
Centralization
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]