Most Compact Form: The minimal representation where all optional sections are represented solely by their SAIDs. This form discloses the absolute minimum information necessary while maintaining verifiability through cryptographic commitments.

Fully Compact Form: A complete but condensed representation where all sections are present but may be represented as SAIDs rather than expanded content. Document 24 clarifies that this is the only signed variant of an ACDC, with the signature cryptographically anchored in a Transaction Event Log (TEL).

The key architectural insight from Document 8 is that all ACDC variants are various degrees of expansion of the compact variant. This means the compact form serves as the canonical base representation, with other variants (partially expanded, fully expanded) building upon this foundation.

Key Components

The compact variant's structure centers on top-level section fields, which Document 4 defines as fields shared across all variants of an ACDC. Each top-level section field contains one of two possible values:

1. The SAD itself: The complete Self-Addressed Data structure for that section
2. The SAID of the SAD: A cryptographic digest serving as a commitment to the section's content without revealing it

This dual-value approach enables flexible disclosure patterns. A credential holder can present a compact variant with some sections as SAIDs (undisclosed) and others as full SADs (disclosed), creating what Document 26 describes as a "most compact" form for that specific disclosure level.

Data Format

Field Definitions

The compact variant maintains the standard ACDC top-level field structure defined in Document 9:

Core Identity Fields:

• v (Version String): Regexable format encoding protocol version, serialization type, size, and terminator
• d (SAID): Self-referential digest of the entire ACDC
• i (Issuer AID): Autonomic Identifier of the credential issuer
• ri (Registry Identifier): Optional link to issuance/revocation registry

Content Section Fields (may be SAIDs or full content):

• s (Schema): SAID or full JSON Schema definition
• a (Attributes): SAID or full attribute block
• A (Selective Attributes): Aggregate or array of selectively disclosable attributes
• e (Edges): SAID or full edge block linking to other ACDCs
• r (Rules): SAID or full Ricardian contract clauses

Privacy Field:

• u (UUID): High-entropy nonce enabling private/public ACDC variants

The critical distinction in compact variants is that content section fields (s, a, A, e, r) are represented as SAIDs rather than expanded content, while core identity fields remain fully specified.

Encoding Format

Compact variants support multiple serialization formats as specified in Document 11:

1. JSON: Human-readable text format with insertion-ordered field maps
2. CBOR: Concise Binary Object Representation for efficient binary encoding
3. MGPK: MessagePack binary serialization
4. CESR: Composable Event Streaming Representation enabling text-binary composability

All serialization formats must preserve insertion order of field maps, as this is critical for reproducible SAID computation. The specification explicitly states that lexicographic (alphabetical) ordering is NOT required—only insertion order matters.

Document 2 demonstrates that when computing a SAID, the ACDC must be serialized to compact JSON (no whitespace) to ensure consistent digest computation. The computed SAID then appears in the $id field of schemas or the d field of ACDCs.

Size and Constraints

The compact variant's size depends on the number of sections represented as SAIDs versus expanded content. A SAID in CESR encoding is a fixed-length qualified cryptographic digest, typically 44 characters in Base64 URL-safe encoding.

Size Optimization: By replacing potentially large attribute blocks, edge sections, or rule sections with their SAIDs, compact variants can achieve significant size reduction. For example, a credential with a 2KB attribute section can be reduced to a 44-character SAID, yielding over 97% size reduction for that section.

Constraint Requirements:

• All SAIDs must be computed using the same cryptographic algorithm (typically Blake3-256)
• Field maps must maintain insertion order across serialization/deserialization cycles
• The top-level d field SAID must be computed over the entire compact variant structure
• Private ACDCs must include a u field with ≥128 bits of entropy to prevent rainbow table attacks

Operations

Creation and Initialization

Creating a compact variant involves several steps as outlined in Document 9:

1. Schema Definition: Define or reference a JSON Schema that supports both compact and uncompacted variants using oneOf composition operators
2. Content Section Creation: Create full SAD structures for each section (attributes, edges, rules)
3. SAID Computation: Compute SAIDs for each section by:
   • Serializing the section to compact JSON
   • Computing the cryptographic digest
   • Embedding the SAID in the section's d field
   • Recomputing to verify self-referential consistency
4. Compact Variant Assembly: Construct the compact variant by replacing full section content with their SAIDs
5. Top-Level SAID Computation: Compute the top-level d field SAID over the entire compact structure
6. Signature Generation: The issuer signs the compact variant, creating a cryptographic commitment to all variants

Document 2 provides detailed Python-to-JSON mapping guidance:

• Python True/False map to JSON true/false
• Python None maps to JSON null
• Compact serialization removes all whitespace for SAID computation

Updates and Modifications

Compact variants are immutable by design. The SAID-based architecture means any modification to content invalidates all SAIDs in the chain. However, the compact variant enables progressive disclosure without modification:

Expansion Operations: A compact variant can be expanded by replacing SAIDs with their corresponding SAD content. Document 26 explains that this creates different "most compact" forms at each disclosure level:

• Level 0 (Fully Compact): All sections as SAIDs
• Level 1 (Partial Expansion): Some sections expanded, others as SAIDs
• Level 2 (Full Expansion): All sections expanded to full content

Each level maintains verifiability through the original issuer signature on the fully compact form.

Compaction Operations: Conversely, a fully expanded ACDC can be compacted by replacing SAD content with SAIDs. This operation is useful for:

• Reducing transmission size
• Minimizing information disclosure
• Creating privacy-preserving presentations

Verification and Validation

Verification of compact variants involves multiple layers as described in Document 3:

Signature Verification:

1. Verify the issuer's signature on the compact variant
2. Confirm the signature covers the top-level section fields
3. Validate that the signature was created by the AID specified in the i field
4. Check the KEL (Key Event Log) to confirm the signing keys were authoritative at issuance time

SAID Verification:

1. For each SAID in the compact variant, verify it matches the digest of the corresponding SAD if disclosed
2. Recompute the top-level d field SAID and verify it matches the presented value
3. For expanded sections, verify their internal SAIDs match their content

Schema Validation:

1. Retrieve the schema referenced by the s field SAID
2. Validate that the compact variant conforms to the schema's compact variant definition
3. Verify that the schema supports the specific combination of SAIDs and expanded content presented

Cross-Variant Commitment Verification: Document 6 emphasizes that compact variants maintain cross-variant Issuer commitment verifiability. This means:

• The issuer's signature on the fully compact form commits to all possible expansions
• A verifier can validate any disclosure level against the original signature
• SAIDs serve as cryptographic commitments that bind expanded content to the signed compact form

Usage Context

In Which Protocols

Compact variants are integral to several KERI ecosystem protocols:

IPEX (Issuance and Presentation Exchange): Document 10 defines IPEX as the protocol for exchanging ACDCs, with compact variants enabling:

• Initial low-disclosure presentations
• Progressive disclosure through multiple exchange rounds
• Contractually protected disclosure with legal enforceability

ACDC Chaining: Document 17 demonstrates how compact variants enable credential chaining in the vLEI ecosystem:

• QVI credentials chain to GLEIF root authority
• Legal Entity credentials chain to QVI credentials
• Role credentials chain to Legal Entity credentials
• Each chain link can be presented in compact form, revealing only necessary SAIDs

TEL (Transaction Event Log): Document 24 explains that the fully compact variant is anchored in TELs, providing:

• Issuance event recording
• Revocation state tracking
• Transfer authorization logging

Lifecycle Management

The compact variant lifecycle follows these stages:

Issuance Phase:

1. Issuer creates fully expanded ACDC with all content
2. Computes SAIDs for all sections
3. Creates fully compact variant
4. Signs the fully compact variant
5. Anchors signature in TEL
6. Delivers appropriate variant to issuee (may be compact, partial, or full)

Presentation Phase: Document 22 describes graduated disclosure:

1. Initial presentation uses highly compact form (minimal disclosure)
2. Verifier requests additional information
3. Holder expands specific sections while keeping others compact
4. Process repeats until sufficient information disclosed
5. All presentations remain verifiable against original signature

Verification Phase:

1. Verifier receives compact variant
2. Verifies signature and SAIDs
3. Requests expansion of specific sections if needed
4. Validates expanded content against SAID commitments
5. Confirms credential status via TEL query

Revocation Phase:

1. Issuer creates revocation event in TEL
2. Compact variant remains structurally unchanged
3. TEL query reveals revoked status
4. All variants (compact, partial, full) become invalid simultaneously

Related Structures

Compact variants interact with several related ACDC structures:

Fully Expanded Variant: Document 26 explains that when all SAIDs in a compact variant are replaced with their full SAD content, the result is a fully expanded variant. This represents maximum disclosure.

Metadata Variant: Contains only top-level fields without attribute, edge, or rule sections. Useful for credential discovery and catalog operations.

Partial Variant: Document 23 describes partial disclosure where some field maps are expanded while others remain as SAIDs. This creates intermediate disclosure levels.

Selective Variant: Enables unbundled disclosure of specific attributes from the A (Attribute Aggregate) section while keeping others blinded.

Private vs. Public Variants: Document 12 distinguishes:

• Private ACDCs: Include u field with high-entropy UUID, making SAIDs resistant to rainbow table attacks
• Public ACDCs: Lack u field, suitable for non-confidential data where discoverability is acceptable

The compact variant architecture enables seamless transitions between these related structures while maintaining cryptographic integrity through SAID-based commitments and issuer signatures that bind all variants together.

Performance Optimization

1. SAID Caching: Cache computed SAIDs to avoid redundant digest computation. SAIDs are immutable once computed.

2. Lazy Expansion: Don't expand all sections when receiving a compact variant. Expand only the sections needed for the current verification or presentation.

3. Streaming Support: For large ACDCs, consider streaming CESR encoding which supports efficient parsing of compact variants without loading entire structures into memory.

Error Handling

1. SAID Mismatch: If a disclosed section's computed SAID doesn't match the SAID in the compact variant, reject the credential immediately—this indicates tampering or corruption.

2. Schema Validation Failures: Validate both compact and expanded forms against the schema. A credential that validates in one form but not another indicates a schema design error.

3. Missing Sections: When expanding a compact variant, ensure all referenced SAIDs can be resolved to actual content. Missing sections should be treated as verification failures unless the use case explicitly supports partial disclosure.

Testing Strategies

1. Round-Trip Testing: Verify that compact → expanded → compact transformations preserve all SAIDs and structural integrity.

2. Cross-Variant Signature Testing: Test that signatures on compact variants successfully verify against all expanded forms.

3. Schema Compliance Testing: Validate that all compact and expanded variants conform to the schema's oneOf definitions.

4. Graduated Disclosure Scenarios: Test multi-step disclosure flows where different sections are progressively revealed across multiple presentations.