No account, no app, and no trust in the operator.

Every Sunday the 833 calls are hashed with salts into a Merkle tree. The root is stamped on Bitcoin through OpenTimestamps and by two RFC 3161 authorities before Monday's open. Friday's labels are stamped the same way before Saturday's beacon fires. This page says exactly what that proves, what it does not, and what the verifier reports today.

A verifiable stock prediction track record is one where a stranger can confirm, from public data alone, that every prediction existed before its outcome and that none was edited or removed afterwards. That is a narrower claim than "provably honest AI stock picks", and it is the only one TensorSwing makes: the proof covers when the calls were made and that they were not tampered with, not whether they were any good.

01 What a passing week proves

• The calls existed before Monday's open. The root is in a Bitcoin block and in two independent timestamp tokens (Sectigo and DigiCert), none of which we control. The date git records is written by our own machine; these are not.
• The set is fixed. One root over 833 leaves: adding, dropping, replacing or reordering a call after seal breaks it for anyone holding the manifest.
• Labels came before the sample was known. The label file is stamped before the drand round that selects the audit set, so it cannot have been tuned to the sample.
• Every week opens in full. The archive is encrypted to a drand round 104 weeks after seal and decrypts by itself when that round is published, so a past week cannot be suppressed.

02 What it does not prove

• It does not reveal what the sealed calls are before Friday.
• It says nothing about whether the calls are any good. Only the sampled leaves, every scratch and every abstain are opened against their labels before the 104-week release.
• It does not prove model quality or profitability, and nothing about future weeks.

The honesty statement the record is built on puts it plainly: the timestamp removes exactly one trust assumption, that we could have backdated our own record, and that is all it removes.

03 What the verifier reports today

Run against the public repository on 16 September 2026, after the W36 and W37 audits were published. Failures are listed, not hidden, and are never closed by rewriting history.

• PASSMerkle root rebuilt from 833 leaf hashes, all three sealed weeks (W36, W37, W38).
• PASSLabel coverage, one entry per leaf, W36 and W37. W38 labels are due Friday 18 September.
• PASSOpenTimestamps attestation on Bitcoin, all three weeks.
• PASSRFC 3161 manifest and label tokens from Sectigo and DigiCert; labels stamped before the beacon target.
• PASSManifest chain, roster and universe pins, time-lock seed, incident chain.
• PASSBeacon audits for W36 and W37: the drand round pinned at seal selected 42 leaves each; those plus every scratch and abstain, 57 for W36 and 50 for W37, were opened with their salts and Merkle proofs and match their commitments and labels. Both audits were published late, on 16 September, because the Saturday audit job had never been scheduled; it now is.
• FAILW37 and W38 were sealed after Monday 09:30 ET. The protocol requires a late-seal incident entry for each; the operator has not filed them. The leaves were stamped at seal and are unchanged.
• PENDINGW38 labels, audit and label stamps, all inside their deadlines.

04 How commit-reveal forecasting works here

Commit-reveal means publishing a hash of a prediction first and the prediction itself later. Each Sunday every call from every model is serialised with a random salt and hashed with SHA-256; the salt is what makes a sealed call impossible to brute-force from its hash. The 833 hashes form a Merkle tree whose root is submitted to OpenTimestamps, which aggregates it into a Bitcoin transaction, and to two RFC 3161 timestamp authorities. Friday's labels are published against that fixed set. Saturday's drand round selects at least 20 leaves, which are opened with their salts and Merkle proofs alongside every scratch and every abstain, so anyone can confirm that a sampled call, its salt, its hash and its label all agree.

05 Verify a week from the public record

No account, no app, and no trust in the operator. You need a terminal, Python 3.9 or later, and for the last line the ots client:

$ git clone https://github.com/YermekIbrayev/tensorswing-record.git
$ cd tensorswing-record
$ git checkout 2026-W37
$ python3 scripts/verify.py 2026-W37
$ python3 scripts/verify.py --all            # also fetch and check the encrypted archive
$ ots verify 2026-W37.manifest.ots -f manifests/2026-W37.manifest.json

verify.py rebuilds the Merkle root from the committed leaf hashes, checks that every leaf has a Friday label, checks both timestamp tokens and their ordering against the beacon target, and checks the audit set against what the beacon should have selected. It prints one PASS, FAIL or PENDING row per check and exits non-zero only on FAIL; PENDING means the week is younger than that artifact's own deadline. ots verify confirms the root is attested in the Bitcoin block it claims. Every week is tagged in the repository; checking out the week's tag pins the verifier to the exact revision published with that week. The procedure is normative in §13 of PROTOCOL.md; where any implementation disagrees with the text, the text governs.

06 What is in the public repository

• Repository — github.com/YermekIbrayev/tensorswing-record
• hashes/<model>/<week>/<ticker>.sha256 — one commitment per call, seven models, published Sunday.
• manifests/<week>.manifest.json and <week>.manifest.ots — the root, its pins, and the Bitcoin timestamp proof.
• stamps/<week>/ — RFC 3161 tokens for the manifest and the labels.
• labels/<week>.json — Friday's win, loss, scratch or abstain per call.
• audits/<week>/ — the beacon record and the sampled reveals, with salts and Merkle proofs.
• release/<week>.seed.tle — the time-locked archive key.
• incidents/ — the hash-chained log of every missed obligation.
• roster.json, universe.json and PROTOCOL.md — which models and which universe were in force, and the normative specification. Read it.

The graded results these proofs cover are on the track record page. The grading rule and the full weekly timetable are on the methodology page.