• Current keys (k): Array of qualified public keys for signing
• Current threshold (kt): Signature threshold for current operations
• Next key digests (n): Cryptographic commitments to pre-rotated keys
• Next threshold (nt): Signature threshold for next rotation
• Witness identifiers (b): Array of witness AIDs
• Witness threshold (bt): Minimum witness receipts required
• Configuration traits (c): Operational mode flags

Key Components

The inception event integrates several critical components:

Self-Certifying Identifier Derivation: For basic self-certifying identifiers, the AID prefix is derived directly from the initial public key(s) using a one-way cryptographic function. For self-addressing identifiers, the prefix is derived from a digest of the entire inception event content, creating a self-referential structure.

Pre-rotation Mechanism: The n field contains cryptographic digests (typically Blake3-256) of the next rotation keys. This forward commitment enables KERI's post-quantum secure key rotation by hiding the actual next keys while cryptographically binding them to the inception event.

Witness Configuration: The b array specifies witness AIDs, while bt defines the threshold of accountable duplicity (TOAD). This establishes the distributed consensus infrastructure for the identifier from inception.

Configuration Traits: The c array contains flags that define operational characteristics such as whether the identifier is transferable, whether it supports delegation, and other protocol-level behaviors.

Data Format

Field Definitions

The inception event uses a precisely defined field structure with mandatory ordering:

{
  "v": "KERI10JSON000188_",
  "t": "icp",
  "d": "EL1L56LyoKrIofnn0oPChS4EyzMHEEk75INJohDS_Bug",
  "i": "EL1L56LyoKrIofnn0oPChS4EyzMHEEk75INJohDS_Bug",
  "s": "0",
  "kt": "1",
  "k": ["DPmhSfdhCPxr3EqjxzEtF8TVy0YX7ATo0Uc8oo2cnmY9"],
  "nt": "1",
  "n": ["EQb3h4JWfzMXKnIjLGhyU0Q7Qw6HYKqVVVKLLLLLLLLL"],
  "bt": "2",
  "b": ["BFUOWBaJz-sB_6b-_u_P9W8hgBQ8Su9mAtN9cY2sVGiY",
        "BDg1zxxf8u4Hx5IPraZzmStfSCZFZbDzMHjqVcFW5OfP"],
  "c": [],
  "a": []
}

Version String (v): The version string follows the format KERI{version}{serialization}{size}_ where:

• KERI10 indicates KERI protocol version 1.0
• JSON specifies JSON serialization
• 000188 is the hexadecimal size of the serialized event
• _ is the terminator character

Event Type (t): Always "icp" for inception events, distinguishing them from rotation ("rot") and interaction ("ixn") events.

Digest (d): A qualified cryptographic digest (SAID) of the entire event. For self-addressing identifiers, this matches the i field. The digest is computed after replacing the d field with placeholder characters of appropriate length.

Identifier (i): For self-addressing identifiers, this is identical to d. For basic self-certifying identifiers, it's derived from the public key in k. The derivation code prefix (e.g., E for Ed25519) indicates the cryptographic algorithm.

Sequence Number (s): Always "0" for inception, establishing this as the first event in the KEL.

Current Threshold (kt): String representation of the signature threshold. Can be:

• Simple integer: "1" requires one signature
• Fractional weights: "1/2" requires signatures totaling 1/2 weight
• Complex thresholds: ["1/2", "1/2", "1/4"] for weighted multi-sig

Current Keys (k): Array of qualified public keys in CESR format. Each key includes a derivation code prefix indicating the key type (e.g., D for Ed25519 public key).

Next Threshold (nt): Signature threshold for the next rotation event, following the same format as kt.

Next Key Digests (n): Array of qualified cryptographic digests of the next rotation keys. These digests hide the actual next keys while cryptographically committing to them.

Witness Threshold (bt): String representation of the minimum number of witness receipts required. This implements the threshold of accountable duplicity (TOAD).

Witness Identifiers (b): Array of witness AIDs in qualified format. These witnesses will receipt events and provide distributed validation.

Configuration Traits (c): Array of configuration flags. Common traits include:

• "EO": Establishment-only (no interaction events)
• "DND": Do not delegate (prevents delegation)

Anchors (a): Array of seals anchoring external data. Typically empty for inception events.

Encoding Format

KERI supports multiple serialization formats through CESR:

JSON Serialization: Human-readable text format using UTF-8 encoding. Field order is significant and must be preserved. The version string indicates JSON with KERI10JSON.

CBOR Serialization: Binary format using Concise Binary Object Representation. More compact than JSON while maintaining the same logical structure. Version string uses KERI10CBOR.

MGPK Serialization: Binary format using MessagePack. Similar compactness to CBOR with different encoding characteristics. Version string uses KERI10MGPK.

CESR Native: Fully qualified primitives in composable event streaming representation. Enables efficient streaming and parsing without delimiters.

All formats maintain semantic equivalence and support round-trip conversion without information loss.

Size and Constraints

Version String Size: Fixed at 17 characters for KERI 1.0, encoding protocol version, serialization type, and event size.

Identifier Length: Typically 44 characters for Base64 URL-safe encoding of 256-bit keys/digests, including the derivation code prefix.

Key Array Constraints: The number of keys in k must align with the threshold specified in kt. For weighted thresholds, the number of keys must match the number of weight specifications.

Digest Array Constraints: The number of digests in n must align with the next threshold nt. Each digest represents one next key.

Witness Array Constraints: The witness threshold bt must be achievable given the number of witnesses in b. Typically bt <= len(b).

Sequence Number: Must be exactly "0" for inception. Any other value invalidates the event as an inception.

Operations

Creation and Initialization

Creating an inception event involves a multi-step process:

1. Key Generation: Generate the initial keypair(s) using cryptographically secure random number generation. For Ed25519, this involves:

• Generating 32 bytes of entropy for the seed
• Deriving the private key from the seed
• Computing the public key from the private key

2. Next Key Generation: Generate the next (pre-rotated) keypair(s) and compute their digests:

• Generate next keypair(s) using separate entropy
• Store next private keys securely (separate from current keys)
• Compute Blake3-256 digests of next public keys
• Encode digests with appropriate derivation codes

3. Witness Selection: Choose witness AIDs and threshold:

• Select witnesses from available witness pools
• Determine TOAD value based on security requirements
• Ensure witness threshold is achievable

4. Event Construction: Build the inception event structure:

• Populate all required fields
• Set sequence number to "0"
• Set event type to "icp"
• Leave d and i fields as placeholders initially

5. Identifier Derivation:

For self-addressing identifiers:

• Replace d field with # characters of appropriate length
• Serialize the event
• Compute cryptographic digest of serialized event
• Replace d field with computed digest
• Set i field to same value as d

For basic self-certifying identifiers:

• Derive identifier from public key in k
• Set i field to derived identifier
• Compute digest for d field separately

6. Signing: Sign the complete event with current private key(s):

• Serialize the finalized event
• Generate signature(s) using current private key(s)
• Attach signatures as CESR-encoded primitives

7. Witness Receipting: Publish to witnesses for receipting:

• Transmit signed inception event to designated witnesses
• Collect witness receipts (signatures from witnesses)
• Store receipts in Key Event Receipt Log (KERL)

Updates and Modifications

Inception events are immutable once created and published. They cannot be updated or modified. Any change to an inception event creates a different identifier entirely.

However, the key state established by the inception event can be changed through subsequent rotation events. The inception event establishes:

• Initial current keys (can be rotated)
• Initial next key commitments (revealed during first rotation)
• Initial witness configuration (can be modified through rotation)
• Initial thresholds (can be changed through rotation)

The inception event itself remains unchanged in the KEL, serving as the permanent genesis record.

Verification and Validation

Verifying an inception event involves multiple validation steps:

1. Structural Validation:

• Verify version string format and protocol version
• Confirm event type is "icp"
• Verify sequence number is "0"
• Check all required fields are present
• Validate field ordering matches specification

2. Cryptographic Validation:

For self-addressing identifiers:

• Extract the d field value
• Replace d field with # characters
• Serialize the event
• Compute digest of serialized event
• Verify computed digest matches extracted d value
• Verify i field matches d field

For basic self-certifying identifiers:

• Extract public key from k field
• Derive identifier from public key
• Verify derived identifier matches i field
• Verify d field digest is correct

3. Signature Validation:

• Extract attached signatures
• Verify signature count meets threshold kt
• Verify each signature using corresponding public key from k
• Confirm signatures are over the correct event content

4. Threshold Validation:

• Verify kt threshold is achievable with keys in k
• Verify nt threshold is achievable with digests in n
• Verify bt threshold is achievable with witnesses in b
• For weighted thresholds, verify weights sum correctly

5. Witness Validation:

• Verify witness AIDs in b are valid KERI identifiers
• Optionally verify witnesses are reachable
• Verify witness threshold bt is reasonable

6. Configuration Validation:

• Verify configuration traits in c are valid
• Check for conflicting configuration flags
• Validate configuration is appropriate for use case

7. Receipt Validation (for KERL):

• Verify witness receipts are present
• Verify receipt count meets bt threshold
• Verify each receipt signature is valid
• Confirm receipts reference correct event digest

Usage Context

In Which Protocols

The inception event is fundamental to multiple protocols in the KERI ecosystem:

KERI Core Protocol: The inception event is the foundational operation in KERI, required to create any AID. Every KEL begins with exactly one inception event.

ACDC (Authentic Chained Data Container): ACDC credentials reference issuer and issuee AIDs, which must be established through inception events. The credential's cryptographic binding depends on the issuer's KEL starting with a valid inception.

IPEX (Issuance and Presentation Exchange): IPEX message exchanges occur between AIDs established through inception events. The protocol relies on the cryptographic properties established at inception.

did:keri Method: The DID document for a did:keri identifier is derived from the key state established by the inception event. The DID itself is constructed from the AID prefix created at inception.

did:webs Method: Similar to did:keri, did:webs DIDs are anchored to KERI identifiers created through inception events, with the KEL providing the verifiable history.

Transaction Event Logs (TEL): TELs for credential registries are controlled by AIDs established through inception events. The registry's authority derives from the controlling identifier's inception.

Lifecycle Management

The inception event marks the beginning of an identifier's lifecycle:

Creation Phase: The inception event creates the identifier and establishes its initial state. This is the only time the identifier comes into existence.

Operational Phase: After inception, the identifier can be used for:

• Signing statements and credentials
• Issuing ACDCs
• Participating in IPEX exchanges
• Anchoring external data through interaction events
• Rotating keys through rotation events

Key Rotation Phase: The pre-rotation commitments in the inception event enable the first key rotation. Subsequent rotations continue the chain of pre-rotation commitments.

Delegation Phase (if applicable): If the identifier supports delegation (not flagged with "DND"), it can delegate authority to other identifiers through delegated inception events.

Abandonment Phase: An identifier can be abandoned by rotating to an empty next key digest list with threshold zero. After abandonment, no further events are accepted.

Archival Phase: Even after abandonment, the inception event and complete KEL remain as a permanent historical record, enabling verification of past statements and credentials.

Related Structures

The inception event interacts with numerous KERI data structures:

Key Event Log (KEL): The inception event is the first entry in the KEL. All subsequent events reference back to the inception through the hash chain.

Key Event Receipt Log (KERL): The KERL includes the inception event plus witness receipts, providing distributed validation of the identifier's creation.

Rotation Events: Rotation events reveal the next keys committed to in the inception event's n field, and establish new next key commitments.

Interaction Events: Interaction events anchor external data to the key state established by the inception event (and modified by subsequent rotations).

Delegated Inception Events: When an identifier delegates authority, the delegate's inception event includes a reference to the delegator's AID, creating a delegation chain.

Key State: The inception event establishes the initial key state, which includes current keys, next key commitments, witness configuration, and thresholds.

Witness Receipts: Witnesses receipt the inception event, providing independent validation of the identifier's creation and initial configuration.

ACDC Credentials: ACDCs reference issuer AIDs in their i field, linking to the issuer's inception event and KEL for verification.

Transaction Event Logs (TEL): TEL events are anchored to KEL events through seals, with the KEL's inception event establishing the controlling authority for the registry.

OOBI (Out-of-Band Introduction): OOBIs provide discovery mechanisms for AIDs, enabling validators to locate and retrieve the inception event and complete KEL.

Implementation Considerations

Implementing inception event creation and validation requires careful attention to:

Entropy Quality: The security of the entire identifier depends on the quality of randomness used to generate the initial and next keypairs. Use cryptographically secure random number generators.

Key Storage: Current private keys must be stored securely but accessibly for signing. Next private keys should be stored with even higher security, potentially offline or in cold storage.

Witness Selection: Choose witnesses carefully based on:

• Reliability and availability
• Geographic and jurisdictional diversity
• Independence from each other
• Reputation and trustworthiness

Threshold Configuration: Set thresholds based on security requirements:

• Higher thresholds provide more security but reduce availability
• Consider fault tolerance (F) when setting witness threshold
• Ensure thresholds are achievable in practice

Serialization Consistency: Maintain consistent field ordering and serialization to ensure digest computation is reproducible. Use canonical serialization libraries.

CESR Encoding: Properly encode all cryptographic primitives using CESR derivation codes. Incorrect encoding will cause verification failures.

Event Size Calculation: Accurately compute and encode the event size in the version string. Size mismatches will cause parsing failures.

Signature Attachment: Attach signatures in the correct CESR format with appropriate count codes and framing. Improper attachment prevents verification.

Witness Communication: Implement robust protocols for publishing events to witnesses and collecting receipts. Handle network failures and timeouts gracefully.

Validation Ordering: Perform validation steps in the correct order to fail fast on invalid events and avoid unnecessary computation.

Error Handling: Provide clear error messages for validation failures, indicating which specific check failed and why.

Performance Optimization: Cache validated inception events and their derived key states to avoid repeated validation overhead.

Testing: Thoroughly test inception event creation and validation with:

• Valid events of various configurations
• Invalid events with specific validation failures
• Edge cases (minimum/maximum thresholds, empty arrays, etc.)
• Different serialization formats
• Multi-signature scenarios
• Witness receipt collection

The inception event is the cornerstone of KERI's security model, and its correct implementation is essential for the integrity of the entire system.

Canonical Serialization: Use consistent serialization:

• Preserve field ordering exactly as specified
• No whitespace variations in JSON
• Consistent Unicode normalization
• Use standard library serializers when possible

Witness Configuration

Witness Selection Criteria:

• Availability: Choose witnesses with high uptime
• Geographic diversity: Distribute across regions/jurisdictions
• Independence: Avoid witnesses with common failure modes
• Reputation: Select established, trustworthy witnesses

Threshold Configuration:

• TOAD calculation: Set bt based on fault tolerance: bt >= N - F where N is total witnesses and F is maximum faults
• Typical values: For 3 witnesses, use bt=2; for 5 witnesses, use bt=3
• Availability trade-off: Higher thresholds increase security but reduce availability

Witness Communication:

• Implement retry logic for witness publication
• Handle network timeouts gracefully
• Collect receipts asynchronously
• Store receipts in KERL for verification

Validation Implementation

Validation Order (fail fast):

1. Version string format and protocol version
2. Event type is "icp"
3. Sequence number is "0"
4. Required fields present
5. Field types correct
6. Digest computation (most expensive)
7. Signature verification (most expensive)

Error Handling:

• Provide specific error messages for each validation failure
• Include field names and expected vs. actual values
• Log validation failures for debugging
• Return early on first failure to avoid unnecessary computation

Performance Optimization:

• Cache validated inception events and derived key states
• Use lazy evaluation for expensive operations
• Parallelize signature verification when multiple signatures present
• Pre-compute and cache witness AID lookups

Multi-Signature Considerations

Threshold Validation:

• Verify threshold is achievable: kt <= len(k)
• For weighted thresholds, verify weights sum correctly
• Ensure signature count meets threshold

Signature Collection:

• Collect signatures from all required parties
• Verify each signature independently
• Aggregate signatures in correct CESR format
• Use count codes for multi-signature attachments

Testing Requirements

Unit Tests:

• Valid inception events with various configurations
• Invalid events for each validation rule
• Edge cases (empty arrays, maximum thresholds)
• Different serialization formats (JSON, CBOR, MGPK)
• Self-addressing vs. basic self-certifying identifiers

Integration Tests:

• End-to-end identifier creation workflow
• Witness publication and receipt collection
• Multi-signature coordination
• Key rotation from inception commitments

Security Tests:

• Entropy quality verification
• Digest collision resistance
• Signature forgery attempts
• Replay attack prevention

Common Pitfalls

Incorrect Digest Computation: Failing to replace d field with placeholders before computing digest results in incorrect self-addressing identifiers.

Field Ordering: Changing field order breaks digest computation and signature verification. Always maintain canonical ordering.

Threshold Mismatches: Setting thresholds that cannot be satisfied (e.g., kt=3 with only 2 keys) creates unusable identifiers.

Witness Threshold Too High: Setting bt equal to total witnesses means any single witness failure prevents validation.

Insecure Key Storage: Storing private keys in plaintext or with weak encryption compromises the entire identifier.

Missing Receipts: Failing to collect witness receipts leaves the identifier without distributed validation.

Serialization Inconsistency: Using different serialization libraries or settings for creation vs. verification causes digest mismatches.