The PTEL architecture consists of two primary components:

Management TEL: Signals the creation of the Virtual Credential Registry (VCR) and tracks the list of Registrars that act as backers for individual credential TELs. Registrars are analogous to witnesses in KELs, providing distributed validation and availability for credential state information.

VC TEL (Virtual Credential Transaction Event Log): Tracks the issued or revoked state of each individual credential and contains a reference to its corresponding management TEL. Each credential has its own VC TEL that records all state transitions throughout its lifecycle.

Key Components

Every PTEL event contains several essential fields:

• i (Identifier): The AID of the credential registry controller
• s (Sequence Number): Represents the "clock" for the transaction set, which may be independent of KEL sequence numbers
• t (Event Type): Identifies the type of transaction event (inception, issuance, revocation, etc.)
• d (Digest): The SAID of the event itself, providing content-addressable integrity
• p (Prior Event Digest): Hash of the previous event, creating the cryptographic chain

Data Format

Field Definitions

PTEL events follow the standard KERI event structure with specific fields for transaction management:

Common Fields (present in all PTEL events):

• v: Version string specifying KERI version and serialization format
• i: Identifier of the registry controller (AID)
• s: Sequence number (hexadecimal string representation)
• t: Event type identifier
• d: Self-addressing identifier (SAID) of the event
• p: Prior event digest (SAID of previous event)

Registry-Specific Fields:

• ri: Registry identifier (for VC TEL events)
• ra: Registry anchor (reference to management TEL)
• ba: Backer (Registrar) list
• br: Backer removal list
• bt: Backer threshold

Credential-Specific Fields:

• vc: Verifiable credential SAID (for issuance events)
• dt: Datetime of transaction

Encoding Format

PTEL events are encoded using CESR (Composable Event Streaming Representation), supporting both:

JSON Serialization: Human-readable format for debugging and development

{
  "v": "KERI10JSON000116_",
  "i": "ELvaU6Z-i0d8JJR2nmwyYAZAoTNZH3UfSVPzhzS6b5CM",
  "s": "0",
  "t": "vcp",
  "d": "ELvaU6Z-i0d8JJR2nmwyYAZAoTNZH3UfSVPzhzS6b5CM",
  "bt": "2",
  "b": ["BFUOWBaJz-sB_6b-_u_P9W8hgBQ8Su9mAtN9cY2sVGiY"],
  "c": ["NB"]
}

Binary Serialization: Compact format for efficient transmission and storage using CESR binary encoding.

Size and Constraints

PTEL events have variable size depending on:

• Number of backers in the registry
• Event type and associated data
• Serialization format chosen

Typical constraints:

• Sequence numbers use hexadecimal representation to support large registries
• Backer thresholds must satisfy sufficient majority requirements
• Event digests use cryptographic hash functions with approximately 128 bits of strength

Operations

Creation and Initialization

Management TEL Inception (vcp event):

The first step in creating a PTEL-based registry is establishing the management TEL through an inception event:

1. Generate Registry Identifier: Create a unique identifier for the registry
2. Define Backer Set: Specify the initial set of Registrars that will maintain copies of credential TELs
3. Set Backer Threshold: Establish the minimum number of Registrar confirmations required
4. Create Inception Event: Generate the vcp (verifiable credential registry inception) event
5. Anchor to KEL: Create a seal in the controller's KEL that commits to the management TEL inception event digest
6. Sign KEL Event: The controller signs the KEL event, cryptographically binding the management TEL to their control authority

VC TEL Inception (iss event):

For each credential to be issued, a separate VC TEL is created:

1. Reference Management TEL: Include the management TEL identifier
2. Specify Credential SAID: Reference the ACDC credential being issued
3. Create Issuance Event: Generate the iss (verifiable credential issuance) event
4. Anchor to KEL: Seal the issuance event in the issuer's KEL
5. Distribute to Registrars: Send the event to all designated Registrars for backing

Updates and Modifications

Credential Revocation (rev event):

Revoking a credential involves:

1. Create Revocation Event: Generate a rev event referencing the credential SAID
2. Sequence Properly: Ensure the sequence number follows the previous VC TEL event
3. Include Prior Digest: Reference the digest of the previous event in the VC TEL
4. Anchor to KEL: Create a seal in the issuer's KEL committing to the revocation event
5. Sign and Distribute: Sign the KEL event and distribute the revocation to Registrars

Registrar Rotation:

The management TEL supports rotation of the Registrar set:

1. Create Rotation Event: Generate an event specifying backers to add (ba) and remove (br)
2. Update Threshold: Adjust the backer threshold (bt) if needed
3. Anchor and Sign: Seal in KEL and sign
4. Coordinate Transition: Ensure new Registrars receive complete VC TEL history

Verification and Validation

PTEL Verification Process:

Validators verify PTEL events through a multi-step process:

1. Retrieve KEL: Obtain the complete KEL for the registry controller
2. Verify KEL Integrity: Validate all KEL events, signatures, and witness receipts
3. Locate Anchoring Seals: Find the KEL events containing seals for PTEL events
4. Extract PTEL Event Digests: Retrieve the committed digests from the seals
5. Retrieve PTEL Events: Obtain the actual PTEL events from Registrars
6. Verify Digest Match: Confirm the PTEL event digest matches the sealed commitment
7. Validate Chain Integrity: Verify the hash chain through all PTEL events
8. Check Registrar Confirmations: Ensure sufficient Registrars have confirmed the events

Importantly, PTEL events themselves do not require signatures. The cryptographic commitment comes from:

• The digest sealed in the KEL event
• The signatures on that KEL event by the controller
• The confirmations from Registrars

This design reduces overhead while maintaining strong security guarantees through the KEL's established control authority.

Usage Context

In Which Protocols

PTELs are integral to several KERI ecosystem protocols:

ACDC Credential Issuance: When issuing ACDC credentials, issuers create VC TEL entries to establish the credential's initial issued state. The ACDC's ri (registry identifier) field references the management TEL, creating a verifiable link between the credential and its state tracking mechanism.

IPEX (Issuance and Presentation Exchange): During IPEX exchanges, verifiers check the PTEL to confirm a presented credential has not been revoked. The PTEL provides the authoritative source for credential status.

vLEI Ecosystem: The vLEI (verifiable Legal Entity Identifier) system extensively uses PTELs to track the lifecycle of organizational credentials, including:

• QVI (Qualified vLEI Issuer) credentials
• Legal Entity credentials
• Official Organizational Role (OOR) credentials
• Engagement Context Role (ECR) credentials

Lifecycle Management

PTEL lifecycle follows this progression:

Phase 1: Registry Establishment

• Controller creates management TEL
• Designates initial Registrar set
• Anchors management TEL inception to KEL

Phase 2: Credential Issuance

• For each credential, create VC TEL with issuance event
• Anchor issuance to KEL
• Distribute to Registrars for backing

Phase 3: Active State Management

• Credentials remain in issued state
• Verifiers query Registrars for current state
• Registrars provide consistent state information

Phase 4: Revocation (if needed)

• Controller creates revocation event
• Anchors to KEL
• Registrars update state to revoked

Phase 5: Registry Maintenance

• Rotate Registrars as needed
• Update thresholds based on operational requirements
• Maintain availability through distributed Registrar network

Related Structures

Key Event Log (KEL): The PTEL's authoritative anchor. Every PTEL event must be sealed in a KEL event to be considered valid. The KEL provides:

• Control authority over the registry
• Cryptographic commitment to PTEL events
• Signature verification for state changes

Key Event Receipt Log (KERL): When witnesses receipt KEL events containing PTEL seals, they create KERLs that provide additional validation of the PTEL's anchoring.

ACDC Credentials: The primary consumers of PTEL services. ACDCs reference PTELs through their ri field, enabling verifiers to check credential status.

OOBI (Out-Of-Band Introduction): Used to discover Registrars and retrieve PTEL events. OOBIs provide the network-level mechanism for locating and accessing PTEL data.

Implementation Considerations

Public vs. Private Credentials

The PTEL specification explicitly states it is designed for public credentials only. The use of hash digests of credential contents as identifiers allows for correlation of credential uses across different presentations. This design trade-off prioritizes:

Transparency: Any party can verify credential status Auditability: Complete history of credential lifecycle is publicly available Simplicity: No complex privacy-preserving cryptography required

For private credentials requiring unlinkability, alternative approaches using blinded registries or zero-knowledge proofs would be necessary, though these are outside the scope of the current PTEL specification.

Registrar Selection and Management

Implementers must carefully consider:

Registrar Count: More Registrars increase availability and fault tolerance but add coordination overhead. The specification recommends a minimum of 5 Registrars with a sufficient majority threshold.

Registrar Independence: Registrars should be operated by independent entities to prevent collusion and ensure genuine distributed validation.

Threshold Configuration: The backer threshold (bt) must balance security (requiring enough confirmations to prevent single-point failures) with availability (not requiring so many confirmations that temporary Registrar unavailability blocks operations).

Sequence Number Management

Unlike KELs where sequence numbers must strictly follow the order of key management events, PTEL sequence numbers represent a registry-specific "clock" that can be:

Independent of KEL Sequence: A single KEL event can anchor multiple PTEL events with different sequence numbers

Context-Specific: Different registries can use different sequencing schemes (monotonic integers, timestamps, block heights)

Flexible: The sequence number scheme can be chosen based on the registry's operational requirements

For most credential registries, simple monotonically increasing integers provide the clearest and most maintainable approach.

Anchoring Seal Format

PTEL events are anchored to KELs using Event Source Seals with the structure:

{
  "s": "3",
  "d": "ELvaU6Z-i0d8JJR2nmwyYAZAoTNZH3UfSVPzhzS6b5CM"
}

In CESR encoding, these seals are delivered as attachments in duple format (s, d) with the group framing code -GAB:

-GAB
0AAAAAAAAAAAAAAAAAAAAAAw
ELvaU6Z-i0d8JJR2nmwyYAZAoTNZH3UfSVPzhzS6b5CM

Implementers must ensure:

• Seals are properly formatted and encoded
• The digest in the seal matches the actual PTEL event digest
• Seals are included in the correct KEL event attachments

Query and Verification Patterns

Efficient Status Checking:

Verifiers should implement efficient PTEL query patterns:

1. Cache Registrar Endpoints: Store OOBI information for Registrars to avoid repeated discovery
2. Parallel Queries: Query multiple Registrars simultaneously to reduce latency
3. Threshold Satisfaction: Stop querying once sufficient Registrar responses are received
4. State Caching: Cache credential states with appropriate TTLs to reduce query load

Consistency Verification:

When querying multiple Registrars, verifiers should:

• Compare responses for consistency
• Detect and report inconsistencies (potential duplicity)
• Require threshold agreement before accepting state
• Escalate to full PTEL verification if inconsistencies are detected

Integration with ACDC Workflows

PTEL integration with ACDC issuance and presentation:

During Issuance:

1. Issuer creates ACDC with ri field referencing management TEL
2. Issuer creates VC TEL issuance event
3. Issuer anchors issuance event to their KEL
4. Issuer distributes ACDC and PTEL information to holder

During Presentation:

1. Holder presents ACDC to verifier
2. Verifier extracts ri field to identify registry
3. Verifier queries Registrars for current credential state
4. Verifier checks that state is "issued" (not revoked)
5. Verifier proceeds with ACDC verification if state is valid

During Revocation:

1. Issuer creates revocation event in VC TEL
2. Issuer anchors revocation to their KEL
3. Registrars update their state records
4. Subsequent verifier queries return "revoked" state
5. Verifiers reject presentations of revoked credentials

This workflow ensures that credential state is always verifiable through the PTEL infrastructure, providing a robust foundation for credential lifecycle management in the KERI ecosystem.

This ordering ensures verifiers can immediately check credential status upon first presentation.

Query Optimization

For high-volume verification scenarios:

• Implement parallel Registrar queries
• Cache Registrar endpoints from OOBI resolution
• Use threshold-based early termination (stop querying once sufficient responses received)
• Implement credential state caching with appropriate TTLs
• Monitor for Registrar inconsistencies as potential duplicity indicators

Error Handling

Implementations should handle:

• Registrar unavailability: Query multiple Registrars, accept threshold responses
• Inconsistent responses: Escalate to full PTEL verification, report potential duplicity
• Missing anchoring seals: Reject PTEL events without valid KEL anchoring
• Sequence gaps: Verify complete PTEL chain before accepting current state

Testing Strategies

Thorough testing should cover:

• Registry inception and Registrar coordination
• Credential issuance and state propagation
• Revocation event processing
• Registrar rotation scenarios
• Network partition and recovery
• Duplicity detection and reporting
• Query performance under load