C 部分 — 应用部分 (C.1-C.4)

C 部分 — 应用领域#

C.0。简介#

本节定义了 B 节要求（8 域）对加密资产市场的每个 4 细分市场的适用性。适用性由每个 B 节域内的 M / R / N/A 矩阵（强制/推荐/不适用）表示（请参阅 B.1 — B.8 末尾的“适用性汇总表”块），并在本节中进行合并。

段：

• C.1 — 托管钱包和托管人
• C.2 — 非托管钱包（供应商钱包软件）
• C.3 — 加密货币交易所（CEX 和 DEX 前端）
• C.4 — 稳定币、RWA 代币、法币代币的发行者

C.1。托管钱包和托管人#

C.1.1。细分领域定义#

在自己的私钥管理下持有客户加密资产的组织。包括：

• 中心化交易所钱包（托管方）
• 专用托管人（Coinbase Custody、Anchorage、BitGo、Fireblocks Vault 等）
• 由数字金融资产（DFA）运营商运营的银行加密钱包
• 白标托管服务

C.1.2。 CCSA 域对于 C.1 的适用性#

所有 8 域对于 C.1 都是必需的。这是最严格的应用细分领域。

C.1.3。 C.1 的具体每级要求#

---

C.2。非托管钱包#

C.2.1。细分领域定义#

为用户提供对私钥唯一控制的软件或设备：

• 浏览器扩展钱包（MetaMask、Rabby 等）
• 手机钱包（Trust Wallet、Phantom 等）
• 桌面钱包（Electrum、Sparrow 等）
• 硬件钱包（Ledger、Trezor、Tangem 等）
• 智能钱包/账户抽象钱包

**C.2中的认证主体：**钱包产品的软件供应商或硬件制造商。最终用户无需认证，也无需审核。

C.2.2。 C.2 范围的双重性质#

C.2.2. C.2 范围的双重性质#

对于 C.2，该标准的要求适用于两种不同的环境：

• 供应商范围 — 对开发钱包产品的组织的要求（供应商内的员工、流程、基础设施）：包括入职、离职、SOD、背景检查、构建基础设施安全、发布管理。
• 设备范围 — 对最终用户设备上的钱包软件架构的要求：包括设备上的熵、Secure Enclave / StrongBox 中的安全存储、可信边界内的签名仪式、恢复 UX。

这些范围不适用于最终用户本身。用户独立决定自己的CCM（轮换种子的频率，是否使用多重签名）；供应商有义务提供机制和文档，而不是对用户强制执行策略。

C.2.3。 CCSA 域对于 C.2 的适用性#

C.2.4。 C.2 的独特要求#

代码安全性：

• 开源首选（用于社区验证和代码审查）
• App Store / Play Store 版本的可重复构建
• 使用经过验证的开发者身份进行代码签名
• 专有部分的代码混淆（如果适用）

防止提取：

• 防篡改措施
• UI 中显示助记词时的防截屏保护
• 越狱/根检测与降级功能（适用于移动设备）
• 反调试措施

关于CCM的用户教育：

• 关于助记词安全的应用内警告
• 反钓鱼措施（交易模拟、经过验证的联系人地址簿）
• 恢复指导文档，无需互联网连接即可使用

C.2.5。 C.2 的具体每级要求#

---

C.3。加密货币交易所（CEX 和 DEX 前端）#

C.3.1。细分领域定义#

加密资产交易平台，关于其托管基础设施CCM的保护：

• 中心化交易所（CEX）——托管方
• DEX 前端 - 管理功能签名密钥的管理
• OTC 平台 — 托管热/温/冷

范围说明： C.3 段仅涵盖交换基础设施中 CCM 的保护。交易引擎完整性、市场操纵预防、订单簿安全、上市标准、公平准入——这些是业务流程和市场完整性，超出了 CCSA 的范围（参见 0.2.2 部分）。

C.3.2。 CCSA 域对于 C.3 的适用性#

所有 8 域对于 C.3 都是必需的，对于 C.1 也是如此。

C.3.3。 C.3 相对于 CCM 的独特要求#

用户钱包（托管方）：

• 会话令牌受 D 类 CCM 保护（B.1.1 节）
• 签名操作的强制 2FA（B.4.3 部分）
• 高价值操作的升级认证（B.4.3 级别 2+）

内部运作：

• 提款时间锁定（B.6.4 部分）
• 机构账户地址白名单（B.6.5 节）
• 所有热/温钱包的实时只读监控（B.7.3 部分）

C.3.4。 C.3 的具体每级要求#

---

C.4。稳定币、RWA 代币、法币代币的发行人#

C.4.1。细分领域定义#

在区块链上发行代币的组织，关于其发行基础设施 CCM 的保护：

• 稳定币（USDT、USDC、DAI 等）
• RWA 代币（现实世界资产代币）
• 法币代币（货币支持代币）
• 证券型代币

范围说明： C.4 段仅涵盖铸造/销毁密钥和相关 CCM 的保护。储备金构成政策、审计储备金、储备金证明、治理流程、监管披露、代币持有者权利——这些是财务、治理和监管合规领域，超出了 CCSA 的范围（参见 0.2.2 部分）。

C.4.2。 CCSA 域对于 C.4 的适用性#

C.4.3。 C.4 相对于 CCM 的独特要求#

铸币/销毁密钥保护：

• 对于铸币/销毁来说，多重签名是强制性的（B.6.1 节）——无论市值如何，都是强制性的
• 只读所有铸币事件的监控（B.6.2 节）
• 铸币时间锁定 > 阈值（B.6.4 部分）
• 对未经授权的铸币事件进行失陷检测（B.7.3 节）

CCSA 不涵盖发行人的内容：

• 储备构成政策和审计储备——一个单独的合规域
• 代币持有者的权利、赎回程序——公司治理
• 智能合约审计（发行合约）——代码安全，单独域
• 监管披露——监管合规

C.4.4。 C.4 的具体每级要求#

---

C.5。跨部门规则#

C.5.1。多部门组织#

如果组织同时在多个部门运营（例如，交易所 + 托管人 + 发行人），则所有适用部门的要求均适用：

• 符合所有强制性要求
• 通用基础设施要求经过一次验证
• 单个ROC，按段细分

C.5.2。下级组织部门#

如果单个组织内的不同业务部门在不同的细分市场运营，则可以按细分市场进行认证：

• 每个业务单元可能有自己的级别和AOC
• 通用 CCM 基础设施要求经过一次验证
• 每个细分市场的独立报告

确定总体实体级别的规则。 如果组织被认证为单个实体（而不是每个细分市场），并且不同的细分市场产生不同的级别（例如，对于 C.1，级别由 AUM 确定为 L2，而对于 C.3，级别由日交易量确定为 L3），则总体实体级别 = 最大（每段级别）。这也适用于单个分段内的不同指标（AUM 与交易量）：采用最严格的级别。如果选择按部门认证（子组织路线），则每个业务部门都单独记录其自己的级别。

C.5.3。控制认可在多细分市场中的适用性#

如果存在基线证书（参见 A 节），则控制认可适用于每个要求，而不是每个细分市场。相同的基线（例如，PCI DSS 级别 1）可以同时涵盖组织所有部门的相同公共基础设施要求（B.4.4 特权访问、B.7.1 日志记录）。

C.5.4。多细分领域的关键要求#

对于所有 8 关键要求（B.1.1、B.1.2、B.2.1、B.3.1、B.4.1、B.5.2、B.7.3、B.8.1 — 参见章节D.2.5），控制认可不适用于任何细分领域（根据 A.0.3 部分）。多部门组织必须通过范围内每个部门的既定方法测试程序对关键要求进行全面的 CCSA 评估。禁止针对关键要求的定制方法（0.7.2 节）；完全禁止对四个完全禁止的关键要求（B.1.1、B.1.2、B.5.2、B.7.3）进行补偿控制（第 0.8.2 节）；对于其余四个（B.2.1、B.3.1、B.4.1、B.8.1），仅在获得理事会批准的情况下才允许在 1 层（第 0.8.3 节）。

相关#

• 10 — B.8 — Personnel and Access Control — 之前的 B 部分域
• 12 — Section D — Certification Levels — 下一部分

来源#

请参阅前面的 0.4 规范性参考文献部分。