Performance
Unit curve (base 100)
Calibration events
- ML out04-04Dropped moneyline — no detectable edge
- Spread out05-09Dropped spreads — converged on totals
- ML+SP back06-18Moneyline + spread reinstated after 2026-aware recal: ML +33.8% / spread +26.8% walk-forward ROI
- v1.106-24v1.1: removed betting-market leakage features (ml_odds, spread_odds, total_odds); spread calibration gap 17pp → 2.6pp; all 3 markets retrained
- v1.206-25v1.2: feature-count tune (ML 13→~20 features +10.6pp ROI, OU 30→~25 +4.5pp ROI) + spread deactivated — clean-model calibrated sweep showed negative ROI at every feature count on spread
- v1.306-25v1.3: added weather_temp_f to OU candidate pool (single-feature ablation showed +4pp ROI vs v1.2 baseline; park_factor_delta solo had no lift). ML/spread excluded from weather/park per ablation (-2pp on ML when added).
Hypothetical P&L by market — model suggestions
MLB started with moneyline, spread (run-line), and totals. Through early April, moneyline was the model's strongest market — books had not yet calibrated to MLB's early-season line volatility, and the model identified real mispricing. As books caught up through April, the edge could only be captured against the morning opener; by the time a normal-hour customer logged in, sharp money had already moved the line. Spread/run-line ran longer but was retired in May. The model now focuses on totals — the one market where the edge survives realistic execution times. We recalibrate regularly across all markets to find edge wherever it surfaces.
Why we don't bet moneyline anymore
The early-season moneyline edge was real, not variance. Every win/loss in the chart above is the actual game outcome — the model genuinely picked winners against the morning opener. So why does the ML curve keep trending up? Because each suggestion is settled at the odds the model saw when it scored it — the dawn opening line. By the time sharp money loaded in at 9 or 10 AM, those numbers had moved 10–20 cents toward the model's predicted probability. A subscriber betting at noon sees the post-sharp-move line, which has already absorbed most of the mispricing. We're not asking anyone to set a 4 AM alarm and race the sharps to the same close. Totals don't have that timing problem — the edge survives normal execution windows. That's where the model concentrates now.
| Market | Bets | W–L | Win% | Net P&L |
|---|---|---|---|---|
| Moneyline | 1001 | 475–526 | 47.4% | +$0.00 |
| Spread | 1114 | 515–599 | 46.2% | +$0.00 |
| Totals (Over/Under) | 1198 | 592–606 | 49.4% | +$0.00 |
| f5_moneyline | 33 | 13–20 | 39.4% | +$0.00 |
| f5_spread | 38 | 19–19 | 50.0% | +$0.00 |
| f5_totals | 27 | 14–13 | 51.8% | +$0.00 |
Audit Trail
Every pick file is cryptographically timestamped on the Bitcoin blockchain. Pre-game ✓ means the proof was created before games started — proving the prediction was locked in pre-game. Retro means the file was back-stamped after the fact; this still proves the file has not been altered since the stamp date, but cannot prove pre-game timing. Click Verify to confirm any proof directly from Bitcoin.
How to verify the blockchain timestamp on your own
Each picks file is hashed and the hash is committed to the Bitcoin blockchain via OpenTimestamps. This proves the file existed before the first Bitcoin block mined after it was stamped — i.e., before any game that day could have started.
- 1Download both filesClick Download JSON to get the picks file, then Download OTS Proof to get the timestamp proof. Keep them in the same folder with the same base name (e.g.,
2026-02-21.jsonand2026-02-21.json.ots). - 2Open the OpenTimestamps verifierGo to opentimestamps.org and scroll to the Stamp & Verify section.
- 3Upload the .ots proof fileDrag the
.otsfile into the verification box. The site will automatically look for a matching document to hash. - 4Upload the JSON picks fileWhen prompted, also upload the
.jsonfile. The verifier hashes it and checks that the hash is embedded in the.otsproof chain. - 5Read the resultA successful verification will show a green confirmation with the Bitcoin block number and timestamp — proving the exact picks were published to the blockchain before that block was mined. Any alteration to the JSON would cause the hash to mismatch and verification to fail.
Prefer the command line? Install opentimestamps-client via pip and run: ots verify 2026-02-21.json.ots