You’re correct about one thing and misunderstanding another. Correct: If a user rotates before a client supports lineage, that client won’t associate the new epoch key with the root identity. Followers there would see it as a separate npub. That’s expected. The part you’re misunderstanding: Cold root identity is optional and backwards compatible. No one rotates until the clients they care about implement lineage. Nothing forces a migration. Nothing breaks for anyone who doesn’t use the feature yet. This is the same adoption pattern as every optional NIP feature. If a client doesn’t support zaps, zaps are invisible. If a client doesn’t support DMs, DMs don’t work. Same here. Rotation is an additive capability. The value doesn’t depend on universal adoption. Just like multisig, hardware wallets, Tor-only nodes, LNURL-auth, and NIP-46. Even if only power users or security focused clients adopt it, it still solves real problems: - key hygiene - blast-radius reduction - eliminating the hot key identity model Practical rollout is simple: 1. Users keep using their current hot nsec. 2. Clients begin adding support for the lineage tag. 3. Once a client supports it, users can optionally switch to an epoch key. 4. The root npub remains the identity anchor. The client maps the root to whichever epoch key is active. This is exactly how PGP subkeys, Monero subkeys, and minisign key hierarchies work. The identity anchor never changes. Only the operational key rotates. Additionally, You don’t need a new root key or any hardware. Your existing nsec becomes the root. Even if it was used hot, it’s fine because the moment you generate the first epoch key, the root goes offline permanently. No one needs to buy anything or start over unless they want to. Rotation simply gives users a safer operational model when they’re ready for it.