Establishment events are organized as a subsequence within the complete KEL. This means:

• The KEL contains all events (establishment and non-establishment)
• Establishment events can be extracted as an ordered subsequence
• Each establishment event references the previous establishment event through cryptographic digests
• The sequence number (s field) increments across all events, not just establishment events

Key Components

Every establishment event contains several critical components:

Version String (v): Specifies the KERI protocol version and serialization format (e.g., KERI10JSON000188_)

Event Type (t): Identifies the specific establishment event type:

• icp - Inception event
• rot - Rotation event
• dip - Delegated inception event
• drt - Delegated rotation event

Identifier (i): The AID prefix being established or rotated

Sequence Number (s): Monotonically increasing event counter (hexadecimal encoded)

Digest (d): Self-addressing identifier (SAID) of the event itself

Prior Event Digest (p): Cryptographic digest of the previous event (absent in inception)

Current Keys (k): Array of current authoritative public keys

Current Threshold (kt): Signing threshold for current keys

Next Key Digests (n): Array of digests of pre-rotated keys

Next Threshold (nt): Signing threshold for next keys (in partial rotation implementations)

Witness Configuration:

• wt - Witness threshold
• w - Array of witness AIDs
• wr - Witness rotation (cuts)
• wa - Witness additions

Configuration Traits (c): Array of configuration flags

Data Format

Field Definitions

Establishment events follow strict field ordering as specified in the KERI protocol. The canonical field order for establishment events is:

[v, t, d, i, s, p, kt, k, nt, n, bt, b, c, a]

Where:

• v = Version string
• t = Event type
• d = Event digest (SAID)
• i = Identifier prefix
• s = Sequence number
• p = Prior event digest
• kt = Current signing threshold
• k = Current keys array
• nt = Next threshold
• n = Next key digests array
• bt = Witness threshold (backer threshold)
• b = Witness array (backers)
• c = Configuration array
• a = Anchors array (for seals)

Encoding Format

Establishment events are encoded using CESR (Composable Event Streaming Representation), which supports dual text/binary encoding:

Text Domain: JSON serialization with CESR version string

{
  "v": "KERI10JSON000188_",
  "t": "icp",
  "d": "EH7Oq9oxCgYa-nnNLvwhp9sFZpALILlRYyB-6n4WDi7w",
  "i": "EH7Oq9oxCgYa-nnNLvwhp9sFZpALILlRYyB-6n4WDi7w",
  "s": "0",
  "kt": "1",
  "k": ["DSuhyBcPZEZLK-fcw5tzHn2N46wRCG_ZOoeKtWTOunRA"],
  "nt": "1",
  "n": ["EPYuj8mq_PYYsoBKkzX1kxSPGYBWaIya3slgCOyOtlqU"],
  "bt": "0",
  "b": [],
  "c": [],
  "a": []
}

Binary Domain: Compact binary representation using CESR encoding

Size and Constraints

Version String: Fixed format with embedded size information

• Format: KERI10JSON000188_ where 000188 is the byte count
• Enables self-framing for stream parsing

Sequence Number: Hexadecimal string representation

• Starts at "0" for inception
• Increments monotonically: "1", "2", "3"... "9", "a", "b", "c"...

Keys and Digests: CESR-encoded qualified cryptographic primitives

• Typically 44 characters for Base64 URL-safe encoding
• Include derivation code prefix (e.g., 'D' for Ed25519 public key)

Thresholds: String representation of integer or fractional weights

• Simple threshold: "1", "2", "3"
• Fractional weights: "1/2", "2/3" for weighted multi-sig

Operations

Creation and Initialization

Inception Event Creation:

The inception event is the first and only establishment event that creates an AID. The process involves:

1. Key Generation: Generate initial key pair(s) and pre-rotated key pair(s)
2. Identifier Derivation: Derive the AID prefix from the inception event data
3. Event Construction: Build the inception event with all required fields
4. Signing: Sign the event with the initial private key(s)
5. Witness Receipting: Obtain receipts from configured witnesses

For self-addressing identifiers, the inception event requires special handling where both the d (digest) and i (identifier) fields must contain identical values after derivation.

Rotation Event Creation:

Rotation events transfer control authority to new keys:

1. Prior Event Reference: Include digest of previous establishment event in p field
2. Key Revelation: Reveal pre-rotated keys committed to in previous event
3. New Pre-rotation: Commit to new next keys via digests in n field
4. Threshold Validation: Ensure both current and prior-next thresholds are satisfied
5. Witness Updates: Optionally rotate witness configuration

Updates and Modifications

Establishment events are immutable once created and signed. However, they enable state changes through:

Key Rotation: The primary update mechanism

• Rotates from current keys to pre-committed next keys
• Establishes new pre-rotation commitments
• Can modify signing thresholds

Witness Rotation: Changes the witness pool

• wr field specifies witnesses to remove (cuts)
• wa field specifies witnesses to add
• wt field updates the witness threshold

Partial Rotation: Advanced rotation mechanism

• Rotates only a subset of pre-rotated keys
• Keeps some keys in reserve (unexposed)
• Requires satisfaction of both current and prior-next thresholds

Verification and Validation

Establishment event verification involves multiple steps:

Structural Verification:

1. Parse CESR encoding and extract event data
2. Verify version string format and protocol compliance
3. Validate field ordering matches specification
4. Check sequence number increments correctly

Cryptographic Verification:

1. Verify event digest (d field) matches computed digest
2. Verify prior event digest (p field) matches previous event
3. Verify attached signatures against current keys
4. For rotations, verify revealed keys match prior commitments

Threshold Verification:

1. Verify current threshold (kt) is satisfied by attached signatures
2. For rotations, verify prior-next threshold is satisfied
3. Verify witness threshold (bt) is satisfied by witness receipts

Semantic Verification:

1. Verify key derivation codes are valid
2. Verify witness AIDs are properly formatted
3. Verify configuration traits are recognized
4. Verify any seals reference valid events

Usage Context

In Which Protocols

Establishment events are fundamental to:

KERI Protocol: Core identifier management

• Inception events create AIDs
• Rotation events manage key lifecycle
• Delegated establishment events enable hierarchical trust

ACDC Protocol: Credential issuance foundation

• Issuer AIDs must have valid establishment events
• Credential registries anchor to establishment events
• Delegation chains use establishment events

IPEX Protocol: Presentation exchange security

• Verifiers validate establishment event chains
• Presenters prove control via establishment events

Lifecycle Management

Establishment events follow a strict lifecycle:

Phase 1: Creation

• Generate cryptographic material
• Construct event with proper field ordering
• Compute SAID for self-addressing

Phase 2: Signing

• Sign with current authoritative keys
• Attach signatures in CESR format
• Create indexed signatures for multi-sig

Phase 3: Witnessing

• Promulgate to configured witnesses
• Collect witness receipts
• Achieve witness threshold

Phase 4: Publication

• Append to KEL
• Distribute to watchers
• Make available for verification

Phase 5: Verification

• Validators retrieve and verify
• Duplicity detection mechanisms engage
• Key state is established

Related Structures

Establishment events interact with several related data structures:

Key Event Log (KEL):

• Container for all events including establishment events
• Provides ordered, verifiable history
• Enables key state reconstruction

Key Event Receipt Log (KERL):

• KEL plus witness receipts
• Provides distributed consensus proof
• Enables ambient duplicity detection

Key State:

• Derived from establishment event subsequence
• Represents current authoritative keys and configuration
• Used for signature verification

Transaction Event Log (TEL):

• Anchored to KEL via establishment events
• Manages credential registry state
• References establishment events for authorization

Seals:

• Cryptographic commitments in establishment events
• Enable anchoring external data
• Support delegation and credential issuance

Special Cases

Non-Transferable Identifiers

For non-transferable identifiers, there is exactly one establishment event - the inception event. These identifiers:

• Cannot rotate keys
• Have simpler verification requirements
• Are suitable for ephemeral use cases
• Provide performance benefits

Transferable Identifiers

For transferable identifiers, multiple establishment events are expected:

• Initial inception event
• Zero or more rotation events
• Enable persistent control despite key compromise
• Support long-lived identifiers

Delegated Identifiers

Delegated establishment events (dip, drt) include additional requirements:

• Must reference delegating event via seal
• Delegator must anchor delegation in their KEL
• Cooperative delegation requires both parties' participation
• Enables hierarchical key management

Security Properties

Establishment events provide critical security guarantees:

Duplicity Evidence: Multiple versions of establishment events for the same sequence number constitute detectable duplicity

Forward Security: Pre-rotation commitments protect against key compromise

Backward Chaining: Prior event digests create tamper-evident history

Threshold Security: Multi-signature thresholds prevent single-point compromise

Witness Consensus: Distributed witnessing provides Byzantine fault tolerance

Post-Quantum Resistance: Digest-based pre-rotation provides quantum-safe properties

1. The nt field specifies the next threshold (may differ from kt)
2. The n field contains an ordered list of next key digests (not a single XORed digest)
3. Rotation events may reveal only a subset of pre-committed keys
4. Both current and prior-next thresholds must be satisfied

CESR Encoding Considerations

Establishment events must be encoded using CESR with:

• Proper version strings including byte count
• Qualified cryptographic primitives with derivation codes
• Attached signatures in CESR format with appropriate framing codes
• Support for both text (JSON) and binary domains

Duplicity Detection Integration

Implementations should maintain mechanisms to detect duplicitous establishment events:

• Store first-seen versions of events at each sequence number
• Compare incoming events against stored versions
• Flag any discrepancies as potential duplicity
• Implement watcher networks for ambient duplicity detection

Performance Optimization

For high-performance implementations:

• Cache computed key states to avoid repeated establishment event processing
• Index KELs by sequence number for fast establishment event lookup
• Implement incremental key state updates rather than full recomputation
• Use efficient cryptographic libraries for signature verification

Error Handling

Implementations must handle various error conditions:

• Invalid field ordering
• Mismatched SAID values
• Threshold violations
• Invalid prior event references
• Witness threshold violations
• Invalid key derivation codes
• Malformed CESR encoding