08 State Machine Design

08 — State Machine Design

Content type: system design, pre-implementation.

8.1 Full state diagram

stateDiagram-v2
    [*] --> ACTIVE: commitment signed
    ACTIVE --> ACTIVE: proof_of_life received
    ACTIVE --> EXTENDED: extension_request (deadline moved forward)
    EXTENDED --> ACTIVE: normal cycle resumes
    ACTIVE --> FULFILLED: fulfillment_declaration received
    EXTENDED --> FULFILLED: fulfillment_declaration received
    ACTIVE --> TRIGGERED: switch_deadline passed, no signal
    EXTENDED --> TRIGGERED: extended deadline passed, no signal
    TRIGGERED --> RELEASED: k-of-n reconstruction complete
    FULFILLED --> [*]
    RELEASED --> [*]

Loading

8.2 Why this differs from DLP's original state machine

DLP's dead man's switch triggers on the holder's death or incapacitation — a state that, once true, does not become false again. VCR's trigger condition (publication silence) is fundamentally reversible: a researcher can resume normal activity at any point before the deadline. This is why EXTENDED is a first-class, publicly logged state rather than a private reset — the system needs to visibly distinguish "still actively engaged, just slower than expected" from "gone silent."

8.3 Guard conditions

Transition	Guard condition
ACTIVE → EXTENDED	Valid signature, extension count < max_extensions (proposed default: no hard cap, but each extension is publicly logged with a timestamp, making an unreasonable pattern visible rather than blocked outright)
ACTIVE/EXTENDED → TRIGGERED	current_time > switch_deadline AND no valid signal received in interim
TRIGGERED → RELEASED	At least k of n registry nodes have independently confirmed trigger conditions and contributed shares

8.4 Design tension: should extensions be capped?

Documented here as an open design question rather than resolved unilaterally.

Argument for no cap: Legitimate research timelines are unpredictable — IRB delays, co-author availability, data cleanup. Capping extensions punishes exactly the honest researchers the system is meant to support.

Argument for a cap (or escalating friction): An uncapped extension mechanism could be used to indefinitely defer with plausible deniability, functionally recreating the silence problem the system was built to solve, just with more paperwork.

Proposed middle ground, not yet validated: No hard cap, but each extension beyond a small number (e.g., 3) requires a brief public justification string attached to the signed request. This keeps the decision with the researcher while making a pattern of indefinite deferral visible to anyone reading the public commitment log — social/reputational pressure rather than a hard technical block. This should be treated as a hypothesis to test in the minimum viable test (Page 18), not a final answer.

8.5 Failure modes to design against

• Network partition during trigger evaluation — a registry node offline near the deadline should not be able to single-handedly force or block a trigger; this is precisely what the k-of-n threshold is for, but the evaluation of "has the deadline passed" also needs a tolerant consensus mechanism among nodes, not just the secret reconstruction step. Flagged as unresolved in Page 05.
• Clock skew between researcher client and registry nodes — deadlines should be defined and compared using a source of time agreed upon by all registry nodes (e.g., median of NTP-synced node clocks), not the researcher's local clock.