You should not need to expose or repeatedly use your root key. Capabilities express operational access as scoped, time-bounded, revocable delegation statements.
| Field | Meaning |
|---|---|
capability_id | content hash of the record |
issuer_public_key | who issued (the authority) |
derived_public_key | the key being delegated |
purpose | what it is for |
scope | what it may do |
valid_from / valid_until | time bounds |
block_context_limits | Bitcoin-native bounds |
service_namespace | which service honors it |
revocation_lane | which revocation path applies |
recipe_id | which recipe produced it |
entropy_card_fingerprint | the commitment |
signature | bare secp256k1 by the issuer |
A signed capability is a claim, not a grant. Access is granted by the service's admission decision (its accepted-key set). The lifecycle:
A capability that is signed but never admitted is not valid.
Cryptographic authorization without forcing the user to manually administer raw cryptographic keys.
Revocation is not deletion of a copied secret. Revocation is refusal to honor the secret after a revocation condition.
When Capability B is compromised, you revoke B — without requiring Root compromise. You preserve the root and all unrelated derivations.
Capability D and Application E are unaffected. The root is untouched.
Revocation is honored only at acceptance boundaries that check revocation state. It is not honored by:
revocation_lane must be bound to a distinct revocation authority at issuance — a key that is not the capability issuer and that the issuer does not control. A capability whose revocation lane is self-declared must be rejected.You lose the laptop, phone, application database, and operational keys — but you retain the physical entropy material and the recipe. Recovery reconstructs authority.
Recovery reconstructs the root and the runtimes — the authority. It does not necessarily recover every historical operational key. Where appropriate, operational state may instead be restored from encrypted backup material (e.g. the dStor keychain).
Generate a printable recovery checklist describing what physical material must be retained, which recipe identifier applies, which derivation profile/version applies, and what public fingerprints should be expected. It does not include secrets.
Fingerprints are verification handles. They prove regeneration succeeded without exposing the secret.
| Fingerprint | Formula | Proves | Does not reveal |
|---|---|---|---|
| Root commitment | SHA-256(transcript || "dc-commit-v1") | You hold the same physical card | The root secret |
| Identity fingerprint | SHA-256(id_pubkey || recipe_id || "identity") | Regeneration of the identity key | The identity private key |
| Bitcoin fingerprint | SHA-256(btc_pubkey || recipe_id || "bitcoin") | Regeneration of the Bitcoin key | The Bitcoin private key |
| Capability fingerprint | content hash of the capability record | The capability is intact and signed | Any private material |
| Descriptor fingerprint | hash of the descriptor | The descriptor is intact | Signing authority |
nsec itself never needs to be printed, cloud-stored, screenshotted, or placed in a persistent password manager.Paste a public fingerprint or capability record and verify format validity, version, checksum, public identity, scope, expiration, and derivation profile identifier. The verifier requires no private material.
Bitcoin public material can be separated from signing material. Watch-only systems track funds without possessing signing authority.
Watch-only wallets can track funds without possessing signing authority. The signing keys stay under the user's physical control; only public material (xpub, descriptors) is shared with the watch-only surface.
A Nostr-oriented example: the nsec can be regenerated from the deterministic root rather than permanently stored online.
The nsec is a downstream artifact of the identity lane. It can be regenerated from the deterministic root whenever needed — it does not need to be permanently stored online.
m/220'/0'/0', unregistered private placeholder). It is not a standard BIP path — it is Domino-Compass-native.No "military-grade security," no "unhackable." Here are the assumptions and failure modes, honestly stated.
For each threat: what is exposed, what remains safe, what must be rotated, what must be reconstructed.
| Threat | What is exposed | What remains safe | What you must rotate / reconstruct |
|---|---|---|---|
| Compromised browser | Anything rendered in it | Root (if never entered online) | Rotate operational keys; reconstruct from card offline |
| Compromised OS | Local plaintext state | Root (if air-gapped) | Rotate operational keys; rebuild environment |
| Compromised cloud storage | Encrypted operational material | Root (never stored there); decryption key (user-only) | Nothing if encryption holds; rotate if decryption key leaked |
| Leaked recipe | Purpose, scope, lane context, commitment | Root secret (commitment is non-revealing) | Reconstruct a new recipe; re-derive lanes |
| Leaked capability | That capability's scope | Root, other capabilities | Revoke the capability; issue a replacement |
| Stolen entropy cards | The root | Nothing — this is the root | Reconstruct a new physical card; migrate everything |
| Partial physical entropy disclosure | Some of the transcript | Remaining entropy (search space shrinks) | Reconstruct a new card if disclosure is material |
| Poor entropy construction | Reduced search space | — | Reconstruct with a proper ceremony |
| Compromised operational key | That key's scope | Root, other lanes | Revoke; rotate the operational key |
| Compromised root key | Everything | Nothing | Reconstruct a new physical card; migrate everything |
| Metadata leakage | Who/what/when of operations | Key material | Reduce metadata; rotate affected capabilities |
| Deterministic encoding ambiguity | Potential wrong-key derivation | — | Verify fingerprints; use canonical encoding |
| Implementation bugs | Depends on the bug | — | Use the audited reference; verify against test vectors |
Domino Compass stores the secret in the derivation path, not the start seed. The path is m/i1'/…/i9', where each index is a hardened child number derived from the 256-bit secret S.