KERI and NOSTR
Two Paths to Self-Verifying Identity
Digital identity has always suffered from a foundational flaw: our confidence in “who controls this key” depends on trusted intermediaries, not on cryptographic evidence.
The Key Event Receipt Infrastructure (KERI) project set out to solve that. It replaces certificate authorities and registries with self-certifying identifiers and tamper-evident key event logs.
But what’s fascinating is that Nostr, with only signed events and hierarchical key derivation (BIP-32), can reach many of the same guarantees by very different means.
Let’s unpack the flaws KERI was built to fix, and how a Nostr-based model could solve them with different cryptographic machinery.
First Flaw to Fix: Weak binding between identifiers and keys
In traditional PKI, a certificate authority asserts that an identifier (like example.com) belongs to a certain public key. The binding exists because a trusted third party said so, not because it’s provable.
KERI’s approach:
An identifier is the digest of its own key material — a self-certifying identifier (SCID). No external assertion is needed.
Nostr’s equivalent:
A Nostr npub already serves as a self-certifying identifier: it’s derived from a public key. To go further, a user can publish a root public key (an xpub) inside their kind-0 event, making that xpub the governing identity from which all active keys are deterministically derived.
This simple step formalizes what KERI calls inception: your root key defines your identifier, not a third-party registry.
Second Flaw to Fix: Unverifiable key rotation
When keys change due to compromise, expiration, or policy, most systems can’t prove continuity between the old and new keys. Revocation lists and new certificates express intent, not verifiable linkage.
KERI’s approach:
KERI uses pre-rotation. Controllers pre-commit to the next key by publishing its digest ahead of time. When rotation happens, the previous key’s log entry already references the next, creating an immutable chain.
Nostr’s equivalent:
With BIP-32 hierarchical key derivation, we don’t need pre-rotation.
Each rotation is a deterministic step forward in the derivation path.
A signed event announces the move from child key i to child key i+1, and the newly rotated child key can sign that announcement. Also, the beauty of BIP-32 is that anyone can derive the valid child public keys (child npubs) from the xpub created at the publicly available inception event and prove for themselves that they are related to the root npub.
The result is the same cryptographic continuity: verifiers can reconstruct the entire key lineage from the xpub and verify that each transition was authorized by the prior key.
Third Flaw to Fix: No tamper-evident history of key state
Traditional PKI has no native mechanism to prove which key was valid at any given time. Certificate expiration and revocation signals are operational, not cryptographic.
KERI’s approach:
The Key Event Log (KEL): a signed, append-only, hash-chained record of every key event: inception, rotation, and interaction.
Nostr’s equivalent:
Each key rotation can be published as a signed Nostr event referencing the previous one. Together, these events form a hash-chained log distributed across relays.
A verifier can walk the chain backward from the current event to genesis, confirming every link and signature.
Nostr becomes, effectively, a decentralized KEL carried by relays instead of a dedicated KERI infrastructure.
Fourth Flaw to Fix: Reliance on trusted infrastructure
PKI depends on certificate authorities, revocation servers, and DNS registries which can be single points of failure and control.
KERI’s approach:
End-verifiability: anyone can verify the cryptographic truth of an identifier’s state without querying an authority. Witnesses and receipts provide distributed confirmation.
Nostr’s equivalent:
Nostr relays are untrusted but redundant witnesses. Every event is signed and broadcast to many independent relays. Verification doesn’t depend on which relay delivers it, only on the signature chain and hash links.
This yields the same property: ambient verifiability. Anyone, anywhere, can check the authenticity of data without contacting a specific registry.
Fifth Flaw to Fix: Undetectable duplicity
If two conflicting key states exist, traditional systems offer no built-in way to expose the conflict.
KERI’s approach:
Duplicity-evident logs: conflicting events for the same sequence number can be cryptographically compared and proven inconsistent.
Nostr’s equivalent:
Because all key-state events are public, any double-signing or divergent chain is visible. Multiple relays can act as watchers, and other witnesses can publish an event that attests when they first saw each event. If two conflicting updates exist, events from different witnesses can demonstrate which appeared first, a distributed equivalent to KERI’s “first-seen” policy.
Putting it all together
Both KERI and Nostr aim to make control over identifiers cryptographically verifiable rather than institutionally trusted, but they take very different routes to get there.
In KERI, every identity is established through a self-certifying identifier. The identifier itself is derived from the cryptographic keys that control it. Nostr achieves the same outcome more simply: every npub is inherently self-certifying, and when tied to a published root public key (xpub), it serves as the foundation from which all derived keys are deterministically generated.
Where KERI maintains a formal Key Event Log (KEL), a structured, append-only record of key events. Nostr accomplishes a similar function through a sequence of signed key-update events. Each update references the previous one, forming a verifiable chain of custody distributed across relays. In both systems, a verifier can reconstruct the entire history of key control, confirming continuity from inception to the current state.
KERI’s concept of pre-rotation, where future keys are pre-committed to ensure seamless and provable rotations, finds a practical analogue in Nostr’s use of hierarchical key derivation (BIP-32). Instead of pre-publishing future keys, Nostr identities derive each new key from the same master key in a deterministic sequence. The previous key signs the rotation event, ensuring the same cryptographic continuity without the need for pre-commitment.
Similarly, with KERI’s witnesses and receipts, where independent entities that attest to key events and their order have a natural parallel in Nostr’s relays and watchers. Each relay independently stores and timestamps signed events, providing redundant, cross-verifiable records of when a key update occurred. This makes authenticity “ambient” where anyone, anywhere, can verify the cryptographic truth without relying on a central authority or registry.
Finally, both architectures address the issue of duplicity, the existence conflicting claims over key state. KERI explicitly defines duplicity-evident logs, allowing inconsistencies to be proven. In Nostr, any attempt at double-signing or publishing divergent chains would immediately surface in the public relay ecosystem. Multiple relays can serve as independent witnesses, issuing receipts that expose which event appeared first.
In essence, KERI provides a formalized, specification-driven trust framework, while Nostr achieves many of the same assurance properties through emergent, minimal design. Both converge on the same foundational principle: that trust on the internet should be derived from what can be verified, not what must be believed.
The future of verifiable identity
What both KERI and Nostr ultimately reveal is that the evolution of digital identity is shifting from trusting institutions to trusting mathematics. Instead of delegating authority to certificate authorities, registries, or platforms, we’re learning how to embed verifiability directly into protocols themselves. KERI demonstrates that this can be done through formal governance and explicit event logs; Nostr shows that it can also emerge from minimalist primitives using just signatures, derivation paths, and public propagation. Together, they point to a future where identity is not something that must be issued or approved, but something that can be proven — cryptographically, transparently, and independently of intermediaries. In that world, the question “Who can we trust?” quietly gives way to a better one: “What can we verify?”
Why this all matters
As we move toward decentralized communication, credentials, and signing protocols, both KERI and Nostr illuminate the same design philosophy:
Trust emerges from verifiability, not authority.
KERI formalizes that principle through specification and governance.
Nostr demonstrates it through minimalism and composability.
Different toolkits yet same cryptographic truth:
Identity should be something you can verify, not something you have to trust.
Author’s Note
In addition to reviewing the KERI specification, I’ve been actively experimenting with Nostr as a lightweight environment for exploring similar trust mechanisms. Initial prototype code based on BIP-32 hierarchical key derivation has been developed to test how key-state continuity, rotation, and verification could function natively within Nostr’s event model without introducing external dependencies or registries.
This post emerged from that experimentation. Its purpose is not to critique KERI, but to use KERI’s design principles as a reference framework for exploring new requirements and design patterns for digital trust infrastructure. By comparing a formalized specification (KERI) with an emergent protocol (Nostr), the goal is to illuminate how cryptographic verifiability can manifest across very different architectural layers and to advance the broader conversation about what a truly self-verifying Internet might look like
Quoting Above: “KERI’s concept of pre-rotation, where future keys are pre-committed to ensure seamless and provable rotations, finds a practical analogue in Nostr’s use of hierarchical key derivation (BIP-32). Instead of pre-publishing future keys, Nostr identities derive each new key from the same master key in a deterministic sequence. The previous key signs the rotation event, ensuring the same cryptographic continuity without the need for pre-commitment.”
NOSTR has a single point of failure in its master key. So, compared to KERI, NOSTR security is very weak. The whole purpose of pre-commitment is so that a different key infrastructure can be used to differentially protect the pre-rotated keys as opposed to the current signing keys. This protects from the common mode failure of the two infrastructures. Likewise, this pre-committment gives KERI fault tolerance from a surprise quantum attack. NOSTR does not.
NOSTR has no concept of delegated AIDs, so one can’t horizontally scale signing infrastructure, and one can’t build organizational identity authority trees where different key infrastructure is protected by that hierarchy as a threshold structure. KERI, by design, is highly fault-tolerant. NOSTR, in comparison, is not very. One can use a BIP-32 derivation algorithm to derive one's key sequence in KERI. However, forcing everyone to do that means there is no possibility of higher levels of security. One can use KERI in a similarly simplistic way to NOSTR, and then upgrade to higher security or coexist in an ecosystem where high-value targets use higher security and low-value targets use simpler but lower security in their key management. KERI is designed to be the simplest and most universal approach.
KERI supports software thresholded multisig, which means one can have multiple master keys.
With Nostr, if one uses a secure enclave or HS that does not allow export of the master key, then one failure mode is the loss of that hardware. So not tolerant of that fault. If one has an exportable master key, it must be protected well against theft. However, one might still lose it. To account for this, one would need a key recovery mechanism, such as sharding social recovery. That is no longer simple. With KERI, one uses multisig to be tolerant of both faults (theft and loss) of a single master key, so in that regard, KERI is actually simpler than NOSTR.
KERI's witness and watcher network is designed to account for faults deriving from the different incentive and governance structures of controllers versus validators. A relay network doesn't understand those faults and so does not protect from them. For example, in addition to the high availability of key state, witnesses in KERI can also serve as a detection mechanism to detect compromise of the key signing infrastructure, allowing the controller to perform a rotation and recover from the compromise. A witness pool can also be configured with an additional authentication factor or factors, thereby creating a threshold structure for enhanced security.
Unless and until one does the hard work of explicating all the likely faults in a key management system, one will not achieve what in KERI we call a minimally sufficient system. It will be vulnerable to known likely exploits. To quote Einstein (purported), "Everything Should Be Made as Simple as Possible, But Not Simpler". Many key management schemes fall into the trap of being overly simplistic at the cost of insufficient security.
Compared to the PKI protocol stack PKI/CA/OAuth/OIDC, KERI is extremely simple. KERI is designed to be a valid replacement for all of PKI/CA/OAuth/OIDC infrastructure. So it has to survive all the faults to which PKI is susceptible and vulnerable.
Simplicity vs security is not a good trade. Practical but insecure, is well, impractical.
I like this quote. "Virtuous simplification’s evil twin is vicious simplification". https://graeme-47328.medium.com/simplicity-34dec5e201ac
The set of applications where NOSTR is sufficiently secure is actually quite small. So advocating for it, without qualifying its metes and bound of insufficient security, seems somewhat irresponsible to me.
@Tim, one of the things that gets lost in discussions about KERI, particularly when comparing it to other key management schemes, is the sine qua non of KERI: perpetual control over an identifier.
The value of an identifier is the degree to which it represents the reputation of its controller regarding its behavior. Reputation accrues over time, so identifiers with lifespans shorter than "in perpetuity" can never attain the highest value reputation.
Any attack vector or weakness in the control authority becomes exploitable given enough time. Therefore, perpetual control authority requires not merely resilience against faults, but also recoverability from faults. Fault recovery is dependent on fault detection. Fault detection mechanisms may seem like complications until one realizes that they are essential to perpetual control. So it's not a case of "if" but "how" one provides fault detection.
What happens when an identifier is based on infrastructure that has no viable fault detection mechanism? It must be abandoned when its control mechanism (i.e., signing infrastructure, private key or keys used for signing, or authorization mechanism used to approve items to be signed) is compromised. Abandonment of the identifier necessarily abandons any reputation associated with the identifier. So the cost of acquiring the reputation, by which trust is imbued in that identifier, must be repaid with each abandonment. Many of the readily exploitable vulnerabilities in PKI stem from not repaying the identity assurance (reputation) security deposit associated with the new identifier. This is an expensive consequence of "too simple" identifier system designs that do not support fault-tolerant perpetual control of their identifiers.
Similarly, reputational value, hence trust, is depreciated when not everyone uses the same identifier system. If everyone is using different identifier systems with varying security models and trust bases, as well as different protocols for interacting with, appraising, and verifying those trust bases, then the value of the reputation associated with identifiers will be severely limited. This is why KERI is designed to replace PKI/CA/OAuth completely. Because only a universal identity system has the potential to maximize reputation and, consequently, trust.
So ultimately, we should either fix PKI universally or universally replace it. Any other approach is ultimately defeatist. So IMHO there are only two choices: continue using PKI with all its flaws, or replace it with KERI. There is no other alternative to KERI that comes close to satisfying the needs of universality with perpetual control authority. If KERI is not mature enough, then put resources into maturing it, instead of proposing alternatives that are ultimately defeatist.
Anything less than perpetual control authority is inadequate to satisfy the demands of reputation and trust. Therefore, such a system suffers from vicious simplicity.