Loading vLEI.wiki
Fetching knowledge base...
Fetching knowledge base...
This comprehensive explanation has been generated from 7 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.
An [AID](/concept/aid) (Autonomic Identifier) becomes abandoned when either its [inception event](/concept/[inception-event](/concept/inception-event "An inception event is the first establishment event in a KERI Key Event Log KEL ...")) or a subsequent [rotation event](/concept/[rotation-event](/concept/rotation-event "A rotation event is an establishment event in KERI that transfers control author...")) sets the next key digest list (ndigers) to empty (zero) with a next threshold of 0, permanently terminating the identifier's transferability and preventing acceptance of any subsequent events.
An abandoned identifier in KERI represents a terminal state where an Autonomic Identifier (AID) is permanently rendered non-transferable through a specific cryptographic operation. This occurs when either an inception event or a rotation event sets the next key digest list to empty (ndigers = 0) while simultaneously setting the next threshold to 0.
This mechanism provides a cryptographically verifiable way to permanently terminate an identifier's lifecycle. The abandonment is not an error condition but a deliberate protocol operation that makes explicit that no future control authority can be established.
The abandonment condition requires two specific field values in an establishment event:
ndigers (next key digests): Must be set to zero, representing an empty listnt (next threshold): Must be set to 0Both conditions must be satisfied simultaneously. Neither field alone is sufficient to create the abandonment state. This dual requirement ensures that the abandonment is an explicit, intentional operation rather than a configuration error.
An AID can be abandoned at two points in its lifecycle:
At Inception: The identifier is created as abandoned from the start, effectively creating a non-transferable identifier. This is useful for ephemeral or single-use identifiers where future key rotation is never intended.
Implementations MUST validate that abandonment events satisfy both conditions:
ndigers (next key digest list) is empty: n: []nt: "0"Partial abandonment conditions (only one field set) MUST be rejected as invalid.
Implementations SHOULD:
The specification does not explicitly define whether interaction events can occur after abandonment. Implementations SHOULD:
When an identifier is abandoned, implementations MUST:
Witness implementations MUST:
When abandoning identifiers that serve as TEL registries or backers:
Applications SHOULD:
During Rotation: A previously transferable identifier is converted to abandoned state through a rotation event. The rotation itself is signed by the current authoritative keys according to the current signing threshold, but commits to no future keys through the empty ndigers field.
Once an AID is abandoned through this mechanism:
Key State Freezing: The identifier's key state becomes frozen. The current keys from the abandonment event remain in the derived key state, but with next keys set to empty and next threshold set to 0.
Event Rejection: Any event occurring after the abandonment event is not accepted by validators. The key event log cannot be extended beyond the abandonment point.
Permanent Non-Transferability: Control authority cannot be transferred or rotated to new key pairs. The identifier becomes immutable from the abandonment point forward in its event history.
Verifiable Termination: All validators (witnesses, watchers, verifiers) can independently verify the abandonment state by processing the KEL and observing the empty ndigers and zero nt fields.
Abandoned identifiers should be distinguished from:
Non-transferable identifiers: While an abandoned identifier becomes non-transferable, a non-transferable identifier may have been created without pre-rotation capability from inception. Abandonment is a specific terminal state with explicit empty next key commitments.
Key compromise: A compromised key represents a security failure where keys are lost or stolen. An abandoned identifier is a deliberate protocol operation to terminate the identifier.
Revocation: Typically applies to credentials or authorizations derived from an identifier, not the identifier itself. Abandonment terminates the identifier's ability to participate in any future protocol operations.
Critically, abandonment does not delete or invalidate the historical KEL. All previous events in the log remain valid and verifiable. The abandonment operation adds a new event to the KEL that signals the terminal state. This preserves the complete audit trail and provenance of the identifier while making clear that its lifecycle has ended.
For detailed implementation discussion and edge cases, see the KERIpy GitHub discussion #821, which provides technical analysis of how abandoned identifiers are processed and validated in the reference implementation.
Implementations MUST test:
For systems managing large numbers of identifiers:
Implementations MUST: