Checking a seal yourself

Every record an auditor approves is signed, and the signature is on the vehicle's passport and in any provenance report made from it. This page publishes the keys those signatures were made with, so you can check one without taking our word for anything.

That is the point of signing rather than merely storing. A seal only we could check would be a claim about our own records, which is exactly what a buyer has no reason to accept.

The keys

A retired key is one we have stopped signing with. Records it signed are unaffected and still verify - that is why each seal names the key that made it.

How to check one

The scheme is ed25519-sha256-v1: Ed25519 over a canonical description of the record, with the version tag inside the signed bytes so a future format cannot be confused with this one.

You do not have to ask us for anything. Every passport and every shared history carries a check the seals yourself link, and the file behind it holds the exact bytes that were signed, the signature over each one, and step-by-step instructions using openssl - which is not our software. We publish the keys and the format; we do not need to be involved in the checking, which is the whole idea.

What a signature does not prove

A signature establishes that nobody has altered a record since it was sealed. It does not establish that what we sealed was true - a workshop can describe work it did badly, honestly, and the signature says nothing about that.

And on its own it does not establish that we have not gone back and re-sealed an altered record under the same key. We hold the key, so we could. Saying so is not a caveat we are obliged to add; a proof that overstates itself is worse than none, because somebody relies on it.

The corpus roots

That is what these are for. Every seal in existence is a leaf of a Merkle tree and a root is computed daily, so changing any past record changes the root. Each root is anchored into Bitcoin through OpenTimestamps, which nobody at WrenchVerse can rewrite - so if we altered an old record, the anchored root would no longer match and anybody could see it.

Keep a copy of a root. That is the whole mechanism: a root you saved, or one an anchor recorded, is a claim about the past we cannot take back.

Check one with the reference client, which is also not ours: pip install opentimestamps-client. OpenTimestamps timestamps a file rather than a string, so rebuild the root as 32 raw bytes first - the name must match the download with the extension taken off, or the client goes looking for a file that is not there:

echo '<the root above>' | xxd -r -p > roots-<date>.root
ots verify roots-<date>.root.ots

Pending confirmation means it was submitted and Bitcoin has not caught up yet, which takes hours. That is not a failure - a root is published the day it is computed and anchored afterwards.

verify needs a Bitcoin node, because checking a block header against the chain is the one step nobody can do for you without one. Without a node, ask the proof what block it is in and take that to any explorer:

ots info roots-<date>.root.ots
  → BitcoinBlockHeaderAttestation(965312)

That block, and the merkle root printed beneath it, are the whole claim - checkable by anybody, against a chain we have no say over.

Version 0.1 (DRAFT), last updated 28 AUGUST 2026. 2025/397258/07