12 March 2026
What belongs in a signing log (and what never should)
Columns that help future-you reconstruct a transfer—without writing anything an attacker could use.
A useful signing log answers a narrow question: what did this device authorize, under which policy, and how did we verify the destination? It is not a diary of balances and not a backup of secrets.
Fields that earn their keep
- Date and local time of the signature, not the on-chain confirmation
- Device role (spend, vault, travel) rather than a marketing nickname alone
- Destination check method (QR compare, printed address, multisig co-signer call)
- Amount band instead of exact satoshis if you worry about desk photographs
- Policy reference such as “monthly rent rule” or “cold rotation checklist v3”
Fields that invite trouble
Never store seed words, BIP39 indexes mapped to plain language, or raw private keys in the same notebook. Avoid pasting full xpubs on the same page as physical addresses if that notebook travels. Serial numbers can live in a separate sealed card.
Paper versus offline files
Paper survives firmware chaos and does not auto-sync. Offline files print cleanly and search well. Many clients keep paper as the canonical log and a read-only offline duplicate for travel. During our organization sessions we pick one canonical copy so edits do not fork.
If you are rebuilding from scraps, bring everything messy—we would rather sort chaos once than invent a schema that ignores how you actually sign.