Skip to Content
The Protocol

ATL Protocol Specification (v2.0.0)

Author:   Dmitrii Zatona (Evidentum Labs, Inc.)
Status:   Draft Standard
Version:  2.0.0
Date:     January 2026

This document specifies the Anchored Transparency Log (ATL) Protocol version 2.0.0.

Abstract

It defines a cryptographic protocol for maintaining a privacy-preserving, verifiable, append-only log of facts and evidence from across the digital and physical domains.

Unlike traditional transparency logs which require public disclosure of all entries, ATL employs a Selective Disclosure model. This allows a log operator to prove the existence, integrity, and timestamp of specific entries to a verifier without revealing the contents of other entries in the log. The protocol utilizes Merkle Trees (RFC 6962) , Consistency Proofs (RFC 9162) , JSON Canonicalization Scheme (RFC 8785) , Ed25519 Signatures (RFC 8032) , SHA-256 (RFC 6234) , and RFC 3161  Time-Stamps with detached Evidence Receipts to enable offline verification.

1. Introduction

In modern digital infrastructure, proving the integrity and temporal existence of data is critical for auditability, compliance, and dispute resolution. Traditional solutions rely on centralized trusted third parties or fully public transparency logs (like Certificate Transparency).

Centralized solutions introduce a single point of failure and trust. Fully public logs, while verifiable, are unsuitable for sensitive business data or personally identifiable information (PII) due to data leakage risks.

The Anchored Transparency Log (ATL) Protocol addresses these limitations by decoupling the verification of the log’s integrity from the visibility of its contents.

1.1. Core Philosophy

The ATL Protocol is built upon the principle of Selective Disclosure and Receipt Self-Sufficiency.

  1. Private Storage: The full dataset and the Merkle Tree structure are stored privately by the Log Operator.
  2. Public Anchoring: Only the cryptographic root (the “Checkpoint”) is anchored in trusted timestamping services.
  3. Portable Evidence: Verification is performed using a “Receipt” — a self-contained cryptographic proof that links a specific private entry to the public anchor.
  4. Global Consistency: The Super-Tree architecture enables any two receipts to prove they belong to the same consistent log history.

Receipt-Centric Design: The Evidence Receipt is the primary artifact of the protocol. A Receipt-Full is fully self-contained and can be verified independently, even if the log server ceases to exist. Log Operators maintain multiple Data Trees (time-partitioned). All Data Tree roots are aggregated into a Super-Tree, which provides O(log N) proofs for global chain consistency.

Self-Sufficiency Guarantee: Given two Receipt-Full documents from the same log instance, a Verifier can cryptographically prove that the log history between them was not modified — without contacting any server. This is achieved through the super_proof.consistency_to_origin field, which proves each receipt’s Data Tree is part of the same append-only Super-Tree history.

1.2. Trust Model

A fundamental design principle of ATL is that Verifiers do NOT need to trust the Log Operator. Trust is derived exclusively from external, independent anchors:

  1. RFC 3161 TSA: A trusted third-party Time Stamping Authority cryptographically attests that a specific root_hash existed at a specific time.
  2. Bitcoin Blockchain: The immutable Bitcoin ledger provides a decentralized, permissionless proof that a specific root_hash was committed at a specific block height.

The Log Operator’s checkpoint signature serves only as an integrity check — it binds the tree state fields together and prevents accidental corruption. It does NOT establish trust. A malicious Log Operator cannot forge timestamps or rewrite history because:

  • TSA tokens are signed by independent authorities the Operator does not control.
  • Bitcoin proofs are verified against the public blockchain the Operator cannot modify.

Implication: A valid ATL receipt with at least one verified anchor is trustworthy even if the Verifier has never seen the Log Operator’s public key before. The anchor IS the trust anchor.

1.3. Terminology

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

  • Log Operator: The entity maintaining the append-only log.
  • Entry: A data record submitted to the log.
  • Checkpoint: A signed data structure attesting to the state of the Merkle Tree (Root Hash + Tree Size) at a specific point in time. Also known as Signed Tree Head (STH).
  • Receipt: A file containing the Entry, an Inclusion Proof, and a Checkpoint, allowing offline verification.
  • Anchor: An external timestamping token (e.g., RFC 3161 or Bitcoin transaction) proving the Checkpoint existed at a specific time.
  • Consistency Proof: A cryptographic proof that demonstrates the append-only property of the log by proving that an earlier tree state is a prefix of a later tree state. This prevents the Log Operator from rewriting history (Split-View attacks).

2. Cryptographic Primitives

To ensure interoperability and security, implementations MUST adhere to the following cryptographic standards.

2.1. Hashing Algorithm

All hashing operations MUST use SHA-256 [RFC6234]. In text representations (JSON), hashes MUST be encoded as lowercase hexadecimal strings prefixed with sha256:.

Example: "sha256:a1b2c3d4..."

2.2. Digital Signatures

Signatures for Checkpoints MUST use Ed25519 (EdDSA over Curve25519) [RFC8032]. In text representations (JSON), signatures MUST be encoded as standard Base64 strings prefixed with base64:.

Example: "base64:SGVsbG8gV29ybGQ..."

2.3. Canonicalization

To ensure deterministic hashing of structured metadata, all JSON objects MUST be canonicalized according to the JSON Canonicalization Scheme (JCS) [RFC8785] before being hashed.

3. Merkle Tree Structure

The ATL Protocol uses a binary Merkle Tree structure consistent with [RFC6962] (Certificate Transparency), with specific modifications for leaf construction.

3.1. Leaf Hash Calculation

The input to the Merkle Tree leaves is not just the payload, but a composite structure including metadata.

The hash of a leaf entry $L$ is calculated as:

LeafHash = SHA256( 0x00 || PayloadHash || MetadataHash )

Where:

  • 0x00 is a single byte prefix to prevent second-preimage attacks (distinct from node prefix).
  • PayloadHash is the 32-byte SHA-256 hash of the original document/data.
  • MetadataHash is the 32-byte SHA-256 hash of the JCS-canonicalized metadata JSON.

3.2. Internal Node Hash Calculation

The hash of an internal node $N$ is calculated as:

NodeHash = SHA256( 0x01 || LeftChildHash || RightChildHash )

Where:

  • 0x01 is a single byte prefix.
  • LeftChildHash and RightChildHash are the 32-byte hashes of the children.

3.3. Super-Tree (Global Chain Consistency)

To maintain cryptographic integrity across multiple Merkle Trees with O(log N) verification complexity, ATL employs a Super-Tree architecture. The Super-Tree is a standard RFC 9162 Merkle Tree where each leaf is the root hash of a closed Data Tree.

3.3.1. Super-Tree Structure

When a Data Tree is closed, its root hash is appended as a new leaf to the Super-Tree:

SuperTreeLeaf[i] = DataTree[i].root_hash

The Super-Tree provides:

  • A single Super Root representing the entire log history
  • O(log N) inclusion proofs for any Data Tree
  • O(log N) consistency proofs between any two log states

3.3.2. Genesis Super Root

The first Data Tree’s root becomes Super-Tree leaf #0. This hash, called genesis_super_root, serves as the immutable identifier for the log instance. All Receipt-Full documents include this value to enable cross-receipt verification.

3.3.3. Consistency to Origin

Every Receipt-Full MUST include a consistency proof from Super-Tree size 1 to the current size. This enables transitive verification:

  • Receipt A proves: its entry is in SuperRoot_v100 AND SuperRoot_v100 is consistent with genesis
  • Receipt B proves: its entry is in SuperRoot_v200 AND SuperRoot_v200 is consistent with genesis

Since both prove consistency with the same genesis, and Merkle trees are append-only, this mathematically guarantees that the history between them was not modified.

3.3.4. Two-Tier Anchoring

Super-Tree introduces a two-tier anchoring model:

Anchor TypeTargetPurpose
RFC 3161 (TSA)Data Tree RootImmediate timestamp proof
Bitcoin (OTS)Super RootEternal immutability + global consistency

TSA provides fast, legally-recognized timestamps. OTS provides Bitcoin-level immutability for the entire log history. Anchoring the Super Root (not individual Data Tree roots) in Bitcoin is more efficient: one anchor covers all trees.

4. Data Structures

4.1. Checkpoint (Wire Format)

To avoid parser ambiguities and ensure byte-for-byte signing consistency, the Checkpoint MUST be constructed as a fixed-length binary blob of exactly 98 bytes before signing.

Checkpoint Wire Format

Offset  Size   Field         Encoding
------  ----   -----         --------
0       18     Magic Bytes   "ATL-Protocol-v1-CP" (ASCII)
18      32     Origin ID     SHA256 of Tree UUID (binary)
50      8      Tree Size     u64 little-endian
58      8      Timestamp     u64 little-endian (Unix nanoseconds)
66      32     Root Hash     SHA256 root of Merkle tree (binary)
------  ----
Total:  98 bytes

4.2. Evidence Receipt (JSON)

The Evidence Receipt allows an offline verifier to prove that an entry exists in the log. Receipts MUST be saved with the file extension .atl.

{
  "spec_version": "2.0.0",
  "upgrade_url": "<URL>",
  "entry": {
    "id": "<UUID>",
    "payload_hash": "sha256:<hex>",
    "metadata_hash": "sha256:<hex>",
    "metadata": { ... }
  },
  "proof": {
    "tree_size": <integer>,
    "root_hash": "sha256:<hex>",
    "inclusion_path": [ "sha256:<hex>", ... ],
    "leaf_index": <integer>,
    "checkpoint": {
       "origin": "sha256:<hex>",
       "tree_size": <integer>,
       "root_hash": "sha256:<hex>",
       "timestamp": <integer_nanos>,
       "key_id": "sha256:<hex>",
       "signature": "base64:<string>"
    }
  },
  "super_proof": {
    "genesis_super_root": "sha256:<hex>",
    "data_tree_index": <integer>,
    "super_tree_size": <integer>,
    "super_root": "sha256:<hex>",
    "inclusion": [ "sha256:<hex>", ... ],
    "consistency_to_origin": [ "sha256:<hex>", ... ]
  },
  "anchors": [
    {
      "type": "rfc3161",
      "target": "data_tree_root",
      "target_hash": "sha256:<hex>",
      "tsa_url": "<URL>",
      "timestamp": "<ISO8601>",
      "token_der": "base64:<string>"
    },
    {
      "type": "bitcoin_ots",
      "target": "super_root",
      "target_hash": "sha256:<hex>",
      "timestamp": "<ISO8601>",
      "bitcoin_block_height": <integer>,
      "bitcoin_block_time": "<ISO8601>",
      "ots_proof": "base64:<string>"
    }
  ]
}

Field Definitions:

  • spec_version (REQUIRED): Protocol version. Currently “2.0.0”.
  • upgrade_url (OPTIONAL): URL to request an upgraded receipt with additional anchors (e.g., Bitcoin proof). Clients such as atl-cli can use this URL to automatically fetch Receipt-Full when Bitcoin confirmation is available.
  • entry (REQUIRED): The anchored entry data.
  • proof (REQUIRED): Cryptographic proof linking entry to the Data Tree root.
  • super_proof (REQUIRED for Receipt-Full): Cryptographic proof linking the Data Tree to the Super-Tree, enabling cross-receipt verification.
    • genesis_super_root: The root hash of Super-Tree at size 1 (first Data Tree’s root). Used to verify that two receipts belong to the same log instance.
    • data_tree_index: Position of this Data Tree in the Super-Tree (0-indexed).
    • super_tree_size: Size of the Super-Tree at the time of anchoring.
    • super_root: The Super-Tree root hash that was anchored.
    • inclusion: Merkle inclusion proof from Data Tree root to Super Root.
    • consistency_to_origin: RFC 9162 consistency proof from size 1 to super_tree_size.
  • anchors (REQUIRED for trust): External timestamp proofs. Each anchor specifies its target (what it anchors) and target_hash.
    • RFC 3161 anchors target data_tree_root for immediate timestamps.
    • Bitcoin OTS anchors target super_root for eternal immutability and global consistency.

5. Verification Algorithm

A Verifier, possessing only the Evidence Receipt, MUST perform the following steps to validate the receipt. Trust is established through external anchors (Section 5.5), NOT through the Log Operator’s key. If any step fails, the receipt is considered invalid.

5.1. Step 1: Reconstruct Leaf Hash

The Verifier must verify the integrity of the entry data.

  1. Decode receipt.entry.payload_hash from the Hex string to raw bytes.
  2. Canonicalize receipt.entry.metadata using JCS [RFC8785].
  3. Calculate MetadataHash = SHA256(CanonicalMetadata).
  4. If receipt.entry.metadata_hash is present, verify it matches the calculated MetadataHash.
  5. Calculate LeafHash = SHA256(0x00 || PayloadHash || MetadataHash).

5.2. Step 2: Verify Checkpoint Integrity

The Verifier must verify the internal consistency of the checkpoint. This step ensures the checkpoint fields are properly bound together, but does NOT establish trust (trust comes from anchors in Step 5).

  1. Reconstruct the 98-byte binary blob using fields from proof.checkpoint:
    • Magic Bytes (ATL-Protocol-v1-CP)
    • Origin ID (Decoded from origin)
    • Tree Size (Little-Endian 64-bit)
    • Timestamp (Little-Endian 64-bit)
    • Root Hash (Decoded from root_hash)
  2. If the Log Operator’s public key is available, verify the Ed25519 signature in proof.checkpoint.signature against the reconstructed blob. This is an integrity check, not a trust establishment.
  3. Verify that proof.checkpoint.root_hash matches proof.root_hash.
  4. Verify that proof.checkpoint.tree_size matches proof.tree_size.

Note: Even if the checkpoint signature cannot be verified (unknown key), the receipt MAY still be valid if anchor verification (Step 5) succeeds. The anchor cryptographically commits to the same root_hash, providing independent verification.

5.3. Step 3: Verify Inclusion Proof

The Verifier must prove that the LeafHash is a member of the tree defined by RootHash.

  1. Execute the Merkle Inclusion Proof verification algorithm (as defined in RFC 6962) using:
    • LeafHash (from Step 1)
    • leaf_index
    • tree_size
    • inclusion_path
  2. The resulting Root Hash computed from the path MUST strictly equal proof.root_hash.

5.4. Step 4: Verify Super-Tree Proof (Receipt-Full)

If super_proof is present, the Verifier MUST verify it to establish global chain consistency. This step is REQUIRED for Receipt-Full and enables cross-receipt verification.

5.4.1. Verify Super-Tree Inclusion

  1. Verify that proof.root_hash (Data Tree root) is included in the Super-Tree at position super_proof.data_tree_index.
  2. Execute the Merkle Inclusion Proof verification algorithm (RFC 9162) using:
    • Leaf: proof.root_hash
    • Index: super_proof.data_tree_index
    • Tree Size: super_proof.super_tree_size
    • Path: super_proof.inclusion
  3. The resulting root MUST equal super_proof.super_root.

5.4.2. Verify Consistency to Origin

  1. Execute the Merkle Consistency Proof verification algorithm (RFC 9162, Section 2.1.4) using:
    • from_tree_size: 1 (genesis)
    • to_tree_size: super_proof.super_tree_size
    • from_root_hash: super_proof.genesis_super_root
    • to_root_hash: super_proof.super_root
    • path: super_proof.consistency_to_origin
  2. The algorithm MUST confirm that the genesis state is a prefix of the current state.

Result: If both sub-steps succeed, the receipt is cryptographically linked to the global log history from genesis.

5.4.3. Cross-Receipt Verification

To verify that two receipts (A and B) belong to the same consistent log history:

  1. Verify each receipt independently (Steps 1-4).
  2. Verify that A.super_proof.genesis_super_root == B.super_proof.genesis_super_root.
  3. If both receipts have the same genesis_super_root and valid consistency_to_origin proofs, the log history between them was not modified.

No server access required. Only the two receipts are needed.

5.5. Step 5: Verify Anchors (REQUIRED for Trust)

At least one anchor MUST be verified to establish trust in the receipt. Anchors provide independent, third-party proof that a specific hash existed at a specific time. Without a verified anchor, the receipt proves only internal consistency, not temporal existence.

A receipt without any verified anchors SHOULD be treated as untrustworthy.

5.5.1. RFC 3161 Anchor (type: "rfc3161", target: "data_tree_root")

TSA anchors provide immediate timestamp proof for the Data Tree root.

  1. Verify that anchor.target equals "data_tree_root".
  2. Verify that anchor.target_hash equals proof.root_hash.
  3. Decode token_der (ASN.1 DER).
  4. Verify the cryptographic signature of the Time Stamping Authority (TSA).
  5. Verify that the MessageImprint within the token matches anchor.target_hash.

5.5.2. Bitcoin OpenTimestamps Anchor (type: "bitcoin_ots", target: "super_root")

OTS anchors provide eternal immutability proof for the Super-Tree root, covering the entire log history.

  1. Verify that anchor.target equals "super_root".
  2. Verify that anchor.target_hash equals super_proof.super_root.
  3. Decode ots_proof (OpenTimestamps binary format).
  4. Verify the OTS proof chain from anchor.target_hash to the Bitcoin block.
  5. Verify that bitcoin_block_height and bitcoin_block_time match the proof.

5.5.3. Trust Hierarchy

Receipt TierAnchorsTrust Level
Receipt-LiteNoneInternal consistency only
Receipt-TSARFC 3161Immediate timestamp (TSA trust)
Receipt-FullRFC 3161 + Bitcoin OTSEternal immutability (Bitcoin trust) + Global consistency

For maximum trust, Verifiers SHOULD require both RFC 3161 and Bitcoin OTS anchors (Receipt-Full).

6. Security Considerations

6.1. Hash Collisions

The security of the log depends on the collision resistance of SHA-256. While currently considered secure, future revisions of this protocol MAY introduce algorithm negotiation if SHA-256 is compromised.

6.2. Key Management and Trust

The Log Operator’s private key is used to sign Checkpoints. However, this signature serves as an integrity mechanism, not a trust anchor. Verifiers do NOT need to trust the Log Operator’s key to validate a receipt — trust is derived from external anchors (TSA, Bitcoin).

The key_id field in the Checkpoint structure allows implementations to support key rotation. If the Log Operator’s public key is available (e.g., from a previous interaction or published directory), Verifiers MAY verify the checkpoint signature as an additional integrity check.

Key Distribution: There is no requirement for out-of-band key distribution. A Verifier encountering a receipt for the first time can fully validate it using only the anchor verification, without any prior knowledge of the Log Operator.

6.3. Privacy and Selective Disclosure

6.3.1. Information Leakage

By design, the Inclusion Proof reveals O(log n) intermediate hashes of the tree. While these hashes are cryptographically opaque, they represent the existence of other entries. The probability of guessing the content of a sibling hash is negligible (2^-256), assuming sufficient entropy in the original entries.

6.3.2. Metadata Privacy

Log Operators MUST ensure that sensitive PII is not included in the metadata object unless it is intended to be disclosed to any holder of the Evidence Receipt. For highly sensitive metadata, it is RECOMMENDED to use encrypted fields within the metadata or store only the hash of the metadata off-log.

6.3.3. Unlinkability

ATL receipts for different entries in the same log will share some intermediate nodes in their inclusion paths. An observer possessing multiple receipts can reconstruct partial segments of the tree structure. However, without the corresponding payloads, this information cannot be used to de-anonymize the entries.

6.4. Log Integrity and Split-View Attack Prevention

6.4.1. The Split-View Attack

A malicious Log Operator could attempt to present different views of the log to different parties (a “Split-View” or “Fork” attack). For example, presenting a log containing entry X to one verifier, while presenting a different log without entry X to another verifier. Without countermeasures, the Log Operator could later claim the entry never existed by presenting only the forged view.

6.4.2. Defense Mechanisms

ATL employs external anchoring as the primary defense against Split-View attacks:

  1. External Anchoring (Primary): By anchoring Checkpoints in immutable external systems (RFC 3161 TSAs, Bitcoin blockchain), the Log Operator commits to a specific tree state at a specific time. Any attempt to present an alternative history will conflict with the anchored commitment. This is the primary trust mechanism. A receipt with a verified Bitcoin anchor is permanently protected — the anchor cannot be revoked or modified.

  2. Consistency Proofs (Within a Tree): For entries between anchor points within the same tree, Consistency Proofs demonstrate that the tree grew append-only. This prevents the Operator from presenting different tree states to different parties within the same tree.

  3. Gossip Protocols (Out of Scope): For high-assurance scenarios, Verifiers MAY implement gossip protocols to compare Checkpoints with other parties. While this mechanism is out of scope for this specification, the Checkpoint structure supports such cross-verification.

For trustworthy verification, Verifiers MUST:

  1. Verify at least one external anchor (RFC 3161 or Bitcoin). This is the primary and sufficient trust mechanism.

For additional assurance within a single tree, Verifiers MAY:

  1. Maintain a local record of the last verified Checkpoint for each Origin ID.
  2. Request and verify Consistency Proofs when presented with new receipts from the same tree.
Last updated on
MotivationData Structures