Non-establishment events are also known as interaction events (event type ixn in KERI serialization). They maintain the cryptographic chain integrity of the KEL while explicitly avoiding any modification to the key state established by the most recent establishment event (either inception or rotation).

The structural organization follows KERI's event message format with specific constraints:

1. Event Type Designation: The t field must be set to ixn (interaction)
2. Sequence Continuity: The s field contains the next sequential number in the KEL
3. Prior Event Binding: The p field contains the SAID of the immediately preceding event
4. Seal Array: The a field contains an array of seal objects anchoring external data
5. No Key State Changes: Absence of fields that would modify keys, thresholds, or witnesses

Key Components

The essential components of a non-establishment event include:

Version String (v): Specifies the KERI protocol version and serialization format (e.g., KERI10JSON for KERI version 1.0 with JSON serialization). This enables protocol evolution and ensures parsers can correctly interpret the event structure.

Event Type (t): Set to ixn to designate this as an interaction event, distinguishing it from establishment events (icp, rot, dip, drt).

Identifier (i): The AID prefix for which this event is being created. This field remains constant throughout the identifier's lifecycle.

Sequence Number (s): A monotonically increasing integer (encoded as hexadecimal string in text domain) that establishes the event's position in the KEL. For non-establishment events, this continues the sequence from the most recent establishment event.

Prior Event Digest (p): The cryptographic digest (SAID) of the immediately preceding event in the KEL. This creates the backward-chaining property that makes the KEL tamper-evident.

Anchor Array (a): An array of seal objects that cryptographically commit to external data. Each seal typically contains:

• i: Identifier being sealed (may be the same AID or a different identifier)
• s: Sequence number of the event being sealed
• d: Digest (SAID) of the data being anchored

Signature Attachments: Following the event body, CESR-encoded signatures from the current authoritative keypairs prove the controller's commitment to the anchored data.

Data Format

Field Definitions

The canonical field structure for a non-establishment event follows KERI's ordered field map convention:

{
  "v": "KERI10JSON0000cb_",
  "t": "ixn",
  "d": "EL1L56LyoKrIofnn0oPChS4EyzMHEEk75INJohDS_Bug",
  "i": "EH7Oq9oxCgYa-nnNLvwhp9sFZpALILlRYyB-6n4WDi7w",
  "s": "2",
  "p": "EEnwxEm5Bg5s5aTL0HgwfRSNd7wgWHJ_1FKDcyDJKXYw",
  "a": [
    {
      "i": "EH7Oq9oxCgYa-nnNLvwhp9sFZpALILlRYyB-6n4WDi7w",
      "s": "0",
      "d": "EBkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM"
    }
  ]
}

Version String Format: The v field follows the pattern KERI{major}{minor}{kind}{size}_ where:

• KERI is the protocol identifier
• {major}{minor} encode the version (e.g., 10 for version 1.0)
• {kind} specifies serialization (e.g., JSON, CBOR, MGPK)
• {size} is a hexadecimal count of bytes/characters
• _ is the terminator

Sequence Number Encoding: The s field uses hexadecimal string representation to support compact encoding in CESR streams. Values 0-9 use decimal digits, 10-15 use lowercase a-f, and larger values continue in hexadecimal.

Digest Fields: Both d (event SAID) and p (prior event digest) use CESR qualified Base64 encoding with derivation codes indicating the hash algorithm (e.g., E prefix for Blake3-256 digest).

Anchor Array Structure: The a field contains an array of seal objects. An empty array [] is valid and indicates the event maintains KEL continuity without anchoring external data. Non-empty arrays contain seal objects with i, s, and d fields creating cryptographic commitments.

Encoding Format

Non-establishment events support multiple serialization formats through KERI's CESR encoding:

JSON Serialization: Human-readable text format using UTF-8 encoding. Field ordering must be preserved as specified (insertion-ordered dictionaries). This is the primary format for development and debugging.

CBOR Serialization: Compact binary format (Concise Binary Object Representation) for efficient transmission. Maintains semantic equivalence with JSON while reducing size.

MGPK Serialization: MessagePack binary format providing another compact encoding option with different performance characteristics.

CESR Native: Events can be encoded directly in CESR's composable streaming format, enabling efficient concatenation with other primitives and groups.

All formats must support round-trip conversion without loss of information, ensuring semantic equivalence across serialization boundaries.

Size and Constraints

Minimum Event Size: A minimal non-establishment event with empty anchor array requires approximately 200 bytes in JSON format (varies with identifier length and sequence number).

Maximum Practical Size: While KERI does not impose hard limits, practical considerations suggest keeping anchor arrays under 100 seals per event to maintain reasonable processing times and network transmission efficiency.

Sequence Number Range: Sequence numbers are unbounded integers, though implementations typically use 64-bit representations. Hexadecimal encoding in text domain supports arbitrarily large values.

Digest Size: Standard digest fields use 256-bit hashes (32 bytes raw, 44 characters Base64), though KERI's crypto-agility allows algorithm upgrades to larger digests if needed.

Operations

Creation and Initialization

Creating a non-establishment event requires several steps that maintain KEL integrity:

1. Retrieve Current Key State: Query the KEL to determine the current sequence number, prior event digest, and authoritative keypairs. The non-establishment event must reference the correct prior event and use the current keys for signing.

2. Construct Seal Array: Build the anchor array with seal objects for any external data being committed. Each seal must reference valid identifiers and include correct SAIDs for the data being anchored.

3. Compute Event SAID: The d field is self-referential, requiring a two-pass computation:

• First pass: Replace d field with # characters matching the digest length
• Compute digest over the entire event structure
• Second pass: Replace # characters with the computed digest

4. Sign Event: Generate signatures using the current authoritative private keys. For multi-sig identifiers, collect threshold-satisficing signatures from the controlling entities.

5. Attach Signatures: Append CESR-encoded signature attachments to the event message. These attachments include indexed signatures that identify which key from the current key set produced each signature.

Updates and Modifications

Non-establishment events are immutable once signed and published. The KEL's append-only property means events cannot be modified after creation. However, subsequent events can:

Supersede Previous Commitments: A new non-establishment event can anchor updated data, effectively superseding earlier commitments. Validators must process events in sequence order to determine current state.

Correct Errors: If an incorrect seal was published, a subsequent event can anchor corrected data. The KEL maintains the complete history, enabling audit of changes.

Revoke Commitments: Specific revocation patterns can be implemented through seal conventions. For example, anchoring a revocation registry event that nullifies a previous commitment.

Verification and Validation

Validating a non-establishment event requires multiple verification steps:

1. Structural Validation:

• Verify all required fields are present (v, t, d, i, s, p, a)
• Confirm t field equals ixn
• Validate field types and formats
• Check version string compatibility

2. Sequence Validation:

• Verify s equals the expected next sequence number
• Confirm p matches the SAID of the prior event in the KEL
• Ensure no sequence gaps or duplicates

3. SAID Verification:

• Recompute the event SAID using the same algorithm
• Verify computed digest matches the d field
• This confirms event integrity and prevents tampering

4. Key State Verification:

• Retrieve the current key state from the most recent establishment event
• Verify the event does not attempt to modify keys, thresholds, or witnesses
• Confirm the event uses the correct current key state

5. Signature Verification:

• Extract signature attachments from the event message
• Verify each signature against the event body using current public keys
• For multi-sig identifiers, confirm threshold requirements are met
• Check signature indices match valid keys in the current key set

6. Seal Validation:

• For each seal in the anchor array, verify referenced identifiers are valid
• If seals reference other KEL events, verify those events exist and are valid
• Confirm seal digests match the actual data being anchored (if available)

7. Witness Receipt Validation (for indirect mode):

• Verify witness receipts are present if required by witness threshold
• Confirm receipts are signed by designated witnesses
• Check receipt timestamps and ordering

Usage Context

In Which Protocols

Non-establishment events are utilized across multiple KERI-based protocols:

KERI Core Protocol: The foundational use case is maintaining KEL continuity between establishment events. Even when no external data needs anchoring, interaction events may be created to demonstrate continued control and prevent KEL staleness.

ACDC Credential Protocol: Authentic Chained Data Containers leverage non-establishment events extensively:

• Credential Issuance: Anchoring the SAID of an issued credential to the issuer's KEL
• Credential Revocation: Anchoring revocation registry state changes
• Credential Presentation: Recording presentation events for audit trails

TEL Registry Protocol: Transaction Event Logs use non-establishment events to anchor registry operations:

• Registry Creation: Anchoring the inception of a new TEL registry
• State Updates: Anchoring transaction events that modify registry state
• Backers Coordination: Coordinating state across multiple registry backers

IPEX Exchange Protocol: Issuance and Presentation Exchange uses interaction events to anchor:

• Grant Messages: Anchoring credential grant offers
• Admit Messages: Anchoring credential admissions
• Apply Messages: Anchoring credential application requests

DID:KERI Method: The did:keri DID method uses interaction events to anchor:

• Service Endpoint Updates: Publishing new service endpoints
• DID Document Changes: Anchoring updates to DID document metadata

Lifecycle Management

The lifecycle of non-establishment events follows the broader KEL lifecycle:

Creation Phase: Events are created by the controller when external data needs anchoring or KEL continuity must be maintained. Creation may be triggered by:

• Application-level operations (credential issuance, service updates)
• Periodic KEL maintenance (preventing staleness)
• Delegation operations (anchoring delegated events)

Publication Phase: After signing, events are published to:

• Witnesses (in indirect mode): Events are sent to designated witnesses for receipting
• Watchers: Events may be propagated to watcher networks for duplicity detection
• Verifiers: Events are transmitted to parties that need to verify anchored data

Verification Phase: Recipients validate events through the verification process described above. Invalid events are rejected and may trigger duplicity detection if conflicting valid events exist.

Archival Phase: Events become part of the permanent KEL record. They may be:

• Stored in local databases for fast retrieval
• Cached by witnesses and watchers
• Archived in long-term storage systems
• Indexed for efficient querying

Supersession Phase: While events themselves are immutable, their semantic meaning may be superseded by later events. For example:

• A new service endpoint anchor supersedes an earlier one
• A revocation event supersedes an issuance event
• Updated data anchors replace stale commitments

Related Structures

Non-establishment events interact with several related KERI data structures:

Establishment Events: Non-establishment events depend on the key state defined by the most recent establishment event. They cannot exist without a prior inception or rotation event that establishes the authoritative keys used for signing.

Key Event Receipts: Witnesses generate receipt messages for non-establishment events, creating key event receipt logs (KERLs) that provide distributed consensus on event ordering and validity.

Seals: The anchor array contains seal objects that are themselves structured data. Seals may reference:

• Other KEL events (creating event-to-event linkages)
• TEL events (anchoring transaction state)
• ACDC credentials (anchoring credential operations)
• Arbitrary data (via digest commitments)

Transaction Event Logs: TELs are anchored to KELs through seals in non-establishment events. This creates a cryptographic binding between the transaction state and the identifier's key state.

ACDC Credentials: Credentials are anchored to issuer KELs through interaction events, enabling verifiable credential issuance without requiring the credential itself to be stored in the KEL.

Delegated Events: When an identifier delegates authority to another identifier, the delegation is anchored through a seal in a non-establishment event (or rotation event) of the delegator's KEL.

Witness Pools: Non-establishment events are sent to witness pools for receipting in indirect mode. The witness configuration is established by the most recent establishment event and remains unchanged by interaction events.

Watcher Networks: Watchers observe non-establishment events to detect duplicity. If a controller creates conflicting interaction events at the same sequence number, watchers can detect this duplicitous behavior.

Security Properties

Non-establishment events inherit and extend KERI's security properties:

Cryptographic Integrity: The SAID mechanism ensures events cannot be tampered with after creation. Any modification invalidates the digest and breaks the KEL chain.

Non-Repudiation: Digital signatures provide non-repudiable proof that the controller authorized the anchored data. The controller cannot later deny creating the commitment.

Duplicity Evidence: If a controller creates conflicting non-establishment events at the same sequence number, both events serve as cryptographic evidence of duplicitous behavior. This enables duplicity detection mechanisms.

Key State Isolation: By not modifying key state, non-establishment events reduce the attack surface for key compromise. An attacker who compromises signing keys can create fraudulent interaction events but cannot rotate keys without access to pre-rotated keys.

Temporal Ordering: The sequence number and prior event digest create a verifiable temporal ordering of commitments. This enables audit trails and prevents reordering attacks.

Witness Consensus: In indirect mode, witness receipts provide distributed consensus on event validity and ordering, making it difficult for attackers to create alternative event histories.

Performance Considerations

Non-establishment events are designed for high-frequency operations:

Lightweight Creation: Since they don't modify key state, creation is computationally cheaper than establishment events. No key generation or pre-rotation computation is required.

Efficient Verification: Validators can verify interaction events using cached key state from the most recent establishment event, avoiding repeated key state computation.

Scalable Anchoring: The seal array enables batching multiple commitments in a single event, reducing the number of events needed for high-volume operations.

Parallel Processing: Multiple non-establishment events can be created in parallel (at different sequence numbers) without coordination, enabling high-throughput scenarios.

Compact Encoding: CESR's compact binary encoding minimizes network transmission overhead for interaction events, important for bandwidth-constrained environments.

Common Patterns

Several common patterns emerge in non-establishment event usage:

Empty Interaction Pattern: Creating interaction events with empty anchor arrays to maintain KEL liveness and demonstrate continued control. This prevents KEL staleness and provides regular proof-of-control.

Batch Anchoring Pattern: Including multiple seals in a single interaction event to anchor several operations atomically. This is efficient for high-volume credential issuance or registry updates.

Delegation Anchoring Pattern: Using interaction events to anchor delegated inception or rotation events, creating verifiable delegation chains.

Registry State Pattern: Anchoring TEL state changes through interaction events, enabling verifiable credential registries without blockchain dependencies.

Service Endpoint Pattern: Publishing service endpoints and communication routes through interaction events, enabling dynamic service discovery.

Revocation Pattern: Anchoring credential revocation events through interaction events, providing verifiable revocation without requiring credential holders to check centralized revocation lists.

An empty anchor array [] is valid and commonly used for KEL maintenance. Implementations should not treat empty arrays as errors. This pattern is used to:

• Demonstrate continued control over an identifier
• Maintain KEL liveness between establishment events
• Provide regular proof-of-control timestamps

Performance Optimization

For high-throughput scenarios:

• Cache current key state to avoid repeated KEL traversal
• Batch multiple seals in single interaction events when possible
• Use CBOR or MGPK serialization for reduced message size
• Implement parallel event creation for different sequence numbers
• Pre-compute SAIDs for frequently anchored data

Error Handling

Implementations must handle several error conditions:

• Sequence gaps: Reject events with non-sequential sequence numbers
• Invalid prior digest: Reject events where p doesn't match the actual prior event
• Signature verification failure: Reject events with invalid or insufficient signatures
• SAID mismatch: Reject events where recomputed SAID doesn't match d field
• Witness timeout: Handle cases where witnesses don't respond within timeout period

Multi-Signature Coordination

For multi-sig identifiers, interaction event creation requires coordination:

1. One party creates the unsigned event
2. Event is circulated to all signing parties
3. Each party adds their signature
4. Once threshold is met, event is published
5. All parties must use the same event serialization to ensure SAID consistency

Delegation Anchoring

When anchoring delegated events, the seal must reference the delegated event correctly:

• i: The delegated identifier (not the delegator)
• s: The sequence number of the delegated event
• d: The SAID of the delegated event

This creates the cryptographic binding that enables delegation verification.

TEL Registry Integration

When anchoring TEL events:

1. Create the TEL event first
2. Compute its SAID
3. Create an interaction event with a seal referencing the TEL event
4. The TEL event is now cryptographically bound to the KEL
5. Validators can verify the TEL state by checking the KEL anchor

Backward Compatibility

Implementations should support multiple KERI versions:

• Parse version strings to determine protocol version
• Support older event formats for historical KEL validation
• Implement version-specific validation rules
• Provide migration paths for protocol upgrades