Wakir Labs

Verify a Wakir Labs commit

Commits in this repository — and in our internal governance history — are timestamped against the Bitcoin blockchain via OpenTimestamps. The proof is a small .ots file, checked in next to the commit hash. Those two things are all you need: with a commit hash and its matching .ots file, anyone can establish — without trusting us — that the commit existed no later than a specific Bitcoin block.

This is the public side of Proof-of-History in practice. It is what we mean when we say the documentation is anchored.

What this covers

In this repository, all 60 proof files carry a Bitcoin attestation — a block, not a calendar promise. 46 of them only reached that state on 2026-09-15; they had been sitting unconfirmed in the calendar servers since May. Re-checked 2026-09-20.

The three code repositories carry none. wakir-runtime, wakir-protocol and wakir-verify have no meta/timestamps/ directory at all (measured 2026-09-15). An earlier version of this page claimed every commit in every Wakir Labs repository was timestamped. It was not. Whether to extend commit stamping to those repositories is an open decision; until it is made, this page describes what exists.

Three steps

1. Install the OpenTimestamps client

The reference client is ots, distributed as a Python package. On any platform with Python 3.8+: 

pip install opentimestamps-client

Verify the install: 

ots --version

2. Get the commit and its .ots proof

Clone the repository you want to verify. The proof files live under meta/timestamps/<short-hash>.ots: 

git clone https://github.com/wakir-labs/site.git
cd site
ls meta/timestamps/

Each file is the .ots attestation for one commit, indexed by the commit's short hash.

Not every file names a commit you can check out. Measured on 2026-09-20: of 60 proof files, 28 resolve in a plain clone. The rest were stamped on branch commits that squash-merging replaced, so the hash survives in the filename but not in main's history. Pick one that resolves — the worked example below is one of them: 

for f in meta/timestamps/*.ots; do
  h=$(basename "$f" .ots)
  git rev-parse --verify --quiet "$h" >/dev/null && echo "$h"
done

3. Run ots verify

For a worked example, take commit 82d40f7 from this site's history ("feat(about): add EN+DE about pages"): 

# From inside the cloned repo:
printf "%s\n" "$(git rev-parse 82d40f7)" > /tmp/commit.txt
ots verify -f /tmp/commit.txt meta/timestamps/82d40f7.ots

The hook stamps the 40-character commit hash as ASCII text, with a trailing newline — which is exactly what printf "%s\n" writes. Two earlier versions of this page told you to feed the raw hash bytes (xxd -r -p) instead. That is not what was stamped, so ots rejects it with File does not match original!. We found this on 2026-09-15 by running this page's own worked example end to end. Both published forms are corrected.

A successful verification prints something like: 

Success! Bitcoin block N attests existence as of YYYY-MM-DD

That is the receipt. The commit existed at or before that Bitcoin block. No trust in us required — only in Bitcoin and in the OpenTimestamps calendar servers, which only sign; they do not back-date.

The corporate repository

The full corporate repository — ADRs, activity log, governance — is currently local to the supervisory board, not yet public. Public verification today therefore covers the wakir-labs/* repositories on GitHub (github.com/wakir-labs). When the corporate repository becomes public, the same recipe applies: clone, point ots verify at the .ots file and the commit hash, read the receipt.

Members of the supervisory board verify against their local clone of the corporate repository the same way.

Step 3 needs a Bitcoin node — or a second command

ots verify does not finish without one. Measured against opentimestamps-client 0.7.2 — the version the pip install above gives you — on 2026-09-20: the package contains no block-explorer code path at all, and the verify path calls setup_bitcoin() unconditionally, which exits 1 when no node answers. An earlier version of this page said the client falls back to a remote block explorer. It does not.

Without a node, use ots info, which needs no chain access. It prints the Bitcoin block the proof commits to: 

ots info meta/timestamps/82d40f7.ots | grep BitcoinBlockHeaderAttestation

Take that block height to any Bitcoin explorer and read its timestamp. That is the same fact ots verify would confirm — you are trusting the explorer to report the chain correctly instead of checking it yourself.

With your own node, the client does the whole chain end to end: 

ots --bitcoin-node http://user:pass@127.0.0.1:8332 verify -f /tmp/commit.txt meta/timestamps/82d40f7.ots

This removes the last residual trust assumption: you are now reading the attestation directly from a chain you validate yourself.

If verification fails

Two normal reasons:

  • The proof is "pending". Fresh commits live in the calendar servers for a few hours before being aggregated into a Bitcoin block. Run ots upgrade meta/timestamps/<hash>.ots after a few hours, then re-verify.
  • You hashed the wrong thing. The hook stamps the 40-character commit hash as ASCII text with a trailing newline. Reproduce it with printf "%s\n" "$(git rev-parse <commit>)" — not with xxd -r -p. Earlier versions of this page recommended the latter; they were wrong.

If neither applies, open an issue. A failed verification on a real commit is a finding we want to know about.

Auf Deutsch lesen.