Loading vLEI.wiki
Fetching knowledge base...
Fetching knowledge base...
This comprehensive explanation has been generated from 19 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.
A specialized Transaction Event Log (TEL) that signals the creation of a Virtual Credential Registry (VCR) and tracks the list of Registrars that act as [Backers](/concept/backer) for individual [VC TELs](/concept/[virtual-credential-transaction-event-log](/concept/virtual-credential-transaction-event-log "A transaction event log TEL that tracks the issued or revoked state of individua...")), providing the governance and infrastructure layer for KERI-based credential registries.
A management transaction event log (management TEL) is a foundational data structure within KERI's verifiable credential infrastructure that operates at the registry governance level. Unlike individual credential TELs that track specific credential states, the management TEL establishes and maintains the infrastructure layer for an entire credential registry ecosystem.
The management TEL serves two critical functions as documented in Document 3 and Document 4:
This two-tier architecture separates concerns between registry governance (management TEL) and individual credential state tracking (VC TEL), enabling scalable credential management while maintaining cryptographic verifiability.
Implementations MUST ensure that every management TEL event is properly anchored to the controlling KEL:
Digest Computation: Use the same cryptographic hash function (typically Blake3-256) for computing management TEL event digests as used in the controlling KEL
Event Source Seal Placement: Event source seals MUST be placed in KEL events (interaction or rotation events) that are signed by the current authoritative keys
Seal Verification: Validators MUST verify that the digest in the event source seal matches the recomputed digest of the management TEL event
Signature Verification: The KEL event containing the seal MUST have valid signatures from the controller's authoritative keys at that sequence number
Registrar Identifier Validation: All Registrar identifiers in the management TEL MUST be valid KERI AIDs. Implementations should:
Rotation Coordination: When implementing Registrar rotations:
Event Serialization: Management TEL events should be serialized using canonical JSON (RFC 8785) before computing digests to ensure consistent digest values across implementations
Attachment Handling: Event source seal attachments use CESR group codes:
-GAB for event source seal triplesMonotonic Increment: Management TEL sequence numbers MUST increment monotonically. Implementations should:
The management TEL inherits the core structural properties of all Transaction Event Logs within KERI:
Event-Based Architecture: Like all TELs, the management TEL is an append-only log of events, each cryptographically anchored to a controlling Key Event Log (KEL). This anchoring mechanism ensures that all registry operations are authorized by valid key states of the registry controller.
Hash-Linked Chain: Events within the management TEL form a hash-linked data structure where each event contains a cryptographic digest of the previous event, creating an immutable audit trail of registry governance changes.
KEL Anchoring: According to Document 3, TEL events do not require their own signatures. Instead, authenticity derives from:
This design means validators verify the authoritative state of a management TEL by validating signatures on the referenced KEL, not on the TEL events themselves.
The management TEL contains several critical components:
Registry Identifier: A unique identifier for the Virtual Credential Registry being managed. This identifier distinguishes one registry from another within the broader KERI ecosystem.
Registrar List: The authoritative list of identifiers that serve as Registrars (Backers) for the registry. As noted in Document 11, "Registrars are analogous to Backers in KERI KELs, and Registrar lists are analogous to Backer lists in KERI KELs."
Rotation Capability: The Registrar list can be rotated through specific management TEL events, allowing the registry controller to add, remove, or replace Registrars as operational needs change. This provides operational flexibility while maintaining cryptographic integrity.
Event Source Seals: Each management TEL event is anchored to the controlling KEL through event source seals, which are delivered as attachments in the form of event source seal triples (sequence number and digest pairs).
According to Document 3, all TEL events share common fields with KEL events:
i (Identifier): The identifier for the management TEL itself. This is the registry identifier that distinguishes this management TEL from others.
s (Sequence Number): Represents the "clock" for the management TEL's transaction set. Unlike KEL sequence numbers that strictly follow event ordering, TEL sequence numbers can represent different timing mechanisms. For credential registries, this is typically a monotonically increasing integer, but the specification allows for alternative clocks like Bitcoin block height or wall clock time.
t (Event Type): Specifies the type of management TEL event. Document 4 defines several event types for verifiable credential registries:
vcp (VDR Inception): Verifiable Data Registry inception event that creates the management TELvrt (VDR Rotation): Verifiable Data Registry rotation event that updates the Registrar listRegistrar List Fields: The management TEL must contain fields that specify:
Management TEL events are encoded using CESR (Composable Event Streaming Representation), which provides:
Dual Text-Binary Encoding: Events can be represented in either text domain (Base64 URL-safe) or binary domain, with full round-trip conversion capability between domains.
Self-Framing Primitives: All cryptographic primitives (digests, signatures, identifiers) within the management TEL are self-framing, meaning they include derivation codes that specify their type and length, enabling stream parsing without external schema information.
Composability: Multiple management TEL events can be concatenated into streams that maintain their individual integrity while supporting efficient batch processing.
As documented in Document 3, event source seals that anchor management TEL events to the controlling KEL have the JSON structure:
{
"s": "3",
"d": "ELvaU6Z-i0d8JJR2nmwyYAZAoTNZH3UfSVPzhzS6b5CM"
}
Where:
s is the sequence number of the KEL event providing the anchord is the digest of the management TEL event being anchoredThese seals are delivered as attachments in CESR format:
-GAB
0AAAAAAAAAAAAAAAAAAAAAAw
ELvaU6Z-i0d8JJR2nmwyYAZAoTNZH3UfSVPzhzS6b5CM
The -GAB prefix is a CESR group framing code indicating an event source seal triple attachment follows.
Event Size: Management TEL events are relatively compact, containing primarily:
Registrar List Constraints: While the specification does not mandate a maximum number of Registrars, practical considerations suggest:
Sequence Number Range: The s field uses a monotonically increasing integer for credential registries, providing effectively unlimited sequence space (64-bit integers support over 18 quintillion events).
Registry Inception Process:
Controller Decision: The controller of a KEL decides to create a verifiable credential registry
Management TEL Inception Event Creation:
vcp (VDR inception)Digest Generation: Create a cryptographic hash digest of the serialized management TEL inception event
KEL Anchoring:
Publication: Distribute the management TEL inception event along with the anchoring KEL event to Registrars and other interested parties
This process establishes the Virtual Credential Registry and designates the initial set of Registrars who will provide backing services for individual VC TELs.
Registrar Rotation:
The primary update operation for management TELs is rotating the Registrar list. According to Document 11, "Registrars can be rotated with events specific to a certain type of TEL."
The rotation process follows a similar pattern to inception:
Create Rotation Event:
vrt (VDR rotation)Anchor to KEL:
Propagate Changes: Notify affected parties (old and new Registrars, credential holders, verifiers) of the Registrar list change
Operational Considerations:
Management TEL Validation Process:
Validators verify management TEL authenticity through the following steps:
Retrieve Management TEL Events: Obtain the sequence of management TEL events from Registrars or other sources
Retrieve Controlling KEL: Obtain the KEL that controls the registry identifier
Verify KEL Integrity:
Verify TEL Anchoring:
Verify TEL Hash-Chaining:
Validate Registrar List:
As noted in Document 3, "Validators can verify the authoritative state of any TEL by validating the signatures on the referenced KEL." This means the security of the management TEL derives entirely from the security of the controlling KEL.
Duplicity Detection:
KERI's ambient duplicity detection extends to management TELs:
The management TEL is a core component of several KERI-based protocols:
Public Transaction Event Log (PTEL) Protocol: As defined in Document 4, the PTEL specification establishes management TELs as the foundation for public verifiable credential registries. The PTEL protocol defines:
vLEI Ecosystem: The verifiable Legal Entity Identifier (vLEI) ecosystem, governed by GLEIF, uses management TELs to establish credential registries for:
Each Qualified vLEI Issuer (QVI) operates a management TEL to govern their credential issuance infrastructure.
ACDC Issuance and Revocation: Authentic Chained Data Containers (ACDCs) that require public verifiability of issuance and revocation state use management TELs to establish the registry infrastructure. The management TEL designates which Registrars will maintain VC TELs for individual ACDCs.
Inception Phase:
Operational Phase:
Evolution Phase:
Termination Phase:
Key Event Log (KEL):
The management TEL is fundamentally dependent on its controlling KEL. As stated in Document 17, "The registry is fundamentally anchored to the controller's KEL, establishing the cryptographic root of trust for all credential state information tracked by the registry."
The KEL provides:
Virtual Credential Transaction Event Log (VC TEL):
Each individual credential tracked by the registry has its own VC TEL. According to Document 6, the VC TEL "contains a reference to the corresponding management transaction event log."
This reference linkage means:
Registrar Infrastructure:
Registrars listed in the management TEL function as Backers for the registry. They:
Virtual Credential Registry (VCR):
The management TEL signals the creation of the Virtual Credential Registry, which is the logical registry structure encompassing:
The VCR is not a separate data structure but rather the conceptual entity that the management TEL brings into existence and governs.
Separation of Concerns:
The two-tier TEL architecture (management TEL + VC TELs) provides important separation:
This separation allows:
Delegated Authority:
The management TEL enables a form of delegated authority:
Scalability Through Indirection:
By separating registry governance (management TEL) from individual credential tracking (VC TELs), the architecture scales efficiently:
Registrar Selection:
Controllers must carefully select Registrars for their management TEL:
Registrar Coordination:
Management TEL operations require coordination among Registrars:
Privacy Considerations:
As noted in Document 4, "This document addresses public VCs only. The use of hash digests of VC contents allows for correlation of VC uses."
This means:
Governance Integration:
Management TELs should integrate with broader governance frameworks:
The vLEI Ecosystem Governance Framework provides an example of how management TELs integrate with comprehensive governance structures for credential ecosystems.
Clock Independence: While credential registries typically use simple integer sequences, implementations should support alternative clock mechanisms (Bitcoin block height, wall clock) for future extensibility
Caching Strategies: Verifiers should cache:
Batch Verification: When verifying multiple credentials from the same registry:
Missing Anchors: If a management TEL event's anchoring KEL event cannot be found:
Registrar Unavailability: If Registrars listed in the management TEL are unavailable:
Duplicity Detection: If conflicting management TEL versions are detected:
Reference Validation: When processing VC TELs that reference a management TEL:
Registrar Rotation Handling: When a management TEL Registrar rotation occurs:
KEL Security Dependency: The security of a management TEL is entirely dependent on the security of its controlling KEL. Implementations should:
Registrar Trust Model: While Registrars don't have control authority, they do have operational influence:
Replay Attack Prevention: Management TEL events are protected against replay attacks through:
Unit Tests: Implement comprehensive unit tests for:
Integration Tests: Test interactions between:
Scenario Tests: Test specific scenarios:
Implementations should provide monitoring for:
This monitoring data is essential for maintaining reliable credential registry operations and detecting operational or security issues early.