ES · EN

FARO · Verificación

Compruébalo tú mismo

Cada día publicamos en un repositorio público la huella criptográfica (SHA-256) de cada señal sellada, encadenada con la del día anterior. Si alguien —nosotros incluidos— cambiara la entrada, el stop o el objetivo de una señal publicada hace meses, su huella dejaría de cuadrar, y con ella todos los digests posteriores. No hace falta que te fíes de FARO: hace falta que sepas restar.
Y si prefieres no fiarte ni de esta página: los seis pasos a mano

1 · Coge la huella de la señal. Está en su ficha, con un botón de copiar, junto al payload exacto con el que se calcula.

2 · Búscala en el registro público. github.com/teaminvestx-oss/faro-integridad — un archivo por día, cadena.txt con el índice de digests y indice.txt para saber en qué archivo cayó cada señal. Clónalo: a partir de ese momento tienes tu propia copia, y ya no dependes de que la nuestra no cambie.

3 · Compara el payload con lo que ves en la página. Activo, dirección, entrada (o los precios de entrada declarados), stop, objetivo y fecha tienen que ser los mismos. Este paso es mirar.

4 · Comprueba que la huella sale de ese texto. Guarda el bloque en un archivo y ejecuta sha256sum archivo.txt. Este paso es aritmética: no hay forma de que ese texto dé otra cosa.

5 · Si quieres ir más lejos, recalcula la cadena. El digest de cada día es el SHA-256 de un bloque que incluye el digest del día anterior y todas las huellas del día, ordenadas. Por eso alterar una señal vieja rompe todos los digests posteriores, no solo el suyo. Las reglas exactas del formato están en el README del registro, con un ejemplo reproducible paso a paso.

6 · Y el cuándo, pregúntaselo a Bitcoin. Junto a cada archivo diario del registro hay una prueba .txt.ots (OpenTimestamps). Descarga el archivo y su prueba y arrastra los dos en opentimestamps.org: te dirá qué bloque de Bitcoin da fe de que ese archivo —y con él, toda la cadena hasta ese día— existía en esa fecha. Ni FARO ni GitHub intervienen en esa respuesta.

Y si la señal está en publicación diferida, estos seis pasos no valen igual. Mientras la operación vive, sus parámetros no son públicos, así que los pasos 1, 3 y 4 no se pueden hacer todavía: no hay payload en la ficha con el que comparar ni al que sacarle el SHA-256. Lo que sí puedes hacer es el 2, el 5 y el 6, cada uno a su hora: cuando la señal queda sellada, su huella se publica en el registro como compromiso —en integridad/compromisos/, sin sus datos y con su propia prueba de tiempo—; a la mañana siguiente del día en que se publicó, esa misma huella entra en el archivo del día y en su digest, como cualquier otra; y su prueba de tiempo queda fechada en Bitcoin cuando la transacción confirma. Para el compromiso hay dos plazos fijados antes de medirlos —en el registro como mucho 15 minutos después de que la señal quede sellada, y en un bloque de Bitcoin antes de 24 horas desde su publicación—: son objetivos y no medidas, y se medirán con la primera señal diferida real. Los tres que faltan se pueden hacer en cuanto la señal se revela, y entonces dicen además desde cuándo existía el compromiso: la fecha que da su prueba de tiempo.

La auditoría completa, en un comando

El programa que genera la cadena viaja dentro del propio registro, y la pasada que ejecutas tú no usa ninguna credencial: lee la misma API pública que puedes leer tú y no escribe en ninguna base de datos. Con Node 18 o superior:

git clone https://github.com/teaminvestx-oss/faro-integridad
cd faro-integridad
node tools/sellar.mjs --check

Eso recalcula la huella de todas las señales ancladas pidiendo los datos a la API pública —de una diferida que sigue viva no puede: comprueba que lo anclado es su compromiso, y la recalcula en cuanto se revela—, y las compara con lo publicado. Si alguna señal sellada hubiera cambiado, lo dice con nombre y las dos huellas. Dos avisos honestos: hasta la hora a la que sale el archivo de ayer —por la mañana: en septiembre de 2026, entre las 07:30 y las 09:00 UTC— dirá que «faltaría» ese archivo, porque aún no le toca. Con tu copia del registro al día, si lo dice de un archivo anterior al de ayer —a cualquier hora— o si pasada esa franja lo sigue diciendo, ya no es la espera normal: el trabajo se ha retrasado o ha fallado, y lo publicado ese día sigue sin anclar hasta que salga. Y el bloque inicial no se puede regenerar desde cero, porque su forma depende del día en que se creó; sus huellas, una a una, sí.

La gracia de fondo: en una señal publicada en abierto, la huella no se guarda en ninguna parte, se calcula cada vez. Una huella guardada sería una afirmación nuestra más; una calculada es una comprobación.

Y hay un caso en el que no podemos decir eso, así que lo decimos entero. En una señal de publicación diferida los parámetros no son públicos mientras la operación vive, así que nadie de fuera puede calcular todavía su huella. FARO la compromete cuando la señal queda sellada: la calcula el mismo programa, en su otro modo (--compromiso), y la publica en el registro, en integridad/compromisos/, con su propia prueba de tiempo; a la mañana siguiente la cadena ancla esa misma huella, en la ventana de aquí arriba. Es la única lectura del sistema de integridad que usa una credencial, y es de solo lectura: lee, de todas las señales públicas, las columnas que su huella necesita —también las que la lectura pública retiene—; no tiene permiso de escritura sobre ninguna tabla de FARO, y no puede escribir ni ejecutar nada que no pueda ya cualquiera con la clave anon. Y se recalcula al revelarse, cuando los parámetros salen. Durante esa ventana, esa huella concreta es una afirmación nuestra: solo tú mismo puedes comprobarla después. Al revelarse vuelve a ser una comprobación, y además dice algo que la de una señal en abierto no necesita decir: desde cuándo existía el compromiso, la fecha que da su prueba de tiempo.

Qué demuestra esto, y qué no

Decirlo entero es parte del trato. Las cuatro limitaciones, con la letra grande, están en la metodología. En corto: esto demuestra que un registro no ha cambiado desde que se selló, no que el dato fuera correcto al sellarlo; el digest se genera una vez al día, así que una señal recién publicada tarda en quedar anclada; y el cuándo lo atestigua Bitcoin — cada archivo diario lleva su prueba OpenTimestamps (.ots) en el registro: descárgala junto al archivo y arrastra los dos en opentimestamps.org para ver el bloque que da fe.

Si algo de esto te parece insuficiente, tienes razón en decirlo. Preferimos la pregunta incómoda a un sistema que parezca más sólido de lo que es.

Nota de integridad n.º 1

Dos cosas que salieron mal por nuestra parte entre el 26 de agosto y el 1 de septiembre de 2026, una de ellas con una señal que sigue sellada en este registro. Ninguna se corrige. Leer la nota completa.