链上证据
一个数字如何回到它所依赖的区块，以及这条链薄在哪里。
证据总览
每张卡都点明来源。不给覆盖率百分比——§十六 要求先定义分母。
已验证支付事件C06 · C09
539
11 个已发布数据点
活跃支付地址C06
0
地址不等于用户；同一方可能持有多个。
已覆盖的链C01 · C09
2
100 · 5000
数据新鲜度C09
2026-09-01 06:40
UTC——已发布事实所依据的最新区块
证据链
从左到右：一个数字如何抵达它所依据的区块。每一段都点明拥有它的组件、它的状态、可引用的标识符，以及覆盖到哪里。展开可看细节。
C09洞察 / 指标部分metric-v45 个指标 · 3 个有序列 · 26 个点
支付事件post_auth_funds_action_count已观察11更早修订版没有更多历史
冲正reversal_count无数据0authorization_reversed_count 在 metric-v3 上有 394 点
授权调整authorization_adjusted_count无数据0authorization_adjusted_count 在 metric-v3 上有 76 点
活跃账户active_account_count已观察11更早修订版没有更多历史
活跃支付地址active_payment_address_count已观察4更早修订版没有更多历史
C06支付事实部分2 个部署9,100 个已提交批次 · 2 / 4 个部署
一个批次记录的是某个区块区间已被解释并提交。它回答的是覆盖到了哪里，绝不是有多少事实——因为 repair 会重新发布一个区间，被重发的事实是一行、却是两次批次贡献。
15 个已提交批次与其他批次重叠。逐部署的记录在下方的发布覆盖里。
C05解释部分3 个适配器修订版4 个修订区段
| 部署 | 适配器 | 修订版 | ABI / 映射 / 解析器 | 批次 | 区块 |
|---|---|---|---|---|---|
gnosis-pay-gnosis gnosis-pay | gnosis-pay-gnosis | ur-mantle-v0.3 | ur-mantle-v0.1 / ur-mantle-v0.1 / ur-mantle-v0.1 | 40 | 47,817,934 – 47,823,402 |
gnosis-pay-gnosis gnosis-pay | gnosis-pay-gnosis | gnosis-pay-gnosis-v0.2 | gnosis-pay-gnosis-v0.2 / gnosis-pay-gnosis-v0.2 / gnosis-pay-gnosis-v0.2 | 7,045 | 47,823,403 – 48,021,665 |
ur-mantle-mainnet ur | ur-mantle-mainnet | ur-mantle-v0.3 | ur-mantle-v0.1 / ur-mantle-v0.1 / ur-mantle-v0.1 | 46 | 31,420,289 – 99,600,000 |
ur-mantle-mainnet ur | ur-mantle-mainnet | ur-mantle-v0.4 | ur-mantle-v0.1 / ur-mantle-v0.1 / ur-mantle-v0.1 | 1,969 | 99,600,001 – 100,056,858 |
C03原始事件 / 交易未观察—本终端不发布
上面每一条事实都是从原始日志、交易与回执读出来的，而本终端不发布指向它们的定位符。C06 通过比本页背后更高权限的查询返回它们，而且原始载荷会过期——所以这里给出的标识符可能指向一个已经不存在的东西。
C02已终局区块已观察finalized2 条链 · 2 个部署
上面的一切都在终局头部读取，绝不在最新区块。C06 会拒绝任何 head policy 不是终局的发布，所以这个值是数据的性质、不是本页的设置——这里出现别的值意味着某个批次绕过了检查。
发布覆盖
所有已注册部署，以及 C06 提交了什么
etherfi-cash-optimism链 10
尚无发布
etherfi-cash-scroll链 534352
尚无发布
gnosis-pay-gnosis链 100
100%已读 203,732 个区块中的 203,732，连续
ur-mantle-mainnet链 5000
23%已读 68,636,570 个区块中的 16,395,859，连续
| 部署 | 链 | 活动 | 批次 | 区块区间 | 连续至 | 重复发布 | 数据截至 |
|---|---|---|---|---|---|---|---|
| etherfi-cash-optimism | 10 | 活跃 | 0 | — | — | 0 | — |
| etherfi-cash-scroll | 534352 | 已停止 | 0 | — | — | 0 | — |
| gnosis-pay-gnosis | 100 | 活跃 | 7085 | 47,817,934 – 48,021,665 | 48,021,665 | 0 | 2026-09-01 06:40 UTC |
| ur-mantle-mainnet | 5000 | 活跃 | 2015 | 31,420,289 – 100,056,858 | 47,816,147 | 15i与其他已提交批次区间重叠的批次——某次 repair 重新发布了该区间。事实本身不会重复计数，但批次的事实计数会，这就是本终端不给事实总数的原因。 | 2026-09-01 06:21 UTC |
指标目录状态
本页不读取的修订版上是否存在历史
| 指标 | 状态 | 点数 | 更早修订版 |
|---|---|---|---|
| 支付事件 post_auth_funds_action_count | 已观察 | 11 metric-v4 | 无 |
| 冲正 reversal_count | 无数据 | 0 metric-v4 | 394 点 authorization_reversed_count @ metric-v3 |
| 授权调整 authorization_adjusted_count | 无数据 | 0 metric-v4 | 76 点 authorization_adjusted_count @ metric-v3 |
| 活跃账户 active_account_count | 已观察 | 11 metric-v4 | 无 |
| 活跃支付地址 active_payment_address_count | 已观察 | 4 metric-v4 | 无 |
按支付职能看证据
每个目录职能已发布的评估分布
| 编号 | 职能 | 已评估系统 | 证据分布 |
|---|---|---|---|
| F01 | 支付账户 | 4/4 | 3 事实 1 仅私有面 |
| F02 | 用户资金 | 4/4 | 3 事实 1 仅私有面 |
| F03 | 账户注资 | 4/4 | 4 推断 |
| F04 | 授权请求 | 4/4 | 3 已被否证 1 推断 |
| F05 | 授权决策 | 4/4 | 2 已被否证 1 事实 1 仅私有面 |
| F06 | 链上支付控制 | 4/4 | 2 事实 2 推断 |
| F07 | 授权后资金动作 | 4/4 | 4 事实 1 仅私有面 |
| F08 | 资金冻结 | 4/4 | 2 事实 1 仅私有面 1 已被否证 |
| F09 | 授权调整 | 4/4 | 2 已被否证 1 推断 1 未知 |
| F10 | 清算指令 | 4/4 | 3 已被否证 1 推断 |
| F11 | 结算前资金移动 | 4/4 | 3 事实 1 未知 1 已被否证 |
| F12 | 网络最终结算 | 4/4 | 3 已被否证 1 推断 |
| F13 | 冲正 | 4/4 | 2 已被否证 1 事实 1 仅私有面 |
| F14 | 授权过期 | 4/4 | 2 已被否证 1 仅私有面 1 未知 |
| F15 | 退款 | 4/4 | 2 已被否证 1 仅私有面 1 未知 |
| F16 | 争议与拒付 | 4/4 | 1 推断 1 仅私有面 1 未知 1 已被否证 |
| F17 | 费用 | 4/4 | 1 推断 1 仅私有面 1 未知 1 已被否证 |
§七 还要求逐职能的已验证事件数、占比，以及 evidence link 覆盖率。C09 的序列是按部署发布的、不是按职能，而本终端没有 evidence link 投影，所以这三列是缺席而不是估算。§七 自己也写了数据不足时隐藏趋势、不要 mock。
证据来源
每个已发布区间是在什么之下读出来的——只计数，不做占比
适配器2
适配器修订版3
ABI 修订版2
映射修订版2
解析器修订版2
已发布区间4
一个区间同时在四种修订版下被读出，所以这些数字加起来不等于区间数，也不是它的占比。§九 要的是依赖集合，不是分布。
最近已验证事件
尚未发布这个模块需要逐事件的时间、链、职能、事件类型、金额与交易哈希。C10 的公开读模型不发布任何逐事件投影：本页背后的快照只有 scope、protocols、functions、capability_groups、metrics、capabilities 与 methodology，其中没有一项是逐事件或逐地址的。缺口在 C10，不在本页的布局。
最近原始交易
尚未发布这个模块需要逐交易的交易哈希、来源、去向、金额与链上状态。C10 的公开读模型不发布任何逐事件投影：本页背后的快照只有 scope、protocols、functions、capability_groups、metrics、capabilities 与 methodology，其中没有一项是逐事件或逐地址的。缺口在 C10，不在本页的布局。
已解码活动
尚未发布这个模块需要一条原始事件与它被解释成的支付事实并列。C10 的公开读模型不发布任何逐事件投影：本页背后的快照只有 scope、protocols、functions、capability_groups、metrics、capabilities 与 methodology，其中没有一项是逐事件或逐地址的。缺口在 C10，不在本页的布局。
可信层
已通过的规则，以计数表示——§十一 禁止在没有方法论时给出百分比
在终局头部读取2/2
已对照目录评估4/4
在锁定修订版上发布3/5
可追溯性没有展示。§十一 把它定义为已发布事实中可回溯到交易 / 日志 / 区块的比例，这需要 C10 不发布的逐事件投影。在这里给一个数字，就是 §十一 拒绝的那种臆造百分比。
证据示例
尚未发布§十二 要为每个支付职能给出一条代表性的已验证事实，并可展开到它的原始事件。两半都需要 C10 的逐事件投影，而它没有被发布。
证据洞察
尚未发布§十 要求每条洞察都带事实、时间窗口、观察范围与 evidence link。本系统没有组件产出确定性规则或研究结论，也不发布 evidence link 投影——所以这里的洞察会正好缺掉让它可核对的那一部分。
本终端不发布
observed_amount_totals
未观察 i金额按币种分别给出，不给总计。跨币种合计需要汇率，而 SpendGraph 在链上观察不到汇率。
industry_signals
规划中 i产品设计里有一条信号流。目前没有组件产出它，所以这里没有这个面板，而不是一个空面板。
protocol_ranking
未观察 i产品规格禁止：只描述能力与覆盖，不给系统排名。
market_share
未观察 i被观察的人群是 SpendGraph 的覆盖范围，不是市场。占比需要一个分母，而这里没有人测过它。
identity_capability_group
待研究 i冻结的职能目录里没有身份职能。注册表的身份词汇是 identity_continuity，问的是另一件事：账户能否在持有地址变更后延续。
credit_capability_group
待研究 i信用是评估行上的融资模型和 rail 角色，不是目录里的职能。没有可供协议据以被评估的对象。
protocol_category
无数据 i没有任何注册包声明类别，注册表模型里也没有这个字段。这里若显示类别，那会是本站的发明而不是对注册包的读取，所以对比页保留这一栏并点明缺口。
entity_directory
未观察 i公开读模型完全不携带账户引用，所以实体只被计数，永不被列举。
方法学
- 本站的每个计数都是 SpendGraph 的观察覆盖范围，不是链上支付市场的总量；本站也不在任何地方发布这个市场的分母。
- 计数从 C09 在锁定目录修订版上的已发布序列读取。本页不自己做任何计数——已发布指标的第二份实现就是第二个可能出错的地方。
- 发布批次回答的是覆盖到了哪里，绝不是有多少事实。repair 会重新发布一个区间，因此对批次的事实计数求和会把被修复的部分算两遍：2026-08-21 的实测是求和 85,021，而真实事实 81,034，撤回为零。
- 注册状态描述的是 SpendGraph 对某个注册包的审阅进行到了哪一步，不是对协议的评价；而且任何审阅状态都可能对应一个几个月前就停止承载支付的部署——这就是活动状态单独一列的原因。
- 支付职能目录冻结在十七项。新的协议术语被映射到已有职能上，而不是扩充目录；因此某个职能在一个协议的评估中缺席，意味着没有人评估过它，而不是它不存在。
- 六个能力分组只由本站定义，是十七个职能之上的呈现层。其中身份与信用在目录里没有对应职能，因此没有协议能据此被评估，页面上如实标出。