Trust

Reading the chain head and the timestamp proof…

Those figures are read from the server as you open this page. Each one is checkable yourself, and the rest of this page explains what each check does and does not establish.

Run the checks yourself

A receipt is stored with its own hash, and that hash is computed over two things: the hash of the previous receipt, and the canonical serialisation of this receipt's complete body. The body is the receipt minus its own identifier and its own hash, so the hash covers the evidence reference, the strategy specification hash, every evaluated condition, the decision, the confidence, the computed flip conditions and the review result. The identifier of a receipt is its hash: a receipt cannot be renamed.

The first receipt links to a fixed genesis constant. Every one after it links to its predecessor. That makes the store append-only in a way that is checkable rather than promised.

apps/server/app/chain.py, receipt_hash(), build_receipt()

What chain_ok means

Verification walks the chain from genesis and does two things at each step. It checks that the receipt's recorded predecessor hash equals the hash it actually computed for the previous receipt, and it recomputes this receipt's hash from its stored body and compares it to the stored hash. Both must match, on every receipt, in order.

When they do, chain_ok is true, and it means precisely this: no stored receipt has been edited, deleted or reordered since it was written. Change one number in one receipt body and its recomputed hash stops matching. Delete a receipt and the next one's predecessor hash stops matching. Insert a receipt and the same thing happens. The verification reports the exact sequence number where it broke.

When it is false, the report names the sequence and the reason, and the product does not carry on as if the record were intact.

A hash chain proves a record was not altered. It says nothing about whether the record was right in the first place. Replay is the check that addresses that.

Replaying a receipt loads the snapshot set the receipt names, re-resolves every logical field from those stored RYO envelopes, looks up the strategy specification by the specification hash recorded on the receipt rather than by its identifier, and evaluates it again from scratch. Then it compares three things against what was stored: the side, the confidence, and the complete list of computed flip conditions.

identical is true only when all three match. When they do not, the differences are listed individually, in the form side: stored LONG vs replay NO_TRADE.

Replay is a real test because it can fail. Looking the strategy up by its specification hash is what makes that true: editing a strategy after the fact produces a new hash, so a later version cannot quietly stand in for the one that made the decision. If the engine changes in a way that alters an old outcome, replay of an old receipt disagrees with the record, and that disagreement is reported rather than smoothed away.

apps/server/app/chain.py, verify_chain(), replay_receipt()

The chain proves internal consistency, but a consistent chain can still be written all at once, after the fact, by someone who knows how the outcome went. Something outside the system has to fix the record in time.

The chain head hash is written to a file, and that file is stamped with OpenTimestamps, which aggregates it with many other stamps and commits the result into a Bitcoin transaction. Once the containing block is mined, the proof file carries a Bitcoin block header attestation naming that block height.

What that attestation proves

It proves that the file containing that head hash existed before that Bitcoin block was mined. Since the head hash covers the entire chain up to that point, it follows that every receipt in the chain up to that head was already written by then. Nobody, including us, can move that time later or earlier, because doing so would mean rewriting Bitcoin.

What it does not prove

• It does not prove any decision was correct. A timestamp says when something was written, not whether it was right.
• It does not prove the evidence was accurate. It proves we stored what we stored, at that time, and did not change it afterwards.
• It does not cover anything written after the stamp. Receipts added since the stamp are protected by the chain but are not yet anchored in time, and the server reports the gap when the head has moved on.

Checking the proof yourself

Two commands, and the difference between them matters. ots info reads the proof file and prints the attestations it already contains, including the block heights, and needs nothing but the file. ots verify does the stronger check: it looks the block up and confirms the attested hash against the chain itself, which is why it needs a local Bitcoin node. Anyone can run the first; the second is for anyone who wants the full check without trusting a block explorer.

# Node-free: print the attestations the proof already carries.
ots info data/head.txt.ots

# Full check: confirms the attested block hash against the chain itself.
# Needs a local Bitcoin node, because that is what it asks.
ots verify data/head.txt.ots

apps/server/app/timestamp.py, ots_status(), block heights 965149 and 965152 read from head.txt.ots on 2026-09-03

Taken together, the three checks establish a narrow and specific claim: these decisions were made from this evidence, by these rules, before this Bitcoin block, and have not been touched since. That is all, and it is worth being blunt about how much it leaves out.

It does not establish that RYO's numbers were true. It does not establish that the strategies are any good. It does not establish that a confidence of 70 corresponds to being right seven times in ten, and at present nothing does, because no outcome has been graded. Verifiability is a floor, not a recommendation.

How the confidence number is produced and graded , What this system cannot do , Run the checks yourself