Check it yourself.

What is checked

The SHA-256 hashes of the documents the project commits not to change are published in a public repository that contains only hashes: github.com/MontanaMiramar/rall-attestations. Each file is sealed with OpenTimestamps, which anchors it in a Bitcoin block. Anyone can then check that this exact file existed no later than the time of that block.

Set up, once

You need Linux or macOS with git and Python 3. On Windows, use WSL: in our test (Python 3.14), the OpenTimestamps client did not run on native Windows.

git clone -c core.autocrlf=false https://github.com/MontanaMiramar/rall-attestations.git
cd rall-attestations
python3 -m venv ots-venv
./ots-venv/bin/pip install opentimestamps-client==0.7.2
./ots-venv/bin/ots --version        # v0.7.2

• -c core.autocrlf=false keeps every file byte for byte as published. Without it, Git on Windows may change the line endings, and the hashes will not match.
• On Debian or Ubuntu, if python3 -m venv fails, first install the package its error message names (on Ubuntu 24.04, python3.12-venv).
• On macOS, if sha256sum is not available, shasum -a 256 does the same.

Today: the 13 pre-registrations

Before Phase 2 starts, 13 internal files were sealed; the .txt below lists their names. The repository holds their hashes, not their contents, in the folder preregistros/:

• 2026-10-26-preregistros.sha256 — the 13 hashes, one per line, in sha256sum format.
• 2026-10-26-preregistros.txt — the list of the 13, with the seal time the server declares for each, and what this anchor proves and does not prove.
• Each one with its OpenTimestamps proof (.ots), already complete.

1. The file is the one that was sealed

sha256sum preregistros/2026-10-26-preregistros.sha256
./ots-venv/bin/ots info preregistros/2026-10-26-preregistros.sha256.ots | grep 'File sha256 hash'

Both lines must show the same hash:

2. Which Bitcoin blocks hold the seal

./ots-venv/bin/ots --no-bitcoin verify preregistros/2026-10-26-preregistros.sha256.ots

--no-bitcoin goes before verify. The client does not contact any Bitcoin node; for each seal it prints a block and the merkle root that block must have:

To verify manually, check that Bitcoin block 973276 has merkleroot ca070bc7d92dd41e8814b1805cac6f3ac84d86039a5d300dff5d4cc50a560fb4
To verify manually, check that Bitcoin block 973294 has merkleroot d6d7ebc9e32fbb64c165e2975e85db83c08c9fba0fc643fef6f582d795b956b6
To verify manually, check that Bitcoin block 973322 has merkleroot e3d255408dbcaa854893c843784edbc0058f73113f2ce099e6fd593610e90ff5
To verify manually, check that Bitcoin block 973423 has merkleroot 585a9f6411812ce9ba12d3d3c52d2184f9f5d380ee36e83c808db96f01385a2c

3. Compare with a public block explorer

Open the block by its height, for example mempool.space/block/973276 or blockstream.info/block-height/973276. Both hide the Merkle root field until you press Details. Compare it exactly as printed, character by character. There is nothing to reverse or convert. One block is enough; two explorers are better than one. Explorers may show the block time in your own time zone; the times below are UTC.

Four different calendar servers — two of them under opentimestamps.org — sealed the same hash, each in its own block; ots info shows which. Result: these 13 files, with exactly these hashes, existed no later than 2026-10-26 at 19:16:23 UTC. The same three steps work on 2026-10-26-preregistros.txt and its .ots. Its hash is different (742b76f6…): what step 1 checks is that its two lines match each other, not that they match the hash shown above.

What this does not show: what the 13 files say (only their hashes are public; if and when each one is published, its content can be checked with sha256sum -c), the earlier seal times written in the .txt (the server's clock declares them), or that no different earlier versions existed. The list itself labels four files as “declared post-hoc” and one as “registered retroactively”; these are the server's own labels, as written in the .txt. Today, sha256sum -c on the pre-registrations reports that the 13 files cannot be read: that is expected, because they are not published.

From 2026-11-10: the frozen methodology

On 10 November the methodology is frozen and published byte for byte in the same repository, in the folder methodology/, with its hash and its seals:

• METODOLOGIA_SOMBRA_v<version>.md — the file itself.
• METODOLOGIA_SOMBRA_v<version>.md.sha256 — a single line: the SHA-256 in lowercase hex, two spaces, the file name, a line break.
• .md.ots and .md.sha256.ots — their OpenTimestamps proofs.

The exact version, the file name and the commit will be published here and on the Lab page that day. Then:

cd methodology
sha256sum -c METODOLOGIA_SOMBRA_v<version>.md.sha256       # → METODOLOGIA_SOMBRA_v<version>.md: OK
cd ..
./ots-venv/bin/ots --no-bitcoin verify methodology/METODOLOGIA_SOMBRA_v<version>.md.ots

and compare the blocks it prints as in step 3. Get the file raw (with git clone, or from raw.githubusercontent.com): copying the text from GitHub's web view can change its bytes, and with them the hash.

From 2026-11-11: daily anchors

One file per UTC day, anchors/YYYY-MM-DD.txt, with its proof anchors/YYYY-MM-DD.txt.ots. Files are only added; a day already published is never rewritten. The first is anchors/2026-11-10.txt, the day of the freeze; then one per day of observation, until 2026-12-11. Each holds six lines:

date_utc: YYYY-MM-DD
anchored_at_utc: YYYY-MM-DDTHH:MM:SSZ
paper_log_chain_head_sha256: <hex64>
paper_log_lines: <integer>
paper_log_file_sha256: <hex64>
methodology_sha256: <hex64>

• paper_log_chain_head_sha256 is the hash of the last line of the internal prediction log. Each line of that log includes the hash of the one before, so this value commits to the whole history up to that moment.
• methodology_sha256 must match the hash of the frozen methodology.

They are checked with the same three steps. In the first hours after a seal, its .ots may still be pending; if so, run ./ots-venv/bin/ots upgrade anchors/YYYY-MM-DD.txt.ots first.

Other ways to check the seals

With your own Bitcoin node — the most independent

./ots-venv/bin/ots verify preregistros/2026-10-26-preregistros.sha256.ots

This needs a synced Bitcoin Core on the same machine, reachable over RPC. It removes the need to trust any explorer. Without a node, the command stops with Could not connect to Bitcoin node.

The web verifier at opentimestamps.org

You upload the file and its .ots. It is convenient, but it means trusting that service.

We have not tested either of these two ways ourselves; see the end of this page.

What cannot be verified independently

A verification page that does not say what cannot be verified is not one. None of the following can be checked from outside:

• That the system really followed the methodology. The hash proves the text did not change, not that the code applied it as written. Only someone reading the text, the code and the data, if they are published, can judge that.
• The content of the internal prediction log. The daily anchors prove that a chain of hashes existed on each date, not what it contained. The predictions, their order and their signatures can only be checked if the log is published; then everything can be verified backwards by recomputing the chain.
• The content of the 13 pre-registrations, as long as they are not published. Today only their hashes are public: they existed no later than a given date, but what they said cannot be checked.
• Any date before the first anchor. The seal times of the pre-registrations (13 to 26 October) and every time written inside a file, such as anchored_at_utc, come from the server's clock. What can be proven is the upper bound given by the Bitcoin block.
• The exact time. OpenTimestamps gives an upper bound — the time of the block — not the moment a file was written.
• That no different earlier versions existed. An anchor proves that this version existed, not that there were no others before it.
• The protection of the main branch on GitHub (no force-push, no deletion) cannot be checked from outside, and the repository owner could switch it off. The integrity of the history does not rest on GitHub but on the .ots proofs: an altered file would not match its seal.
• The block explorers. Checking without a node relies on third-party explorers for each block's merkle root. Using two independent explorers reduces that trust; only your own node removes it.

What we tested

On 2026-10-29, the commands for today's checks were run as a third party would run them: a fresh clone from the public URL, a clean Linux container (Python 3.12, opentimestamps-client 0.7.2), and the merkle roots of every block compared against both mempool.space and blockstream.info, through their APIs (all blocks) and, for block 973276, on their web pages. All matched exactly as printed. The sha256sum -c format was checked with a test file.

Not tested: Windows through WSL, end to end — the path this page recommends to Windows users (on native Windows we only tested the clone and the hash); the own-node way; the web verifier; and macOS. The methodology and the daily anchors cannot be tested yet: they will exist from 10 and 11 November.

Contact

If a step does not work as written, please write: roderickchicas@gmail.com