Loading vLEI.wiki
Fetching knowledge base...
Fetching knowledge base...
This comprehensive explanation has been generated from 180 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.
The rot field is a JSON attribute used in KERI protocol messages to represent rotation events - establishment events that change the authoritative key state of an Autonomic Identifier (AID). The field's value contains a hash pointer (cryptographic digest) that creates a verifiable chain linking each rotation to its predecessor event, enabling cryptographic verification of the complete key management history.
Rotation events are fundamental to KERI's security model, enabling transferable identifiers that can maintain persistent control despite key compromise or planned key lifecycle management. Each rotation event:
rot fieldThis creates an append-only, cryptographically chained log where any tampering becomes immediately evident through broken hash chains.
The rotation mechanism implements KERI's innovative pre-rotation scheme, where each rotation event includes a cryptographic digest of the next rotation keys. This provides:
A critical architectural role of rotation events is anchoring Transaction Event Logs (TELs) to KELs. All TEL events (which track credential issuance/revocation state) must be anchored to a KEL through either:
This anchoring provides the cryptographic foundation for verifiable credential protocols built on KERI, as credential state changes inherit the security properties of the underlying KEL.
Rotation events contain:
p field): Creates backward chainingk field): New authoritative signing keysn field): Pre-rotation commitmentkt, nt fields): Signature requirementswt, wr, wa fields): Witness managementImplementations MUST verify that the p (prior) field in each rotation event contains the correct digest of the previous establishment event. This backward chaining is essential for detecting tampering or duplicitous event histories.
When processing a rotation event, validators MUST:
k) match the pre-rotated key digests (n) from the prior establishment eventkt) and prior next threshold (nt)Rotation events can modify witness configuration through:
bt: New witness thresholdbr: Witnesses to remove (rotation)ba: Witnesses to addImplementations must handle witness set changes atomically with key rotation to maintain security guarantees.
KERI supports partial rotation where only a threshold-satisfying subset of pre-rotated keys participates. Implementations must validate both:
When rotation events include seals in the a (anchors) field, implementations must:
Out-of-order rotation events should be placed in escrow until:
This ensures the KEL remains internally consistent and verifiable.