Vault lifecycle
Model application-owned interfaces from Ownfold's explicit browser states for onboarding, locking, recovery, device pairing, and root-key rotation.
Browser vault states
| State | Meaning | Allowed next actions |
|---|---|---|
not-created |
No remote vault exists. | Create locally. |
recovery-setup-required |
Vault exists; recovery is not verified. | Create and download a kit. |
recovery-verification-required |
A pending kit must be imported locally. | Verify exact file and secret. |
ready-unlocked |
This device can use the root key. | Encrypt, decrypt, lock, manage devices, rotate. |
ready-locked |
Device material exists but active key access is locked. | Unlock or restore. |
unavailable-on-device |
Remote vault exists without local device access. | Restore a Recovery Kit or pair. |
error |
Initialization or persisted state failed validation. | Show typed recovery guidance. |
Onboarding invariant
Strict onboarding does not declare the vault ready until the downloaded Recovery Kit has been re-imported and decrypted locally. Applications may opt into a weaker policy, but the default does not allow users to skip verification.
Device and rotation sub-states
Pairing and root rotation have independent persisted state so refreshes and process interruption do not turn completion into an ambiguous action. All updates use revisions. A stale browser must reload instead of overwriting a newer device, Recovery Kit, or rotation state.
UI mapping
Applications render directly from these states through
useVaultStatus, useRecoveryKit, useVaultDevices, useVaultPairing, and useKeyRotation. Avoid
inventing parallel boolean flags such as hasVault, hasKit, and isLocked; they permit impossible
combinations that the SDK state machine already excludes.