Sealed Prospective Validation: The Future Is the Only Clean Test Set Left

Train, validation and test from the 2,255-strategy tournament are spent: re-evaluating that same data now would be retrospective overfitting. The only thing still clean is what hasn't happened yet. That's why a daily log now runs, hash-chained and sealed on the Bitcoin chain itself, promising no return. It promises that nobody, not even whoever wrote it, can touch it after the fact.

Once an experiment's three data partitions (train, validate, and a single test shot) are spent, the usual temptation is to look at that same data again with fresh eyes, find a new angle, convince yourself this time it's real. The trading strategy tournament covered in this series chose the opposite: declare that data officially burned, and open a different experiment on the one dataset still intact. The future.

Why the future is the only data left unspent

How the log works: a hash chain sealed on Bitcoin

Every day, the system computes the signal the strategy would emit using frozen parameters, always read from the tournament's own results file, never typed by hand. That signal gets appended to a log that only allows appending, never editing: each new entry includes the previous entry's hash, so altering any line would break the entire chain in a detectable way. Periodically, the hash at the head of the log gets sealed with OpenTimestamps, a service that anchors that proof to the Bitcoin chain itself, an independent, public confirmation that a specific entry already existed on a given date, with no need to trust anyone's word for it.

The bug the system itself caught on its first real run

The best proof a verification mechanism actually works is that, at some point, it stops something. On the log's first real activation with fresh data, the shadow-test (which re-derives every already-logged signal from the full historical record and compares it to what's stored) caught a real divergence: the inaugural batch had been computed on a Bitcoin candle that technically hadn't closed yet, the current day's provisional price had slipped into the data download. The system didn't quietly fix anything or carry on as if nothing had happened. It stopped, without touching the log already written. The lines affected by that birth defect stay exactly as they were, unedited (the log is never edited, not even to correct an already-identified bug of its own), documented for what they are: proof that, the first time it mattered, the verification mechanism did its job.

Why anchor to Bitcoin instead of a regular timestamp server

A conventional timestamp server would already improve on an editable spreadsheet, but it still asks for trust in one party: whoever runs the server could, in principle, backdate or refuse to issue a receipt. OpenTimestamps sidesteps that by batching many timestamp requests into a single Merkle tree and committing only the tree's root hash into a real Bitcoin transaction, at the network's own pace, roughly one confirmation every ten minutes. Verifying a seal later doesn't require asking OpenTimestamps' own server to vouch for anything: it means walking the Merkle proof back to that transaction and checking it against the blockchain itself, which anyone can already do independently with software that has nothing to do with the project that logged the signal. The guarantee isn't "we didn't touch it and you have to believe us." It's "here's a transaction anyone can look up, at a height that already existed before this claim was made."

Success criteria, fixed before the first signal

Before a single real entry was written, the tournament fixed in writing the three criteria that would decide whether this experiment succeeded. A minimum of 3 months of continuous daily logging before drawing any conclusion. A 100% match between the signal computed live each day and its full re-derivation from history, no exceptions tolerated. And zero edits to the log, independently verifiable three separate ways at once: the internal hash chain, git history, and the OpenTimestamps seals. The financial outcome is deliberately not one of the three. Three months of returns is statistical noise, the same warning already applied to the rest of the tournament. What this experiment measures is operational fidelity, not profitability. A faithful log that turns out to be a loser would be a success; a log with unexplained divergences would be a failure even if, by chance, it made money.

What this isn't

This log isn't a trading tool or a signal service, and it isn't trying to be one. The strategy it logs every day remains, formally, the same one the tournament labeled documentation only: it cleared the robustness gate, but never the decisive statistical bar, nor the out-of-sample consistency test. Logging it live doesn't redeem it. No amount of pre-registration can turn an unproven hypothesis into a proven one; it can only check, over time, whether its behavior keeps resembling what the backtest predicted. NodeWitness is considering, not yet implemented, pending ratification, a twin log for its own Score, frozen as "Score DCA v1" and pinned to a specific project commit, under the same discipline: name an exact version before the future gets a chance to validate or disprove it.

Nothing in this article is investment advice, and nothing on NodeWitness is. The log described here exists to measure fidelity, not to suggest what to buy or sell. You can read the tournament's full verdict, why backtests lie even the careful ones, or follow NodeWitness's live Cycle Score, same discipline of publishing what doesn't work too.

Last updated: August 31, 2026