XODE 哨兵
Gene Son ·
自动化决策很容易做出，但事后准确证明到底发生了什么却更加困难。XODE Sentinel 为每一个决策创建加密凭证，将证明锚定到区块链，并让用户无需单纯信任运营方即可验证记录。
Sentinel 要解决的问题
当自动化系统拒绝奖励、封禁账户或应用某项政策时，用户通常只有一个选择：相信系统给出的解释。
Sentinel 改变了这种关系。它不再要求用户相信内部日志，而是提供一份可以独立验证的记录。
传统模式
相信运营方
运营方做出决定、保存证据并解释证据。用户必须在每一个环节都相信同一个主体。
SENTINEL 模式
验证证据
决策会变成加密凭证并锚定到 XODE，因此历史记录可以被独立验证。
10 月 1 日的案例
2026 年 10 月 1 日，Omni 因冷却时间拒绝了 166 笔广告奖励，因每日上限拒绝了 37 笔。
用户已经观看完广告，Google 也确认了观看行为，并且已经产生收入。真正重要的问题是：如何证明当时究竟做出了什么决定，以及这份记录之后是否可能被修改。
要求你相信证据的一方，不应该独占对该证据的控制权。
Sentinel 如何工作
每一个自动化决策都会获得一个指纹。系统将钱包、结果、原因、政策和时间戳标准化为确定性的记录，然后转换为加密哈希。
这些指纹会被每小时汇总到一棵 Merkle 树中。该树会生成一个根，只要其中一个指纹发生变化，最终的根也会发生变化。
随后，该根会通过 System.remark_with_event 提交到 XODE。从这一刻开始，运营方无法简单地重写这份历史承诺。
01
为决策生成指纹
将钱包、结果、原因、政策和时间戳标准化为一个确定性记录，并生成其加密指纹。
02
构建每小时 Merkle 根
将单独的指纹组合成 Merkle 树。即使只有一个指纹发生变化，最终的根也会改变。
03
将根锚定到 XODE
将根提交到 XODE。公开区块链成为历史记录的外部承诺。
系统只提交已经关闭的时间窗口。开放的时间窗口可能会因为之后到达的决策而失效。一份仍然可以被重写的提交无法证明任何事情。
用户无需依赖我们即可验证
用户会收到一份凭证和验证脚本，可以在自己的电脑上运行。
脚本只使用标准库和公开 RPC 数据。它不会询问 XODE 应用服务器验证是否有效。
验证过程会回答两个独立的问题。
01
用户提出异议
用户报告自己已经完成广告观看，但没有收到奖励。
02
支持团队查询
支持团队通过管理查询功能找到相关凭证。
03
提供凭证
将凭证和独立验证脚本提供给用户。
04
在本地运行
用户使用标准库在自己的电脑上运行验证器。
本地计算
记录是否属于该根？
验证器在本地重新构建证明，并检查用户的记录是否属于已记录的 Merkle 根。
公开 RPC
该根是否存在于链上？
验证器检查公开 RPC 数据，以确认该根是否确实存在于 XODE 区块链上。
如果两个检查都通过，那么该决策就以原样被记录，并且这份记录存在的事实已经公开锚定在区块链上。
支持团队不需要只解释决策，而可以直接提供证据。验证过程在用户自己的电脑上运行，我们的服务器不会参与计算。
事后篡改会立即被发现
将拒绝改为批准、修改原因、时间戳、目标钱包、政策或证据，都会导致验证失败。
测试期间，10 个字段分别进行了修改，全部 10 次修改都被检测出来。
原始记录
凭证与根匹配
原始决策生成的指纹包含在已经提交的 Merkle 根中。
已篡改
凭证不再匹配
修改受保护字段后会产生不同的指纹，从而导致验证失败。
如果历史记录发生变化，那么证明也应该随之发生变化。
“当时使用的是什么规则？”也会被记录
每一条记录都包含一个政策哈希。它不是人工维护的版本号。
该哈希会根据决策发生时实际生效的配置自动计算。
例如：每日 60 次 · 180 秒冷却时间 · 每月 200/50 上限。
如果之后修改了限制，政策哈希也会发生变化。因此，用户被拒绝时所使用的规则无法在之后简单地隐藏。
系统有意避免使用人工版本号。一个被忘记更新的版本号甚至比没有版本号更糟，因为它可能错误地声称系统当时使用了某种配置。
Sentinel 不是什么
它不能阻止黑客攻击。区块链并不会让 AI 变得无法被攻击，也不会阻止提示词注入。这些保护由应用内 AI 中单独设置的硬性防护机制负责。
它也不能证明决策本身是正确的。Sentinel 证明的是记录没有被修改。由于政策哈希也被记录，因此规则本身可以单独接受审计。
这两个概念必须区分：不可修改的决策并不意味着该决策自动正确。
验证器不会执行 SCALE 解码。为了让验证器无需额外库即可运行，它会直接在区块中查找根的字节。
希望进行更严格验证的人，可以使用 substrate-interface 或区块浏览器查看同一个区块，并找到相同的字节。
它带来了什么价值？
领域 现在 Sentinel 之后 奖励争议 “请相信我们的日志。” “自己验证。” — 提供凭证 + 验证器 监管审查 没有自动化决策的审计追踪 可以提供不可修改的历史决策记录 刷奖励治理 解释为什么用户被封禁 处罚决策拥有可验证的证据 企业信任 内部日志是唯一记录 任何人都可以查看的公开链上记录
在菲律宾 SEC 和 BSP 的监管环境中，一个潜在问题是：自动化决策是否拥有审计追踪。
没有这样的系统时回答这个问题，与能够证明系统已经实际运行，是完全不同的事情。
扩展路径
Sentinel 目前从广告奖励决策开始，因为这里是争议最常发生的地方。
通过改变记录中的 kind 字段，同样的结构未来还可以覆盖刷奖励标记、设备验证结果以及 AI 助手响应。
记录 AI 响应时，系统还可以保存生成该响应的模型以及约束该响应的政策文本。
01
广告奖励
保存奖励批准和拒绝背后的原因与政策。
02
刷奖励治理
为自动化刷奖励和滥用决策创建可验证的证据。
03
设备验证
保存设备身份和验证检查的结果。
04
AI 响应
记录哪个模型进行了响应，以及哪个政策约束了该 AI 回答。
当前状态
采集器目前已经在生产环境中运行。新的奖励决策会在产生后实时加入账本，奖励逻辑本身没有发生改变。
组件 状态 决策采集器 运行中 — 正在记录真实广告奖励决策 标准化 · Merkle 树 · 证明 测试 41/41 通过 独立验证器 测试 19/19 通过 每小时提交计时器 · 公共凭证 API 等待部署 链上提交 等待提交账户充值
在 60 项测试中，最重要的并不是往返测试，而是篡改检测。
系统已经测试了将拒绝改为批准、修改原因、政策、时间戳、目标钱包、替换证据以及降低 schema 版本等情况。
还有一个测试非常关键： 采集器和独立验证器是否生成完全相同的标准化字节？
如果这两个系统产生不同结果，那么所有已经签发的凭证都可能无法验证。这是系统可能遇到的最严重故障之一，因此正在进行直接测试。
更大的意义
Sentinel 的目标不是让用户更加信任自动化系统，而是让不必要的信任变得没那么重要。
每一个决策都会变成指纹。指纹变成 Merkle 根。根变成链上承诺。用户则获得一种可以独立验证结果的方法。
不要要求用户相信记录。给他们凭证、证明，以及区块链。