成绩单与存证怎么验证：不信我们，信哈希

一句话结论：成绩单的数字可以核对口径，存证的记录可以核对哈希。两层都不需要你相信我们的人品。

成绩单的口径

公开成绩单上的每一行都来自校准接口的实时计算，页面自己不写死任何数字。读它时看四个字段：

• 命中率：命中 ÷（命中 + 失效）。「到期未判」的单子不进分母——没到期的不算输也不算赢。
• 样本量 n：已判单数。样本太小的行，区间会很宽，别只看命中率。
• Wilson 95% 置信区间：命中率在这个样本量下的不确定范围。样本越少区间越宽，这是统计的诚实表达。
• 窗口与纪元：按 7 天、30 天、全部三个窗口切，再按引擎纪元和预测类型分桶。引擎改一次规则开一个新纪元，旧单按旧规则跟到了结，统计不混桶。

「贴边」预警额外带一个随机基率与倍数：随便蒙一个币，它 5 天内点火的概率是多少；贴边的命中率是这个基率的多少倍。倍数比裸命中率更接近「这层预警有没有用」。

存证：每天的 Merkle 批次

每天 00:05 UTC，系统把前一 UTC 日打开或关闭的全部信号、连同它们的生命周期事件，逐条做规范化哈希（叶子），按字典序构一棵 Merkle 树，根哈希写进存证批次并公开。Merkle 树的大白话：把很多条记录两两哈希、层层合并成一个根；任何一条记录被改动，根就会变。

根随后提交到 OpenTimestamps 公共日历，锚定到比特币区块链——这证明「这个根在某时刻之前就存在」。OTS 只是增信层：Merkle 路径验证本身不依赖 OTS 是否可用。

动手验证一条记录

打开存证验证，输入信号 ID（要同时选批次日期）或 64 位十六进制叶子哈希，接口返回这条记录的 Merkle 路径——从叶子到根，每一级的兄弟哈希和左右位置。服务端做两道检查：

1. 用叶子和路径重建根，与批次根比对；
2. 对信号条目另做「当前行重算叶子」比对：如果记录入库后被改过，重算的叶子会对不上。

任何人都可以按同一口径离线复算。批次根是公开的，算法是公开的，验证接口是匿名的。

这套机制防什么、不防什么

防的是「事后改单」「删输单」「挑时间窗」——行业里最普遍的三件事。不防的是「规则本身不好」：规则的好坏交给成绩单上的历史统计去证明或证伪，而历史统计不是收益承诺。