Loading vLEI.wiki
Fetching knowledge base...
Fetching knowledge base...
This comprehensive explanation has been generated from 43 GitHub source documents. All source documents are searchable here.
Last updated: October 7, 2025
This content is meant to be consumed by AI agents via MCP. Click here to get the MCP configuration.
Note: In rare cases it may contain LLM hallucinations.
For authoritative documentation, please consult the official GLEIF vLEI trainings and the ToIP Glossary.
Inconsistency refers to a state where different parts of data, events, or logs do not agree with each other or with external references. In KERI, inconsistency is categorized as either internal (within a single data structure, making it unverifiable) or external (between different versions of the same data structure, indicating duplicity).
Inconsistency in digital identity systems describes a condition where data elements, event sequences, or logical relationships fail to maintain agreement either within themselves or with external references. The concept encompasses two fundamental dimensions:
In the context of KERI (Key Event Receipt Infrastructure), inconsistency serves as a critical diagnostic property for evaluating the verifiability and integrity of key event logs (KELs) and related data structures. The distinction between internal and external inconsistency maps directly to KERI's security model: internal inconsistency indicates a fundamentally broken data structure, while external inconsistency reveals duplicity—potentially malicious behavior by a controller.
Detectability: Inconsistency must be cryptographically detectable through verification mechanisms. In KERI, this is achieved through hash chaining, digital signatures, and protocol-defined validation rules.
Verifiability Impact: Internal inconsistency renders a data structure unverifiable, breaking the chain of cryptographic trust. External inconsistency, while each version may be internally consistent, creates provable evidence of conflicting claims.
Internal Consistency Validation: Validators must verify:
External Consistency Monitoring: Effective duplicity detection requires:
Watcher Network Design: Organizations implementing KERI should:
Recovery Procedures: When inconsistency is detected:
Risk Assessment: The distinction between internal and external inconsistency affects risk models:
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.
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.
Blockchain and distributed ledger technologies introduced new dimensions to inconsistency:
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 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."
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.
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.
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:
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:
Identity Verification: When a verifier receives a KEL from a controller, they can:
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:
Key Compromise Recovery: KERI's pre-rotation mechanism enables recovery from key compromise while maintaining consistency:
Scalability: By eliminating the need for global consensus on consistency, KERI enables:
Security: The duplicity-evident approach provides:
Portability: Consistency verification is self-contained:
Detection vs. Prevention: KERI detects external inconsistency rather than preventing it. This means:
However, this trade-off enables KERI's scalability and eliminates consensus overhead.
Watcher Dependency: Effective duplicity detection requires:
Complexity: Understanding the distinction between internal and external inconsistency requires:
This complexity is necessary for the security guarantees KERI provides.
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.
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:
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.