🔬 Clash Watchdog AI：审计的计算方法

版本：v1.0.0，已批准 状态：✅ 创始团队于 2026年4月16日批准 上级文件：../MUST_READ.md 姊妹文件：../architecture/agentic-audit-v1.md，规定 AI 代理（agent）怎样执行这套方法 管理规则：见 MUST_READ 第 15 节（修订流程）

2026年4月16日修订（批准时）： 本文件规定的所有审计流程，都在上面姊妹文件定义的 代理式审计架构 下执行。统计核心仍然完全是确定性的；只有调度、排程和报告草稿的整理由代理完成。5 年可重现承诺（§7.5）依然有效，因为统计函数锁定了版本，而代理的每个动作都记在数据来源账本里（§2.4）。

---

0. 前言

这份文件是 Clash Watchdog AI 审计工作的 技术宪章。它只回答一个问题：

给我们一款崩盘游戏，和它 N 局的历史数据，我们怎样判断它是公平、可疑，还是不公平？

我们公布过的每一份审计，都必须能追溯到这份文件的某一个版本。如果我们改变了衡量公平的方法，这份文件的版本也跟着改变；而每一份过去的审计，都继续挂在它当时所用的版本上。

这份文件里最重要的一句话是：

任何审计结论，都必须在 五年之后 仍然能被任何第三方重现：用公布时的计算方法版本和原始数据，得到同样的结果。

如果我们做不到这个承诺，就不能公布这个结论。

0.1 和 MUST_READ 的关系

这份文件继承了 MUST_READ.md 的以下内容，并把它们落实成做法：

• 第 2 节：六条宪章法则（特别是法则 4：算法不故弄玄虚）
• 第 4 节：产品架构（游戏状态 × 玩家状态数据引擎）
• 第 11 节：法律和风险立场（正当程序的要求）
• 第 15 节：修订流程（这份文件可以怎样修改）

这份文件和 MUST_READ.md 之间如有任何冲突，以 MUST_READ.md 为准。

---

1. 公平的三栏定义

我们不接受只从一个角度定义公平。一款崩盘游戏可以「平均下来在数学上公平」，玩起来却「体验上不公平」。一款游戏可以「统计上分布良好」，在密码学上却「不透明」。所以我们沿着 三个互相独立的栏 评估每一款游戏，只有在足够多的栏上、用足够的证据通过的游戏，才会进入公开的白名单。

1.1 A 栏：返还率公平（分配公平）

「这款游戏长期的返还，和平台说的对不对得上？」

测量的东西： 长期的返还率（RTP，长期每 100 拿回多少）、它的置信区间（误差范围），以及庄家优势随时间是否稳定。

主要统计量： 实测返还率对比官方公布的返还率。偏差用绝对的百分点来量。

基本假设： 平台公开说一个数（例如「RTP = 97%」），我们把它当作零假设，再检验数据是否否定这个零假设。

适用于： 每一款崩盘游戏，不管用什么技术。这是最能在游戏之间比较的一栏。

1.2 B 栏：分布公平（程序公平）

「这款游戏一局一局的表现，看起来像不像它公布的随机数生成器应该产生的结果？」

测量的东西： 倍数（爆点）的完整分布、前后两局之间是否独立，以及连串长度、反转密度和自相关里有没有异常的规律。

主要统计量： 卡方拟合优度检验、Kolmogorov-Smirnov 检验、Anderson-Darling 检验、游程检验、滞后 1 到 50 的自相关，以及倍数首位数字的本福特定律检验。

基本假设： 用诚实随机数生成器的崩盘游戏，产生的倍数会符合一个已知的理论分布（通常是截断的几何分布或幂律分布，形式为 M ~ 1/(1-U)，其中 U 在 [0, 1-house_edge] 上均匀分布）。我们检验实测数据在统计误差之内是否符合这个分布。

适用于： 每一款我们有足够逐局数据的崩盘游戏（最低门槛为 ≥2,000 局）。

1.3 C 栏：密码学公平（可自行验证）

「我们能不能用数学验证，每一局的结果，都正好是游戏平台在开局前就锁定要产生的结果？」

测量的东西：

• 整个可自行验证种子生命周期里，哈希链是否完整。
• 揭晓的服务器种子，和事先锁定的哈希是否一致。
• HMAC(server_seed, client_seed || nonce) 推算是否正确。
• 服务器种子随时间更换的规律（这是我们原创的部分，见 §4.3）。

主要检查： 用 SHA-256 验证每一个锁定的哈希和它揭晓的原像。对每一局能观察到的局，用 HMAC-SHA-256 推算出倍数。

基本假设： 可自行验证的游戏，会在用某个服务器种子玩任何一局之前，先锁定这个种子（公布它的 SHA-256 哈希）。之后种子揭晓，任何观察者都能把这个种子下的每一局重新算一遍，验证没有任何东西被动过。

适用于： 只适用于说自己可自行验证的游戏（目前有 Stake Crash、BC.Game Crash、Roobet Crash 和其他几款）。不适用于传统的服务器随机数游戏（Aviator、JetX、Spaceman 等），这些游戏在这一栏得到 N/A，这不是负分。

1.4 综合判定表

一款游戏的整体分类，取决于有几栏给出正面、负面或无法判断的结果。任何 N/A（这一栏不适用）都不算进分母。

「候选」状态要通过 §6 的正当程序流程之后，才会成为最终结果。

---

2. 数据收集和来源独立

任何单一的数据来源，都不会被单独信任。每一份审计都建立在 三个独立的来源 上，只有在所需的来源互相对得上时，才会公布结论。

2.1 三个来源

来源 1：官方／公开披露 游戏平台自己公开的数据。例如：

• 可自行验证的公开历史页面（Stake、BC.Game、Roobet 会公开一局一局的哈希记录）。
• 监管披露（巴西的 Lei 14.790 要求持牌平台公布返还率指标）。
• 游戏客户端公开的接口（API）。

如果平台在我们观察到这些数据之后，改动或删除了它们，这件事本身就会成为一个记录下来的数据点：来源 1 的所有观察，我们都保存不可更改的快照。

来源 2：社区众包 用户通过 Clash Watchdog AI 浏览器扩展、手动输入表单，以及可选的截图文字识别（OCR）提供的数据。每一份提交都会：

• 标上一个化名的提交者标识（从不连到真实身份）。
• 在提交那一刻由服务器加上时间戳。
• 和不同用户对同一段局提交的数据交叉核对。
• 如果看起来是投毒企图，就从审计里排除（在同一段局上，和其他来源相差超过 6σ 的离群值会被标记并隔离）。

来源 3：自营代理账户 Clash Watchdog AI 在每一款目标游戏上，经营自己的受审计账户，只下最低注，纯粹是为了观察我们用真实价值下注的局。这就是消费者保护和财务审计里用的「神秘顾客」做法。

• 每个代理账户里放着一小笔固定余额（每款游戏的预算待定，见 §10）。
• 账户会轮换并去关联，避免被识别或被区别对待。
• 每个动作都记下时间戳和网络层的抓包。
• 代理账户从不试图「赚」：目标是观察，不是获利。

2.2 交叉验证规则

           ┌────────────┐
           │  Source 1  │
           │  Official  │
           └─────┬──────┘
                 │
   ┌─────────────┼─────────────┐
   │             │             │
   ▼             ▼             ▼
  cross        cross          cross
  check        check          check
   ▲             ▲             ▲
   │             │             │
   └─────────────┼─────────────┘
                 │
        ┌────────┴────────┐
        │                 │
  ┌─────▼──────┐   ┌──────▼──────┐
  │  Source 2  │   │   Source 3  │
  │ Community  │   │ Self-Proxy  │
  └────────────┘   └─────────────┘

公布规则：

• 三个来源在容许范围内都对得上：结论可以完全有把握地公布。
• 两个来源对得上，第三个缺失：结论可以公布，但附上「部分来源」的说明。
• 两个来源对得上，第三个对不上：列入观察名单，展开调查。
• 来源 1 和来源 2、3 对不上（也就是平台报告的数据，和用户以及我们自己的账户观察到的不一样）：这是操控最强的单一信号，会立刻触发紧急黑名单审查（见 §6.3）。

2.3 最低样本量（v1.0 暂定）

这是一栏「开口说话」之前所需的最低局数。低于这些门槛，不管数据看起来怎样，这一栏都给出 INCONCLUSIVE（无法判断）。

注意：这些是暂定数字。 这些门槛来自检验力分析，目标是在 α = 0.05、β = 0.10 下，能发现 1% 的返还率偏差。最终数值会在 v1.0.0 批准前，由技术附录确认。

2.4 数据来源账本

进入审计流程的每一条原始数据记录，都标上：

• source_id：来自三个来源中的哪一个
• collection_timestamp（UTC，ISO 8601）
• observation_timestamp（UTC，ISO 8601）：这一局实际发生的时间
• collector_pseudonym（来源 2）或 proxy_account_id（来源 3）
• raw_payload_hash（未经修改的原始数据的 SHA-256）
• pipeline_version（处理它的数据导入代码的提交哈希）

这个账本只能追加。记录从不删除：如果一条记录后来被判定不合格（例如发现投毒），它会被标记，但仍然保留，作为审计痕迹。

---

3. 分层的统计方法

每一份审计都同时产出 两层 结果。两层必须永远一致：如果公开层说「通过」，技术附录却说「不通过」，这份审计就无效，必须重做。

3.1 公开层（给玩家、记者和监管机构）

简短、好懂、一个屏幕放得下。用平实的语言和少数几个主要指标。

每一份审计报告的公开层包含：

• A 栏主要结果： RTP: observed 96.82% (±0.18%) vs. declared 97.00% → 通过／不通过标志。
• B 栏主要结果： Distribution fit p-value: 0.31 → 通过／不通过标志，加一句平实的解读。
• C 栏主要结果： Provably-fair hash chain: verified for 12,430 consecutive rounds → 通过／不通过标志，或 Not applicable。
• 整体判定： 🛡️ WHITELIST（白名单）、⚠️ WATCHLIST（观察名单）、🚫 BLACKLIST（黑名单）其中之一，同时注明结论所依据的 证据分级（§5）。
• 每一栏 一句平实的解读。
• 审计所用的 计算方法版本。
• 下次复查日期。

3.2 技术附录层（给统计学家、学者和监管机构）

完整的统计分析。和公开报告一起发布，以 Jupyter 笔记本的形式放在 GitHub 上，路径是 clashwatchdog-ai/audit-reports/<game-slug>/<date>/notebook.ipynb。

每一份审计的技术附录包含：

A 栏（返还率）：

• 实测平均返还率，以及用自助法（bootstrap，重抽 1 万次）算出的 95% 置信区间
• 用 Kolmogorov-Smirnov 检验，比较实测返还率的滚动窗口和官方公布的返还率
• 方差分解（同一场之内对比不同场之间）
• 趋势分析：返还率对时间做线性回归，以发现漂移

B 栏（分布）：

• 卡方拟合优度检验，分组数 ≥ 20
• 和理论崩盘分布对比的 Kolmogorov-Smirnov 检验
• Anderson-Darling 检验（加重尾部偏差的权重，这对崩盘游戏很关键）
• 检验前后独立的游程检验
• 滞后 1 到 50 的自相关图
• 倍数首位数字的本福特定律检验
• NIST SP 800-22 的部分检验（第 2 阶段起）
• 多重检验校正： 对报告的所有检验，用 Benjamini-Hochberg 方法，FDR = 0.05

C 栏（可自行验证）：

• 对每一个揭晓的服务器种子，用 SHA-256 完整验证它和锁定的哈希
• 对验证窗口里的每一局，用 HMAC-SHA-256 重新算出倍数
• 种子更换分析：种子寿命的分布，以及换种子和用户层面事件的相关性（见 §4.3）
• nonce 连续性检查：找出漏掉或重复的 nonce

可重现的材料：

• Jupyter 笔记本本身（可以执行）
• 原始数据 CSV（或指向我们数据湖里不可更改快照的引用）
• 计算方法的提交哈希
• 环境说明（requirements.txt 或 pyproject.toml）
• 一条命令就能重现的脚本（make reproduce 或 python reproduce.py）

3.3 工具

第 1 阶段的参考实现：

3.4 分阶段建设

我们不会从第一天起就实现所有检验。统计方法分阶段建设，对应公司的搜索和内容策略：每一项新能力，也会成为一篇公开的方法更新文章。

每一次阶段升级都是一次 次版本号升级（v1.0 → v1.1 → v1.2），公开记录在变更日志里，并提前 14 天预告（见 §6.4）。

---

4. 可自行验证的深入验证

这一节详细说明 C 栏，也是整套方法里技术上最复杂的部分。这也是 Clash Watchdog AI 做出 原创研究贡献 的部分：§4.3 的种子更换分析框架。

4.1 可自行验证入门（留作记录）

一款典型的可自行验证崩盘游戏，是这样运作的：

1. 平台产生一个随机的 256 位 server_seed。
2. 在玩任何一局之前，平台公布 SHA-256(server_seed)，作为公开的锁定。
3. 用这个种子玩的第 n 局，倍数这样推算：

   hmac   = HMAC-SHA-256(key=server_seed, message=client_seed || nonce_n)
   hex    = first 52 bits of hmac, as a big-endian integer
   if hex == 0: multiplier = high_cap
   else:        multiplier = max(1.00, floor((2^52 * house_edge) / hex * 100) / 100)
   

   （确切的公式每个平台不同，我们的流程会记下每个平台自己的推算方法）
4. 玩了一定局数之后（通常是 1,000 到 1 万局，或 24 小时），平台 揭晓 server_seed。这时任何人都能算出 SHA-256(revealed_seed)，和原来的锁定对比。如果对得上，就说明这个种子是在这些局开始之前，诚实地锁定的。
5. 产生一个新的 server_seed，公布新的锁定，如此循环。

4.2 完整的哈希链验证（第 1 阶段能力）

对每一款监测中的游戏，每一个完成的种子周期，我们都会：

1. 取得原来的锁定哈希（分别从来源 1 和来源 3 独立取得）。
2. 取得揭晓的服务器种子。
3. 算出 SHA-256(revealed_seed)，和第 1 步对比。
4. 对 [0, seed_lifetime - 1] 里的每一局 n：
   • 取得平台和我们的代理账户记下的 client_seed 和 nonce。
   • 用平台写明的推算方法重新算出倍数。
   • 和来源 1、2、3 观察到的倍数对比。
5. 把结果记进数据来源账本（§2.4）。

任何一步出现任何差异，都可能是哈希对不上，会立刻列入观察名单并展开调查。确认的差异（能重现、多个来源都看到）会立刻进入紧急黑名单。

4.3 种子更换分析（第 2 阶段能力，Clash Watchdog AI 的原创贡献）

哈希链验证本身，只能确认平台没有违反它已经做出的锁定。它发现不了一种更隐蔽的手法：平台选择在 什么时候 换服务器种子，而这个时机和结果有关。

例如：一个平台可以诚实地锁定 server_seed_1，诚实地用它玩 1,000 局，诚实地揭晓它；却仍然能让游戏偏向自己：在换种子对它有利的那一刻，换到（事先锁定的）server_seed_2。换种子的时机，就成了被攻击的地方。

种子更换分析检查 种子寿命和换种子事件的分布，并且问：

1. 寿命分布。 种子是不是像平台说的那样，大致按固定间隔更换？我们把实测的种子寿命分布和公布的规则做拟合，算出 K-S 拟合优度。

2. 事件相关。 换种子和我们从来源 3 能观察到的用户层面事件有没有关系？

   • 是不是刚好在代理账户赚到一大笔之后换种子？
   • 是不是刚好在代理账户一注本来会在异常高的倍数上赚到之前换种子？
   • 换种子的时间，和每天的流量高峰有没有关系？

3. 换种子前后的分布变化。 换种子前 100 局的倍数分布，和换种子后 100 局相比，在统计上有没有不同？用双样本 Kolmogorov-Smirnov 检验。

4. nonce 连续性。 在一个种子的寿命之内，所有的 nonce 都对得上吗？nonce 序列里有缺口，表示有些局玩了，却没有公开记录。

5. 提前锁定验证。 一个安全的可自行验证平台，会事先锁定一串未来种子的哈希（提前锁定）。如果平台没有提前锁定，换种子的那段时间就成了一个攻击入口。我们会为每一款审计的游戏，记录并公布提前锁定的深度。

种子更换分析的产出：

• 一张换种子时间线图（公开层）。
• 五项检查各自的统计检验结果（技术附录）。
• 一个整体的「种子更换风险分」（Clean / Low / Medium / High / Critical，即无风险／低／中／高／严重）。

种子更换风险分为 Medium 或更差，会把这款游戏的 C 栏从正面降为无法判断，即使基本的哈希验证通过了也一样。

4.4 持续监测模式

对第 3 级（金级）的审计（§5），种子更换分析会持续进行。数据从来源 1 和来源 3 接近实时地导入，种子更换风险分每天更新。在监测窗口内，分数只要有实质变化，就会触发一次复查。

---

5. 按证据分级的分类门槛

我们不是用一条线来给游戏分类，而是用一个 分级的阶梯：证据的要求随样本量提高。数据越多，门槛越严。

5.1 三个等级

低于第 1 级的最低值，不公布任何结论：这款游戏在观察名单上标为 Insufficient Data（数据不足）。

5.2 白名单门槛（以下所有适用的规则都通过，游戏就进入白名单）

5.3 黑名单门槛（以下任何一条适用的规则触发，而且 三个来源都确认，游戏就进入黑名单）

5.4 观察名单

介于白名单和黑名单门槛之间的一切。观察名单 不是不合格，而是一种持续观察的状态。观察名单上的游戏，会附上一段人看得懂的说明，讲清楚还缺什么、哪里还无法判断。

5.5 激励一致（商业策略说明）

因为白名单门槛随等级升高而变严，平台想往上升（暂定 → 已核实 → 金级），就必须提供或允许收集更多数据。这意味着：

• 更多用户来看我们分析他们游戏的页面（我们在搜索上的收获）。
• 他们更透明（我们的数据护城河更深）。
• 更多持续观察的机会（我们的种子更换分析更强）。

这套方法本身，就成了一个让各方利益一致的机制。商业上的含义见 MUST_READ §5.2。

---

6. 正当程序

任何审计结论，都要先通过和它的判定类型相应的正当程序流程，才会公布。这一节规定怎样从 内部候选状态 转为 公开可见的名单。

6.1 正面转变（观察名单 → 白名单，或等级上升）

• 等待期： 0 天（立刻公布）。
• 通知： 公布之后才通知平台，不是之前。
• 理由： 正面转变会改善一款游戏的公开状态，不带诽谤风险。对好消息还要求通知期，只会拖慢建立信任，没有好处。

6.2 负面转变（白名单／观察名单 → 黑名单）

• 等待期： 30 天。
• 流程：
  1. 内部审计完成，设为黑名单候选。
  2. 两位创始人审查并签字同意（MUST_READ §9）。
  3. 私下寄给平台一份 通知材料，包括：
     • 完整的公开报告草稿和技术附录。
     • 用到的所有原始数据。
     • 计算方法版本的链接（§7）。
     • 邀请对方在 30 天内回应。
  4. 平台在 30 天等待期内可以选择：
     • 提交反证。 如果平台提供的数据显示我们的结论不对（例如我们漏了一个数据来源，或用错了推算公式），我们会重做审计。如果重做确认平台是对的，我们会撤销候选状态，在下一份透明度报告里公开更正，游戏维持原来的名单。
     • 对方法提出异议。 如果平台对我们的方法有异议，但对数据没有，黑名单生效时，他们的异议文字会和我们的报告 并列 公布。
     • 不作回应。 30 天之后，黑名单状态自动生效，报告会附上一条说明，注明平台没有回应。
     • 修改游戏。 如果平台因为我们的发现实质修改了游戏，并要求重新审计，我们把这当成一个新的审计周期。原来的黑名单报告会作为历史记录，留在公开存档里。
  5. 第 30 天：黑名单生效，附上平台的回应（或没有回应的说明）。

6.3 紧急黑名单

只用在 30 天等待期会让玩家持续受害的情况。触发条件：

• 观察到一个正在被利用的攻击手段，正在实时伤害玩家。
• 来源 1（平台自己的披露）和来源 2、3 对不上，表示平台在公布虚假数据。
• 哈希链断裂，而且找不到任何说得通的无害解释。
• 平台正在主动销毁我们审计所依据的证据。

流程：

• 等待期： 72 小时。
• 需要的签字： 两位创始人，加一位外部顾问（记者、学者或前监管人员；常设一个 3 人小组，其中任何一人签字即可）。
• 公布形式： 立刻在 Clash Watchdog AI 首页公布一则简短的 Urgent Safety Notice（紧急安全通知），72 小时等待期结束时，链接到完整的紧急报告。
• 同时通知： 紧急报告会同时分享给相关的监管机构、消费者保护非政府组织，以及至少两位资深的博彩业记者。

紧急黑名单是罕见而且沉重的行动。我们预计在运营的头 24 个月里，最多只会用 1–2 次。

6.4 计算方法升级引起的重新分类

当一次次版本或主版本的方法更改，会让任何现有的名单改变状态时：

• 预告期： 14 天。
• 预告期内我们公布：
  • 新的计算方法版本和变更日志。
  • 哪些游戏会在新方法下改变状态，以及怎样改变。
  • 这次升级的理由。
• 14 天之后： 新方法生效。旧的报告继续挂在它们原来的计算方法版本上（§7.3）。

6.5 两位创始人规则（只适用于 v1.0）

在运营的头 24 个月里，除了例行的观察名单 → 观察名单正面更新，每一次公开名单的改变，都需要两位创始人明确的书面签字。这是一层 人工纪律，让我们慢下来，在错误公开之前抓住它们。团队超过两人时，这条规则会由正式的审查委员会取代。

---

7. 版本和可重现性

这份计算方法文件遵循 语义化版本 2.0.0（Semantic Versioning）。每一份公开的审计报告，都永久挂在它当时所用的计算方法版本上。

7.1 版本号的含义

7.2 批准规则

• 修订号： 任何一位创始人都可以提交。
• 次版本： 两位创始人都必须签字。
• 主版本： 两位创始人加一位外部顾问都必须签字。之后按 §6.4 有 14 天预告期。

7.3 结论锚定

每一份审计报告的开头都包括：

game: stake-crash
audit_date: 2026-06-15
methodology_version: 1.1.0
evidence_tier: 2
verdict: WHITELIST
data_snapshot_hash: <SHA-256 of the full raw-data bundle>
notebook_commit: <GitHub commit hash of the reproduction notebook>

当我们后来把方法从 v1.1 升到 v1.2，这份报告 保留它的 v1.1.0 锚点。它不会被悄悄重做。名单现在的状态，可以被新方法下的新审计取代，但原来的报告永远不会改变。

7.4 存档政策

所有过去的计算方法版本都保存在 /methodology/archive/v1.0.0、/methodology/archive/v1.1.0 等位置。旧版本从不删除。任何审查我们历史的人，五年之后都必须能验证，在任何一天生效的是哪些规则。

7.5 可重现承诺（最重要的一项承诺）

Clash Watchdog AI 公布的任何审计报告，在公布五年之后，都必须能被任何第三方重现，而且只用： （a）报告开头引用的原始数据快照， （b）报告开头锁定版本的计算方法文件， （c）报告开头锁定提交哈希的笔记本。 重现必须得到同样的判定。如果得不到，就说明这份报告在公布时就无效，我们会撤回它，并在下一份透明度报告里公布更正。

这个承诺不是愿景，而是我们产出的每一样东西都必须满足的功能要求。

---

8. 法律用语规则

我们的方法是技术性的。我们的用词也必须是技术性的。随便的用语是一个法律上的攻击面，我们拒绝暴露它。

8.1 我们用的说法

• 「在 N 次观察中，X 游戏的平均返还率测得 Y%，和平台公布的 Z% 相差 W 个百分点。」
• 「以平台写明的参数推出的理论分布为对照，X 游戏的倍数分布没有通过卡方拟合优度检验，p = A。」
• 「X 游戏目前在我们的观察名单上，等待收集更多样本。」
• 「在观察窗口内，X 游戏的可自行验证哈希链有 N 局无法验证。」
• 「我们的样本目前不足以支持一个结论。」

8.2 我们从不用的说法

• 「X 游戏在作弊。」
• 「X 游戏被操控。」
• 「X 游戏是骗局。」
• 「别玩 X 游戏。」
• 「X 游戏被抓到偷玩家的钱。」
• 「我们预测 X 游戏会在 Y 爆。」
• 任何命令式或预言式的语言，一律不用。

8.3 时态和语气

• 所有事实陈述用 过去的直陈：「测得」「没有通过」「偏离了」。
• 所有现状陈述用 现在的描述：「在我们的观察名单上」「正在等待复查」。
• 永远不对游戏结果用将来时。 我们只对自己的行动用将来时：「将在 X 日重新审计」。
• 不对平台的意图作任何推测。 我们描述数据，不描述动机。

8.4 数字精度规则

• 百分比在公开层保留一位小数，在技术附录保留三位小数。
• 置信区间永远明确写出（从不只给一个点估计而不给范围）。
• p 值保留两位有效数字。
• 样本量永远和结论出现在同一个画面里。

---

9. 暂缓和未决事项

这些决定 标记为必须在 v1.0.0 批准前解决。写在这里，是为了没有人能假装忘了它们。

---

10. 分阶段建设路线图（有约束力）

这是审计系统本身的建设顺序。它有约束力的意思是：一项能力在建好并测试之前，我们不会用它发布审计结论。

第 1 阶段：第 0–3 个月（最小可行审计）

• A 栏：平均返还率 + 自助法置信区间
• B 栏：卡方 + Kolmogorov-Smirnov
• C 栏：SHA-256 哈希链验证（完整的链，不含种子更换分析）
• 数据来源：只用来源 1 + 来源 3（来源 2 的社区导入延到第 2 阶段）
• 等级：只公布第 1 级（暂定）的判定
• 预计公布：第 1 阶段结束前完成 3 份暂定级审计（Stake Crash、BC.Game Crash、Roobet Crash）
• 建设成果：一个可以重复用的 Jupyter 笔记本模板、一条数据导入流程，以及在网站上上线的 /methodology/audit-v1.md 文件

第 2 阶段：第 3–6 个月（所有栏的完整能力）

• A 栏：+ 方差分解，+ 漂移检测
• B 栏：+ Anderson-Darling，+ 游程检验，+ 滞后 1–50 的自相关
• C 栏：+ 种子更换分析（§4.3 的完整能力）
• 数据来源：开放来源 2 的社区导入（浏览器扩展测试版）
• 等级：可以给出第 2 级（已核实）判定
• 预计公布：再多 5 份审计，第 1 阶段的游戏首次升到已核实级
• 第一次非加密货币游戏的审计（Aviator，通过来源 1 + 2 审计，没有 C 栏）也预计在这个阶段

第 3 阶段：第 6–12 个月（持续监测 + 学术严谨）

• B 栏：+ 本福特，+ NIST SP 800-22 部分检验，+ Benjamini-Hochberg 校正
• C 栏：+ 持续监测模式，+ 多平台换种子对比
• 数据来源：三个来源都成熟
• 等级：运行最久的审计可以给出第 3 级（金级）判定
• 预计公布：持续更新，总共审计 10 款游戏，第一个金级白名单
• 第一次和外部学术审查合作

---

11. 团队培训（统计）

因为这套方法依赖统计素养，而两位创始人都没有公开确认受过正式的统计训练，创始团队承诺在 文件批准后 30 天内 完成以下事项：

必读／要动手做的：

1. Knuth，The Art of Computer Programming, Volume 2: Seminumerical Algorithms，第 3 章（随机数）。这是检验随机数生成器的经典论述。
2. NIST Special Publication 800-22 Rev. 1a，A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications。属于公有领域。
3. Wasserman，All of Statistics，第 9 章（假设检验）、第 10 章（似然）、第 13 章（非参数）。
4. Gentle，Computational Statistics，关于自助法和蒙特卡洛的各章。
5. Lehmann & Romano，Testing Statistical Hypotheses，第 15 章（非参数），拟合优度的理论。

实际培训：

• 重现一份已公布的随机数生成器审计（NIST 公布过示例报告）。
• 做一个从头到尾的小型审计练习：一款模拟的「诚实」崩盘游戏，和一款模拟的「稍有偏差」的崩盘游戏。验证这套方法能把两者正确分类。
• 在第一份公开审计发布之前，安排和一位统计学家的 2 小时付费咨询。

如果在 30 天内，我们判断我们之中必须有一人全职专注统计，另一人负责工程和内容，我们会相应更新 MUST_READ §9（团队结构）。

---

12. 词汇表

这份文件里用到的词的简短定义。带例子的完整定义，放在网站公开的「学习」栏目里。

• 客户端种子（client seed）：玩家可以选择自己设定的一个输入，能影响（但不能选择）可自行验证一局的结果。在 HMAC 里和 server_seed、nonce 组合。
• 崩盘游戏：一种赌博游戏，倍数从 1.00× 开始以不固定的速度上升，玩家必须在倍数在一个随机决定的点「爆掉」之前「收手」。
• 正当程序：把内部判定转为公开可见名单的流程；见 §6。
• 证据分级：暂定（Provisional）、已核实（Verified）或金级（Gold）其中之一；决定白名单／黑名单分类的门槛有多严；见 §5。
• 哈希链：一种密码学序列，每一个服务器种子在用它玩任何一局之前，都先用 SHA-256 锁定。
• HMAC：带密钥的哈希消息认证码。在可自行验证的推算里，用来把结果同时绑定到服务器的保密数值和玩家看得到的输入上。
• nonce：一个计数器，在一个服务器种子的寿命之内，每一局加一。在 HMAC 输入里和 client_seed 组合。
• 可自行验证（provably fair）：一类技术，让玩家事后能用数学验证，没有任何一局的结果和开局前锁定的不一样。
• 种子更换风险分：我们内部的评分（Clean / Low / Medium / High / Critical），总结一款游戏 §4.3 的种子更换分析。
• 返还率（RTP）：所有下注中，长期付回给玩家的百分比。和庄家优势加起来是 100%。
• 服务器种子（server seed）：游戏平台产生的一个随机 256 位数值，开局前用 SHA-256 哈希锁定，在用它玩的所有局结束后揭晓。
• 三来源交叉验证：我们的数据收集原则：官方披露 + 社区众包 + 自营代理账户，互相对照。
• 观察名单（Watchlist）：我们的一种公开状态，用于正在审计、但还没有足够证据（或证据互相矛盾），无法给出白名单或黑名单判定的游戏。

---

13. 下一步（v1.0.0 批准之前）

1. 解决所有暂缓和未决事项（§9）。
2. 完成 30 天的统计培训计划（§11）。
3. 写好并测试第 1 阶段的参考笔记本，用一对模拟的诚实／有偏差游戏。
4. 请一位媒体法律师，对 §8（法律用语规则）做一小时审查。
5. 在 Stake Crash 上开设至少一个来源 3 代理账户，开始导入数据。
6. 在第 1 阶段的数据库里建好数据来源账本表。
7. 签署这份文件（两位创始人），把状态从 DRAFT 改成 RATIFIED。

---

由创始团队起草，2026年4月15日。 版本 1.0.0-DRAFT：「第一个砝码放上去之前的天平」。