Review of Spark's trust model

Privacy, control, and safety

When enabled, Spark's Kubernetes knob provider makes targeted wallet freezes live-updatable, selective, and reversible

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. 123

3 sourcesEvidence reviewed through July 14, 2026

What the evidence shows

Technical and product details

  1. Documented behavior

    Operator startup creates the Kubernetes knob provider only when knob configuration is enabled. That provider watches its ConfigMap and updates internal knob values in real time. 13

    Supporting material shown on this page

    live ConfigMap watcherPinned source code · github.com · checked 2026-07-14
    Relevant lines from the pinned source · open raw file
    74// Behavior:
    75// 1. Attempts to get Kubernetes configuration (uses in-cluster config, no kubeconfig fallback)
    76// 2. Creates a Kubernetes clientset for API communication
    77// 3. Sets up a ConfigMap informer with custom ListerWatcher to avoid LIST permission requirement
    78// 4. Configures event handlers for ConfigMap add/update events
    79// 5. Starts the informer goroutine and waits for initial cache sync
    80//
    conditional Operator initializationPinned source code · github.com · checked 2026-07-14
    Relevant lines from the pinned source · open raw file
    445	var valuesProvider knobs.KnobsValuesProvider
    446	if config.Knobs.IsEnabled() {
    447		if provider, err := knobs.NewKnobsK8ValuesProvider(errCtx, config.Knobs.Namespace); err != nil {
    448			// Knobs has failed to fetch the config, so the controllers will rely on the default values.
    449			logger.Error("Failed to create K8 knobs", zap.Error(err))
  2. Documented behavior

    The integration test freezes Wallet A while its reads still work, leaves Wallet B unaffected, then restores Wallet A by clearing the value. 2

    Supporting material shown on this page

    targeting and reversal testPinned source code · github.com · checked 2026-07-14
    Relevant lines from the pinned source · open raw file
    24//   - Clearing the knob restores walletA's ability to mutate state.
    25//
    26// This test requires the minikube environment (it talks to a real knob
    27// ConfigMap and live SOs). It is skipped automatically when the knob
    28// controller is unavailable.
    29func TestWalletKillSwitch_BlocksMutationsAllowsReads(t *testing.T) {
    30	kc, err := sparktesting.NewKnobController(t)

Interpretation

Why this matters for Spark's trust model

An operator can quietly intervene against one wallet, leave everyone else operating normally, and later reverse the intervention through operational configuration without an on-chain record. 123

This section states the trust-model consequence of the cited evidence. Conditional or inferred claims remain bounded by the next section.

Scope control

What this does not establish

  • This proves the implementation and its integration-test behavior, not that production Operators enable the Kubernetes provider, who holds production RBAC, or whether Lightspark can modify Breez's or Flashnet's configuration. 123

Sources and excerpts

Primary sources

The relevant details and available source-code excerpts appear alongside the claims above. This list preserves the complete original-source trail for independent verification.

1

live ConfigMap watcher

Pinned source code · github.com · Pinned or archival · checked 2026-07-14

Open original source
2

targeting and reversal test

Pinned source code · github.com · Pinned or archival · checked 2026-07-14

Open original source
3

conditional Operator initialization

Pinned source code · github.com · Pinned or archival · checked 2026-07-14

Open original source

How sources, absence findings, and limitations were evaluated