支付生态图景
已注册系统、它们覆盖的能力分组，以及各自被观察到什么程度。
快照
观察覆盖范围，不是市场总量——每张卡都点明自己的来源
已观察支付事件C06 · C09
539
11 个已发布数据点
支付系统C01
4
4 个注册包
活跃支付地址C06 · C09
—
仅限地址模型系统i链上地址是不是账户身份，各个已注册系统的答案不同：UR 的账户是 Fiat24Account 的 ERC-721 token id，注册表明确说它不是持有地址；RedotPay 根本没有链上账户。本指标只回答账户模型为地址的系统，这条边界写在指标定义里。它不是「活跃账户」的一个占比，也不得与之相加——这里数到的每个地址，同时也是那边的一个账户。
已观察活动C06
未观察
需要金额归因模型 i金额按币种分别给出，不给总计。跨币种合计需要汇率，而 SpendGraph 在链上观察不到汇率。
已连接的链C01
2
100 · 5000
支付栈地图
支付经济周围的六个能力分组。位置按目录顺序自顶端顺时针排列；这里没有任何连线代表价值流向，本站也不发布任何流向。
支付经济
4
个已注册系统
6 个能力分组中 4 个可评估
价值存放在哪
F01
价值如何进入
F02 F03
支付如何被批准
F04 F05 F06 F08 F09 F14
价值如何转移
F07 F10 F11 F12 F13 F15
如何阅读：自顶端顺时针为冻结目录顺序。没有目录职能的能力分组留在自己的位置上并说明原因。
内容映射还用「层」指支付经济的六个生态区域。那是另一套模型，不是这张图。iLandscape 映射 §三 命名了六个生态层——Stablecoin Rails、Payment Accounts、Payment Instruments、Merchant & Payments、Settlement & Infrastructure、Credit & Lending。这张图渲染的是六个能力分组，因为那才是十七职能冻结目录能据以评估的东西。没有任何注册包声明 category，所以层模型没有 per-protocol 数据可渲染；今天画出来会是六个空状态取代真实评估。
协议浏览器
按标识符排序——不是排行榜
| 系统 | 注册 | 网络 | 链 | 职能 | 活跃地址 | 覆盖 |
|---|---|---|---|---|---|---|
| Ether.fi Cash (cash-v3) etherfi-cash | DRAFT | 14 | 0 | 17/17 | — | 活跃 未发布 已停止 未发布 |
| Gnosis Pay Safe Card Protocol gnosis-pay | DRAFT | 1 | 1 | 17/17 | — | 活跃 7085 批次 · 47,817,934 – 48,021,665 · 连续至 48,021,665 |
| RedotPay redotpay | DRAFT | 3 | 0 | 17/17 | — | 无部署 |
| UR Account / Card Protocol ur | DRAFT | 1 | 1 | 17/17 | 不适用iC01 登记该系统的账户模型为 `ERC721_TOKEN_ID`，其账户身份不是链上地址，因此地址计数对它没有可报告的值，而不是值为零。它的活动计入「活跃账户」——那是覆盖全部账户模型的口径。 | 活跃 2015 批次 · 31,420,289 – 100,056,858 · 连续至 47,816,147 |
能力分组
身份
目录中无此项账户
4/4 个系统已评估资金注入
4/4 个系统已评估授权
4/4 个系统已评估结算
4/4 个系统已评估信用
目录中无此项链
有已发布事实的链——不是每个已注册网络
1001
50001
已注册网络19
发布状态
注册表声明的内容，与已经发布的内容对照
在发布事实2
已注册，尚未发布2
生态洞察
每条都带数字、窗口与来源
539 支付事件
2026-08-21 → 2026-08-31 · 11 个窗口post_auth_funds_action_count · metric-v43 活跃账户
2026-08-21 → 2026-08-31 · 11 个窗口active_account_count · metric-v40 活跃支付地址
2026-08-28 → 2026-08-31 · 4 个窗口active_payment_address_count · metric-v4§六 还要用规则引擎与研究分析给出每条观察背后的解读。本系统两者都没有，所以这里是带窗口的已发布测量，不是对它们的解读。§六 禁止无证据预测；这里没有任何一条外推到最后一个窗口之外。
最近加入的系统
尚未发布§七 要的是哪些系统最近进入 SpendGraph 的观察范围。注册表是已发布的，但它不带注册时间戳——本读模型里没有任何字段记录一个包是何时加入的——所以没有可排序的依据。按标识符排序看起来像答案，但它不是。
方法学
- 本站的每个计数都是 SpendGraph 的观察覆盖范围，不是链上支付市场的总量；本站也不在任何地方发布这个市场的分母。
- 计数从 C09 在锁定目录修订版上的已发布序列读取。本页不自己做任何计数——已发布指标的第二份实现就是第二个可能出错的地方。
- 发布批次回答的是覆盖到了哪里，绝不是有多少事实。repair 会重新发布一个区间，因此对批次的事实计数求和会把被修复的部分算两遍：2026-08-21 的实测是求和 85,021，而真实事实 81,034，撤回为零。
- 注册状态描述的是 SpendGraph 对某个注册包的审阅进行到了哪一步，不是对协议的评价；而且任何审阅状态都可能对应一个几个月前就停止承载支付的部署——这就是活动状态单独一列的原因。
- 支付职能目录冻结在十七项。新的协议术语被映射到已有职能上，而不是扩充目录；因此某个职能在一个协议的评估中缺席，意味着没有人评估过它，而不是它不存在。
- 六个能力分组只由本站定义，是十七个职能之上的呈现层。其中身份与信用在目录里没有对应职能，因此没有协议能据此被评估，页面上如实标出。