Free 30-min Web3 Consultation
Book Consultation
Smart Contract Security Audits
View Audit Services
Custom DeFi Protocol Development
Explore DeFi
Full-Stack Web3 dApp Development
View App Services
Free 30-min Web3 Consultation
Book Consultation
Smart Contract Security Audits
View Audit Services
Custom DeFi Protocol Development
Explore DeFi
Full-Stack Web3 dApp Development
View App Services
Free 30-min Web3 Consultation
Book Consultation
Smart Contract Security Audits
View Audit Services
Custom DeFi Protocol Development
Explore DeFi
Full-Stack Web3 dApp Development
View App Services
Free 30-min Web3 Consultation
Book Consultation
Smart Contract Security Audits
View Audit Services
Custom DeFi Protocol Development
Explore DeFi
Full-Stack Web3 dApp Development
View App Services
LABS
Glossary

Key Event Receipt Infrastructure (KERI)

KERI is a cryptographic framework for creating self-certifying identifiers and managing their associated keys through a verifiable log of key rotation events, independent of a ledger.
Chainscore © 2026
definition
DECENTRALIZED IDENTIFIER PROTOCOL

What is Key Event Receipt Infrastructure (KERI)?

A cryptographic framework for creating and managing self-sovereign digital identifiers without relying on centralized authorities or distributed ledgers.

Key Event Receipt Infrastructure (KERI) is a protocol for establishing and maintaining self-certifying identifiers (SCIDs) and decentralized key management. It enables entities—people, organizations, or devices—to generate their own globally unique identifiers using cryptographic key pairs, where the identifier is a direct cryptographic digest of the public key. The core innovation is its independence from any specific blockchain or consensus mechanism, instead using a witness-based receipting model to provide cryptographic proof of the integrity and sequence of key management events.

The protocol operates through a series of signed Key Event Logs (KELs). A KEL is a tamper-evident record of all key management events for an identifier, such as creation, rotation, or delegation. To establish trust without a central ledger, KERI employs witnesses—trusted entities that observe and cryptographically sign (provide a receipt for) each event in the KEL. This creates a Key Event Receipt Log (KERL), a collection of receipts that allows any verifier to independently audit the entire history and confirm the current valid keys for an identifier, achieving a form of distributed consensus on state.

KERI's architecture provides several key advantages. Its ledger-agnostic design avoids lock-in to any single blockchain platform. It supports cryptographic agility, allowing for the migration to new quantum-resistant algorithms. The protocol also enables privacy-preserving interactions through non-transferable identifiers and selective disclosure. These features make KERI a foundational layer for Decentralized Identity (DID) systems, verifiable credentials, and secure, portable digital relationships across different ecosystems.

A primary use case is implementing the W3C Decentralized Identifiers (DIDs) specification. KERI provides a concrete method for fulfilling the DID Core requirements of persistence, resolvability, and cryptographic verifiability. For example, a KERI-based DID allows a user to rotate their compromised private key by publishing a new key event to their KEL, with witnesses providing receipts. Any verifier can then resolve the DID, audit the KEL and KERL, and cryptographically verify that the new key is authoritative, all without querying a universal ledger.

The development of KERI is closely associated with the Trust over IP (ToIP) Foundation and its Decentralized Key Management (DKMS) specification. It represents a shift from ledger-centric trust models to a cryptographic receipt-based trust model. By separating the mechanism for proving control of an identifier from the mechanism for proving the history of that control, KERI aims to create a more scalable, secure, and interoperable foundation for the future of digital trust on the internet.

how-it-works
MECHANISM

How Does KERI Work?

Key Event Receipt Infrastructure (KERI) is a decentralized key management protocol that establishes self-certifying identifiers without relying on a central ledger or blockchain.

KERI operates through a cryptographically verifiable log of key events that document the complete lifecycle of a decentralized identifier (DID). The core mechanism involves the identifier's controller signing a sequence of events—starting with an inception event that establishes the initial public key—and broadcasting them to a set of chosen witnesses. These witnesses, which can be any reliable entity, provide receipts by countersigning the events, creating a distributed consensus on the identifier's state without a global consensus layer. This process creates a verifiable data structure that anyone can audit.

The protocol's security is anchored in pre-rotation. Before a current key is compromised or needs to be changed, the controller pre-authorizes the next key in a rotation event. This event is signed by the current key and disseminated to witnesses. Because the new key's hash was committed in the previous event, the transition is cryptographically chained and verifiable. This prevents hostile takeovers and ensures cryptographic continuity, meaning the identifier remains stable even as its controlling keys change over time.

A critical innovation is the use of a self-addressing identifier (SAID), where the identifier itself is a cryptographic hash of the inception event. This makes every identifier self-certifying; its provenance and initial state are proven by its own name. All subsequent events reference prior events by their SAIDs, creating an immutable, hash-linked chain. This design allows any verifier to reconstruct the entire key history from a trusted copy of the event log, enabling portable control and verification entirely off-chain.

KERI supports multiple witness configurations for different trust models, from a single witness for personal use to a robust, decentralized quorum. Witnesses do not need to know each other or run the same software; they only need to follow the protocol for signing receipts. This separation of the consensus layer (witness receipting) from the application layer (using the identifier) provides unparalleled flexibility. The system achieves sufficient consensus for key event validity, which is a lighter, more scalable requirement than the total ordering needed for transaction consensus in blockchains.

In practice, to verify a signature or an identifier's current key, a verifier obtains the relevant key event log and the associated witness receipts. By checking the cryptographic signatures on the event chain and validating that a sufficient threshold of witnesses has receipted each event, the verifier can independently confirm the authoritative current key without querying a central registry. This mechanism enables truly decentralized digital trust for applications like secure messaging, verifiable credentials, and decentralized autonomous organizations (DAOs).

key-features
ARCHITECTURAL PILLARS

Key Features of KERI

Key Event Receipt Infrastructure (KERI) is a cryptographic framework for decentralized key management and identifier authentication. Its core features enable self-sovereign identity without reliance on centralized ledgers.

01

Self-Certifying Identifiers

A Self-Certifying Identifier (SCID) is a cryptographic identifier derived directly from its controlling public key, most commonly using a hash. This creates a cryptographic binding where the identifier itself proves the associated public key, eliminating the need for a third-party registry. For example, a KERI AID (Autonomic Identifier) is a SCID.

02

Key Event Log

The Key Event Log (KEL) is an immutable, append-only sequence of key events signed by the identifier's current private key. It records the entire lifecycle of an identifier, including:

  • Inception: The creation event with the initial public key.
  • Rotation: Events to update to a new public key.
  • Delegation: Events to authorize another identifier. The KEL serves as the single source of truth for an identifier's state.
03

Key Event Receipt Log

A Key Event Receipt Log (KERL) is a verifiable log of receipts from witnesses or validators attesting to the validity of events in a KEL. Receipts are cryptographic signatures on the event digest. The KERL provides distributed consensus and non-repudiation, allowing any verifier to confirm that multiple independent parties have seen and accepted the key events.

04

Witness-Based Consensus

KERI uses a selective endorsement model instead of global consensus. An identifier controller chooses a set of trusted witnesses (e.g., 3 of 5) to observe and receipt its key events. This provides sufficient consensus for most decentralized identity use cases with minimal overhead, as it doesn't require proof-of-work or stake from unrelated parties.

05

Cryptographic Key Rotation

KERI provides a secure, verifiable protocol for key rotation, allowing an identifier's controlling keys to be changed without changing the identifier itself. The process is recorded in the KEL and receipted in the KERL. This is critical for long-term security, enabling recovery from key compromise and adherence to cryptographic best practices for key lifecycle management.

06

Ledger Agnostic Design

KERI is ledger-agnostic, meaning it does not require a specific blockchain or distributed ledger to function. The KEL and KERL can be stored on any durable medium (e.g., a personal server, IPFS, or a blockchain). This design maximizes portability and sovereignty, avoiding lock-in to any particular ecosystem's governance or availability constraints.

etymology-origin
KEY EVENT RECEIPT INFRASTRUCTURE

Etymology and Origin

An exploration of the linguistic and conceptual origins of Key Event Receipt Infrastructure (KERI), a protocol designed to establish a decentralized, self-certifying identifier system.

The term Key Event Receipt Infrastructure (KERI) is a compound noun that precisely describes its core architectural principle. Key Event refers to any cryptographic state change—such as key rotation or delegation—that is immutably logged. Receipt signifies the cryptographic proof, generated by verifiers (witnesses), that the event was seen and its integrity can be verified. Infrastructure denotes the underlying protocol suite that provides the framework for managing these self-certifying identifiers and their associated event logs, independent of any specific distributed ledger.

KERI was conceived by Samuel M. Smith, Ph.D., as a foundational layer for decentralized identity, emerging from research into the limitations of blockchain-based identifiers like those in Decentralized Identifiers (DIDs). Its design philosophy is rooted in the principle of cryptographic autonomy, where control and verification are entirely key-based, eliminating dependency on external consensus mechanisms or ledgers for identifier provenance. This origin positions KERI not as a competitor to blockchains, but as a complementary, more minimalistic base layer for portable, self-sovereign identity.

The protocol's conceptual lineage draws from secure cryptographic engineering and database journaling techniques. Its event-sourcing model, where the current state is derived from a verifiable log of all prior key events, mirrors principles from cryptographic verifiable data structures. This design ensures cryptographic agility, allowing the underlying algorithms to be upgraded without breaking the identifier itself, a critical feature for long-lived digital entities in a post-quantum computing future.

core-components
ARCHITECTURE

Core Components of KERI

Key Event Receipt Infrastructure (KERI) is a decentralized key management system that establishes self-certifying identifiers (SCIDs) and a verifiable chain of control events, enabling trust without centralized authorities.

01

Self-Certifying Identifier (SCID)

A Self-Certifying Identifier (SCID) is a cryptographic identifier where the identifier itself is a direct, verifiable cryptographic digest of the controlling public key. The most common form is a Self-Certifying AID (Autonomic Identifier), which is derived by hashing the initial public key. This creates a permanent, globally unique identity that is entirely under the controller's cryptographic control, eliminating dependency on external registries or certificate authorities.

02

Key Event Log (KEL)

The Key Event Log (KEL) is the authoritative, append-only sequence of signed events that document the complete lifecycle of an identifier. It is controlled solely by the identifier's owner. Key events include:

  • Inception: Establishes the initial public key and SCID.
  • Rotation: Authoritatively changes the current public key to a new one.
  • Interaction: Signs application-specific data without changing control authority.
  • Delegation: Grants authority to another identifier. The KEL provides a cryptographically verifiable history of control statements.
03

Key Event Receipt Log (KERL)

A Key Event Receipt Log (KERL) is a verifiable log, maintained by a witness, that contains cryptographic receipts for events in a KEL. Each receipt is a signature from the witness attesting that they have seen and durably stored a specific event. The collection of KERLs from a sufficient number of trusted witnesses provides durability and non-repudiation, ensuring the KEL's events cannot be altered or denied after the fact, even by the identifier's controller.

04

Witness

A witness is a trusted entity, selected by the identifier controller, whose role is to observe and provide receipts for events in a Key Event Log (KEL). Witnesses provide:

  • Durability: By storing copies of KEL events.
  • Availability: By making the KEL and receipts available to verifiers.
  • Non-repudiation: By providing signed receipts that prevent the controller from denying a past event. A witness pool is a set of witnesses configured to provide redundancy and fault tolerance for an identifier.
05

Verifiable Data Structure (VDS)

The Verifiable Data Structure in KERI refers to the cryptographic chaining mechanism that links all events in a KEL. Each event includes a digest of the previous event, forming an immutable hash chain. This structure ensures:

  • Integrity: Any alteration to a past event breaks the chain for all subsequent events.
  • Ordering: The sequence of events is cryptographically enforced.
  • Verifiability: A verifier can cryptographically audit the entire history from the current key back to the inception event, establishing a root of trust.
06

Prefix & Sequence Number

Every event in a KEL is uniquely addressed by two core fields:

  • Prefix: The Self-Certifying Identifier (SCID) to which the event belongs.
  • Sequence Number (sn): A monotonically increasing integer that defines the strict order of events for that identifier, starting at 0 for the inception event. Together, the (prefix, sn) tuple provides a globally unique coordinate for any event, enabling precise referencing, discovery, and verification across distributed systems.
ARCHITECTURAL COMPARISON

KERI vs. Other DID Method Approaches

A technical comparison of Key Event Receipt Infrastructure (KERI) with traditional blockchain-based and centralized DID method architectures.

Architectural FeatureKERI (Key Event Receipt Infrastructure)Blockchain-Anchored DIDs (e.g., did:ethr, did:sov)Centralized/Registry DIDs (e.g., did:web)

Underlying Trust Layer

Self-certifying identifiers & cryptographic receipts

Public blockchain consensus (e.g., Ethereum, Hyperledger Indy)

Centralized server or database authority

Identifier Resolution

Directly from key event log; no external resolution service required

Requires blockchain node or resolver service to query the ledger

Requires querying the authoritative central registry

Write/Update Operations

Peer-to-peer key event exchange; no transaction fees

On-chain transactions requiring gas/network fees

API calls to central service; may have service fees

Verifiable Data Registry Dependency

None (fully self-sovereign)

Absolute (DID Document state is the blockchain state)

Absolute (DID Document state is the registry state)

Cryptographic Proof Mechanism

Digital signatures on key event receipts (KEL/KEEL)

Digital signatures verified against on-chain state

Digital signatures verified by registry or TLS for did:web

Recovery/Key Rotation

Pre-rotated keys & witness receipts enable robust recovery

Governed by on-chain DID Document controller logic

Governed by central registry's policies and API

Scalability & Throughput

Theoretically unlimited; bound only by peer-to-peer network

Bound by underlying blockchain's throughput and latency

Bound by central service's capacity and availability

Primary Portability Risk

Loss of key event log access or witness set failure

Blockchain fork, network sunsetting, or protocol changes

Service shutdown, policy changes, or domain expiration

examples-use-cases
KEY EVENT RECEIPT INFRASTRUCTURE (KERI)

Examples and Use Cases

KERI is a decentralized key management infrastructure that provides cryptographic proof of control without relying on centralized authorities. Its core applications span digital identity, secure communication, and interoperable trust systems.

05

Recovery & Key Rotation

A primary KERI use case is secure key lifecycle management. The protocol specifies a formal process for:

  • Pre-rotated key pairs: Establishing a next-keys list before rotation is needed.
  • Delegated recovery: Assigning delegated identifiers that can authorize a recovery event if the primary keys are lost.
  • Multi-signature thresholds: Configuring control to require signatures from M-of-N keys for a rotation event. This provides a cryptographically verifiable recovery path, a significant advantage over traditional PKI where a lost private key often means losing the identity.
KEY EVENT RECEIPT INFRASTRUCTURE

Technical Deep Dive

Key Event Receipt Infrastructure (KERI) is a decentralized key management protocol that provides cryptographic proof of control and a verifiable history of key events without relying on a blockchain or a central ledger.

Key Event Receipt Infrastructure (KERI) is a protocol for establishing and maintaining self-sovereign digital identifiers using a cryptographically verifiable event log. It works by having a controller generate a self-certifying identifier (SCID) from a public key, then signing a sequence of Key Event Log entries (like inception, rotation, delegation) that are witnessed and receipted by other participants. This creates a tamper-evident history of key state changes, enabling decentralized key management and verifiable data streaming without a consensus ledger.

Core Mechanism:

  • Inception Event: The initial creation of the identifier and its associated public key.
  • Key Rotation: A signed event to replace the current key with a new one, maintaining continuity of control.
  • Receipts: Cryptographic signatures from witnesses or validators that attest to having seen and logged the event, providing external proof.
ecosystem-usage
DECENTRALIZED IDENTIFIERS

Ecosystem and Adoption

Key Event Receipt Infrastructure (KERI) is a decentralized key management protocol for establishing self-sovereign identifiers and secure cryptographic interactions without relying on centralized authorities or distributed ledgers.

02

Key Event Receipt Log (KERL)

The Key Event Receipt Log (KERL) is the core data structure in KERI. It is a cryptographically chained, append-only log of all key management events for an identifier, such as key rotations or delegation. Each entry is signed and includes a hash of the previous entry, creating an immutable, verifiable history of an identifier's state changes.

03

Witnesses & Watchers

KERI uses a network of witnesses and watchers to provide security and availability without a blockchain.

  • Witnesses: Trusted entities that cryptographically sign and log key event receipts, providing non-repudiation and preventing equivocation.
  • Watchers: Monitor witnesses for consistency and broadcast events, ensuring liveness and detection of malicious activity.
05

ACDC (Authentic Chained Data Container)

Authentic Chained Data Container (ACDC) is a data format specification built on KERI for creating tamper-evident, signed data structures. It is used to issue verifiable credentials and other attested data. ACDC credentials are cryptographically chained back to a KERI identifier, providing a strong proof of provenance and integrity.

06

Adoption & Use Cases

KERI is adopted in projects requiring high-assurance, decentralized identity and provenance.

  • Supply Chain: Tracking asset provenance with immutable logs.
  • Digital Credentials: Issuing verifiable diplomas, licenses, and attestations.
  • Decentralized Finance (DeFi): On-chain credentialing and compliance (e.g., ToIP stacks).
  • IoT & Autonomous Systems: Secure machine-to-machine communication and delegation.
KEY EVENT RECEIPT INFRASTRUCTURE

Common Misconceptions About KERI

Key Event Receipt Infrastructure (KERI) is a decentralized key management protocol that is often misunderstood. This section clarifies frequent points of confusion regarding its purpose, architecture, and relationship to other technologies like blockchain and DIDs.

No, KERI is not a blockchain; it is a cryptographic protocol for managing decentralized identifiers (DIDs) and their associated keys without requiring a consensus ledger. KERI uses a self-certifying identifier system where the identifier is a cryptographic hash of the initial public key. The protocol's security and verification are achieved through a verifiable data structure of signed key events and a peer-to-peer receipting mechanism, not through global consensus or mining. While KERI events can be anchored to a blockchain for additional security or discoverability, the core protocol operates independently, making it more lightweight and scalable for direct, trust-over-IP interactions.

KEY EVENT RECEIPT INFRASTRUCTURE

Frequently Asked Questions (FAQ)

Key Event Receipt Infrastructure (KERI) is a decentralized key management protocol for establishing self-sovereign identity. These questions address its core concepts, differences from blockchain, and practical applications.

Key Event Receipt Infrastructure (KERI) is a cryptographic protocol for creating and managing self-certifying, portable identifiers without a central authority or blockchain. It works by using a self-certifying identifier (SCID) derived from a public key, where control is proven by signing a sequence of key events (like rotations or delegations). These events are logged in a verifiable data structure, and witnesses provide cryptographic receipts, creating a decentralized consensus on the identifier's current state without requiring a global ledger.

ENQUIRY

Get In Touch
today.

Our experts will offer a free quote and a 30min call to discuss your project.

NDA Protected
24h Response
Directly to Engineering Team
10+
Protocols Shipped
$20M+
TVL Overall
NDA Protected Directly to Engineering Team
What is KERI? Key Event Receipt Infrastructure Explained | ChainScore Glossary