Appreciate the response. A few clarifications because I think we’re talking about different layers. 1. No protocol changes A lineage event is just a normal NIP 01 note with the current pubkey as the author. The root and sig tags are client semantics, not protocol extensions. The protocol doesn’t need to understand them. Relays don’t need to do anything. Clients can ignore them completely and nothing breaks. That’s what I mean by “no protocol changes required”. 2. Deterministic != HD chain. I’m not proposing BIP32 style unhardened chains or blinded address links. The derivation in the prototype uses HKDF(root_seed, “epoch:label”). No parent–child leakage. No public derivation path. No hardened/unhardened distinction. It’s just a reproducible function that stays entirely offline. The root never signs online. The root never publishes anything. Clients never derive keys. Only the user’s offline environment does. 3. This doesn’t try to solve the “lost root key” problem. Nothing does except backups or threshold schemes. The model is about containment, not availability. If the epoch key leaks, you lose that epoch. If the root leaks, you lose the lineage. Same as Bitcoin. Same as PGP. Different threat model than NIP-26. 4. NIP 26 solves a different class of problem. NIP 26 is about delegation. Giving another key permission to sign for you. It requires clients and relays to understand delegation. And, as you mentioned, it saw limited adoption because of complexity. Cold root identity isn’t delegation. It’s ancestry. Clients only need to verify: sig_root(epoch_pubkey) Everything else stays NIP-01. 5. Adoption burden on clients is intentionally tiny. A client only needs to add: - detect lineage tag - verify sig_root(epoch_pubkey) - follow the newer key If they don’t implement it, nothing breaks. If they do, users get survivable identity. It's completely optional for the clients. 6. Advanced users always adopt first. Just like PGP, Bitcoin cold wallets, miniscript, Lightning channels, etc. Power users adopt best practices early. Clients catch up as patterns stabilize. The purpose of this model is to demonstrate that survivable identity can exist without NIP changes, relay changes, or delegation semantics. Everything else can evolve around it. Happy to collaborate or cross compare with the key migration NIP. We’re all circling the same core problem with different threat models.