CRYPTOGRAPHIC TOPOLOGY & DATA INTEGRITY

Merkle DAG Provenance Engine

Deterministic Git tree hashing using SHA-256 leaves. Cryptographic proof of commit content, directory topology, and whole-repository state with zero data leaks.

๐ŸŒฒ The Topology of Git Repositories

Every Git repository is inherently structured as a Directed Acyclic Graph (DAG). At any given commit, the repository consists of:

[ Merkle Root Hash (SHA-256) ] / \ / \ [ Subtree Hash A ] [ Subtree Hash B ] / \ / \ [ File 1 ] [ File 2 ] [ File 3 ] [ File 4 ] (SHA-256) (SHA-256) (SHA-256) (SHA-256)

While Git historically used SHA-1 (and is gradually introducing SHA-256 extensions), Git's internal hashes only serve storage identity within Git itself. They do not bind author identity, legal jurisdiction, or third-party cryptographic timestamp attestations into an immutable external record.

๐Ÿ›ก๏ธ GitProof's Merkle Attestation Process

GitProof's pkg/merklizer engine traverses the entire committed Git repository tree at HEAD in canonical POSIX order. It constructs a cryptographic binary Merkle tree:

  1. Canonical Leaf Hashing: Every tracked file is hashed with SHA-256. File paths are strictly normalized to prevent differences between Windows backslashes and Unix slashes.
  2. Deterministic Sorting: Leaves are sorted lexicographically by canonical path before pairing.
  3. Pairwise Reduction: Adjacent pairs are concatenated (LeftHash || RightHash) and hashed recursively until reaching a single 32-byte Merkle Root.
  4. Binding HEAD & Author: The Merkle root is bound together with the Git commit object ID, Git tree hash, author name, and email into the sealed proof.json envelope.
โšก The Avalanche Effect & Tamper Detection

Cryptographic hash functions guarantee the avalanche effect: altering even a single whitespace or comma in any file within a multi-gigabyte repository changes the leaf hash completely. That change cascades up the tree, yielding an entirely different Merkle root. Any silent tampering, backdooring, or license stripping is immediately detected.

๐Ÿ”ฌ Working Tree Dirtiness Verification

Legal authorship claims require proof that code existed in a committed, uncorrupted state. When you execute gproof status or gproof seal, GitProof inspects the working tree:

TERMINALInspecting Working Tree & Root Hash
gproof status

Repository Root:  /path/to/project
Branch:           main
Commit HEAD:      c32c9b82552ca3c3ce4a9b9cede9a84a502494ef
Tree Hash:        b79814e54af802270638c474680dc6942d1eb6b4
Author:           Justin Grant <jgrant27@gmail.com>
Authored At:      2026-10-15T13:18:45Z
Working Tree:     CLEAN (committed)
License:          Community Edition (Free)

If uncommitted changes or unstaged files are present, GitProof flags the working tree as DIRTY. For court-admissible FRE 902 certificates, GitProof ensures only committed revisions are sealed into official judicial exhibits.

๐Ÿ”’ Zero Source Code Leaks

Because the Merkle root is a one-way cryptographic digest, you can safely share your proof.json, publish README authorship badges, and register your proof with legal counsel without disclosing a single line of proprietary code or confidential algorithm logic.