2026-10-06 timestamp git blockchain proof

How to Verify a Git Repository’s Bitcoin Timestamp

You have a .ots receipt in your repository. Now someone — a lawyer, an auditor, an acquirer doing technical due diligence — asks the only question that matters: how do we know this is real?

That question is the whole point of cryptographic prior art. A timestamp you can’t independently verify is just a claim in a database. A timestamp anyone can verify against the Bitcoin blockchain is evidence. This article walks through the verification path for repositories anchored by Timestamp GIT, from the README badge down to the Merkle proof.

Why Verification Matters for Git Timestamps

Git history is surprisingly easy to dispute. Commit dates are set by the machine that made the commit, so they can be backdated with a single environment variable. Hosted history lives on servers you don’t control, and self-hosted history lives in a database someone with admin rights can rewrite. In a legal audit, both are routinely dismissed as self-serving.

Cryptographic anchoring closes that gap — but only if the proof can be checked by a third party who trusts neither you nor the vendor. That means two requirements:

Verification must not require trusting Timestamp GIT. The proof is a SHA-256 hash chain terminating in a Bitcoin block. Anyone can walk that chain with open-source tooling.
Verification must not require exposing your source code. Timestamp GIT operates on a zero-knowledge model: the service receives commit hashes, never file contents. There is nothing to inspect but hashes — which is exactly what an auditor wants, since it means the proof can be shared without sharing the codebase.

Because of that design, verification is a cryptographic exercise, not a code review. Auditors, opposing counsel, or an acquiring company’s engineering team can all validate the same receipt and reach the same conclusion.

What a Timestamp GIT Proof Looks Like

After the nightly anchoring run, each monitored repository gets three artifacts:

A daily manifest (.txt) — the list of commit hashes batched for that day, one file per repository.
A Merkle root — the single SHA-256 hash computed from that manifest. All the individual hashes collapse into one value.
An .ots receipt — the OpenTimestamps proof that binds the Merkle root to a specific Bitcoin block.

These artifacts are pushed back into your repository in a dedicated timestamps branch, or into a separate shadow repository if you prefer to keep the source repo clean. Either way, the proofs are versioned alongside the code they attest to, but in their own ref — nothing is ever committed to your working branches.

Two things are worth stating plainly:

The proof contains no source code. Only commit hashes and their cryptographic reductions.
The proof is not proprietary. It is a standard OpenTimestamps receipt over a Bitcoin transaction, and it stays valid whether or not Timestamp GIT is still around.

Once the receipt file is in your repo, you have everything needed to verify — the rest is tooling.

Step-by-Step Verification Using Timestamp GIT’s Tools

Step 1 — Locate the proof

Open the timestamps branch (or shadow repo) and find the manifest for the date in question, plus the matching .ots file. If you’d rather not hunt through branches, the repository status page shows the same information in a browser:

https://timestampgit.dev/status/{user}/{repo}

Step 2 — Read the public status page

The status page is the fastest sanity check. It shows:

Proof longevity and the earliest anchor date
Daily regularity (a calendar heatmap of anchored days)
The Bitcoin block and transaction that carry the anchor
Download links for the audit CSV and the PDF certificate

For automated checks, the same data is exposed as JSON:

# Last anchored Bitcoin block
curl -s https://timestampgit.dev/api/statusLast/acme/payments-service

# Total number of stamped commits
curl -s https://timestampgit.dev/api/statusCount/acme/payments-service

# Combined summary (used by the Shields.io badges)
curl -s https://timestampgit.dev/api/statusSummary/acme/payments-service

Step 3 — Verify a specific date in the browser

For day-level proof, use the cryptographic verification page:

https://timestampgit.dev/verification/{user}/{repo}/{date}

This page performs the full multi-level Merkle chain verification locally in your browser. The commit hash, the manifest, the Merkle path, and the Bitcoin block header are all checked on your machine — the page does not upload what you’re verifying. That property matters when the repository is private or under NDA: the auditor can confirm the proof without the vendor learning which date they cared about.

Step 4 — Pull the audit ledger or PDF certificate

Compliance teams usually need an artifact they can file. Both are one request away:

# Full audit ledger as CSV
curl -fsSL https://timestampgit.dev/api/audit/acme/payments-service -o audit.csv

# PDF certificate for one day
curl -fsSL https://timestampgit.dev/api/report/acme/payments-service/2026-09-14 -o certificate.pdf

Step 5 — Optionally, embed a verification badge

The badge widget at /connected/{user}/{repo} gives you a live preview and a ready-to-paste Markdown snippet for your README. Drop it in and anyone — a customer, an investor, a prospective acquirer — can click through to the public verification view:

<!-- Snippet copied from https://timestampgit.dev/connected/acme/payments-service -->
[![Bitcoin-timestamped](BADGE_IMAGE_URL)](VERIFY_LINK)

Every step above runs on the managed GitHub App workflow. You install the app once, and verification is a page load or an HTTP request — no command-line tools, no manual protocol handling, nothing to maintain on developer machines.

Interpreting Verification Results and Edge Cases

A successful verification tells you something narrow and powerful: the commit hash existed at or before the timestamp of the Bitcoin block referenced by the receipt, and the Merkle proof links that specific hash to that block. Because Bitcoin blocks cannot be rewritten without redoing the proof-of-work, the “at or before” bound is absolute.

A few situations come up regularly:

No proof for a given date. Usually means there were no commits that day — the manifest is built from pending hashes, so an empty day produces nothing to anchor. Check the heatmap on the status page to confirm.
Pending confirmation. Anchoring is a two-stage process. The nightly cron worker batches hashes, builds the Merkle tree, and submits the root to public OpenTimestamps calendars; confirmation in a Bitcoin block then takes a few hours — normally around three. A proof written shortly after midnight may therefore not be final until later that morning.
Private repositories. Access to the status and verification pages for private repos requires an encrypted HMAC appended to the URL. The HMAC is specific to the server instance, so links cannot be replayed against another deployment.
Vendor independence. If you’d rather not use the hosted verifier at all, download the .ots file and run it through the open-source OpenTimestamps tooling against the Bitcoin blockchain yourself. That is the hard way, and it’s slower, but it exists — and its existence is what makes the managed path credible.

Verifying in Enterprise and Self-Hosted Environments

Enterprise ZK mode. A 12-line GitHub Action runs on your own infrastructure and pushes only commit hashes to the Timestamp GIT API. The service never has read access to the source repository; you only need read-write access to the target repository that receives proofs. Verification is unchanged — the same .ots files, the same public Bitcoin data, the same browser-based Merkle checks.

Docker self-hosted. For air-gapped environments, Timestamp GIT ships as a Docker image you run yourself. A quick-start Docker Compose setup looks like this:

services:
  timestampgit:
    image: rue1401/timestampgit:prod
    ports:
      - "8080:8080"
    volumes:
      - ./data:/app/data
    restart: unless-stopped
  valkey:
    image: valkey/valkey:8
    restart: unless-stopped

docker compose pull
docker compose up -d
docker compose logs -f timestampgit

The instance is available at http://localhost:8080, and a setup wizard on first launch walks you through connecting your GitHub App and configuring the deployment. Verification works entirely inside your network: the .ots files, the manifests, and the local verifier are all you need.

A time-limited demo license for evaluation is available by submitting the request form on the Docker license page with your name, company, email, and optional phone number; the license file can be downloaded immediately.

Automating Verification for Compliance Teams

Manual verification is fine for one audit. Continuous compliance wants it in a pipeline. The REST API covers that:

#!/usr/bin/env bash
set -euo pipefail

REPO="acme/payments-service"
BASE="https://timestampgit.dev/api"

# Merkle chain data for local verification of a specific day
curl -fsSL "$BASE/verify/$REPO/2026-09-14" -o "verify-2026-09-14.json"

# Monthly audit ledger
curl -fsSL "$BASE/audit/$REPO" -o "audit-$REPO.csv"

# PDF certificate per anchored day
curl -fsSL "$BASE/report/$REPO/2026-09-14" -o "certificate-2026-09-14.pdf"

For dashboards, poll the status endpoints rather than the full verification payload:

# Feed /api/statusLast and /api/statusCount into your monitoring system
curl -fsSL "$BASE/statusLast/$REPO"
curl -fsSL "$BASE/statusCount/$REPO"

A useful pattern is to treat a stale statusLast as an alert condition: if the last anchored block hasn’t moved in more than a day for a repo with active commits, something in the pipeline needs attention. All verification computation happens locally in the browser or inside your own script — no sensitive payload leaves your control. If you’re still setting up the anchoring side of this, see Automated Git Timestamping: How a GitHub App Anchors Every Commit; this article is deliberately about what happens after.

FAQ

Do I need to run any command-line tools to verify a Timestamp GIT proof? No. Timestamp GIT provides a web-based verification page that performs all cryptographic checks locally in your browser. You can also download the .ots file and use standard OpenTimestamps tools if you prefer, but the managed service requires no CLI usage.

Can I verify a timestamp without trusting Timestamp GIT? Yes. The proof relies solely on SHA-256 hashes and Bitcoin block data. You can independently verify the .ots file against the Bitcoin blockchain using open-source OpenTimestamps tools, ensuring vendor independence.

How long does it take for a timestamp to become verifiable? After the nightly cron job anchors the Merkle root into a Bitcoin transaction, it typically takes around 3 hours for the transaction to be confirmed in a Bitcoin block. Once confirmed, the proof is immutable and verifiable.

Can I verify timestamps for private repositories? Yes, but access to the status and verification pages for private repositories requires an encrypted HMAC appended to the URL. This ensures only authorized users can view the proof details.

Conclusion

Verification is where a timestamp stops being a promise and becomes evidence. The chain is short and checkable: commit hash → daily manifest → Merkle root → Bitcoin block. Whether you confirm it on the status page, run the browser-based Merkle verification, or pull the CSV ledger for a filing, the conclusion rests on Bitcoin math rather than on anyone’s word — including ours.

Install the GitHub App on a repository, let the nightly run do its work, then verify a date yourself before anyone asks you to. It takes a few minutes and it’s the difference between “we think we can prove it” and “here’s the proof.”

How to Verify a Git Repository's Bitcoin Timestamp