Protecting Agency Code Deliverables With Blockchain Proof

Elena runs a five-person dev shop. Eleven months ago she signed a client for a customer portal: three milestones, fixed price, invoicing on delivery. Milestones one and two went fine. Milestone three shipped on a Friday in September — feature complete, tested, deployed to the client’s staging environment. Then the invoice arrived, and the client went quiet.

Two weeks later, the reply: “The reporting module was never actually delivered. We’re not paying the final invoice, and we want a credit for the delay.”

Elena has evidence. Sort of. There’s an email thread where the client’s own product manager wrote “looks good, we’ll test next week.” There’s a shared Google Drive folder with exported specs. And there’s the GitHub repository — 400+ commits ending exactly when she says they ended, with the reporting module shipping six weeks before the invoice.

None of it is neutral. The email thread is a screenshot war. The Drive folder has files whose modified dates the client can (and did) question. The Git history lives in an organization the client co-owns, and commit dates can be rewritten with a single git rebase and a force push. In a payment dispute, “we have internal logs” is worth roughly nothing — it’s evidence you produced about yourself, on systems you control.

This article is a practical playbook for agencies that want the opposite: a record that neither party controls, that doesn’t require the client’s goodwill to verify, and that survives the client changing the repository, the hosting provider, or the story.

Cryptographic proof of existence solves exactly this problem. And since 2026 you don’t need to understand the cryptography to use it — the managed layer does the work.

Why Blockchain Proof Matters for Agencies (Not Just Patent Trolls)

Blockchain timestamping gets filed under “patent defense,” which is why most agencies ignore it until they need it. But patent trolls aren’t the daily risk for a dev shop. Clients with a cash-flow problem are.

Four concrete places where a Bitcoin-anchored commit record pays for itself:

• Payment disputes. You can prove the exact date a milestone was committed — not when an invoice was sent, not when someone said “done” in Slack. The date is derived from a Bitcoin block, not from your server clock or the client’s.
• Liability shielding. Scope-creep arguments usually hinge on when something was agreed versus when it was built. An immutable, per-day record of what existed at each point in the project lets you show that a change request landed after delivery, without arguing about anyone’s calendar.
• Portfolio and reuse protection. Most agencies carry a component library — an auth module, a billing adapter, a CMS integration — that shows up in a dozen client projects. Proving you authored it, and when, protects you if a former client claims you lifted their code.
• Client trust as a feature. A delivery package that includes a verifiable certificate of authorship reads differently in a procurement negotiation than one that includes a PDF you generated yourself.

This is not primarily a patent story. If you want the prior-art angle — invalidating broad patents, protecting trade secrets before filing — that’s covered in the sibling post on prior art protection for software startups. Here we’re staying on the commercial relationship.

A Practical Playbook: Setting Up Blockchain Proof for Agency Repos

The whole setup is five steps, and four of them are one-time. Nothing here requires your developers to learn a new tool or change a single command.

Step 1 — Install the Timestamp GIT GitHub App

Install the app on the repositories you use for client work. In Standard Mode the GitHub App reads the HEAD commit hash of each monitored repository automatically and writes proofs into a dedicated branch (in the same repo or in a separate shadow repo, your choice). It requires read-only access to the source repo and read-write access to the target repo where proofs land.

Do this once, at the start of the engagement, not after the dispute starts. A timestamp created during a disagreement is worth a fraction of one created during normal delivery.

Step 2 — Let nightly anchoring happen

There’s no per-commit step. Commit hashes are detected via webhooks and queued in memory. Each night, a worker batches everything pending, builds manifest files per repository, constructs a Merkle tree, and anchors the Merkle root into the Bitcoin blockchain through the OpenTimestamps protocol using public calendars.

Bitcoin confirmation normally takes around three hours, so proofs are written back a few hours after the batch runs. From your side: you push code, and by the next morning the previous day’s work is anchored.

Step 3 — Put the verification badge in the client’s face (politely)

Embeddable badges are available for your README and for delivery reports. Anyone with the link can verify the timestamp via the public status page — no account, no login.

# Get ready-made badge markdown for your delivery report or README
curl -s https://timestampgit.dev/api/badgeLink/your-agency/client-portal

The badge is a Shields.io-compatible snippet, so it drops into a README, a Notion page, or the PDF you send with an invoice. On private repositories, the status URL carries an encrypted HMAC so only authorized people can read the status — the proof itself stays public and verifiable, the metadata doesn’t leak.

Step 4 — Export certificates and audit ledgers at milestones

At each milestone, pull the paperwork and attach it to the invoice.

# Full audit ledger as CSV — every anchored commit, every date
curl -s -o audit-client-portal.csv \
  "https://timestampgit.dev/api/audit/your-agency/client-portal"

# Per-day PDF certificate — include with the handover pack
curl -s -o certificate-2026-09-30.pdf \
  "https://timestampgit.dev/api/report/your-agency/client-portal/2026-09-30"

The repository status page gives you the same data visually: proof longevity, earliest anchor date, daily regularity, the Bitcoin block and transaction behind each anchor, a calendar heatmap, and the downloadable CSV and PDF. The /api/statusSummary/{user}/{repo} endpoint returns a combined summary if you want to pipe it into an internal dashboard.

Step 5 — (Optional) Enterprise ZK mode for sensitive clients

Some client contracts — defense, fintech, anything with a strict IP clause — forbid third-party access to source code. Enterprise ZK mode addresses that: a 12-line GitHub Action runs inside your infrastructure and pushes only commit hashes to the Timestamp GIT API. Your source never leaves your environment, and only the target repository needs write access.

Optional: self-hosted Docker

If a client requires air-gapped operation or data residency on your own hardware, Timestamp GIT ships as a Docker image. The quick-start Compose file:

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 app is on http://localhost:8080. A setup wizard on first launch walks you through the GitHub App connection and instance configuration. A time-limited demo license for evaluation can be requested from the Docker license page.

What to Avoid When Using Blockchain Proof for Client Work

Five mistakes agencies make here, in roughly descending order of frequency:

• Relying on internal Git logs alone. They’re editable, they’re stored on infrastructure you or the client control, and in an audit they get dismissed as self-serving. A commit date from GitHub is a claim; a commit hash inside a Bitcoin block is evidence.
• Trying to do the protocol by hand. You can drive the underlying OpenTimestamps machinery yourself with CLI tooling and your own calendar submissions — it’s the hard way, it needs a per-commit workflow your developers will forget, and it produces exactly the outcome you want with roughly a hundred times the maintenance. The managed layer exists so that no one on your team ever has to think about it.
• Timestamping only at project end. A single end-of-project proof says “this existed on date X.” A nightly chain says “this commit existed on this date, and that commit on that date, all the way through.” When a client disputes a timeline rather than a deliverable, granularity is the whole case.
• Keeping the proof to yourself. A proof the other side can’t check is a proof they’ll dispute. Put the badge in the README, send the status link, attach the PDF certificate.
• Ignoring the client’s privacy requirements. If the contract prohibits third-party code access, use Enterprise ZK mode or self-host. Do not quietly assume “hashes only” satisfies a clause that says “no third parties.”

How Timestamp GIT Fits Into Your Agency Workflow

The design goal is that timestamping is invisible until you need it:

• Zero setup for developers. Install the GitHub App once. Every commit to a monitored repository is queued automatically; the batch runs nightly. No new commands, nothing to install on developer machines.
• Zero-knowledge architecture. Timestamp GIT never sees, copies, or stores your source code. It stamps commit hashes. The fingerprint in step one is a one-way hash of repository state — nothing about your implementation is recoverable from it.
• Vendor-independent verification. The proof is a .ots receipt anchored in Bitcoin. Verification depends on SHA-256 and Bitcoin block data — no proprietary format. Anyone can download the receipt and check it with standard OpenTimestamps tools against the blockchain, even if Timestamp GIT disappeared tomorrow. There’s a step-by-step walkthrough in how to verify a Git repository’s Bitcoin timestamp.
• Integration points that fit agency paperwork. A REST API for status, audit CSV, and PDF certificates; embeddable badges for READMEs and delivery docs; a public status page clients can bookmark.
• Pricing that matches agency scale. Open Source (free) for public repositories, Pro Agency at $49/mo for private repos, Enterprise ZK at $199/mo when a contract demands isolation. Details on the pricing page.

For teams that want the mechanics rather than the playbook, the technical companion piece is automated Git timestamping: how a GitHub App anchors every commit.

FAQ

Do I need to change how my developers commit code?

No. Once the Timestamp GIT GitHub App is installed on a repository, every commit is detected automatically and its hash is queued for the nightly Bitcoin anchoring. Developers keep using their normal Git workflow with no extra commands or tools.

Can clients verify the proof themselves?

Yes. You can embed a verification badge in your README or delivery report that links to a public status page. Clients can also download the .ots receipt file and verify it independently against the Bitcoin blockchain using standard OpenTimestamps tools.

What if a client demands that no third party ever sees the code?

Use Enterprise ZK mode, where a 12-line GitHub Action runs on your infrastructure and pushes only commit hashes to the Timestamp GIT API. Your source code never leaves your environment. Alternatively, you can self-host Timestamp GIT using the provided Docker image for full control.

How long does it take for a commit to be anchored in Bitcoin?

Commit hashes are batched daily and anchored into a Bitcoin block via the OpenTimestamps protocol. The Bitcoin confirmation typically takes around three hours, after which the proof is immutable and verifiable.

Does this replace a contract?

No. It replaces the weakest part of a contract dispute: the factual record of what existed when. Your contract determines who owes what; the timestamp determines what was true on a given date.

Conclusion

Elena’s dispute resolved the way these usually do — a partial payment and a lost client. The frustrating part wasn’t the money. It was that she was right and had no way to demonstrate it that a third party would accept.

That’s the gap blockchain proof closes for agencies. Not the patent war, not the abstract future — the ordinary Tuesday where a client decides the invoice is optional, and your only defense is a record neither of you can edit.

Install the Timestamp GIT GitHub App on your client repositories, let the nightly anchoring run, and attach the certificate to your next invoice. It takes about ten minutes once, and it changes the tone of every delivery conversation after that.

Related posts

• Git Commit Timestamp Proof for Patent Disputes
• How to Verify a Git Repository’s Bitcoin Timestamp
• Automated Git Timestamping: How a GitHub App Anchors Every Commit