> For the complete documentation index, see [llms.txt](https://derec-alliance.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://derec-alliance.gitbook.io/docs/concepts/failure-modes.md). # Failure Modes The **DeRec** protocol defines clear threshold-based guarantees. However, real-world systems encounter operational failures. This page describes common operational failure modes and their impact on recovery. This section is conceptual. Normative behavior is defined in the Protocol Specification. ## Helper Unavailability One or more *Helpers* may be offline, unreachable, or non-responsive during recovery. Impact: * Recovery succeeds if the number of reachable Helpers ≥ `t`. * Recovery fails if reachable Helpers < `t`. This is an availability failure, not a security failure. The system tolerates up to `n - t` unavailable Helpers. ## Helper Data Loss A Helper may lose its stored share for a specific version due to storage corruption, operational error, or misconfiguration. Impact: * If enough other valid shares exist (≥ `t`), recovery succeeds. * If total valid shares across all Helpers drop below `t`, recovery becomes permanently impossible. Mitigation: * Choose `n` and `t` with redundancy margin. * Implement verification flows. ## Share Corruption A *Helper* may return an invalid or corrupted share. Impact: * Reconstruction fails if invalid shares reduce the number of usable shares below `t`. * Reconstruction succeeds if at least `t` valid shares are obtained. The protocol’s validation rules and cryptographic checks detect invalid shares. Corrupted shares do not compromise security but may reduce availability. ## Threshold Misconfiguration Improper selection of `n` and `t` weakens either availability or security. Examples: * `t` too low → easier collusion * `t` too high → fragile recovery This is an operational risk rather than a protocol flaw. ## Collusion at or above Threshold If `t` or more *Helpers* collude and combine their shares independently of the *Owner*, reconstruction of the *Secret* becomes possible. Impact: * The *Secret* can be reconstructed directly from the colluding shares. Security therefore relies on *Helper* independence. ## Compromised Owner or Replica During Recovery If any device under the Owner identity (the *Owner* or any paired *Replica*) is compromised during recovery: * The reconstructed *Secret* may be exposed. The protocol does not separate Replicas from the Owner cryptographically and does not protect against a malicious or fully compromised device under the Owner identity. ## Compromised Owner or Replica Before Protection If any device under the Owner identity is compromised before share generation: * The *Secret* may already be exposed. This scenario falls outside the protocol's threat model. ## Network Failure Network disruption during recovery may prevent communication with enough *Helpers*. Impact: * Recovery temporarily fails if reachable *Helpers* < `t`. This does not weaken security guarantees and recovery may succeed once connectivity is restored. ## Protocol Version Mismatch *Owner* and *Helper* implementations may run incompatible protocol versions. Impact: * Pairing may fail. * Protocol messages may be rejected due to validation errors. * Recovery may be impossible between incompatible implementations. Proper version negotiation and compatibility management are required. ## Helper Refusal to Participate A *Helper* may refuse to respond to recovery requests even if it still holds a share. Impact: * Operationally equivalent to *Helper* unavailability. * Recovery succeeds only if enough other Helpers respond to satisfy the threshold. ## Helper Set Change Without Reconfiguration Helpers are removed or replaced without redistributing shares: Impact: * Some shares may become inaccessible. * The effective number of available *Helpers* may decrease. If the effective `n` becomes less than `t`, recovery becomes permanently impossible.\ Proper Helper set changes require redistributing shares and typically creating a new secret version. ## Replica Synchronization Failures Replicas extend the Owner identity across multiple devices via the Secret synchronization mechanism. The following failures are specific to that mechanism. ### Stale Replica A Replica device may hold a Secret version older than the current one — for example, if the device was offline when newer versions were published, or if it was paired before the most recent change but has not yet received the sync. Impact: * Reading the user-facing data from the stale Secret yields outdated information. * Driving recovery against Helpers using snapshotted addressing may fail or return shares for an older version if the Helper roster has been rotated since the snapshot was taken. The Replica catches up on the next Secret sync round. ### Concurrent Writes from Different Replicas Two Replicas may independently produce the same `version` of the Secret before either has seen the other's write — for example, due to network partitions or offline operation. Impact: * The Helper-side state holds both writes side-by-side, distinguished by `replica_id`. * The conflict surfaces via Discovery (or via `owner_replica_id` on a subsequent sync between the Replicas). * Application policy decides the winner; the protocol does not. See [Conflict resolution](/docs/concepts/replicas/conflict-resolution.md) for the detection surfaces and the resolution flow. ### Loss of a Replica Device A Replica device may be lost, destroyed, or otherwise permanently unavailable. Impact: * Other devices under the Owner identity continue to operate normally — the Secret is held in full by every remaining Replica. * The lost device's local Secret cache is unrecoverable but does not need to be: the same data lives on every other device under the identity. * If the application wants the lost device to stop receiving syncs, it must explicitly unpair the device from the rest of the group. ## Process Restart During In-Flight Flows Every protocol flow produces short-lived in-flight state for outstanding requests — verification challenges awaiting their responses, unpair acknowledgements still pending, recovery accumulators tracking how many shares have arrived, share-distribution rounds tracking which Helpers have confirmed. The orchestrator does not hold this state in memory; it persists all of it through the `DeRecStateStore` the application supplies. Whether an in-flight flow survives a process restart therefore depends on the state store backend: * **Durable backend (SQLite, Postgres, Redis, …)** — the in-flight state outlives the restart. When the process resumes, inbound responses still bind to their originating requests and the flow continues where it left off. This is what lets the orchestrator run in stateless or load-balanced deployments where any instance may handle any message. * **In-memory backend** — the state is lost on restart, exactly as an in-memory-only deployment always behaved. Inbound responses then arrive with no in-flight entry to bind to, and the protocol safely drops them as nothing actionable; the affected flows must be re-initiated by the application after the process resumes. Impact: * With a durable state store, verification challenges, unpair acknowledgements, and recovery sessions in flight at restart resume automatically; with an in-memory state store they must be re-initiated by the application after the process resumes. * Replay safety does not depend on the restart. A response binds only to a still-outstanding request, and the orchestrator removes that request's state the moment the response is accepted — so a replayed or late-delivered copy finds nothing to bind to, whether or not a restart occurred. * In the in-memory case the cost is availability of the specific in-flight flow, not security. See [Implementing a persistent store](/docs/sdk/implementing-a-persistent-store.md) for the `DeRecStateStore` contract and the trade-off between an in-memory and a durable backend.