PaidK config is advertised in deployment config but ignored at runtime

[cryptskii]

Deployment config advertises PaidK tuning that the runtime never reads. The documented values happen to match the hard-coded ones today, so the drift is currently invisible — changing either config value would silently have no effect.

Advertised

dsm_storage_node/config/production.toml:35

[paidk]
flat_rate = 1000     # Minimum payment amount per operator
k = 3                # Distinct operators required for spend-gate satisfaction

The inline comments describe these as the operative values.

Actual runtime behaviour

dsm_storage_node/src/api/vault/paidk.rs:28

const DEFAULT_K: u32 = 3;
const DEFAULT_FLAT_RATE: i64 = 1000;

Both are used directly at the decision points — count_distinct_paid_operators(pool, &device_id_b32, DEFAULT_FLAT_RATE) and if distinct >= DEFAULT_K as i64 — and in get_status, which reports required_k: DEFAULT_K back to clients.

ServerConfig (dsm_storage_node/src/main.rs:49) has no paidk field:

bind_addr, node_id, concurrency_limit, tls_enabled, tls_cert_path,
tls_key_path, body_limit_bytes, hsts_max_age, database_url, seed_peers

There is no paidk reference anywhere in the config loader, so the [paidk] section is parsed into nothing.

Impact

An operator editing [paidk] k or flat_rate — for a test fleet, a staging tier, or a policy change — gets no error and no effect. The gate keeps using 3 and 1000. get_status continues advertising required_k=3 regardless.

This is low severity today because the values agree, which is exactly what makes it worth fixing before they diverge.

Fix direction

Either load the [paidk] section into ServerConfig and thread it through to the gate, or delete the section from production.toml and document the values as compile-time constants. Silently accepting ignored configuration is the part to eliminate.

Found while diagnosing an HTTP 402 during ADR 0003 hardware validation.