Domino Compass · deterministic key runtime

·Operations

dStor, Tails, offline workflow.

10dStor cloud keychain

The optional Domino Compass + dStor architecture. dStor stores encrypted operational material — never root custody.

The model

physical root authority ↓ air-gapped signer ↓ signed request ↓ dStor encrypted keychain

dStor stores encrypted operational material. The user retains root authority.

What the cloud keychain may store (encrypted)

  • recipes
  • capability records
  • descriptors
  • watch-only Bitcoin material
  • revocation records
  • recovery packets
  • operational metadata

The cloud keychain must not be portrayed as holding custody of the root secret.

Hard rules

  • Do not store root secret plaintext in dStor.
  • Do not store plaintext nsec in dStor.
  • dStor possession ≠ signing authority.
  • dStor possession ≠ decryption authority. The keychain decryption key must be held only by the user and must not be derivable from any material stored in dStor (including the recipe).
  • Pluronymous possession ≠ recovery authority.

Keychain manifest

The keychain snapshot is content-addressed, manifest-backed, encrypted, and independently verifiable:

keychain_manifest_root, encrypted_payload_refs, public_metadata_envelope, recipient/decryption_policy_commitment, version, previous_snapshot_ref, revocation_state_ref, capability_set_root, descriptor_set_root, receipt_refs, HedlBit_persistence_payment_ref, expiry_or_renewal_terms, integrity_checksum

The manifest root is signed by the air-gapped authority (authenticity, not just integrity). Encryption is deterministic/IV-stable so re-encryption does not change the content address.

Air-gapped request signing

online client prepares request → request transferred to air-gapped signer → signer derives/unlocks nsec or delegated secret → request signed offline → signed request returned online → cloud keychain / service peer verifies signature → authorized action executes

The online machine asks. The air-gapped signer authorizes. The cloud keychain obeys only signed instructions.

Replay protection: every signed mutation request must carry a request nonce / idempotency key and a replay window. A captured signed request must not be replayable.

11Tails / air-gapped workflow

The secure dStor keychain workflow is the sealed round trip — both the outgoing encrypted TXXM and the incoming dStor response are sealed inside the same Tails amnesiac environment.

Recommended flow

1. boot trusted Tails environment 2. reconstruct root secret 3. derive required identity 4. create encrypted TXXM request 5. send request to dStor 6. receive dStor response 7. encrypt the response before leaving the same amnesiac environment 8. shut down 9. destroy plaintext session state

Strong mode (MUST-level)

In strong mode, the Tails sealed round trip is the only acceptable way to operate the dStor keychain. The full sequence:

boot Tails → derive / unlock secret material inside Tails → construct TXXM → encrypt TXXM before persistence → deploy encrypted TXXM to dStor → receive dStor response → encrypt / seal incoming dStor response inside the same Tails session → export only encrypted artifacts, receipts, public fingerprints, signed commitments → shutdown Tails → discard live plaintext state

Allowed exports: encrypted TXXM blob, encrypted dStor response packet, content-addressed dStor manifest, signed receipt, public fingerprint, capability public record, revocation public record, watch-only descriptor, verification checksum, audit hash.

Disallowed unless explicitly intended: plaintext TXXM, plaintext nsec, plaintext recipe transcript, plaintext recovery packet, plaintext delegated secret, plaintext dStor response, unencrypted keychain snapshot.

Degradation conditions — each independently breaks the model

  • Request generation in Tails but the dStor response received/processed in a normal persistent OS → degrades.
  • Signing in Tails but incoming response material stored plaintext outside Tails → degrades.
  • Encrypted upload in Tails but receipts, capability state, recovery material, or response packets leave unencrypted → degrades.
  • Response capture or sealing happens outside Tails → degrades.
Warning: splitting request creation and response encryption across separate environments weakens the intended security properties. A degraded profile is still usable for low-sensitivity operations, but it is not the sealed round trip and must be labeled as such.

Amnesiac vs. air-gapped — do not conflate

  • The air-gapped signer is offline and never connects.
  • The Tails round-trip is amnesiac and network-capable.

The sealed round-trip derives the root inside Tails and connects to dStor from that same environment — the root is handled in a networked environment during the round-trip. For the highest-sensitivity operations, the air-gapped signer signs the request offline; the Tails session only handles the encrypted artifacts and the network round-trip, never the root in a form that can be exfiltrated.

25Offline mode

The long-term runtime is installable or downloadable for offline use.

Potential surfaces

  • static offline web app
  • Tails-compatible bundle
  • CLI
  • native application
  • deterministic reference runtime

The public website explains this separation: documentation and simulation are distinct from a hardened production runtime. If production secret generation is eventually supported in-browser, it is a separate hardened application surface with explicit security assumptions. The marketing site must not silently become a wallet.

30QR representation

Public and encrypted artifacts can be encoded as QR where appropriate.

Examples

  • public fingerprints
  • capability records
  • encrypted recovery packets
  • descriptor material
  • recipe identifiers
Do not encourage encoding raw root secrets into casually scannable QR codes.

26Explicit non-goals

What the initial website does not do.

  • act as a custodial wallet
  • store user root secrets
  • require user accounts
  • require cloud identity
  • silently upload entropy
  • generate production secrets without explicit mode separation
  • imply deterministic generation eliminates operational security risks
  • invent proprietary Bitcoin transaction formats
  • replace descriptors, BIP32, PSBT, or Bitcoin wallet standards where those standards already apply

27Analytics & privacy

Privacy-preserving analytics or none. Never log secrets.

This site defaults toward privacy-preserving analytics or no analytics. It never logs:

  • secrets
  • entropy inputs
  • derived private keys
  • recovery material
  • recipe contents containing sensitive state

Telemetry boundaries are documented. All cryptography runs locally in your browser — nothing is sent anywhere.