In ACDCs: Data anchors enable the compact disclosure mechanism where field maps can be represented by their SAIDs (Self-Addressing Identifiers) rather than full content. This supports graduated disclosure privacy patterns while maintaining cryptographic verifiability.

In Transaction Event Logs (TELs): Data anchors bind credential state changes to the authoritative KEL, creating a verifiable chain of custody for credential lifecycle events.

Type Classification

Data anchors are classified as:

• Cryptographic primitives: Fundamental building blocks in KERI's cryptographic architecture
• Content-addressable identifiers: Enable location-independent data reference
• Integrity mechanisms: Provide tamper-evidence for anchored data
• Commitment schemes: Allow cryptographic commitments without data disclosure

Cryptographic Properties

Underlying Algorithms

Data anchors in KERI utilize collision-resistant hash functions to ensure cryptographic security. The KERI protocol supports multiple hash algorithms through its derivation code system, including:

Blake3-256: A modern, high-performance cryptographic hash function providing:

• 256-bit output length
• Collision resistance: ~2^128 operations
• Pre-image resistance: ~2^256 operations
• Second pre-image resistance: ~2^256 operations

SHA-256: The widely-adopted SHA-2 family hash providing:

• 256-bit output length
• Collision resistance: ~2^128 operations
• NIST-approved cryptographic standard

SHA3-256: The Keccak-based SHA-3 standard providing:

• 256-bit output length
• Different internal structure from SHA-2
• Quantum-resistant properties for hash functions

Security Properties

Data anchors provide several critical security properties:

Collision Resistance: The computational infeasibility of finding two different inputs that produce the same digest. This ensures that each unique data item has a unique anchor, preventing ambiguity in data references.

Pre-image Resistance: Given a digest, it is computationally infeasible to find the original data that produced it. This property enables data anchors to serve as commitments without revealing the committed data.

Second Pre-image Resistance: Given data and its digest, it is computationally infeasible to find different data that produces the same digest. This prevents substitution attacks where an attacker might try to replace anchored data with malicious content.

Deterministic Output: The same input data always produces the same digest, ensuring consistency in data references across different systems and time periods.

Avalanche Effect: Small changes in input data produce completely different digests, making tampering immediately evident through digest comparison.

Key/Output Sizes

Data anchor digest sizes in KERI are determined by the chosen hash algorithm:

256-bit digests (32 bytes):

• Blake3-256: 32 bytes raw, 44 characters in Base64
• SHA-256: 32 bytes raw, 44 characters in Base64
• SHA3-256: 32 bytes raw, 44 characters in Base64

512-bit digests (64 bytes):

• Blake3-512: 64 bytes raw, 88 characters in Base64
• SHA-512: 64 bytes raw, 88 characters in Base64

When encoded in CESR format, data anchors include a derivation code prefix that identifies the hash algorithm used, adding 1-2 characters to the total length.

Data Format & Encoding

CESR Encoding Format

Data anchors in KERI are encoded using CESR (Composable Event Streaming Representation), which provides dual text-binary encoding with composability properties. A CESR-encoded data anchor consists of:

Derivation Code: A prefix that identifies:

• The hash algorithm used (Blake3, SHA-256, SHA3, etc.)
• The output length (256-bit, 512-bit, etc.)
• The encoding domain (text or binary)

Digest Value: The actual hash output encoded in:

• Text domain: Base64 URL-safe encoding
• Binary domain: Raw bytes

Text and Binary Representations

Text Domain Example (Blake3-256):

EAdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM

Breakdown:

• E: Derivation code for Blake3-256 in text domain
• AdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM: Base64-encoded 256-bit digest

Binary Domain: The same digest in binary domain would use a different derivation code and raw byte encoding, maintaining the same semantic meaning while optimizing for binary streaming.

Derivation Codes

Common derivation codes for data anchors include:

Text Domain:

• E: Blake3-256 digest
• F: Blake2b-256 digest
• G: Blake2s-256 digest
• H: SHA3-256 digest
• I: SHA2-256 digest

Binary Domain:

• 0D: Blake3-256 digest
• 0E: Blake2b-256 digest
• 0F: Blake2s-256 digest
• 0G: SHA3-256 digest
• 0H: SHA2-256 digest

The derivation code system enables:

• Algorithm agility: Support for multiple hash algorithms
• Self-describing data: The encoding contains algorithm information
• Forward compatibility: New algorithms can be added without breaking existing data

Usage in KERI/ACDC

In Key Event Logs

Data anchors appear in KELs through seal mechanisms within interaction events. The seal structure includes:

Seal Types:

• Digest seals: Direct anchoring of data digests
• Merkle tree root seals: Anchoring multiple data items through tree structures
• Event seals: Anchoring to other key events or transaction events

Interaction Event Structure:

{
  "v": "KERI10JSON00011c_",
  "t": "ixn",
  "d": "EL1L56LyoKrIofnn0oPChS4EyzMHEEk75INJohDS_Bug",
  "i": "EBkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM",
  "s": "2",
  "p": "EAdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
  "a": [
    {
      "d": "EFH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZIl3MOA"
    }
  ]
}

In this structure:

• The a (anchors) field contains seal objects
• Each seal's d field is a data anchor (digest) of external data
• The seal cryptographically binds the external data to this key event

In ACDC Credentials

Data anchors enable ACDC's sophisticated disclosure mechanisms:

Compact Variant: Field maps are represented by their SAIDs:

{
  "v": "ACDC10JSON00011c_",
  "d": "EAdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
  "i": "EBkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM",
  "s": "ED6jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
  "a": "EEveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY"
}

The a field contains a data anchor (SAID) of the attribute section rather than the full attributes, enabling:

• Privacy preservation: Attributes not disclosed until necessary
• Selective disclosure: Individual attributes can be revealed independently
• Cryptographic binding: The SAID commits to the full attribute content

Full Variant: The same ACDC with expanded attributes:

{
  "v": "ACDC10JSON00011c_",
  "d": "EAdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
  "i": "EBkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM",
  "s": "ED6jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
  "a": {
    "d": "EEveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
    "name": "John Doe",
    "role": "Developer"
  }
}

The d field within the attribute block is the same data anchor, proving the expanded content matches the compact reference.

Common Usage Patterns

Credential Issuance: When issuing an ACDC credential, the issuer:

1. Computes data anchors for each disclosable section
2. Creates compact variant with SAIDs
3. Signs the compact variant
4. Can later provide full content with cryptographic proof of consistency

Data Provenance: Controllers use data anchors to create verifiable chains:

1. Anchor original data in an interaction event
2. Reference that anchor in subsequent events
3. Build provenance chains through anchor references

Multi-Party Workflows: Data anchors enable coordination:

1. Party A anchors data in their KEL
2. Party B references Party A's anchor in their KEL
3. Creates verifiable cross-reference without data duplication

Verification Procedures

Verifying data anchors involves:

Step 1: Extract the anchor

• Locate the data anchor (digest) in the event or credential
• Identify the derivation code to determine hash algorithm

Step 2: Obtain the anchored data

• Retrieve the full data that was supposedly anchored
• This may come from the same message, a separate disclosure, or external source

Step 3: Recompute the digest

• Apply the same hash algorithm to the obtained data
• Use the algorithm specified by the derivation code

Step 4: Compare digests

• Compare the recomputed digest with the anchor
• Exact match proves data integrity and authenticity
• Mismatch indicates tampering or incorrect data

Step 5: Verify signatures

• Verify that the event or credential containing the anchor is properly signed
• Confirms the anchor was created by the claimed controller

Related Primitives

Self-Addressing Identifiers (SAIDs)

SAIDs are a specialized form of data anchor where the digest is embedded within the data being digested. This creates a self-referential, content-addressable identifier. The relationship:

• Data anchors: General mechanism for referencing any data
• SAIDs: Self-referential data anchors embedded in the data itself
• Usage: SAIDs are data anchors with additional self-addressing properties

Seals

Seals are the mechanism by which data anchors are embedded in key events. The relationship:

• Data anchors: The digest values themselves
• Seals: The data structures that contain and contextualize data anchors
• Usage: Seals provide semantic meaning to data anchors in KELs

Digests

Digests are the raw cryptographic hash outputs. The relationship:

• Digests: The cryptographic primitive (hash output)
• Data anchors: The application of digests for data referencing
• Usage: All data anchors are digests, but not all digests are used as anchors

Merkle Trees

Merkle tree roots are specialized data anchors that commit to multiple data items:

• Single data anchor: References one data item
• Merkle root: Data anchor that commits to a tree of data items
• Usage: Enables efficient anchoring of large datasets with selective disclosure

Composition Patterns

Hierarchical Anchoring: Data anchors can reference other data anchors, creating chains:

Event A → Anchor(Data B) → Anchor(Data C) → Anchor(Data D)

Multi-Anchor Seals: Single events can contain multiple data anchors:

{
  "a": [
    {"d": "EAnchor1..."},
    {"d": "EAnchor2..."},
    {"d": "EAnchor3..."}
  ]
}

Cross-KEL Anchoring: Data anchors enable references between different identifiers' KELs, creating verifiable inter-identifier relationships without requiring shared infrastructure.

Disambiguation

The KERI documentation explicitly warns against confusing cryptographic data anchors with HTML anchor elements. The distinction:

HTML Anchors: Web navigation constructs that create clickable links within documents. These are purely presentational and provide no cryptographic security.

Cryptographic Data Anchors: Cryptographic commitments that provide integrity verification, content-addressability, and tamper-evidence. These are fundamental security primitives.

This disambiguation is critical because the term "anchor" appears in both web development and cryptographic contexts with entirely different meanings and security properties.

Data Retrieval:

• Implement content-addressable storage using anchors as keys
• Cache frequently accessed data with anchor-based invalidation
• Support both local and distributed storage backends

Security Best Practices

Collision Resistance:

• Never truncate digests below 256 bits
• Monitor for hash algorithm deprecation announcements
• Plan migration paths for algorithm upgrades

Pre-image Protection:

• Do not use data anchors as encryption keys
• Avoid revealing data unnecessarily even when anchored
• Implement proper access controls for anchored data

Timing Attacks:

• Use constant-time comparison for digest verification
• Avoid leaking information through timing channels
• Implement rate limiting for verification operations

Interoperability

Cross-System Anchoring:

• Document which hash algorithms your system supports
• Provide clear error messages for unsupported algorithms
• Implement graceful degradation for unknown derivation codes

Version Management:

• Support multiple CESR versions simultaneously
• Maintain backward compatibility for existing anchors
• Plan for future algorithm additions

Performance Optimization

Batch Processing:

• Compute multiple anchors in parallel when possible
• Use vectorized hash implementations
• Optimize for common data sizes

Caching Strategies:

• Cache computed anchors for frequently accessed data
• Implement anchor-based content deduplication
• Use anchor prefixes for efficient indexing

Testing Requirements

Test Vectors:

• Validate against official KERI test vectors
• Test all supported hash algorithms
• Verify correct CESR encoding/decoding

Edge Cases:

• Test with empty data
• Test with maximum-size data
• Test with malformed anchors
• Test with unknown derivation codes

Documentation

Implementation Documentation:

• Document supported hash algorithms
• Provide examples of anchor creation and verification
• Explain derivation code mappings
• Include performance characteristics

API Design:

• Provide clear interfaces for anchor creation
• Support both synchronous and asynchronous operations
• Include validation functions for anchors
• Offer utilities for anchor comparison and manipulation