Wakir Labs

Verify a Wakir Labs commit

Every commit in Wakir Labs repositories is timestamped against the Bitcoin blockchain via OpenTimestamps. The proof is a small .ots file checked in next to the commit hash. With those two things — any commit hash from our history and the matching .ots file — anyone can verify, without trusting us, that the commit existed at or before the timestamp baked into 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.

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.

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:
ots verify meta/timestamps/82d40f7.ots -d $(git rev-parse 82d40f7 | xxd -r -p | sha256sum | head -c 64)

The simpler form, when the proof was created against the raw commit hash bytes used by our hook, is: 

git rev-parse 82d40f7 | xxd -r -p > /tmp/commit.bin
ots verify -f /tmp/commit.bin meta/timestamps/82d40f7.ots

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 trust in Bitcoin and in the OpenTimestamps calendar servers (which themselves only sign, they do not back-date).

Where the source of truth lives

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.

Advanced: verify against your own Bitcoin node

By default the OpenTimestamps client reaches out to public calendar servers and, for the Bitcoin attestation, to a remote block explorer. If you run your own Bitcoin node, you can verify the proof end-to-end against your own copy of the chain: 

ots --bitcoin-node http://user:pass@127.0.0.1:8332 verify -f /tmp/commit.bin 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. Our hook stamps the raw 32-byte commit hash. Make sure you pass binary bytes (xxd -r -p), not the ASCII hex.

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

Auf Deutsch lesen.