CoinRegistry 与 Currency：全链「币种目录」
本节要回答的问题
CoinRegistry在链上是什么角色（系统维护的共享注册中心）？Currency<T>与某地址下的Coin<T>列表，分别回答什么问题？- 索引器「按类型查元数据」与「按地址查余额」如何衔接？
前置：§15.2、§15.3。
后续：§15.7 · 地址资金。
原理：类型级登记 vs 地址级持有
| 维度 | Currency<T>（经 CoinRegistry） | 某 address 的 Coin<T> |
|---|---|---|
| 回答的问题 | 这类币 叫什么、几位小数、监管/供应状态 | 这个地址 当前持有哪些对象、各多少额度 |
| 是否共享 | 全局唯一目录项（逻辑上人人可读） | 拥有型对象，owner 为该地址 |
| 典型消费者 | 钱包展示、区块浏览器、合规标签 | 钱包余额、转账构造 |
精髓：Currency 是「电话簿里的条目」；Coin 是「你口袋里具体哪几张钞票」。二者通过 类型 T 关联，但 数据不在同一对象里。
CoinRegistry 的角色
Framework 将 CoinRegistry 实现为 系统级共享对象，集中保存各 Currency<T> 的注册信息（源码注释中说明其作为 central registry 的职责）。finalize 把 Currency<T> 纳入该注册体系，使得 按类型 T 解析元数据 成为可行、可缓存的读路径。
具体 对象 ID、字段布局 随版本演进；集成时应使用 官方 RPC / GraphQL 与当前 索引器 schema，而非硬编码 ID。
Currency 的 derived_object 与 TreasuryCap 关联
Currency<T> 使用 derived_object 从 CoinRegistry 派生地址空间（见 coin_registry 中 CurrencyKey<T>），保证 同类型唯一。treasury_cap_id 字段在注册流程中与 TreasuryCap 对象 ID 对齐，便于浏览器展示「该币的供应能力对象是谁」。
查询路径（集成视角）
- 解析类型
T：部署包地址、模块名、结构名（OTW 类型名）。 - 读取
Currency<T>（或经注册表 API）：展示 name、symbol、decimals 等。 - 读取用户地址下的
Coin<T>对象（或聚合接口）：展示 可用余额。 - 若使用 §15.7 的 地址资金，还需 另一读数路径（如
settled_funds_value），不可与 仅统计Coin对象 混为同一「余额」定义。
常见误区
- 「在 Registry 里查余额」：Registry 侧主要是 类型档案；余额在 对象 owner 与 accumulator（若使用）两侧。
- 以为
symbol全局唯一：链上允许多个类型使用相同展示符号；区分靠类型T。 - 忽略 regulated 状态：
is_regulated为真时，§15.8 的 DenyList 可能影响 输入可用性，与展示层「是否标红」需一致。
小结
共享的是类型元数据与注册状态；不共享的是各人手里的 Coin。 下一节讨论 协议层地址资金，它与 对象列表 并行存在，产品口径必须显式定义。