Skip to content

Verifying a seal you saw somewhere

You spotted a green or gold fingerprint next to an avatar, in a video description, or on a website. This page walks through checking it properly, ending with recomputing the record’s hash yourself so you do not have to take anyone’s word for it, including ours.

When to be suspicious

Section titled “When to be suspicious”
  • The seal has no link. A legitimate seal sits next to a link to the record’s page. A picture of a seal with nothing to click is not checkable.
  • “Verified” is claimed without the gold seal. The word “verified” is only ever attached to the gold seal, never the green one. See Displaying your seal for the rule.
  • No THB number anywhere. Every real record has one, in the format THB-<year>-<number>, for example THB-2026-00001.

Step 1: find the THB number

Section titled “Step 1: find the THB number”

Look near the seal, or in the linked page, for a code like THB-2026-00001. If there is a link instead, it usually leads straight to the record’s page at https://platform.thehumanbehind.com/r/<slug>, in which case you can skip to step 3.

Step 2: look it up in the directory

Section titled “Step 2: look it up in the directory”

Go to platform.thehumanbehind.com and search either the THB number or the avatar’s name. Only Verified records are searchable and public; a Registered-only record will not appear here, it is a private record its owner has not made public. See Directory for how search works.

Step 3: read the public record

A record’s page shows exactly what was declared: the avatar’s name, type and scope, where it operates, the responsible person’s name, the THB number, the registration date, and the content hash. Nothing else, the responsible person’s email is never on the page. See Records for what each field means.

Step 4: recompute the hash, if you want proof

Section titled “Step 4: recompute the hash, if you want proof”

Reading the page is enough for most purposes. If you want to actually verify it rather than trust it, recompute the content_hash yourself using the exact public recipe. For our worked example record (Laia, platform.thehumanbehind.com/r/laia), this is the whole check on a command line:

printf '%s' '{"slug": "laia", "type": "avatar", "scope": "general", "avatar_name": "Laia", "operates_at": "", "registered_at": "2026-07-30T23:44:44.547749Z", "registry_code": "THB-2026-00001", "responsible_name": "AIGiner S.L."}' | sha256sum
# 23ec5dae1e4b330a1ebe266db49bf2d0ca88b7bb6fff0e0eeca1106bbbc5fb6d

Swap in the fields from the record you are checking and the output should match its published content_hash exactly. The full recipe, plus Python and Node versions, is in Records; the public API is the easiest way to fetch a record’s fields programmatically before recomputing.

Step 5: check an OLD version

Section titled “Step 5: check an OLD version”

Step 4 checks what the record says today. Sometimes what matters is what it said in March, and the registry keeps every version with its own hash and date.

Ask for the history and you get one entry per version, each with the exact object that was hashed:

curl {SITE.platformUrl}/api/v0/records/laia-torres/history.json

Take the snapshot of the version you care about, hash it with the same recipe as step 4, and it must equal that version’s content_hash. The registration version is number 1, and it is the one that carries the date of anteriority.

For a record of type agent you also get how many times its instructions changed and when. Not the text, which is the author’s, and not the text’s fingerprint either: instructions are often templates that repeat between clients, so a published digest would let anyone with a candidate confirm this record uses it.

If someone hands you a proof.json

Section titled “If someone hands you a proof.json”

A record’s owner can download a proof file and send it to you. You do not need an account, and you do not need to believe anything we say to check it.

Every check is the same three moves (hash a preimage, walk a path, land on the anchor’s root), and what changes is only where in the file you read them from:

  1. The record as it stands today. Hash the bytes of anchor.leaf_preimage with SHA-256: it must give anchor.leaf. Then walk anchor.inclusion_path, hashing pairs, until you reach a root.
  2. An older version of the record. Each entry of history.versions with kind: "metadata" carries its own leaf.preimage, leaf.hash and leaf.inclusion_path. Same three moves, one version at a time. The entry also carries the snapshot that was hashed, so you can recompute that version’s hash the way step 4 above describes.
  3. An agent’s instructions. Their proofs live in anchor.agent_instructions.versions, each with leaf_preimage, leaf and inclusion_path. The matching entries in history.versions carry leaf: null and point you there with proof_in, so nothing is said twice.

Whichever of the three you walked, the root you end up with must equal anchor.merkle_root, and that anchor’s receipt and its Bitcoin proof are public.

Some entries come back with preimage: null and inclusion_path: null. That is not a gap in the proof: those versions are either newer than the last anchor, so they genuinely are not in that tree yet, or they fall past the twenty paths a single file embeds. Their salt is handed over anyway, so the leaf can be built today and checked against tomorrow’s anchor.

The full walk-through is in Anchoring. The only thing you take on faith is the file you were given, and if it were altered, the root would not match.

What a seal does not prove

Section titled “What a seal does not prove”

A matching hash proves the record has not been altered since it was sealed and tells you who declared it and when. It does not prove the underlying content is lawful, it is not a licence to reuse the avatar, and it does not excuse whoever publishes the content from their own transparency obligations. A seal is a record of accountability, not a permission slip.