Eternity Layer v2 — Portable, Offline‑Verified Provenance with Anchored Time Evidence

Authors. Eternity Layer Research Group — research@EternityLayer.org

Date. 27 October 2025 ·

Abstract. Eternity Layer is a content‑binding and time‑evidence protocol that turns arbitrary digital artifacts into compact, signed Eternity Packages (EPs) that can be verified offline. Version 2 consolidates and formalizes the design choices proven in the public prototype—hash‑based content commitments, deterministic canonicalization, portable envelopes, and human‑readable verification UX—while integrating thirteen substantive updates across identifiers, anchoring, similarity evidence, governance, interoperability, and economics.

1. Introduction

The integrity and timing of digital claims—who signed exactly which bytes when—are increasingly contested across media, scientific communication, software supply chains, and public records. Eternity Layer provides portable packages that bind bytes to signatures and optional multi‑ledger time evidence and that verify entirely offline. Scope of assertion is explicit: the system confirms integrity, authorship (keys), and time‑evidence; it does not certify factual truth or rights.

2. System Overview

Artifacts. EPs contain canonicalized content commitments, issuer keys and signatures, optional anchors and receipts.
Actors. Issuers, gateways, watchers, verifiers, replica operators, catalog publishers, witnesses.
Workflow. Create → Anchor → Verify; verification remains fully offline via portable proofs.

3. Cryptographic Foundations (EL‑RM2, EL‑C14N‑v2)

EL‑C14N‑v2. Deterministic JSON canonicalization (UTF‑8 only; minimal numbers; key ordering; stable escapes). Signatures bind canonical bytes.

EL‑RM2. Multi‑hash Rolling‑Merkle commitment with a wide authoritative digest (e.g., SHA3‑384) and optional legacy SHA‑256 for compatibility.

4. Package & Identifier (EP v1.1, DID Policy v1.1)

EPs list hashes[], a canonical did_full, optional did_short (UI alias with check digit), pubkeys[]/sig[], anchors[], and context.

Full‑root DID. Canonical; short aliases are UI‑only and never used as keys.
PQ‑Hybrid keys. Cosignature sets (m‑of‑n) support classical + post‑quantum families.

5. Transformation & Similarity Evidence (Truth‑DAG v2)

VCE‑v2 combines deterministic signals (char‑5‑gram MinHash, token‑3‑gram SimHash‑256, structure‑signature, rare anchors) with per‑segment alignment and hashed invariants (numbers/dates/entities). A Transformation Receipt v1.1 carries per‑segment alignment, a multi‑signal score (MSS), and optional witness cosignatures.

6. Keys, Identity, and Lifecycle (KBA + Eon Ops)

KBA v1.0. Bind keys to organizations via DNSSEC‑verifiable TXT, X.509/TLS statements, and OIDC JWTs—verifiable offline.

Eon Ops. Signed lifecycle statements: KCS (rotation), KSN (suspension), KRS (revocation) with as‑of semantics.

7. Time Evidence (Anchors, Gateways, Watchers) & CFS

Anchor‑Proof v1.1. Provider‑signed proofs with optional watcher observations (height, first‑seen).

Composite Finality Score (CFS v2). Per‑ledger reliability × operational quality aggregated in log‑odds; binary predicates (e.g., BTC depth ≥ N or ETH finalized) remain first‑class; profiles: BTC‑only, Dual, Tri, Lite.

8. Cost & Scale (Batching, Proof Bundles)

Hierarchical batching and light‑client proof bundles (BTC SPV, ETH MPT receipts, AR descriptors) enable offline acceptance without full nodes and amortize fees across many claims.

9. Governance, Safety, and Replication

Scope‑of‑Assertion banner, Safety Declarations (general/sensitive/restricted/prohibited), Replica‑Receipts, Catalogs, Tombstones, and a Data Availability Score (DAVS) maintain graph consistency and policy expression without forcing content hosting.

10. Interoperability

C2PA embedding (EP assertion), Sigstore/in‑toto coexistence (dual‑sign, receipts as links), and TUF wrapping for update metadata.

11. Tokenless Ecosystem Economics

SLC v1.0 and SR v1.0 provide auditable, signed service records for anchoring, watching, replication, and verification—no token required.

12. Security Analysis

Deterministic canonicalized bytes prevent serialization attacks.
Full‑root DID avoids prefix confusion; short aliases are UI‑only.
Provider/watchers signatures make misreporting auditable.
DAVS/Tombstones maintain availability semantics; receipts keep provenance traversable.

13. Case Studies & Evaluation

See the case‑study collection for sector‑specific deployments (media, software, clinical, legal, procurement, publishing, ML datasets, education). The test suite covers canonicalization, Merkle roots, DID binding, anchor proof validation (BTC/ETH/AR), VCE‑v2 scores and coverage, DAVS, and policy profiles.