We anchor every AI-generated commit to Bitcoin. Here is why.

#ai #github #bitcoin #devops

We build software with an AI code editor. Every feature, every fix, every deploy: generated by AI, committed to GitHub, shipped to production.

That is the workflow. It works. But it has a gap.

The gap

Git records history. But git history is editable. You can rebase, force-push, amend, rewrite. A commit hash proves internal consistency, not external time. Nobody outside your system can verify when that commit actually existed.

For most teams this does not matter. For regulated industries, IP disputes, audit trails, or supply chain security: it matters a lot.

The question is simple: can you prove this code existed before Thursday?

With git alone, you cannot.

Why AI makes this urgent

When a human writes code, there is a paper trail: Slack messages, PR reviews, meeting notes, the developer's memory. Context exists outside the repository.

When AI writes code, the only record is the commit itself. There is no Slack thread. No one remembers writing it. If someone questions the timeline: when was this feature added? Was this fix deployed before the incident? The commit history is the only evidence.

And commit history can be rewritten.

What we did

We added one step to our CI/CD pipeline. Every push to main triggers a GitHub Action that:

Creates a deterministic archive of the repository
Computes a SHA-256 hash
Anchors the hash to Bitcoin via OpenTimestamps
Stores a .proof file as a build artifact

name: Anchor deploy to Bitcoin
on:
  push:
    branches: [main]

jobs:
  anchor:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: AnchoringTrust/anchor-action@v1
        with:
          api-key: ${{ secrets.UMARISE_API_KEY }}
          path: .

That is the entire change. No SDK in the codebase. No code modifications. One YAML block.

If you prefer the CLI directly: npx @umarise/cli proof snapshot.tar.gz : same result, more control.

The numbers

This is not a demo. It runs in production.

4,079 total attestations anchored to Bitcoin
Nearly all Bitcoin confirmed (independently verifiable)
0 human steps
Under 60 seconds anchor latency

Live numbers: umarise.com/case/ai-code-generation

Every number on that page is a live query against the production database.

The three-layer stack

Layer 3: Cryptographic proof    Bitcoin via OpenTimestamps
Layer 2: Version control        GitHub
Layer 1: Code generation        AI editor

Most teams have Layer 1 and 2. Layer 3 is the missing piece. Without it, the commit history is a claim, not proof.

What a proof contains

After every push the workflow produces:

snapshot.tar.gz           deterministic archive of the repo at that commit
snapshot.tar.gz.ots       OpenTimestamps proof file (Bitcoin tx path)

Anyone can verify it:

ots verify snapshot.tar.gz snapshot.tar.gz.ots
# Success: Bitcoin block 941168 attests data existed by 2026-03-19

Or drag-and-drop at verify-anchoring.org. No account. No API key. No trust required.

Why not just run OpenTimestamps yourself?

You can. OpenTimestamps is open source and the protocol is public.

But running it yourself means:

Maintaining calendar server infrastructure
Handling proof upgrades (OTS proofs go through multiple stages before Bitcoin confirmation)
Detecting and recovering from stuck proofs
Managing the proof lifecycle over time

The cryptography is the same. The difference is who runs the operations.

The deeper question

When your system creates a file, is there independent proof that this exact file existed at that moment, outside your own system?

For most systems the honest answer is no. Logs, timestamps, audit trails: all self-issued. All from the system under question.

This applies beyond code. Model checkpoints, dataset versions, research outputs, trading strategies: anything where the question "when did this exist?" might matter later.

The gap only becomes visible when it costs you. The time to close it is before that moment.

Try it on your next push: