The W3C specification uses inclusive "and/or" language to indicate that different VDR implementations may provide different subsets of these capabilities. Importantly, the W3C definition explicitly extends beyond DIDs: "a verifiable data registry might also be used for other cryptographically-verifiable data structures such as verifiable credentials."

KERI Implementation: Transaction Event Logs

Architectural Foundation

In KERI, VDRs are implemented as Transaction Event Logs (TELs) - hash-linked data structures of transactions that track state anchored to a Key Event Log (KEL). This architecture provides several critical properties:

Cryptographic verifiability: All state changes are cryptographically bound to the controlling KEL through anchoring seals. As the PTEL specification states: "A KERI KEL controls a TEL" through a specific anchoring mechanism:

1. Create the TEL inception event with a TEL-specific unique identifier
2. Generate a hash digest of the serialized TEL inception event content
3. Attach anchoring seals from KEL events to the TEL events they authorize
4. Sign the KEL event to commit to the digest of the serialized TEL event

Duplicity evident: Conflicting registry states can be detected through KERI's duplicity detection mechanisms inherited from the KEL layer. Any attempt to create conflicting TEL states anchored to the same KEL will be detectable by validators.

Anchored trust: Registry events inherit the security properties of KERI identifiers through cryptographic seals. Notably, TEL events themselves do not require signatures - the commitment is established through the signed KEL event that includes the TEL event digest as a seal.

Two-Tier TEL Architecture

KERI employs a sophisticated two-tier TEL structure for credential lifecycle management:

Management TEL

The management TEL (also called management-TEL or MANAGEMENT-TEL) provides the registry foundation by:

• Signaling the creation of the Virtual Credential Registry (VCR) itself through a registry inception event
• Tracking the list of Registrars who act as backers for individual TELs associated with each verifiable credential
• Enabling rotation of the Registrar set through management-specific events
• Establishing governance for the entire credential registry under a controller's authority

The management TEL creates the authoritative structure that individual credential TELs reference for their operational backing and governance context.

VC TEL

The VC TEL (virtual credential transaction event log, also VCTEL or vctel) operates at the individual credential level to:

• Track the issued or revoked state of each specific verifiable credential
• Contain a reference to its corresponding management TEL, establishing the chain of authority
• Enable verification of credential status changes through cryptographically-linked event sequences
• Support lifecycle operations including issuance, revocation, and potentially transfer events

This separation of concerns enables scalable credential management where the management layer handles infrastructure governance while individual VC TELs handle credential-specific state transitions.

VDR Operation Types and Event Codes

The KERI protocol defines specific operation codes for VDR lifecycle management:

vcp (VDR inception): Stands for "vdr incept" or "verifiable data registry inception." This operation type initializes a new VDR instance, establishing its unique identifier and initial configuration.

vrt (VDR rotation): Stands for "vdr rotate" or "verifiable data registry rotation." This operation enables rotation of control over the registry, analogous to key rotation in KELs but applied to the registry governance layer.

These operation codes are part of KERI's message type nomenclature using CESR encoding, where short codes identify specific protocol operations within event streams.

Technical Implementation Details

CESR Encoding and Stream Processing

VDR events utilize CESR (Composable Event Streaming Representation) encoding throughout the KERI infrastructure. CESR provides:

Text-binary duality: Events can be represented in both human-readable Base64 text and compact binary formats with bidirectional conversion without loss.

Self-framing: Each primitive (cryptographic value) includes derivation codes that specify its type and length, enabling stream parsers to extract atomic elements without parsing entire messages.

Composability: Multiple primitives, groups, and nested structures can be concatenated and processed as unified streams, critical for efficient VDR query/response patterns.

The CESR encoding for VDR events follows the same patterns as KEL events, with version strings (e.g., "KERI10JSON"), event type codes, and cryptographic attachments all using CESR primitives.

Event Source Seals and Anchoring Mechanism

The cryptographic binding between KELs and TELs uses event source seals - a specific seal type that commits to external events. The anchoring process works as follows:

1. TEL event creation: A transaction event (issuance, revocation) is created with its unique identifier and state transition data
2. Digest computation: The serialized TEL event content is hashed using a cryptographic hash function (typically Blake3-256 in modern KERI implementations)
3. Seal attachment: An event source seal containing the TEL event digest is attached to a KEL event (either an interaction event ixn or rotation event rot)
4. KEL signature: The KEL event (including the seal) is signed by the controller's current signing keys
5. Validation path: Validators verify the TEL event by: (a) obtaining the KEL event containing the seal, (b) verifying KEL signatures against current key state, (c) computing the digest of the TEL event, (d) confirming digest match with the seal

This architecture means the security of the TEL is directly inherited from the KEL - any compromise of TEL integrity requires compromising the controlling KEL, which benefits from KERI's key pre-rotation and witness consensus mechanisms.

Registrars as Backer Infrastructure

Registrars serve as the witnessing/backing infrastructure for TELs, analogous to witnesses in KEL architecture. Key distinctions:

Witness vs Registrar roles:

• Witnesses provide receipts for KEL events, establishing distributed consensus on key state
• Registrars serve as backers for TEL events, providing persistence and availability for credential registry state

Rotation and governance: The management TEL can rotate its Registrar list through specific events, enabling dynamic infrastructure management without disrupting individual credential TELs.

Threshold configuration: Like witness thresholds, Registrar configurations support threshold requirements where a minimum number of Registrars must confirm TEL state for it to be considered authoritative.

Discovery and Resolution Mechanisms

The vLEI Ecosystem Governance Framework documents detail multiple discovery mechanisms for VDR endpoints:

Out-of-Band Introduction (OOBI)

OOBI provides the primary discovery mechanism, associating AIDs with URLs where VDR data can be accessed. For VDRs, OOBIs enable:

• Direct endpoint discovery: Mapping credential issuer AIDs to their TEL query endpoints
• Registrar discovery: Locating the network endpoints of Registrars backing a registry
• Witness discovery: Finding witnesses for the controlling KEL that anchors the VDR

Well-Known URIs

The governance framework specifies well-known URI patterns for standardized VDR endpoint discovery, enabling automated location of registry services without prior configuration.

Distributed Hash Table (DHT)

The framework references DHT-based discovery as a supplementary mechanism, leveraging distributed key-value storage for decentralized VDR endpoint resolution. This approach supports the "percolated discovery" model where endpoint information propagates through the network.

DID Resolution

For did:keri and did:webs identifiers, DID resolution provides an alternative discovery path where the DID document can include service endpoints pointing to VDR query interfaces.

GLEIF vLEI Ecosystem Context

The source documents reveal that GLEIF vLEI credentials represent a primary and extensively-documented use case for KERI VDRs:

QVI Credential Infrastructure

The Qualified vLEI Issuer (QVI) framework establishes rigorous VDR requirements:

Registry inception: QVIs must establish VDRs for tracking Legal Entity vLEI Credentials, OOR vLEI Credentials, and ECR vLEI Credentials.

Registrar requirements: The governance framework mandates minimum pools of 5 Registrars with mathematical consensus requirements using KERI's Agreement Algorithm for witness/Registrar consensus.

Access control: Registrars must maintain access control independence from controller keys to prevent poisoning attacks where a compromised controller could manipulate registry state.

Trust Assurance Framework

The vLEI Trust Assurance Framework maps VDR requirements across four pillars:

1. vLEI Ecosystem Governance Framework: High-level policy requirements for registry operations
2. ISO 20000 Certification: Service management standards applied to VDR infrastructure
3. vLEI Issuer Qualification Program: Specific technical and operational criteria for QVI registry services
4. vLEI Software Specifications: Implementation requirements for VDR query interfaces and data formats

GLEIF Root AID Delegation

The GLEIF External Delegated AID (GEDA) architecture demonstrates VDR delegation patterns:

• GLEIF maintains a root AID with maximum security (likely HSM-backed key management)
• GEDA serves as a delegated identifier from the GLEIF root, used for operational QVI authorization
• QVI credentials are tracked in VDRs anchored to GEDA's KEL
• This delegation enables GLEIF to authorize QVIs while maintaining root key security through limited exposure

Public vs Private VDR Architectures

Public VDR Limitations

The PTEL specification includes a critical scope limitation: "This document addresses public VCs only. The use of hash digests of VC contents as identifiers allows for correlation of VC uses, making this design unsuitable for private credential use cases."

Public VDRs using credential content digests as identifiers enable:

• Transparent verification: Any party can query registry state
• Auditability: Complete history of issuance/revocation is publicly verifiable
• Correlation risk: Multiple presentations of the same credential can be linked through its registry identifier

This makes public VDRs appropriate for:

• Organizational credentials (vLEI Legal Entity credentials)
• Public role credentials (OOR vLEI credentials with public officials)
• Supply chain credentials where transparency is desired

Blinded Revocation Registries

For privacy-preserving use cases, the glossary references blinded revocation registries:

Salty nonce blinding factors: The current state of a TEL may be hidden/blinded such that the only way for a verifier to observe state is when the controller of a designated AID discloses it at presentation time.

Selective state disclosure: The holder controls what registry state information is revealed, enabling:

• Private credential presentations without registry correlation
• Selective disclosure of revocation status
• Zero-knowledge proof integration for advanced privacy

The salty nonce blinding factor mechanism uses random salts to blind TEL state, allowing credential holders to prove current validity without exposing correlation identifiers.

Comparison with Traditional Registry Approaches

KERI VDRs represent a fundamental architectural shift from traditional credential registry models:

Ledger-Based Registries

Blockchain/DLT approach:

• Central ledger provides single source of truth
• Consensus through mining (PoW) or staking (PoS)
• High latency for finality
• Scalability limitations from global replication
• Smart contract complexity for revocation logic

KERI VDR approach:

• Distributed TELs anchored to controller's KEL
• Consensus through witness/Registrar thresholds specific to each identifier
• Low latency - no global mining/staking required
• Horizontal scalability - each controller manages their own registry
• Simple cryptographic commitment model (digests + signatures)

Centralized Status Lists

Traditional PKI/CA model:

• Certificate Revocation Lists (CRLs) or OCSP responders
• Trust in centralized authority
• Single point of failure
• Privacy leaks through revocation queries

KERI VDR model:

• Controller maintains their own registry
• Trust through cryptographic verification to KEL
• Distributed infrastructure through Registrars
• Privacy options through blinded registries

W3C Status List 2021

Status List approach:

• Bitstring-encoded status values
• Published at well-known URLs
• Herd privacy through aggregation
• Requires trust in list publisher

KERI TEL approach:

• Cryptographically-linked event chains
• Self-certifying through KEL anchoring
• Verifiable to root-of-trust
• No required trust in infrastructure providers (witnesses/Registrars provide availability, not trust)

Operational Lifecycle and State Transitions

The VDR lifecycle follows specific patterns documented across the sources:

Registry Inception

Management TEL creation:

1. Controller generates management TEL inception event with unique registry identifier
2. Specifies initial Registrar pool and threshold configuration
3. Creates digest of management TEL inception event
4. Anchors digest to KEL via interaction or rotation event seal
5. Signs KEL event with current signing keys
6. Distributes to Registrars for backing/persistence

Credential Issuance

VC TEL creation:

1. Issue ACDC credential with unique SAID
2. Create VC TEL inception event referencing management TEL
3. Record issuance transaction in VC TEL
4. Compute digest of VC TEL event
5. Anchor to issuer's KEL through event seal
6. Sign anchoring KEL event
7. Credential becomes verifiable through registry query

Credential Revocation

State transition process:

1. Create revocation event in VC TEL
2. Reference previous VC TEL event via digest
3. Update credential state to revoked
4. Anchor revocation event digest to KEL
5. Sign anchoring KEL event
6. Validators observe state change through registry query

Registry Rotation

Registrar set changes:

1. Management TEL rotation event specifies new Registrar configuration
2. Existing Registrars confirm rotation event
3. Digest anchored to controller KEL
4. New Registrars receive historical TEL state
5. Threshold transitions to new configuration
6. Old Registrars can be deprecated after transition period

Security Properties and Guarantees

End-to-End Verifiability

KERI VDRs provide end-to-end verifiability where validators can cryptographically verify registry state without trusting intermediaries:

1. KEL verification: Establish current key state of credential issuer
2. Seal verification: Confirm TEL events are properly anchored to authoritative KEL events
3. Digest verification: Validate TEL event integrity through digest chains
4. Threshold verification: Confirm sufficient Registrar confirmations if using witness/Registrar receipts

Duplicity Detection

The duplicity evident property extends from KELs to VDRs:

KEL duplicity: Any attempt to create conflicting KEL branches (fork attack) is detectable by witnesses and validators

TEL duplicity: Since TEL events are anchored to KEL events via seals, any conflicting TEL states would require conflicting KEL events, triggering KEL-level duplicity detection

First-seen policy: The first-seen principle applies - witnesses/Registrars log the first version of each event they observe, making later conflicting events provably duplicitous

Pre-Rotation Protection

VDRs inherit KEL pre-rotation security:

Next key commitment: KEL establishes cryptographic commitment to next rotation keys through digests of pre-rotated keys

Live attack resistance: Even if current signing keys are compromised, attackers cannot create valid rotation events without access to pre-rotated keys

TEL inheritance: Since TEL state is anchored to KEL events signed by current keys, compromised signing keys cannot forge historical TEL state - they can only create new (detectable) branches

Witness/Registrar Threshold Security

The threshold mechanism provides Byzantine fault tolerance:

Sufficient majority: Requires M confirmations from N witnesses/Registrars where M >= N - F for F maximum faulty nodes

KAWA/KA2CE: KERI's Agreement Algorithm for Control Establishment ensures witnesses reach consensus on event ordering

Ample property: The minimum participants needed for supermajority ensures one and only one agreement is possible

Performance and Scalability Characteristics

Horizontal Scalability

KERI VDRs scale horizontally through controller autonomy:

Per-controller registries: Each credential issuer operates their own VDR infrastructure, avoiding global bottlenecks

Independent consensus: Witness/Registrar consensus is local to each identifier, not global across all participants

Parallel processing: Multiple VDR queries can be processed independently without coordination

Query Performance

TEL query patterns enable efficient credential verification:

Direct queries: Validators query specific credential state via SAID identifier

Caching strategies: TEL state can be cached with cache invalidation through KEL event monitoring

Incremental updates: Only new TEL events need transmission for validators with historical state

Storage Efficiency

Compact encoding: CESR primitives minimize storage overhead

Sparse registries: Only credentials with state changes require TEL events

Pruning strategies: Obsolete VC TELs (for expired credentials) can be archived while maintaining management TEL integrity

Integration with ACDC Credential Issuance

VDRs integrate tightly with ACDC issuance workflows:

Registry Identifier Field

ACDCs include an ri (registry identifier) field specifying the VDR that tracks credential state. This enables:

• Issuance verification: Validators confirm credential appears in issuer's registry
• Revocation checking: Query current credential state via registry identifier
• Transfer tracking: For transferable credentials, registry records ownership changes

Graduated Disclosure Compatibility

VDRs support ACDC graduated disclosure patterns:

Compact disclosure: Present credential with SAID references, validators query full details from registry if authorized

Selective disclosure: Present partial credential content, registry provides confirmation of unshown attributes

Full disclosure: Present complete credential, registry confirms issuance and current status

IPEX Protocol Integration

The Issuance and Presentation Exchange (IPEX) protocol leverages VDRs:

Issuance exchange: Issuer creates ACDC, records in VDR, presents credential to issuee

Presentation exchange: Holder presents credential, verifier queries VDR for current status

Chained presentations: Multi-hop credential chains verified through respective VDR queries

Future Directions and Extensions

While not fully detailed in current specifications, source documents suggest evolution directions:

Transfer Support

Extending TELs to track credential ownership transfers for transferable credentials, enabling:

• Asset-backed credentials with chain of custody
• Delegated authority transfers
• Supply chain provenance tracking

Advanced Privacy Mechanisms

Integration with zero-knowledge proof systems for:

• Credential validity proofs without revealing registry identifiers
• Selective disclosure of revocation status
• Privacy-preserving compliance verification

Cross-Registry Queries

Federated query protocols enabling:

• Multi-issuer credential validation
• Cross-organizational registry discovery
• Standardized registry API specifications

Implementation Considerations

keripy VDR Module

The keripy implementation includes a keri.vdr module with subcomponents:

• keri.vdr.credentialing: Credential-related VDR operations
• keri.vdr.eventing: Event processing and handling
• keri.vdr.verifying: Verification logic
• keri.vdr.viring: Component wiring/routing

keriox Rust Implementation

The keriox changelog documents VDR infrastructure evolution including:

• Database migration: Movement from sled to redb for improved performance
• Escrow systems: Partially signed escrow, delegation escrow, reply escrow for asynchronous VDR operations
• Duplicitous event storage: Tracking conflicting VDR states for duplicity evidence
• OOBI integration: VDR endpoint discovery through Out-Of-Band Introduction

Testing Infrastructure

The demo witness networks (Wan, Wes, Wil) documented in training materials provide:

• Pre-configured three-witness setup for VDR development
• Known AIDs and endpoints for predictable testing
• Examples of CESR-encoded receipt collection
• Threshold configuration demonstrations

Conclusion

KERI verifiable data registries represent a fundamental architectural innovation that:

1. Decentralizes credential lifecycle management through per-controller TEL infrastructure anchored to KELs
2. Eliminates reliance on blockchains for credential registries while maintaining cryptographic verifiability
3. Provides flexible privacy models from fully public to blinded registries
4. Scales horizontally through autonomous controller infrastructure
5. Integrates deeply with ACDC credential format and IPEX exchange protocols
6. Supports enterprise requirements demonstrated by GLEIF vLEI governance frameworks

The VDR architecture achieves what traditional approaches could not: a registry system that is simultaneously verifiable, decentralized, scalable, and privacy-preserving through cryptographic mechanisms rather than trusted intermediaries. By anchoring TEL state to KERI's duplicity-evident KEL infrastructure, VDRs inherit KERI's security properties while extending them into the credential lifecycle domain, enabling a new generation of trustworthy digital credential systems.