BLAKE3 employs a binary tree structure as its fundamental architectural pattern, which fundamentally distinguishes it from traditional sequential hash functions. This tree-based design enables:

• Practically unlimited parallelism for sufficiently long inputs
• Support for both SIMD (Single Instruction, Multiple Data) operations
• Multithreading capabilities across multiple CPU cores
• Merkle tree format enabling verified streaming and incremental updates

The compression function is closely based on BLAKE2s but incorporates a critical optimization: the number of rounds is reduced from 10 to 7. This design decision reflects the assumption that current cryptographic standards tend to be overly conservative in their security margins, allowing BLAKE3 to achieve significantly higher performance while maintaining strong security properties.

Security Properties

BLAKE3 provides 128 bits of cryptographic strength in its 256-bit variant, which is considered sufficient for post-quantum security in hash functions. According to research by Daniel J. Bernstein referenced in KERI documentation, hash collision attacks remain inefficient on quantum computers compared to classical approaches, meaning BLAKE3's security properties are expected to hold even in a post-quantum computing environment.

Key security characteristics:

• Collision resistance: Computationally infeasible to find two inputs producing the same digest
• Pre-image resistance: Computationally infeasible to find an input producing a specific digest
• Second pre-image resistance: Computationally infeasible to find a different input producing the same digest as a given input
• Avalanche effect: Small changes in input produce dramatically different outputs
• Deterministic: Same input always produces same output

Performance Characteristics

BLAKE3 is specifically designed to be as fast as possible, achieving speeds consistently several times faster than BLAKE2—itself already known for high performance. The performance gains derive from:

• Reduced compression rounds: 7 rounds instead of 10
• Optimized compression function based on BLAKE2s
• Parallel processing architecture enabling scalable performance
• Efficient memory access patterns for modern CPU architectures

The Merkle tree format provides additional operational benefits:

• Verified streaming: On-the-fly verification of data as it's being processed
• Incremental updates: Ability to update hash values efficiently without reprocessing entire datasets
• Scalable parallelism: Performance scales with available computational resources

Output Sizes

BLAKE3 supports two primary output sizes in KERI:

Blake3-256 (256-bit / 32-byte output):

• Provides 128 bits of cryptographic strength
• Encoded as 44-character CESR text primitive
• Uses single-character derivation code E
• Primary digest algorithm for most KERI/ACDC operations

Blake3-512 (512-bit / 64-byte output):

• Provides 256 bits of cryptographic strength
• Encoded as 88-character CESR text primitive
• Uses two-character derivation code 0D
• Used for applications requiring higher security margins

As an XOF, BLAKE3 can technically produce outputs of any length, but KERI standardizes on these two sizes for interoperability.

Data Format & Encoding

CESR Encoding Format

In KERI's CESR (Composable Event Streaming Representation) encoding system, BLAKE3 digests are represented as qualified primitives that include both the digest value and metadata about the algorithm used.

Blake3-256 CESR Encoding:

• Derivation code: E (single character)
• Total length: 44 characters in text domain
• Structure: E + 43 Base64 characters encoding the 32-byte digest
• Binary length: 33 bytes (1 byte code + 32 bytes digest)

Blake3-512 CESR Encoding:

• Derivation code: 0D (two characters)
• Total length: 88 characters in text domain
• Structure: 0D + 86 Base64 characters encoding the 64-byte digest
• Binary length: 66 bytes (2 bytes code + 64 bytes digest)

Text Domain Representation

In the CESR text domain, BLAKE3 digests use Base64 URL-safe encoding (character set: A-Z, a-z, 0-9, -, _). The encoding follows CESR's composability requirements, ensuring 24-bit boundary alignment.

Example Blake3-256 text representation:

ELEjyRTtmfyp4VpTBTkv_b6KONMS1V8-EW-aGJ5P_QMo

Breakdown:

• E: Derivation code indicating Blake3-256
• LEjyRTtmfyp4VpTBTkv_b6KONMS1V8-EW-aGJ5P_QMo: 43 Base64 characters encoding the 32-byte digest

Binary Domain Representation

In the CESR binary domain, BLAKE3 digests are represented as raw bytes with a prepended derivation code:

Blake3-256 binary:

• First byte: 0x1C (binary representation of derivation code E)
• Following 32 bytes: Raw digest bytes
• Total: 33 bytes

Blake3-512 binary:

• First two bytes: Binary representation of derivation code 0D
• Following 64 bytes: Raw digest bytes
• Total: 66 bytes

Raw Domain Representation

In the CESR raw domain, a BLAKE3 digest is represented as a tuple:

("E", <32-byte digest>)  # Blake3-256
("0D", <64-byte digest>) # Blake3-512

This representation separates the derivation code metadata from the actual cryptographic material, which is useful for cryptographic operations that require the raw digest bytes.

Usage in KERI/ACDC

SAID Generation

BLAKE3-256 is the mandatory digest algorithm for generating SAIDs (Self-Addressing Identifiers) in KERI and ACDC. The SAID generation protocol follows these steps:

1. Reserve field space: Allocate 44-character field for SAID
2. Insert dummy string: Fill with # characters (ASCII 35)
3. Compute digest: Generate Blake3-256 digest of serialization
4. CESR encode: Encode digest with E derivation code
5. Replace dummy: Substitute dummy string with computed SAID

Example from ACDC specification:

{
  "v": "ACDC10JSON00011c_",
  "d": "ELEjyRTtmfyp4VpTBTkv_b6KONMS1V8-EW-aGJ5P_QMo",
  "i": "EAco5dU5WjDrxDBK4b4HrF82_rYb6MX6xsegjq4n0Y7M",
  "s": "EBfdlu8R27Fbx-ehrqwImnK-8Cm79sqbAQ4MmvEAYqao",
  "a": {
    "name": "John Doe",
    "role": "Developer"
  }
}

The d field contains the Blake3-256 SAID of the entire ACDC structure.

Key Event Log (KEL) Integrity

In KEL (Key Event Log) structures, BLAKE3 digests provide cryptographic chaining between events:

Inception Events: Include Blake3-256 digest of configuration data Rotation Events: Include Blake3-256 digest of previous event Interaction Events: Include Blake3-256 digest of previous event

This creates a hash chain where each event cryptographically commits to all previous events, making the log tamper-evident.

Pre-Rotation Commitments

KERI's pre-rotation mechanism uses Blake3-256 digests to commit to next keys:

{
  "v": "KERI10JSON00011c_",
  "t": "icp",
  "d": "EAco5dU5WjDrxDBK4b4HrF82_rYb6MX6xsegjq4n0Y7M",
  "i": "EAco5dU5WjDrxDBK4b4HrF82_rYb6MX6xsegjq4n0Y7M",
  "s": "0",
  "kt": "1",
  "k": ["DKxy2sgzfplyr-tgwIxS19f2OchFHtLwPWD3v4oYimBx"],
  "nt": "1",
  "n": ["ELEjyRTtmfyp4VpTBTkv_b6KONMS1V8-EW-aGJ5P_QMo"],
  "bt": "0",
  "b": [],
  "c": [],
  "a": []
}

The n field contains Blake3-256 digests of the next (pre-rotated) public keys, providing post-quantum secure commitment.

ACDC Attribute Commitments

In ACDC credentials, Blake3-256 enables selective disclosure through attribute commitments:

Compact Disclosure: Only SAIDs of attribute blocks are revealed Selective Disclosure: Individual attributes are blinded using Blake3-256 digests Full Disclosure: Complete attribute data is provided with verifiable SAIDs

Example compact ACDC:

{
  "v": "ACDC10JSON00011c_",
  "d": "ELEjyRTtmfyp4VpTBTkv_b6KONMS1V8-EW-aGJ5P_QMo",
  "i": "EAco5dU5WjDrxDBK4b4HrF82_rYb6MX6xsegjq4n0Y7M",
  "s": "EBfdlu8R27Fbx-ehrqwImnK-8Cm79sqbAQ4MmvEAYqao",
  "a": "ELEjyRTtmfyp4VpTBTkv_b6KONMS1V8-EW-aGJ5P_QMo"
}

The a field contains only the Blake3-256 SAID of the attribute block, enabling privacy-preserving disclosure.

Transaction Event Log (TEL) Anchoring

In TEL (Transaction Event Log) structures for credential registries, Blake3-256 digests anchor registry events to KEL events:

• Issuance events: Anchored via Blake3-256 seal in KEL interaction event
• Revocation events: Anchored via Blake3-256 seal in KEL interaction event
• Registry state: Verified through Blake3-256 digest chain

This creates a verifiable link between credential lifecycle events and the authoritative KEL.

Verification Procedures

SAID Verification:

1. Extract SAID from field
2. Replace SAID with dummy string (# characters)
3. Compute Blake3-256 digest of modified serialization
4. CESR encode computed digest
5. Compare to extracted SAID—equality proves integrity

Event Chain Verification:

1. Extract digest of previous event from current event
2. Compute Blake3-256 digest of previous event serialization
3. Compare computed digest to extracted digest
4. Repeat for entire chain back to inception

Pre-Rotation Verification:

1. Extract next key digest from previous event
2. Compute Blake3-256 digest of current event's public key
3. Compare computed digest to extracted digest
4. Equality proves key was pre-committed

Related Primitives

Alternative Hash Functions

While Blake3-256 is the primary digest algorithm in KERI, the specification supports multiple hash functions for cryptographic agility:

Blake2b-256 (derivation code F):

• Predecessor to Blake3
• 256-bit output
• Slower than Blake3 but widely supported
• Used in legacy systems or where Blake3 is unavailable

Blake2s-256 (derivation code G):

• Optimized for 8-32 bit platforms
• 256-bit output
• Suitable for resource-constrained environments

SHA3-256 (derivation code H):

• NIST standard hash function
• 256-bit output
• Used for regulatory compliance requirements

SHA2-256 (derivation code I):

• Widely deployed legacy algorithm
• 256-bit output
• Supported for interoperability with existing systems

Signature Primitives

BLAKE3 digests are often used in conjunction with signature primitives:

Ed25519 signatures (derivation code 0B):

• Sign Blake3-256 digests of events
• Provide non-repudiable authentication
• Standard signature algorithm in KERI

ECDSA secp256k1 signatures (derivation code 0C):

• Alternative signature algorithm
• Used for Bitcoin/Ethereum compatibility

Key Material Primitives

BLAKE3 digests commit to key material:

Ed25519 public keys (derivation code D):

• Digested for pre-rotation commitments
• Verified against Blake3-256 digests in next key fields

X25519 public keys (derivation code C):

• Used for encryption key commitments
• Digested for secure key exchange protocols

Composition Patterns

SAID + Signature Pattern:

SAID(event) = Blake3-256(event)
Signature = Ed25519.sign(SAID(event))

This pattern enables efficient verification—verifiers can check the signature against the SAID without recomputing the digest of the entire event.

Merkle Tree Pattern: BLAKE3's native Merkle tree structure enables efficient verification of large data sets:

Root = Blake3-256(Blake3-256(leaf1) || Blake3-256(leaf2))

This pattern is used for batch verification of multiple credentials or events.

Selective Disclosure Pattern:

Attribute_SAID = Blake3-256(attribute_value)
Aggregate_SAID = Blake3-256(Attribute_SAID_1 || ... || Attribute_SAID_n)

This pattern enables privacy-preserving credential disclosure where only selected attributes are revealed while maintaining verifiable commitments to undisclosed attributes.

Canonicalization:

• Always canonicalize input before hashing for SAID generation
• Use insertion-ordered field maps for JSON serialization
• Ensure consistent encoding (UTF-8 for text, specific byte order for binary)

Verification:

• Always verify SAIDs by recomputing digests
• Never trust SAIDs without verification
• Implement constant-time comparison for digest equality checks

Common Pitfalls

Incorrect Padding:

• CESR uses pre-padding with lead bytes, not post-padding
• Never use = pad characters in CESR-encoded Blake3 digests
• Ensure 24-bit boundary alignment

Wrong Derivation Code:

• Use E for Blake3-256, not F (Blake2b-256) or other codes
• Use 0D for Blake3-512, not 0E (Blake2b-512)
• Verify derivation code matches actual algorithm used

Canonicalization Errors:

• Inconsistent field ordering breaks SAID verification
• Whitespace differences cause digest mismatches
• Ensure serialization is deterministic and reproducible

Testing Recommendations

Test Vectors:

• Use official Blake3 test vectors for algorithm verification
• Test CESR encoding/decoding round-trips
• Verify SAID generation with known inputs

Edge Cases:

• Empty input (should produce valid digest)
• Very large inputs (test streaming/incremental hashing)
• Unicode and special characters (test canonicalization)

Performance Benchmarks:

• Measure throughput for typical event sizes
• Test parallel processing scalability
• Verify memory usage for large inputs