Scope Boundaries: KERI's definition of inconsistency is strictly technical and cryptographic. It does not address semantic correctness, veracity, or the truthfulness of claims—only whether data structures maintain cryptographic coherence.

Historical Context

Origins in Data Management

The concept of data inconsistency has roots in traditional database management systems, where data inconsistency occurs when similar data is maintained in different formats across multiple files or databases. This creates challenges for data matching, reconciliation, and maintaining a single source of truth.

In distributed systems, inconsistency became a central concern with the development of consensus algorithms and replication protocols. The CAP theorem formalized trade-offs between Consistency, Availability, and Partition tolerance, establishing that distributed systems cannot simultaneously guarantee all three properties.

Evolution in Cryptographic Systems

Blockchain and distributed ledger technologies introduced new dimensions to inconsistency:

• Fork Detection: Identifying when a blockchain splits into multiple competing chains
• Double-Spend Prevention: Ensuring transactions cannot be inconsistently recorded across network nodes
• Consensus Mechanisms: Protocols like Byzantine Fault Tolerance designed to achieve consistency despite malicious actors

However, these systems typically address inconsistency through global consensus—requiring all participants to agree on a single version of truth. This approach introduces scalability limitations, energy costs, and governance challenges.

KERI's Approach

Internal Inconsistency Protection

KERI protects against internal inconsistency through its foundational architecture:

Self-Certifying Identifiers: AIDs (Autonomic Identifiers) are cryptographically derived from key pairs, creating an unbreakable binding between identifier and controlling keys. This cryptographic root-of-trust ensures that the identifier itself cannot be internally inconsistent.

Hash-Chained Event Logs: Each event in a KEL includes a cryptographic digest of the previous event, creating a tamper-evident chain. Any modification to a past event would break the hash chain, making internal inconsistency immediately detectable through verification.

Pre-Rotation Commitments: KERI's innovative pre-rotation mechanism includes cryptographic commitments to next keys in current establishment events. This forward-chaining creates additional internal consistency requirements—rotation events must use keys that were pre-committed in prior events.

Protocol-Defined Validation: The KERI specification defines precise rules for event structure, sequencing, and cryptographic binding. Any KEL that violates these rules is internally inconsistent and therefore unverifiable.

As Document 6 states: "In KERI, you are protected against internal inconsistency by the hash chain data structure of the KEL because the only authority that can sign the log is the controller itself."

External Inconsistency and Duplicity Detection

KERI's revolutionary approach to external inconsistency transforms it from a problem to be prevented into evidence to be detected:

Duplicity as External Inconsistency: When a controller creates two or more versions of their KEL that are each internally consistent but mutually contradictory, this constitutes duplicity. As Document 5 explains: "Duplicity in KERI represents external inconsistency in identifier management... when two or more versions of a Key Event Log (KEL) exist for the same Autonomic Identifier (AID), where each version is internally consistent but mutually incompatible."

Duplicity Evident Infrastructure: Rather than attempting to prevent duplicity through consensus mechanisms, KERI makes duplicity provably evident. Because all events are signed with non-repudiable signatures, possession of two mutually inconsistent KEL versions provides cryptographic proof of misbehavior.

Witness and Watcher Networks: KERI's infrastructure includes:

• Witnesses: Designated entities that sign receipts of events they observe, creating independent records
• Watchers: Entities that monitor KELs in "promiscuous mode," collecting all versions they encounter
• First-Seen Policy: Once a witness or watcher accepts an event as valid for a given sequence number, that event is permanently recorded—"first seen, always seen, never unseen"

This architecture enables ambient duplicity detection—the ability for any validator, anywhere, at any time to detect external inconsistency by comparing KEL versions.

Duplicitous Event Logs (DELs): As Document 42 describes, KERI maintains specialized logs that "record inconsistent event messages produced by a given controller or witness with respect to a specific KERL." These DELs provide forensic evidence of duplicity.

Distinguishing Incompleteness from Inconsistency

KERI makes a critical distinction: a shorter KEL that contains no differing events compared to a longer KEL is incomplete, not inconsistent. Only when events actually differ or conflict does external inconsistency (duplicity) occur. This distinction is important because:

• Network delays may cause validators to have incomplete KELs temporarily
• Incomplete KELs can be safely extended as new events arrive
• Inconsistent KELs indicate potential compromise or malicious behavior

Security Model Implications

Document 9 establishes KERI's security philosophy:

Internal Inconsistency Prevention: "Prevented by log verification from self-certifying root-of-trust." The cryptographic binding from identifier through key pairs to event signatures ensures internal consistency is maintained or violations are immediately detectable.

External Inconsistency Detection: "Detected through duplicity detection when multiple verifiable but conflicting logs exist." Rather than preventing external inconsistency, KERI makes it evident and provable.

This approach enables KERI to provide security guarantees without requiring:

• Global consensus mechanisms
• Shared distributed ledgers
• Trusted third-party validators
• Centralized certificate authorities

Practical Implications

Use Cases

Identity Verification: When a verifier receives a KEL from a controller, they can:

1. Verify internal consistency through cryptographic validation
2. Check with watchers for any externally inconsistent versions
3. Make trust decisions based on consistency evidence

If internal inconsistency is detected, the KEL is rejected as unverifiable. If external inconsistency is detected, the verifier has proof of duplicitous behavior and can choose to reject the controller's claims.

Credential Issuance: ACDC (Authentic Chained Data Container) credentials rely on KERI's consistency guarantees:

• Credential SAIDs (Self-Addressing Identifiers) ensure internal consistency
• Issuer KEL consistency proves the credential was issued by the claimed authority
• TEL (Transaction Event Log) consistency tracks credential status (issued/revoked)

Key Compromise Recovery: KERI's pre-rotation mechanism enables recovery from key compromise while maintaining consistency:

• Pre-rotated keys are committed before compromise occurs
• Recovery rotation uses pre-committed keys, maintaining the consistency chain
• Any attempt to rotate using compromised keys creates detectable external inconsistency

Benefits

Scalability: By eliminating the need for global consensus on consistency, KERI enables:

• Independent validation by any party
• Parallel processing of events
• No blockchain bottlenecks

Security: The duplicity-evident approach provides:

• Cryptographic proof of misbehavior
• No reliance on trusted intermediaries
• Post-quantum security through pre-rotation

Portability: Consistency verification is self-contained:

• KELs can be validated anywhere
• No dependence on specific infrastructure
• True self-sovereign identity

Trade-offs

Detection vs. Prevention: KERI detects external inconsistency rather than preventing it. This means:

• Controllers can create duplicitous KELs
• Validators must actively check for duplicity
• Watcher networks are required for comprehensive detection

However, this trade-off enables KERI's scalability and eliminates consensus overhead.

Watcher Dependency: Effective duplicity detection requires:

• Active watcher networks monitoring KELs
• Validators querying watchers before trust decisions
• Infrastructure for watcher discovery and communication

Complexity: Understanding the distinction between internal and external inconsistency requires:

• Cryptographic knowledge
• Understanding of KERI's event structure
• Familiarity with duplicity detection mechanisms

This complexity is necessary for the security guarantees KERI provides.

Relationship to Other KERI Concepts

Inconsistency serves as a foundational concept connecting multiple KERI mechanisms:

Verifiability: A KEL is verifiable only if it is internally consistent. As Document 40 states: "A KEL is considered verifiable when all content within it... is verifiably compliant with respect to the KERI protocol specification."

Integrity: Consistency is a prerequisite for integrity. Document 36 explains that KERI's "security first approach" to integrity includes "internal consistency" and "external consistency or duplicity detection."

End-Verifiability: KERI's consistency mechanisms enable any party to verify KELs without trusted intermediaries, supporting the principle of "any-data, any-where, any-time by any-body" verification.

Conclusion

Inconsistency in KERI represents a precisely defined technical concept with profound implications for decentralized identity security. By distinguishing internal inconsistency (which breaks verifiability) from external inconsistency (which reveals duplicity), KERI creates a security model that:

• Prevents internal inconsistency through cryptographic binding
• Detects external inconsistency through duplicity-evident infrastructure
• Enables scalable, portable, self-sovereign identity
• Provides cryptographic proof of misbehavior

This approach transforms inconsistency from a problem to be avoided through consensus into evidence to be detected through cryptography, fundamentally changing how distributed identity systems can achieve security and trust.