Blind Vault and MemChain Crash-Recovery Boundaries

AeroNyxJune 17, 20262 min read509 views

What Blind Vault and MemChain can recover after process interruption, what tests cover, and why power-loss durability, key recovery, and fleet deployment remain separate claims.

<!-- docs-node-evidence-2026-08-31:start --> <!-- [DOCS-NODE-EVIDENCE 2026-08-31 by Codex] -->

Blind Vault and MemChain crash-recovery boundary

Blind Vault and MemChain are separate stores with different recovery semantics.

Source implemented

  • Blind Vault uses bounded SQLite WAL transactions for immutable ciphertext records. A committed retry can be read after process restart; the node still does not obtain the content key.
  • MemChain's append-only file scanner validates framing and semantic links. On open it may truncate only an incomplete physical tail, then synchronize that repair. A complete corrupt record fails closed and is retained for investigation.
  • When the optional cognitive router is enabled, a stale processing claim can return to pending after its lease timeout. This does not resume an external model call exactly where it stopped and does not guarantee that an external provider is never called twice.

Automated tests verified

Five foundational tests passed for Blind Vault immutable retry/pull, issuer restart continuity, AOF torn-tail repair, complete-corruption refusal without truncation, and stale-claim reset. On the repaired commander integration line, six replica-recovery store tests also passed, covering prepared/committed/resolved restart recovery, V1 compatibility, corruption rejection, and conflict or rollback fail-closed behavior. These are automated-test results, not current-fleet crash-drill evidence.

Current fleet verified

The 2026-08-31 public snapshot reported three follower nodes with locally verified commitment history, but no active coordinator, strict checkpoint threshold, or witness-certified tip. No current-fleet Blind Vault crash exercise or MemChain recovery drill from r6 is available yet. Fleet crash recovery therefore remains awaiting verification.

Non-claims

  • SQLite synchronous=NORMAL and an append path that flushes without an fsync do not prove zero data loss during sudden power loss.
  • The legacy MemChain AOF can contain node-readable Fact fields; it must not be described as a ciphertext history. Client-sealed node storage is a separate path.
  • Recovery cannot recreate a lost owner identity or content key, guarantee a complete remote replica, create public-chain consensus, or prove global finality.

Run the aggregate-only AOF verifier before a guarded restart and stop on any complete-record integrity error. Never publish the store, record IDs, hashes, signatures, owner keys, ciphertext, plaintext, or node-local paths.

Related: signed commitment ledger and witness protection · node health and relay-smoke verification.

<!-- docs-node-evidence-2026-08-31:end --> <!-- [DOCS-STALE-TAIL-REMOVED 2026-09-03 by Codex] -->