ATL Protocol Specification (v1.0.0)

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

This document specifies the Anchored Transparency Log (ATL) Protocol version 1.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.

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 of the Merkle Tree (the “Checkpoint”) is made public or anchored in a trusted timestamping service.
3. Portable Evidence: Verification is performed using a “Receipt” — a self-contained cryptographic proof that links a specific private entry to the public anchor.

1.2. 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.

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.

Offset  Size   Field         Encoding
------  ----   -----         --------
0       18     Magic Bytes   "ATL-Protocol-v1-CP" (ASCII)
18      32     Origin ID     SHA256 of Instance 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.

{
  "spec_version": "1.0.0",
  "entry": {
    "id": "<UUID>",
    "payload_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>"
    },
    "consistency_proof": {
       "from_tree_size": <integer>,
       "path": [ "sha256:<hex>", ... ]
    }
  },
  "anchors": [
    {
      "type": "rfc3161",
      "timestamp": "<ISO8601>",
      "token_der": "base64:<string>"
    }
  ]
}

5. Verification Algorithm

A Verifier, possessing only the Evidence Receipt and the Log Operator’s trusted Public Key, MUST perform the following steps:

Step 1. Reconstruct Leaf Hash

Decode payload_hash, canonicalize metadata, and compute:

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

Step 2. Verify Checkpoint Signature

Reconstruct the 98-byte binary blob from the checkpoint fields and verify the Ed25519 signature using the trusted Public Key.

Step 3. Verify Inclusion Proof

Execute the Merkle Inclusion Proof algorithm (RFC 6962) using LeafHash, leaf_index, tree_size, and inclusion_path. The result must match the root_hash.

Step 4. Verify Consistency Proof (Conditional)

If a consistency_proof is present in the receipt, the Verifier MUST verify it to ensure the log’s append-only property. This step is REQUIRED when verifying receipts against a previously known tree state.

1. Retrieve the previously trusted Checkpoint (from local storage or prior verification).
2. Verify that consistency_proof.from_tree_size matches the previously trusted tree_size.
3. Execute the Merkle Consistency Proof verification algorithm (as defined in RFC 9162, Section 2.1.4) using:
   • from_tree_size (the previously trusted tree size)
   • to_tree_size (current proof.tree_size)
   • from_root_hash (the previously trusted root hash)
   • to_root_hash (current proof.root_hash)
   • consistency_proof.path
4. The algorithm MUST confirm that the old tree is a prefix of the new tree.

Note: If the Verifier has no prior knowledge of the log state (first-time verification), this step MAY be skipped. However, for ongoing monitoring scenarios, Verifiers SHOULD maintain a local record of the last verified Checkpoint.

Step 5. Verify Anchors (Optional)

If anchors are present, the Verifier SHOULD verify them to establish independent temporal proof.

• RFC 3161:
  1. Decode token_der (ASN.1 DER).
  2. Verify the cryptographic signature of the Time Stamping Authority (TSA).
  3. Verify that the MessageImprint within the token matches proof.root_hash.

6. Security Considerations

6.1. Hash Collisions

The security of the log depends on the collision resistance of SHA-256.

6.2. Key Management

The integrity of the Checkpoints relies entirely on the secrecy of the Log Operator’s private key. Implementations SHOULD support key rotation mechanisms.

6.3. Privacy

By design, the Inclusion Proof reveals O(log n) intermediate hashes. The probability of guessing the content of a sibling hash is negligible (2^-256).

6.4. Log Integrity and Split-View Attack Prevention

A malicious Log Operator could attempt to present different views of the log to different parties (a “Split-View” or “Fork” attack). ATL employs a layered defense:

1. Consistency Proofs: Verifiers who maintain state can detect forks by requiring Consistency Proofs between successive Checkpoints. If a Log Operator attempts to present inconsistent tree states, the Consistency Proof verification will fail.

2. External Anchoring: 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.

3. Gossip Protocols: For high-assurance scenarios, Verifiers MAY implement gossip protocols to compare Checkpoints with other parties.