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.