They’re hot only because clients force them to be. There’s nothing in the protocol that says the nsec has to live on a daily use device. That’s just UX inertia. The protocol just says: A user has a keypair. Everything else is implementation detail. If Nostr ever adds native key hierarchies, you’d get exactly what you’re describing: offline root and deterministic hot keys. What I’d like to see is epoch rotation on top of that. Treat the nsec as an offline root that never touches a live client, and use it only to deterministically derive the ‘hot’ operational keys you actually use for a given epoch (year, quarter, whatever). Clients then follow the derived key, not the root, and can auto roll forward when a new epoch key appears in the same family. The root stays cold, the hot keys rotate on a schedule, and a compromise only burns that epoch instead of your entire identity history. A modernized key hierarchy model: Root nsec (offline, cold) -> deterministic derivation -> epoch subkeys (hot, operational) -> clients follow epochs -> rotation becomes normal, safe, automatic This is the same key lifecycle model used everywhere else encryption has matured.