FARO · Verification

Check it yourself

Every day we publish in a public repository the cryptographic fingerprint (SHA-256) of every sealed signal, chained to the previous day’s. If anyone —us included— changed the entry, the stop or the target of a signal published months ago, its fingerprint would stop matching, and so would every later digest. You don’t need to trust FARO: you just need to be able to do the math.

Check a signal in the app (Spanish) →

And if you’d rather not trust even this page: the six steps by hand

1 · Take the signal’s fingerprint. It’s on the signal’s page, with a copy button, next to the exact payload it is computed from.

2 · Find it in the public registry. github.com/teaminvestx-oss/faro-integridad — one file per day, cadena.txt with the index of digests and indice.txt to find which file each signal landed in. Clone it: from that moment you have your own copy, and you no longer depend on ours not changing.

3 · Compare the payload with what you see on the page. Asset, direction, entry (or the declared entry prices), stop, target and date must be the same. This step is just looking.

4 · Check that the fingerprint comes from that text. Save the block to a file and run sha256sum archivo.txt. This step is arithmetic: there is no way that text gives anything else.

5 · If you want to go further, recompute the chain. Each day’s digest is the SHA-256 of a block that includes the previous day’s digest and all of that day’s fingerprints, sorted. That is why altering an old signal breaks every later digest, not just its own. The exact format rules are in the registry README, with a reproducible step-by-step example.

6 · And for the when, ask Bitcoin. Next to each daily file in the registry there is a .txt.ots proof (OpenTimestamps). Download the file and its proof and drag both into opentimestamps.org: it will tell you which Bitcoin block attests that the file —and with it, the whole chain up to that day— existed on that date. Neither FARO nor GitHub takes part in that answer.

And if the signal uses deferred publication, these six steps don’t all work the same way. While the trade is in progress its parameters are not public, so steps 1, 3 and 4 cannot be done yet: there is no payload on the page to compare with or to take the SHA-256 of. What you can do is 2, 5 and 6, each in its own time: when the signal is sealed, its fingerprint is published in the registry as a commitment —in integridad/compromisos/, without its data and with its own timestamp proof—; the morning after the day it was published, that same fingerprint enters the day’s file and its digest, like any other; and its timestamp proof is dated on Bitcoin when the transaction confirms. For the commitment there are two deadlines set before measuring them —in the registry at most 15 minutes after the signal is sealed, and in a Bitcoin block within 24 hours of its publication—: they are targets, not measurements, and they will be measured with the first real deferred signal. The three missing steps can be done as soon as the signal is revealed, and then they also tell you since when the commitment existed: the date its timestamp proof gives.

The full audit, in one command

The program that generates the chain travels inside the registry itself, and the run you perform uses no credential: it reads the same public API you can read and writes to no database. With Node 18 or later:

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

That recomputes the fingerprint of every anchored signal by requesting the data from the public API —for a deferred signal that is still live it can’t: it checks that what was anchored is its commitment, and recomputes it as soon as it is revealed—, and compares them with what was published. If any sealed signal had changed, it says so by name, with both fingerprints. Two honest warnings: until the time yesterday’s file comes out —in the morning: in September 2026, between 07:30 and 09:00 UTC— it will say that file would be “missing”, because it isn’t due yet. With your copy of the registry up to date, if it says so about a file older than yesterday’s —at any time— or if it keeps saying so after that window, it is no longer the normal wait: the job is late or has failed, and what was published that day stays unanchored until it comes out. And the initial block cannot be regenerated from scratch, because its form depends on the day it was created; its fingerprints, one by one, can.

The underlying point: in a signal published in the open, the fingerprint is not stored anywhere, it is computed every time. A stored fingerprint would be one more claim of ours; a computed one is a check.

And there is one case where we can’t say that, so we say it in full. In a signal under deferred publication the parameters are not public while the trade is in progress, so nobody outside can compute its fingerprint yet. FARO commits to it when the signal is sealed: the same program computes it, in its other mode (--compromiso), and publishes it in the registry, in integridad/compromisos/, with its own timestamp proof; the next morning the chain anchors that same fingerprint, in the window described above. It is the only read in the integrity system that uses a credential, and it is read-only: it reads, for every public signal, the columns its fingerprint needs —including the ones the public read withholds—; it has no write permission on any FARO table, and it cannot write or run anything that anyone with the anon key cannot already write or run. And it is recomputed when revealed, when the parameters come out. During that window, that particular fingerprint is a claim of ours: only you can check it afterward. Once revealed it becomes a check again, and it also says something an open signal doesn’t need to say: since when the commitment existed, the date its timestamp proof gives.

What this proves, and what it doesn’t

Saying it in full is part of the deal. The four limitations, in large print, are in the methodology. In short: this proves that a record has not changed since it was sealed, not that the data was correct when it was sealed; the digest is generated once a day, so a newly published signal takes a while to be anchored; and the when is attested by Bitcoin — every daily file carries its OpenTimestamps proof (.ots) in the registry: download it with the file and drag both into opentimestamps.org to see the block that attests it.

If any of this seems insufficient to you, you are right to say so. We prefer the uncomfortable question to a system that looks more solid than it is.

Integrity note no. 1

Two things that went wrong on our side between August 26 and September 1, 2026, one of them with a signal that is still sealed in this registry. Neither is corrected. Read the full note.