Architectural Position

The VCTEL operates within a two-tier TEL architecture as described in Document 13 and Document 14:

• Management TEL Layer: Operates at the registry level, signaling the creation of the Virtual Credential Registry (VCR) and tracking the list of Registrars who act as backers for individual credential TELs
• VC TEL Layer: Operates at the individual credential level, with each verifiable credential having its own dedicated VCTEL that tracks its specific lifecycle state changes

This hierarchical structure enables scalable credential management while maintaining cryptographic verifiability throughout the credential lifecycle. The VCTEL is tightly coupled with KERI's Key Event Log infrastructure, ensuring that all credential operations are authorized by valid key states and that credential state changes are cryptographically anchored.

Purpose and Role

The VCTEL serves as the authoritative record for credential status changes throughout a credential's lifecycle. As noted in Document 2, by maintaining issued and revoked states, it enables credential status verification and supports the broader KERI credential registry infrastructure.

The VCTEL is a foundational component in KERI's verifiable credential infrastructure, working in conjunction with management TELs to provide a complete audit trail for credential lifecycle management. The VCTEL enables cryptographic proof of credential status through its integration with the broader KERI event log architecture, as described in Document 6.

Structural Organization

The VCTEL follows the general transaction event log structure within KERI, which is built upon the foundation of append-only verifiable data structures. According to Document 11, KERI's design philosophy emphasizes:

• Cryptographic strength: Minimum 128 bits entropy, quantum-safe considerations
• Strong bindings: Everything signed and committed, immutable by design
• Verifiable root-of-trust: No middlemen, direct cryptographic verification
• Minimized attack surface: Primitive reuse, simple designs

These principles apply directly to the VCTEL structure, ensuring that credential state changes are:

1. Cryptographically bound to the issuing AID's KEL
2. Immutable once recorded
3. Verifiable without requiring trust in intermediaries
4. Duplicity-evident through KERI's ambient verifiability properties

Key Components

While the source documents do not provide explicit field-level specifications for the VCTEL data structure, the architectural descriptions indicate the following key components:

1. Credential State Field: Records whether the credential is "issued" or "revoked"
2. Management TEL Reference: Cryptographic pointer to the corresponding management transaction event log
3. Event Anchoring: Mechanism for anchoring VCTEL events to the issuer's KEL through interaction events or rotation events
4. Registrar Backing: Association with Registrars who provide witnessing and persistence services

Data Format

Encoding and Serialization

As part of the KERI ecosystem, VCTELs utilize CESR (Composable Event Streaming Representation) encoding. According to Document 10, CESR provides:

• Dual text-binary encoding: Fully supports both textual and binary streaming applications
• Composability: Guaranteed property allowing future extensible support of new compositions
• Self-framing: Textual or binary encoding that begins with type, size, and value
• Optimized stream processing: Enables efficient processing in both binary and text domains

The VCTEL, as a transaction event log, inherits these encoding properties, ensuring that credential state changes can be efficiently streamed, stored, and verified across distributed systems.

Field Definitions

While explicit field schemas are not provided in the source documents, the functional requirements described in Document 1, Document 2, and Document 13 indicate that a VCTEL must contain:

1. Credential Identifier: Reference to the specific verifiable credential being tracked
2. State Indicator: Current state (issued/revoked)
3. Management TEL Reference: Cryptographic link to the governing management transaction event log
4. Event Sequence: Ordered log of state change events
5. Anchoring Information: References to KEL events that anchor the VCTEL state changes

Integration with KEL Structure

As documented in Document 13, the VCTEL is tied to KERI's identifier control structure through the controller's Key Event Log, which serves as the authoritative source for the issuing identifier's key state. This integration ensures that:

• All credential operations are authorized by valid key states
• Credential state changes are cryptographically anchored
• The entire system benefits from KERI's duplicity detection and ambient verifiability properties

According to Document 10, all TEL events are anchored in a KEL through either interaction events (ixn) or rotation events (rot). This anchoring mechanism is the foundation enabling a verifiable credential protocol to be built on top of KERI.

Size and Constraints

The source documents do not specify explicit size constraints for VCTELs. However, as append-only logs, VCTELs grow monotonically with each state change event. The use of CESR encoding ensures compact representation while maintaining verifiability.

Operations

Creation and Initialization

The creation of a VCTEL is initiated when a verifiable credential is issued. According to Document 15, the management transaction event log signals the creation of the Virtual Credential Registry (VCR) and tracks the list of Registrars that will act as backers for individual VCTELs.

The initialization process involves:

1. Registry Establishment: The management TEL creates the VCR infrastructure
2. Registrar Assignment: Registrars are designated to provide backing services for the VCTEL
3. Credential Issuance: An issuance event creates the initial VCTEL entry with state "issued"
4. KEL Anchoring: The issuance event is anchored to the issuer's KEL through an interaction event or rotation event
5. Management TEL Reference: The VCTEL records a cryptographic reference to its governing management TEL

Updates and Modifications

As an append-only log, the VCTEL does not support modification of existing entries. Instead, state changes are recorded as new events appended to the log. The primary state change operation is revocation:

1. Revocation Event: A revocation event is created to change the credential state from "issued" to "revoked"
2. KEL Anchoring: The revocation event is anchored to the issuer's KEL
3. Registrar Witnessing: Registrars acting as backers witness and store the revocation event
4. State Update: The VCTEL's current state is updated to "revoked"

According to Document 10, KERI follows a RUN model (Read, Update, Nullify) rather than the traditional CRUD model. In the context of VCTELs:

• Read: Query the current state of a credential
• Update: Append new state change events (issuance, revocation)
• Nullify: Mark credentials as revoked (rather than deleting them)

This approach ensures that the complete history of credential state changes is preserved and verifiable.

Verification and Validation

Verification of a VCTEL involves multiple layers of cryptographic validation:

1. KEL Verification: Verify the issuer's KEL to establish the current key state and ensure the issuing AID is valid
2. Anchoring Verification: Verify that VCTEL events are properly anchored to the issuer's KEL through seals in interaction events or rotation events
3. Management TEL Verification: Verify the reference to the management TEL and ensure the VCTEL is part of a valid registry
4. Registrar Verification: Verify receipts from Registrars acting as backers
5. Event Sequence Verification: Verify the integrity of the append-only log structure
6. Signature Verification: Verify digital signatures on all events using the issuer's authoritative keys

As noted in Document 11, KERI's design philosophy emphasizes verifiable root-of-trust with no middlemen in the verification chain. This principle applies directly to VCTEL verification, enabling validators to independently verify credential status without relying on trusted third parties.

Duplicity Detection

KERI's ambient duplicity detection mechanisms apply to VCTELs. If an issuer attempts to create conflicting versions of a VCTEL (e.g., issuing and revoking the same credential simultaneously), watchers and validators can detect this duplicity by comparing event logs. The first-seen policy ensures that the first valid version of an event is considered authoritative.

Usage Context

Integration with KERI Protocol

The VCTEL is a core component of KERI's verifiable credential infrastructure. According to Document 10, the anchoring of TEL events to KELs is the foundation enabling a verifiable credential protocol to be built on top of KERI.

The VCTEL operates within the broader KERI ecosystem, which includes:

• KEL: Provides the root-of-trust for issuer identities
• ACDC: Defines the structure of verifiable credentials
• CESR: Provides encoding and streaming capabilities
• OOBI: Enables discovery of VCTEL endpoints
• IPEX: Facilitates credential issuance and presentation exchanges

Lifecycle Management

The VCTEL tracks the complete lifecycle of a verifiable credential:

1. Issuance: Initial creation of the VCTEL with state "issued"
2. Active Period: Credential remains in "issued" state and can be presented and verified
3. Revocation: State changes to "revoked" through a revocation event
4. Post-Revocation: Credential remains in "revoked" state indefinitely (append-only property)

As noted in Document 10, there is a concept of ghost credentials - valid credentials within a 90-day grace period (the revocation transaction time frame) before being recorded in the revocation registry. This suggests that VCTEL state changes may have temporal considerations for finality.

Role in Public Verifiable Credential Registry

According to Document 13 and Document 14, the VCTEL is part of a public verifiable credential registry - a form of Verifiable Data Registry that tracks the issuance/revocation state of credentials issued by the controller of a KEL.

The two-tier architecture consists of:

1. Management TEL: Registry-level infrastructure tracking Registrars
2. VC TEL: Individual credential-level state tracking

This architecture enables:

• Scalability: Each credential has its own VCTEL, avoiding monolithic registry bottlenecks
• Distributed Verification: Registrars as backers provide redundancy and availability
• Cryptographic Verifiability: All state changes are cryptographically anchored to KELs
• Ambient Duplicity Detection: Watchers can detect conflicting credential states

vLEI Ecosystem Application

The VCTEL is particularly important in the vLEI (verifiable Legal Entity Identifier) ecosystem. According to Document 10, the vLEI ecosystem uses VCTELs to track:

• Legal Entity vLEI Credentials: Credentials issued to legal entities
• OOR vLEI Credentials: Official Organizational Role credentials
• ECR vLEI Credentials: Engagement Context Role credentials

The GLEIF (Global Legal Entity Identifier Foundation) governance framework relies on VCTELs to provide cryptographic proof that credential information is verifiably authentic, accurate, and up-to-date.

Related Structures

The VCTEL is closely related to several other KERI data structures:

1. Management TEL: Governs the registry infrastructure and tracks Registrars
2. KEL: Provides the root-of-trust for issuer identities and anchors VCTEL events
3. KERL: Key Event Receipt Log that includes witness receipts
4. ACDC: Authentic Chained Data Container that defines credential structure
5. TEL: General transaction event log structure

Registrar and Backer Roles

As described in Document 15, Registrars designated in the management TEL serve as backers - entities that maintain copies of and provide verification services for individual VCTELs. This backing mechanism ensures the availability and verifiability of credential state information across the distributed system.

Registrars function similarly to witnesses in KERI KELs, providing distributed verification and redundancy for credential state tracking. According to Document 10, a backer is an alternative to a traditional KERI-based witness, commonly using Distributed Ledger Technology (DLT) to store the KEL for an identifier. However, in the VCTEL context, backers provide similar witnessing services for transaction event logs.

Security and Trust Properties

Cryptographic Foundations

According to Document 11, KERI's design philosophy establishes an unwavering hierarchy: Security → Confidentiality → Privacy, with security being non-negotiable at the foundational level. This manifests in VCTELs through:

• Cryptographic strength: Minimum 128 bits entropy, quantum-safe considerations
• Strong bindings: All events signed and committed, immutable by design
• Verifiable root-of-trust: No middlemen, direct cryptographic verification
• Proven cryptography: Long-standing, well-tested cryptographic functions
• Minimized attack surface: Primitive reuse, simple designs

End-Verifiability

The VCTEL inherits KERI's end-verifiability properties. As noted in Document 10, when a log is end-verifiable, it means that the log may be verified by any end user that receives a copy. No trust in intervening infrastructure is needed to verify the log and validate the content.

This property is critical for VCTELs because it enables:

• Independent verification: Validators can verify credential status without trusting registries or intermediaries
• Portability: Credential status can be verified across different systems and contexts
• Resilience: Verification does not depend on the availability of specific infrastructure

Duplicity Evidence

KERI's duplicity-evident properties apply to VCTELs. According to Document 10, duplicity refers to the existence of more than one version of a verifiable KEL for a given AID. In the VCTEL context, duplicity would involve conflicting credential state claims (e.g., simultaneously issued and revoked).

KERI's ambient duplicity detection mechanisms enable anyone, anywhere, at any time to detect such duplicity by comparing event logs from different sources. This provides strong protection against malicious issuers attempting to manipulate credential status.

Implementation Considerations

Storage and Persistence

VCTELs must be stored in a manner that preserves their append-only properties and enables efficient verification. Registrars acting as backers provide distributed storage and redundancy.

Performance and Scalability

The two-tier architecture (management TEL + individual VCTELs) enables horizontal scalability. Each credential has its own VCTEL, avoiding the bottlenecks associated with monolithic credential registries.

Interoperability

The use of CESR encoding ensures that VCTELs can be efficiently exchanged between different KERI implementations and integrated with other systems that support CESR.

Privacy Considerations

While VCTELs provide transparency for credential status, they must be designed to minimize privacy leakage. According to Document 11, KERI acknowledges the security-confidentiality-privacy trillema (Smith's Triangle), where complete security, confidentiality, and privacy cannot be achieved simultaneously. KERI's approach prioritizes security at the foundational level while building privacy-preserving mechanisms on top.

For VCTELs, this means:

• Public verifiability: Credential status must be verifiable to prevent fraud
• Selective disclosure: Credential content can be selectively disclosed using ACDC mechanisms
• Blinded registries: Some VCTEL implementations may use blinded revocation registries where state is only revealed upon presentation

Governance and Policy

The vLEI ecosystem demonstrates how VCTELs can be governed through formal frameworks. According to Document 10, the vLEI Ecosystem Governance Framework defines information security, privacy, availability, confidentiality, and processing integrity policies that apply to all vLEI ecosystem members.

Conclusion

The virtual credential transaction event log (VCTEL) is a critical component of KERI's verifiable credential infrastructure, providing cryptographically verifiable tracking of credential lifecycle states. By leveraging KERI's foundational properties - end-verifiability, duplicity detection, and append-only logs - VCTELs enable scalable, secure, and privacy-preserving credential status management without relying on centralized authorities or trusted intermediaries.

The two-tier architecture (management TEL + individual VCTELs) provides the organizational structure needed for large-scale credential registries, while the anchoring to KELs ensures that all credential operations are cryptographically bound to valid issuer identities. This design enables the vision of a truly decentralized, verifiable credential ecosystem where credential status can be independently verified by any party without requiring trust in intermediaries.

• Blinded revocation registries where state is only revealed upon presentation
• Selective disclosure of credential attributes using ACDC mechanisms
• Minimizing correlation risks through careful identifier management

Performance Optimization

For large-scale deployments:

• Implement efficient indexing for credential status queries
• Use caching mechanisms for frequently accessed VCTELs
• Consider sharding strategies for management TELs governing large numbers of credentials
• Optimize CESR stream processing for high-throughput scenarios

Error Handling

Implementations MUST handle various error conditions:

• Invalid KEL anchoring
• Missing or invalid management TEL references
• Insufficient registrar confirmations
• Append-only integrity violations
• Signature verification failures

Testing and Validation

Implementations SHOULD include comprehensive test suites covering:

• VCTEL creation and initialization
• State change operations (issuance, revocation)
• Multi-layer verification workflows
• Duplicity detection scenarios
• Interoperability with other KERI components

Governance Integration

For ecosystems like vLEI, implementations must integrate with governance frameworks that define:

• Authorized issuers and their roles
• Credential schemas and validation rules
• Registrar qualification requirements
• Audit and compliance procedures