spark.exposed

Editorial standard

Methodology

The review separates direct evidence, bounded observations, threat-model assumptions, documented mechanics, and interpretation. Each analysis states both what the cited material establishes and what it does not.

Scope, boundaries, and threat model

What the public record establishes: The reviewed defaults concentrate several hosted and coordination roles at Lightspark; Operators receive substantial wallet and payment data; Operator code contains wallet-specific refusal controls; and none of twelve reviewed consumer-wallet surfaces exposed a complete in-app operatorless exit.

Critical boundary: The record does not show production use of the wallet gate, private compliance wiring, common control of Operator keys, retained historical keys, observed collusion, or a prepared user's inability to exit with complete current recovery material and external fee funds. Integrators can change default service configuration.

Threat-model assumption TM-1: Lightspark–Flashnet coordination is treated as a scenario to test, without assigning a probability, making the two roles one effective quorum under the published threshold. The scenario does not establish that coordination or key sharing has occurred.

Information hierarchy

The homepage presents ten principal claims. Topic pages divide those claims into evidence groups, and the 61 individual records preserve the complete technical and source trail. Direct Spark behavior, conditional attack analysis, consumer-product observations, and adjacent ecosystem context are labeled separately rather than treated as equivalent evidence.

Evidence rules

Source types

Pinned source code, public schemas, official documentation, contracts, regulator records, public transaction data, product observations, public posts, and archived first-party material are labeled separately.

Corrections

Later contradictory evidence narrows or corrects a finding rather than being silently omitted.