Structural Organization

The DEL is organized as a per-identifier, per-entity data structure. Each juror in the KERI ecosystem maintains separate DELs for:

• Each controller: Tracking duplicitous events produced by identifier controllers
• All designated witnesses: Tracking duplicitous events produced by each witness in the witness pool

This distributed maintenance model ensures that duplicity detection is ambient - any validator can independently verify duplicity by examining relevant DELs without requiring centralized coordination.

The DEL structure consists of:

1. Index References: Pointers to events in the corresponding KERL
2. Duplicitous Event Sets: Collections of two or more mutually inconsistent event messages
3. Metadata: Timestamps, discovery context, and provenance information
4. Cryptographic Proofs: Signatures and digests proving the authenticity of each duplicitous event

Key Components

Each entry in a DEL contains:

• KERL Event Reference: The sequence number and digest of the event in the authoritative KERL
• Conflicting Event Messages: The complete set of inconsistent event messages (minimum two)
• Signatures: Non-repudiable signatures from the controller or witness on each conflicting message
• Discovery Information: How and when the duplicity was detected
• Witness Receipts: If applicable, receipts from witnesses on the conflicting events

Data Format

Field Definitions

While the KERI specification does not mandate a specific serialization format for DELs, the logical structure includes:

DEL Entry Structure:

{
  "kerl_reference": {
    "aid": "<Autonomic Identifier>",
    "sequence": <event sequence number>,
    "digest": "<event digest>"
  },
  "duplicitous_events": [
    {
      "event": <complete event message>,
      "signatures": [<signature attachments>],
      "receipts": [<witness receipts if applicable>]
    },
    {
      "event": <conflicting event message>,
      "signatures": [<signature attachments>],
      "receipts": [<witness receipts if applicable>]
    }
  ],
  "discovery": {
    "timestamp": "<ISO 8601 timestamp>",
    "source": "<discovery source>",
    "context": "<discovery context>"
  }
}

Encoding Format

DEL entries leverage CESR (Composable Event Streaming Representation) encoding for cryptographic primitives, ensuring:

• Text-binary composability: DELs can be serialized in both human-readable and compact binary formats
• Self-framing: Each entry is self-describing and parseable without external schema
• Cryptographic integrity: All signatures and digests use CESR-qualified primitives

The event messages within DEL entries are typically serialized using:

• JSON for human readability and debugging
• CBOR (Concise Binary Object Representation) for compact transmission
• MGPK (MessagePack) as an alternative binary format

Size and Constraints

DEL size is theoretically unbounded, as it grows with detected duplicity. However, practical constraints include:

• Per-event limit: Each DEL entry references exactly one KERL event but may contain multiple conflicting versions
• Minimum duplicity: At least two mutually inconsistent event messages must exist to constitute a DEL entry
• Storage efficiency: DELs typically store only the minimal information needed to prove duplicity, not complete KEL histories

Operations

Creation and Initialization

DEL creation occurs when a juror or validator detects duplicity:

1. Duplicity Detection: The validator receives two or more versions of the same key event (same sequence number, different content)
2. Verification: Each version is cryptographically verified to ensure authentic signatures
3. Inconsistency Confirmation: The versions are compared to confirm mutual inconsistency
4. DEL Entry Creation: A new entry is created in the appropriate DEL (controller or witness-specific)
5. Indexing: The entry is indexed to the corresponding KERL event

Initialization Process:

When a juror begins monitoring an AID, it initializes empty DELs for:

• The controller of that AID
• Each witness in the AID's witness pool

These DELs remain empty unless duplicity is detected.

Updates and Modifications

DELs follow an append-only model with specific update rules:

Adding Duplicity Evidence:

• New conflicting versions of an existing event can be added to the corresponding DEL entry
• Each addition requires cryptographic verification of signatures
• The DEL entry is updated with the new conflicting version and associated metadata

No Deletion Policy:

• DEL entries are never deleted once created
• This ensures permanent forensic evidence of duplicitous behavior
• Even if a controller rotates keys or recovers from compromise, the historical duplicity record persists

Metadata Updates:

• Discovery timestamps may be updated if additional conflicting versions are found
• Source information can be augmented with new discovery contexts

Verification and Validation

DEL verification involves multiple steps:

1. Signature Verification: Each event message in a DEL entry must have valid signatures from the claimed signer
2. Inconsistency Proof: The events must be provably inconsistent (different digests, conflicting key states, etc.)
3. KERL Correspondence: The DEL entry must correctly reference an event in the authoritative KERL
4. Completeness Check: All required fields (events, signatures, metadata) must be present

Validation Algorithm:

function validateDELEntry(entry, kerl):
    # Verify KERL reference exists
    kerl_event = kerl.getEvent(entry.kerl_reference.sequence)
    if kerl_event.digest != entry.kerl_reference.digest:
        return INVALID
    
    # Verify minimum duplicity (at least 2 versions)
    if len(entry.duplicitous_events) < 2:
        return INVALID
    
    # Verify each event's signatures
    for dup_event in entry.duplicitous_events:
        if not verifySignatures(dup_event.event, dup_event.signatures):
            return INVALID
    
    # Verify mutual inconsistency
    if not areEventsInconsistent(entry.duplicitous_events):
        return INVALID
    
    return VALID

Usage Context

In Which Protocols

DELs are integral to several KERI protocol operations:

KERI Core Protocol:

• Duplicity Detection: DELs provide the evidence structure for KERI's ambient duplicity detection
• Validator Decision-Making: Validators consult DELs when assessing whether to trust an identifier
• Witness Evaluation: DELs help validators determine which witnesses are reliable

KAWA (KERI's Algorithm for Witness Agreement):

• DELs track witness duplicity, informing the TOAD (Threshold of Accountable Duplicity) assessment
• Witness pool health is evaluated based on DEL evidence

Judge and Jury Pools:

• Judges examine DELs to determine the authoritative key set for an identifier
• Jurors maintain DELs as part of their duplicity detection responsibilities
• Judges transmit judgements about duplicity discovered by watchers to validators

Lifecycle Management

DEL lifecycle follows these phases:

1. Initialization Phase:

• Empty DELs created when monitoring begins
• Associated with specific AIDs and their infrastructure

2. Active Monitoring Phase:

• Continuous comparison of received events against KERL
• Immediate DEL entry creation upon duplicity detection
• Ongoing updates as additional conflicting versions are discovered

3. Forensic Analysis Phase:

• Validators examine DELs to assess trust
• Historical duplicity patterns inform risk assessment
• DEL evidence may be shared among validators for consensus

4. Archival Phase:

• DELs may be archived for long-term forensic purposes
• Even after an AID is abandoned, its DEL provides historical security context

Related Structures

DELs interact with several other KERI data structures:

Key Event Log (KEL):

• DELs index to KEL events
• KEL provides the authoritative event sequence against which duplicity is measured
• A single KEL may have multiple associated DELs (one per potential duplicitous actor)

Key Event Receipt Log (KERL):

• KERLs include witness receipts, which may themselves be duplicitous
• DELs track both controller and witness duplicity
• KERL consistency is verified by comparing against DEL evidence

Transaction Event Log (TEL):

• TELs for credentials may reference DELs to indicate issuer duplicity
• Credential revocation may be triggered by DEL evidence

Watcher Networks:

• Watchers maintain DELs in "promiscuous mode"
• Watcher DELs provide ambient duplicity detection across the ecosystem
• Validators query watcher DELs to assess identifier trustworthiness

Witness Pools:

• Each witness in a pool has an associated DEL
• Witness pool health is assessed by examining witness DELs
• Witness rotation may be triggered by excessive DEL entries

Practical Usage Scenarios

Scenario 1: Controller Key Compromise

When a controller's keys are compromised, an attacker may attempt to create a conflicting rotation event:

1. Legitimate controller creates rotation event R1
2. Attacker creates conflicting rotation event R2 with same sequence number
3. Witnesses receive both versions
4. Jurors detect inconsistency and create DEL entry
5. Validators examining the DEL can identify the duplicity
6. The first-seen policy helps determine which version is authoritative

Scenario 2: Malicious Witness

A compromised witness may provide inconsistent receipts:

1. Witness W signs event E1 and provides receipt to validator V1
2. Same witness W signs conflicting event E2 and provides receipt to validator V2
3. Validators V1 and V2 compare notes (or a watcher observes both)
4. Witness duplicity is detected and recorded in witness W's DEL
5. Controller may choose to remove witness W from the witness pool
6. Future validators can assess witness W's reliability by examining its DEL

Scenario 3: Ambient Duplicity Detection

The distributed nature of DEL maintenance enables ecosystem-wide duplicity detection:

1. Multiple watchers independently monitor identifier I
2. Each watcher maintains DELs for identifier I's controller and witnesses
3. If duplicity occurs, multiple watchers independently detect and record it
4. Validators can query multiple watchers' DELs for consensus
5. Consistent DEL evidence across multiple independent watchers provides high confidence
6. This "ambient" detection makes duplicity attacks extremely difficult to hide

Security Considerations

DELs provide several security benefits:

Non-Repudiation: Because DEL entries contain signed event messages, duplicitous actors cannot deny their actions. The cryptographic signatures provide irrefutable proof.

Transparency: DELs make duplicity visible to the entire ecosystem, not just direct participants. This transparency deters malicious behavior.

Forensic Evidence: DELs provide permanent records for post-incident analysis, enabling root cause determination and accountability.

Trust Assessment: Validators can make informed decisions by examining DEL history, avoiding identifiers with duplicitous controllers or unreliable witnesses.

Attack Surface Reduction: The existence of DELs and the knowledge that duplicity will be permanently recorded discourages attacks, as the cost of detection is high.

Implementation Considerations

When implementing DEL support:

1. Storage Efficiency: DELs should store only essential information, not complete KEL histories
2. Query Performance: DELs must be efficiently queryable by AID, sequence number, and entity
3. Synchronization: In distributed systems, DEL entries should be shareable among validators
4. Privacy: While DELs record duplicity, they should not leak unnecessary information about honest actors
5. Scalability: DEL storage must scale with the number of monitored identifiers and detected duplicity events

The DEL is a cornerstone of KERI's security architecture, enabling the protocol's unique "duplicity evident" property that distinguishes it from blockchain-based and traditional PKI approaches. By making duplicity both detectable and provable, DELs ensure that malicious behavior cannot remain hidden, creating strong incentives for honest participation in the KERI ecosystem.

Security Best Practices

1. Access Control: Protect DEL write operations to prevent malicious actors from injecting false duplicity evidence.

2. Integrity Protection: Use cryptographic signatures or Merkle trees to protect DEL integrity.

3. Privacy: While DELs record duplicity, avoid including unnecessary information that could leak privacy about honest actors.

4. Audit Logging: Maintain audit logs of DEL modifications for forensic analysis.

Integration with KERI Components

1. Juror Integration: Jurors should automatically create and update DELs as part of their duplicity detection responsibilities.

2. Judge Integration: Judges should query DELs when determining authoritative key sets.

3. Validator Integration: Validators should consult DELs before trusting identifiers or witnesses.

4. Watcher Integration: Watchers should maintain DELs in promiscuous mode and make them queryable by validators.

Performance Optimization

1. Lazy Loading: Load DEL entries on-demand rather than keeping all DELs in memory.

2. Incremental Updates: Support incremental DEL updates rather than requiring full DEL transfers.

3. Pruning Strategy: While DELs are append-only, consider archiving very old entries to separate storage for performance.

Testing Recommendations

1. Duplicity Simulation: Create test scenarios that simulate various duplicity attacks to verify DEL functionality.

2. Performance Testing: Test DEL query performance under load with large numbers of identifiers and duplicity events.

3. Consistency Testing: Verify that DELs remain consistent across distributed validators.

4. Recovery Testing: Test DEL recovery from backups and ensure forensic evidence is preserved.