Comprobar un sello que ves por ahí

Viste una huella verde o dorada junto a un avatar, en la descripción de un vídeo, o en una web. Esta página recorre cómo comprobarla como es debido, terminando por recalcular tú mismo el hash de la ficha, para no tener que fiarte de la palabra de nadie, ni siquiera de la nuestra.

• El sello no tiene enlace. Un sello legítimo va junto a un enlace a la página de la ficha. Una imagen de un sello sin nada en qué hacer clic no se puede comprobar.
• Se afirma «verificado» sin el sello dorado. La palabra «verificado» solo va nunca con el sello dorado, jamás con el verde. Ver Mostrar tu sello para la regla completa.
• No hay número THB por ningún lado. Toda ficha real tiene uno, con el formato THB-<año>-<número>, por ejemplo THB-2026-00001.

Busca cerca del sello, o en la página enlazada, un código como THB-2026-00001. Si en vez de eso hay un enlace, normalmente lleva directo a la página de la ficha en https://platform.thehumanbehind.com/r/<slug>, en cuyo caso puedes saltar al paso 3.

Entra en platform.thehumanbehind.com y busca el número THB o el nombre del avatar. Solo las fichas Verificadas son buscables y públicas; una ficha solo Registrada no aparecerá aquí, es una constancia privada que su dueño no ha hecho pública. Ver Directorio para cómo funciona la búsqueda.

Paso 3: lee la ficha pública

La página de una ficha muestra exactamente lo declarado: el nombre del avatar, su tipo y ámbito, dónde opera, el nombre de la persona responsable, el número THB, la fecha de registro y el hash de contenido. Nada más, el correo de la persona responsable no aparece nunca en la página. Ver Fichas para qué significa cada campo.

Leer la página basta para la mayoría de casos. Si quieres verificarlo de verdad en vez de fiarte, recalcula el content_hash tú mismo con la receta pública exacta. Para nuestra ficha de ejemplo (Laia, platform.thehumanbehind.com/r/laia), toda la comprobación en una línea de comandos es esta:

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

Sustituye por los campos de la ficha que estás comprobando y el resultado debería coincidir exactamente con su content_hash publicado. La receta completa, más las versiones en Python y Node, está en Fichas; la API pública es la forma más fácil de obtener los campos de una ficha por programa antes de recalcular.

El paso 4 comprueba lo que la ficha dice hoy. A veces lo que importa es lo que decía en marzo, y el registro conserva cada versión con su propia huella y su propia fecha.

Pide el historial y te devuelve una entrada por versión, cada una con el objeto exacto que se hasheó:

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

Coge el snapshot de la versión que te interese, hashéalo con la misma receta del paso 4 y tiene que dar el content_hash de esa versión. La versión del alta es la número 1, y es la que lleva la fecha de anterioridad.

En una ficha de tipo agent sabrás además cuántas veces cambiaron sus instrucciones y cuándo. No el texto, que es de quien lo escribió, y tampoco la huella del texto: las instrucciones suelen ser plantillas que se repiten entre clientes, así que publicar el digest permitiría a cualquiera con una candidata confirmar que esa ficha la usa.

El dueño de una ficha puede descargarse su constancia y enviártela. No necesitas cuenta, y no necesitas creerte nada de lo que digamos para comprobarla.

Toda comprobación son los mismos tres movimientos (hashear una preimagen, recorrer un camino y aterrizar en la raíz del ancla). Lo único que cambia es de qué parte del fichero los sacas:

1. La ficha tal y como está hoy. Hashea los bytes de anchor.leaf_preimage con SHA-256: tiene que dar anchor.leaf. Después recorre anchor.inclusion_path, hasheando parejas, hasta llegar a una raíz.
2. Una versión antigua de la ficha. Cada entrada de history.versions con kind: "metadata" lleva su propio leaf.preimage, su leaf.hash y su leaf.inclusion_path. Los mismos tres movimientos, versión a versión. La entrada lleva además el snapshot que se hasheó, así que puedes recalcular el hash de esa versión como describe el paso 4 de arriba.
3. Las instrucciones de un agente. Sus pruebas viven en anchor.agent_instructions.versions, cada una con leaf_preimage, leaf e inclusion_path. Las entradas correspondientes de history.versions llevan leaf: null y te mandan allí con proof_in, para no decir lo mismo dos veces.

Hayas recorrido el que hayas recorrido, la raíz a la que llegas tiene que ser igual a anchor.merkle_root, y el recibo de ese ancla y su prueba en Bitcoin son públicos.

Algunas entradas vienen con preimage: null e inclusion_path: null. No es un agujero en la prueba: esas versiones o son más nuevas que la última ancla, así que de verdad todavía no están en ese árbol, o quedan más allá de los veinte caminos que un solo fichero lleva dentro. Su sal se entrega igualmente, así que la hoja se puede construir hoy y comprobar contra el ancla de mañana.

El recorrido completo está en Anclaje. Lo único que das por bueno es el fichero que te dieron, y si estuviera alterado, la raíz no cuadraría.