第11讲:RWA——现实世界资产代币化

  • RWA:现实世界资产(Real-World Assets)的链上映射与管理
  • 关注:国债、基金、信贷、票据、应收账款等资产的代币化路径
  • 难点:确权、执行、合规与金融基础设施协同
  • 关键问题:RWA 的核心瓶颈在技术还是法律/制度?
  • 关键问题:机构为何在此阶段重新关注链上登记与清结算?

上讲回顾与本讲定位

  • 上讲(第 10 讲)核心:Rollup (Optimistic/ZK)、EIP-4844/blob 交易、模块化区块链的分层逻辑
  • 本讲位置:金融应用主线——当扩容使链上交易成本下降,传统资产"上链"的经济可行性提升
  • 关键追问:RWA 的核心瓶颈在技术还是法律/制度?代币化是"技术升级"还是"制度创新"?
  • 预习回顾:模块化降低基础设施成本 → 为机构级的资产登记与清结算提供了技术前提

1.1 什么是 RWA

  • RWA 是现实世界资产的链上映射与管理,不是"把实物搬上链"
  • 重点是把权利、流程、登记与交割机制数字化与可追踪化
  • 链上 token 只是载体,关键在于权利能否在现实中可执行
  • 判断标准:链上记录与链下法律关系能否闭环
  • 教学要点:区分"技术上链"与"法律确权/可执行性"
flowchart LR A["现实世界资产
Real World Asset

房产|债权|票据|商品|收益权"] B["链下法律关系
Legal Claim

所有权 / 收益权 / 债权
合同、登记、托管、审计"] C["数字化流程
Digitized Process

确权|估值|登记|托管
信息披露|交割|清算"] D["链上表示
On-chain Token

Token / NFT / 合约账户
记录权利状态与交易流转"] E["现实可执行
Real-world Enforceability

法律追索|资产交割
收益分配|违约处置"] F{"链上记录
与链下权利
能否闭环?"} G["只是技术上链
不构成有效 RWA"] A --> B --> C --> D --> F F -- 是 --> E F -- 否 --> G E --> B style A fill:#eef6ff,stroke:#3b82f6,stroke-width:1.5px style B fill:#f8fafc,stroke:#64748b,stroke-width:1.5px style C fill:#ecfdf5,stroke:#10b981,stroke-width:1.5px style D fill:#fff7ed,stroke:#f97316,stroke-width:1.5px style E fill:#fef2f2,stroke:#ef4444,stroke-width:1.5px style F fill:#fefce8,stroke:#ca8a04,stroke-width:1.5px style G fill:#f1f5f9,stroke:#94a3b8,stroke-dasharray: 5 5

1.2 RWA 与传统资产管理的核心区别

  • 传统模式:资产登记依赖中央托管机构(CSD),转让需多层中介对账
  • RWA 模式:以智能合约管理资产状态,以共享账本减少对账摩擦
  • 核心差异不在于"资产本身",而在于权利记录与转让方式
  • 传统金融重视"最终性"(finality),链上强调"可验证性"(verifiability)
  • 两种模式可共存互补:链上作为登记层,链下作为执行层
维度 传统框架 RWA 框架
登记主体 中央证券托管(CSD) 分布式账本 / 智能合约
结算周期 T+1 / T+2 准实时
对账方式 逐层对账、双边确认 共享账本、单次写入
最终性来源 法律规则+机构担保 共识机制+代码执行

1.3 RWA 市场概况与全球趋势

截至 2025 年初,链上 RWA 总规模(不含稳定币):约 150-200 亿美元(数据来源:rwa.xyz,2025 Q1;该数据为链上可观测部分,不含已备案但未上链的项目)

  • 核心增长驱动因素:
    • 利率高位背景下,代币化国债/货币基金收益可观
    • 传统金融机构加速探索链上清结算基建
    • 监管框架逐步清晰(MiCA、新加坡 PSA、香港 VASP 制度)
  • 主要资产类别分布:
    • 代币化基金/国债:约 40%
    • 私募信贷:约 25%
    • 房地产:约 15%
    • 碳信用与另类资产:约 10%
    • 票据与应收账款:约 10%
  • 区域格局:美国(代币化基金/国债)、亚太(贸易融资/票据)、欧洲(基金/房地产)
flowchart LR A["2025初
约 180 亿美元"] --> B["2025中
超过 240 亿美元"] --> C["2026 Q1
约 290 亿美元"] A -.增长.-> B B -.增长.-> C style A fill:#dbeafe,stroke:#2563eb,stroke-width:1.5px style B fill:#bfdbfe,stroke:#1d4ed8,stroke-width:1.5px style C fill:#fef3c7,stroke:#f59e0b,stroke-width:2px
flowchart TB A["主要增长板块"] B["代币化国债 / 货币市场基金
高利率环境下的链上收益资产"] C["私募信贷 / Tokenized Credit
RWA.xyz 单独追踪"] D["房地产 / 基金 / 另类资产
区域与监管差异明显"] A --> B A --> C A --> D style A fill:#eff6ff,stroke:#2563eb,stroke-width:1.5px style B fill:#ecfdf5,stroke:#10b981,stroke-width:1.5px style C fill:#fff7ed,stroke:#f97316,stroke-width:1.5px style D fill:#f8fafc,stroke:#64748b,stroke-width:1.5px
注:2025初采用课程区间中值约 180 亿美元表示;2025中公开资料称不含稳定币 RWA 超过 240 亿美元;2026 Q1 公开资料称约 290 亿美元。实际数据请以 RWA.xyz 实时仪表盘为准。

2.1 传统资产登记与清算流程的痛点

  • 传统资产登记、转让、对账、清算流程涉及多方系统,复杂度高
  • 典型流程:交易执行 → 前台确认 → 后台核对 → 清算所担保 → 托管行交割 → 央行资金结算
  • 各环节信息孤岛,造成对账成本与争议处理费用居高不下
  • 结算周期(T+1/T+2)带来对手方风险与资本占用
  • 国际案例:DTCC 日均处理 1 亿+笔交易,但多系统同步仍是核心瓶颈
flowchart LR A["交易执行
Trade Execution"] B["前台确认
Front-office Confirmation"] C["后台核对
Back-office Reconciliation"] D["清算所担保
CCP / Clearing House"] E["托管行交割
Custodian Settlement"] F["央行资金结算
Central Bank Money Settlement"] A --> B --> C --> D --> E --> F P1["痛点 1
多方系统割裂
信息孤岛"] P2["痛点 2
重复对账
争议处理成本高"] P3["痛点 3
T+1 / T+2 结算周期
对手方风险与资本占用"] P4["痛点 4
中介链条长
流程复杂度高"] B -.-> P1 C -.-> P2 D -.-> P4 E -.-> P3 F -.-> P3 style A fill:#eef6ff,stroke:#3b82f6,stroke-width:1.5px style B fill:#f8fafc,stroke:#64748b,stroke-width:1.5px style C fill:#f8fafc,stroke:#64748b,stroke-width:1.5px style D fill:#fff7ed,stroke:#f97316,stroke-width:1.5px style E fill:#fff7ed,stroke:#f97316,stroke-width:1.5px style F fill:#ecfdf5,stroke:#10b981,stroke-width:1.5px style P1 fill:#fef2f2,stroke:#ef4444,stroke-width:1.5px style P2 fill:#fef2f2,stroke:#ef4444,stroke-width:1.5px style P3 fill:#fef2f2,stroke:#ef4444,stroke-width:1.5px style P4 fill:#fef2f2,stroke:#ef4444,stroke-width:1.5px

2.2 区块链的吸引点:透明、共享、可审计

  • 区块链核心价值:共享账本(shared ledger) 取代逐层对账
  • 共享账本特性:交易记录仅写入一次,所有授权方同步可见
  • 透明度:所有合规节点均可独立验证账户余额与历史记录
  • 可追踪性:从资产创设到流转的完整链上审计轨迹
  • 自动化潜力:智能合约可执行自动合规检查、红利分发、抵押品管理
痛点 传统方案 链上方案
多系统对账 双边对账 + 人工复核 单账本多方共享
结算周期 T+1/T+2 准实时(分钟级)
操作风险 人工干预点多 智能合约自动执行
审计可得性 事后调取 实时链上可查

2.3 机构视角:效率提升与合规可控

  • 机构核心诉求:效率提升 + 合规可控,而非"去中心化最大化"
  • 关注点:
    • 缩短结算周期,降低资本占用
    • 减少运营风险与对账人工成本
    • 提升审计效率与监管汇报可得性
  • 关键信号:DTCC 推出清算与结算的 DLT 测试平台、Euroclear 探索区块链结算
  • 华尔街大型银行(JP Morgan、Citigroup)已投入大量资源建设链上平台
  • 教学要点:机构采用区块链的主要驱动力是"降本增效",而非加密原教旨主义
flowchart LR A["机构采用区块链
Institutional Blockchain Adoption"] B["效率提升
Efficiency"] C["合规可控
Compliance & Control"] B1["缩短结算周期
T+1/T+2 → 更接近实时"] B2["降低资本占用
减少未结算敞口"] B3["减少运营成本
降低人工对账与差错处理"] C1["审计可追踪
交易与权利状态可验证"] C2["监管汇报更可得
数据标准化与自动化报送"] C3["权限与身份管理
许可链 / KYC / 白名单"] D["不是目标:
去中心化最大化"] E["真实目标:
降本增效 + 风险可控"] A --> B A --> C B --> B1 B --> B2 B --> B3 C --> C1 C --> C2 C --> C3 A -.对比.-> D A ==> E style A fill:#eff6ff,stroke:#2563eb,stroke-width:2px style B fill:#ecfdf5,stroke:#10b981,stroke-width:1.5px style C fill:#fff7ed,stroke:#f97316,stroke-width:1.5px style B1 fill:#f0fdf4,stroke:#22c55e,stroke-width:1.2px style B2 fill:#f0fdf4,stroke:#22c55e,stroke-width:1.2px style B3 fill:#f0fdf4,stroke:#22c55e,stroke-width:1.2px style C1 fill:#fffbeb,stroke:#f59e0b,stroke-width:1.2px style C2 fill:#fffbeb,stroke:#f59e0b,stroke-width:1.2px style C3 fill:#fffbeb,stroke:#f59e0b,stroke-width:1.2px style D fill:#f1f5f9,stroke:#94a3b8,stroke-dasharray: 5 5 style E fill:#fef3c7,stroke:#f59e0b,stroke-width:2px

3.1 钱包地址管理与机构账户体系

  • 钱包/地址不仅是个人工具,也可作为机构账户与权限管理载体
  • 地址体系可承载:角色定义、权限分层、审批流程、操作审计
  • 多签钱包(multisig)在机构场景中广泛使用——多方批准才能执行转账
  • 技术架构上,钱包地址可作为"账户单元"连接到内部 ERP/OMS 系统
  • 但"地址控制权"不等同"法律意义上的权利确认"
flowchart TB A["机构账户体系
Institutional Account System"] B["钱包地址 / 账户单元
Wallet Address as Account Unit"] C["内部系统连接
ERP / OMS / 风控系统"] D["角色定义
Role Definition"] E["权限分层
Permission Layers"] F["审批流程
Approval Workflow"] G["操作执行
Transaction Execution"] H["操作审计
Audit Trail"] I["多签钱包
Multisig
多方批准后执行"] J["合规控制
KYC / 白名单 / 限额 / 职责分离"] K["关键边界
地址控制权 ≠ 法律意义上的权利确认"] A --> B A --> C B --> D D --> E E --> F F --> G G --> H B --> I I --> F C --> J J --> E H --> C B -.需要链下法律文件、登记与托管安排支持.-> K style A fill:#eff6ff,stroke:#2563eb,stroke-width:2px style B fill:#ecfdf5,stroke:#10b981,stroke-width:1.5px style C fill:#f8fafc,stroke:#64748b,stroke-width:1.5px style D fill:#f0fdf4,stroke:#22c55e,stroke-width:1.2px style E fill:#f0fdf4,stroke:#22c55e,stroke-width:1.2px style F fill:#f0fdf4,stroke:#22c55e,stroke-width:1.2px style G fill:#f0fdf4,stroke:#22c55e,stroke-width:1.2px style H fill:#f0fdf4,stroke:#22c55e,stroke-width:1.2px style I fill:#fff7ed,stroke:#f97316,stroke-width:1.5px style J fill:#fff7ed,stroke:#f97316,stroke-width:1.5px style K fill:#fef2f2,stroke:#ef4444,stroke-width:2px

3.2 从技术确权到法律确权的飞跃

  • 链上确权需要解决三个层次的问题:
    1. 主体识别:链上地址对应到哪个法律主体(自然人/法人/信托)?
    2. 授权链条:交易指令是否经过合法授权?
    3. 证据与争议解决:链上记录在法庭上作为证据的效力如何?
  • 法律框架要求:技术账户必须对接法律主体的合同关系与责任结构
  • 只靠地址签名不足以建立法律确权 —— 需要补充法律协议、托管安排与 KYC/KYB 验证
flowchart BT T0["链上技术确权
地址 · 私钥 · 签名 · 交易记录"] T1["第一层:主体识别
链上地址对应哪个法律主体?
自然人 / 法人 / 信托"] T2["第二层:授权链条
交易指令是否经过合法授权?
是否符合合同、章程与内部审批"] T3["第三层:证据与争议解决
链上记录在法庭上的证据效力如何?
发生争议时由谁管辖、如何裁判"] T4["法律确权
合同关系 · 责任结构 · 权利归属"] T0 --> T1 --> T2 --> T3 --> T4 S["补充机制
法律协议 · 托管安排 · KYC / KYB 验证"] S -.-> T1 S -.-> T2 S -.-> T3 classDef tech fill:#ecfdf5,stroke:#059669,stroke-width:2px,color:#064e3b classDef layer1 fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#1e3a8a classDef layer2 fill:#ffedd5,stroke:#ea580c,stroke-width:2px,color:#7c2d12 classDef layer3 fill:#fee2e2,stroke:#dc2626,stroke-width:2px,color:#7f1d1d classDef legal fill:#fef3c7,stroke:#d97706,stroke-width:3px,color:#78350f classDef support fill:#f5f3ff,stroke:#7c3aed,stroke-width:2px,color:#4c1d95,stroke-dasharray: 5 5 class T0 tech class T1 layer1 class T2 layer2 class T3 layer3 class T4 legal class S support

3.3 去中心化身份(DID)与分布式身份管理

  • DID(Decentralized Identifier):由用户自主控制的身份标识,不依赖单一中央注册机构
  • 关联概念:可验证凭证(Verifiable Credential, VC)、零知识证明(ZKP)
  • 机构场景作用:
    • 将链上身份与合规审查(KYC/KYB)结合
    • 实现"最小化披露"——仅披露合规所需信息
    • 可跨链/跨平台复用身份凭证
  • 仍需面对的问题:DID 的法律效力、撤销机制、跨辖区互认
  • 教学要点:技术身份体系必须与法律身份体系对接,不能仅靠代码自治
flowchart TB Title["DID + VC 分布式身份管理架构"] subgraph Triangle["Issuer - Holder - Verifier 三角模型"] direction TB I["Issuer
凭证签发方
KYC/KYB 机构
政府登记机关
金融机构 / 托管机构"] H["Holder
凭证持有人
用户 / 企业 / DAO 代表人
自主控制 DID 与私钥
选择性披露身份信息"] V["Verifier
凭证验证方
交易平台
金融机构
链上协议 / 合约系统"] end I -- "签发 VC
Verifiable Credential" --> H H -- "出示证明
VC / ZKP / 最小化披露" --> V V -- "验证签名、状态与规则
不必直接访问全部原始数据" --> I DID["DID
Decentralized Identifier
用户自主控制的身份标识
不依赖单一中央注册机构"] ZKP["ZKP
零知识证明
证明满足条件
不暴露完整身份信息"] LEGAL["法律身份体系
自然人 / 法人 / 信托
合同关系与责任结构
跨辖区承认"] ISSUES["仍需面对的问题
DID 的法律效力
撤销机制
跨辖区互认"] DID --> H ZKP --> H ZKP --> V LEGAL -. "对接主体身份" .-> I LEGAL -. "约束权利义务" .-> H LEGAL -. "支撑合规验证" .-> V ISSUES -.-> DID ISSUES -.-> LEGAL classDef title fill:#f8fafc,stroke:#334155,stroke-width:2px,color:#0f172a classDef issuer fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#1e3a8a classDef holder fill:#ecfdf5,stroke:#059669,stroke-width:2px,color:#064e3b classDef verifier fill:#fff7ed,stroke:#ea580c,stroke-width:2px,color:#7c2d12 classDef tech fill:#eef2ff,stroke:#4f46e5,stroke-width:2px,color:#312e81 classDef legal fill:#fef3c7,stroke:#d97706,stroke-width:2px,color:#78350f classDef risk fill:#fee2e2,stroke:#dc2626,stroke-width:2px,color:#7f1d1d class Title title class I issuer class H holder class V verifier class DID,ZKP tech class LEGAL legal class ISSUES risk style Triangle fill:#ffffff,stroke:#cbd5e1,stroke-width:1px,stroke-dasharray: 6 4

4.1 票据业务的多方协作痛点

  • 票据业务包含:开立、背书、贴现、转贴现、到期兑付等多方协作环节
  • 参与方:出票人、承兑人、持票人、贴现银行、再贴现银行、监管机构
  • 传统票据流转依赖纸质或半电子化流程,信息分散在各自系统中
  • 主要痛点:
    • 信息不一致导致确权困难
    • 手工操作多,易产生操作风险
    • 票据真实性与权利链条的连续性难以实时验证
    • 贴现与转贴现的对账复杂,结算延迟

4.2 链上票据流程的重构设计

  • 链上统一记录:从开立到兑付的全部操作记录在共享账本上
  • 智能合约管理的票据生命周期:
    • 开立:出票人创建链上票据,指定金额、到期日、承兑人
    • 背书/流转:每笔背书转让在链上记录,自动更新权利持有人
    • 贴现:持票人发起贴现申请,银行在线确认并放款
    • 兑付:到期时智能合约自动触发付款/清算指令
  • 流程协同价值:状态同步、操作留痕、审计可追踪
  • 关键要求:票据权利链条的连续性与可验证性
flowchart LR START["链上统一记录
共享账本记录从开立到兑付的全部操作"] A["开立
出票人创建链上票据
指定金额、到期日、承兑人"] B["背书 / 流转
每笔背书转让在链上记录
自动更新权利持有人"] C["贴现
持票人发起贴现申请
银行在线确认并放款"] D["兑付
到期时智能合约自动触发
付款 / 清算指令"] END["票据权利链条
连续性与可验证性"] START --> A --> B --> C --> D --> END SC["智能合约
管理票据生命周期
状态同步 · 自动执行 · 规则校验"] AUDIT["审计与监管视图
操作留痕
可追踪、可核验、可复盘"] SC -. "生命周期管理" .-> A SC -. "权利持有人更新" .-> B SC -. "贴现规则校验" .-> C SC -. "到期自动触发" .-> D A -. "操作记录" .-> AUDIT B -. "操作记录" .-> AUDIT C -. "操作记录" .-> AUDIT D -. "操作记录" .-> AUDIT classDef ledger fill:#eef2ff,stroke:#4f46e5,stroke-width:2px,color:#312e81 classDef step fill:#ecfdf5,stroke:#059669,stroke-width:2px,color:#064e3b classDef contract fill:#fef3c7,stroke:#d97706,stroke-width:2px,color:#78350f classDef audit fill:#f8fafc,stroke:#64748b,stroke-width:2px,color:#334155 classDef final fill:#fee2e2,stroke:#dc2626,stroke-width:2px,color:#7f1d1d class START ledger class A,B,C,D step class SC contract class AUDIT audit class END final

4.3 DCEP 与数字票据的结合探索

  • 数字人民币(DCEP)的"支付即结算"特性与票据场景天然契合
  • 以 DCEP 作为结算工具,可进一步缩短资金清算环节
  • 链上票据流转 + DCEP 资金结算:实现"券款对付"(DvP)
  • 2018-2020 年深圳、雄安等地开展数字票据试点——验证了技术可行性
  • 当前挑战:DCEP 对智能合约的支持程度、票据法与电子票据法规的进一步修订
  • 要点:支付工具与资产登记体系的同步升级才能实现 DvP 闭环
flowchart LR subgraph ASSET["资产登记轨:链上票据流转"] direction LR A1["持票人 A
持有数字票据"] A2["链上票据登记系统
记录票据权利状态"] A3["受让人 / 银行 B
取得票据权利"] A1 -- "背书转让 / 贴现申请" --> A2 A2 -- "更新权利持有人" --> A3 end subgraph PAY["资金结算轨:DCEP 支付即结算"] direction LR P3["受让人 / 银行 B
DCEP 钱包"] P2["DCEP 结算系统
支付即结算"] P1["持票人 A
DCEP 钱包"] P3 -- "支付对价" --> P2 P2 -- "实时到账" --> P1 end SC["DvP 协调机制
智能合约 / 规则引擎
票据权利转移与 DCEP 支付同步完成"] A2 <--> SC P2 <--> SC CLOSE["DvP 闭环
券款对付
票据交割与资金结算同步完成"] SC --> CLOSE PILOT["试点基础
2018-2020 年
深圳、雄安等地数字票据试点
验证技术可行性"] CHALLENGE["当前挑战
DCEP 对智能合约的支持程度
票据法与电子票据法规进一步修订"] PILOT -.-> ASSET PILOT -.-> PAY CHALLENGE -.-> SC CHALLENGE -.-> CLOSE classDef asset fill:#ecfdf5,stroke:#059669,stroke-width:2px,color:#064e3b classDef pay fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#1e3a8a classDef coord fill:#fef3c7,stroke:#d97706,stroke-width:2px,color:#78350f classDef final fill:#fee2e2,stroke:#dc2626,stroke-width:2px,color:#7f1d1d classDef note fill:#f8fafc,stroke:#64748b,stroke-width:2px,color:#334155 class A1,A2,A3 asset class P1,P2,P3 pay class SC coord class CLOSE final class PILOT,CHALLENGE note style ASSET fill:#f0fdf4,stroke:#bbf7d0,stroke-width:1px style PAY fill:#eff6ff,stroke:#bfdbfe,stroke-width:1px

DvP 的关键不是单独实现“票据上链”或“DCEP 支付”,而是让资产登记体系与支付结算体系同步升级,在同一规则框架下完成权利转移与资金结算。

5.1 应收账款上链场景分析

  • 应收账款依赖确权与流转,是 RWA 的高频场景之一
  • 核心业务流程:
    • 核心企业确认应付账款后,上游供应商获得应收账款权益
    • 供应商可将应收款转让给金融机构进行融资
    • 多级供应商之间的应收款亦可逐级拆分转让
  • 上链价值:
    • 增强流转透明度:每级转让可追溯
    • 降低信息不对称:金融机构可直接验证底层贸易数据
    • 支持多级融资:非一级供应商也能获得融资机会
  • 前提条件:真实贸易背景 + 底层合同关系 + 可执行的法律安排
flowchart LR TITLE["5.1 应收账款上链场景分析
确权、流转与多级融资"] subgraph BUSINESS["真实贸易与合同基础"] direction TB CONTRACT["底层合同关系
采购合同 / 订单 / 发票 / 物流单据"] TRADE["真实贸易背景
货物或服务已交付"] LEGAL["可执行的法律安排
债权转让通知
权利确认
违约追索路径"] end CORE["核心企业
确认应付账款"] SUP1["一级供应商
获得应收账款权益"] SUP2["二级 / N 级供应商
接收拆分转让的应收款权益"] PLATFORM["区块链平台
应收账款上链
确权记录
流转记录
拆分记录"] FI["金融机构
验证底层贸易数据
受让应收款
提供融资"] CUSTODY["托管与审计
资料存证
资金监管
审计核验"] VALUE["上链价值
增强流转透明度:每级转让可追溯
降低信息不对称:金融机构可直接验证底层贸易数据
支持多级融资:非一级供应商也能获得融资机会"] TITLE --> BUSINESS CONTRACT --> CORE TRADE --> CORE LEGAL --> PLATFORM CORE -- "确认应付账款" --> SUP1 SUP1 -- "应收账款权益上链" --> PLATFORM PLATFORM -- "确权后的数字凭证" --> SUP1 SUP1 -- "拆分 / 转让" --> SUP2 SUP2 -- "逐级流转记录" --> PLATFORM SUP1 -- "转让应收款融资" --> FI SUP2 -- "非一级供应商融资" --> FI FI -- "直接验证底层贸易数据" --> PLATFORM PLATFORM -- "可追溯流转记录" --> FI CUSTODY -- "审计与托管支持" --> PLATFORM CUSTODY -- "资金与资料核验" --> FI PLATFORM --> VALUE FI --> VALUE classDef title fill:#f8fafc,stroke:#334155,stroke-width:2px,color:#0f172a classDef basis fill:#ecfdf5,stroke:#059669,stroke-width:2px,color:#064e3b classDef core fill:#fee2e2,stroke:#dc2626,stroke-width:2px,color:#7f1d1d classDef supplier fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#1e3a8a classDef platform fill:#fef3c7,stroke:#d97706,stroke-width:2px,color:#78350f classDef fi fill:#f5f3ff,stroke:#7c3aed,stroke-width:2px,color:#4c1d95 classDef custody fill:#fff7ed,stroke:#ea580c,stroke-width:2px,color:#7c2d12 classDef value fill:#e0f2fe,stroke:#0284c7,stroke-width:2px,color:#0c4a6e class TITLE title class CONTRACT,TRADE,LEGAL basis class CORE core class SUP1,SUP2 supplier class PLATFORM platform class FI fi class CUSTODY custody class VALUE value style BUSINESS fill:#f0fdf4,stroke:#bbf7d0,stroke-width:1px,stroke-dasharray: 6 4

应收账款上链的核心不是简单记录一笔债权,而是把真实贸易背景、合同关系、确权记录、流转路径和融资安排连接起来,使金融机构能够基于可验证的链上数据向多级供应商提供融资。

5.2 多级流转与穿透式融资机制

  • 传统供应链金融往往只覆盖一级供应商(直接与核心企业交易方)
  • 区块链可实现穿透式确权:将应付账款逐级标记传递至 N 级供应商
  • 多级流转的核心设计:
    • 凭据拆分:核心企业签发的数字债权凭证可按金额拆分转让
    • 权利连续:每级转让后,权利链条仍可回溯至核心企业
    • 融资分层:不同等级供应商可依据自身情况选择持有或融资
  • 典型案例:中企云链(云信)、浙商银行应收款链平台
flowchart LR TITLE["5.2 多级流转与穿透式融资机制
核心企业信用沿供应链逐级传递"] CORE["核心企业
签发数字债权凭证
应付账款确权"] L1["一级供应商
直接交易方
接收凭证"] L2["二级供应商
接收拆分 / 转让凭证"] L3["三级供应商
继续接收凭证"] LN["N 级供应商
末端供应商
仍可追溯至核心企业"] F1["融资选择
持有到期 / 向银行融资"] F2["融资选择
按需拆分 / 转让 / 融资"] F3["融资选择
小额融资 / 继续支付上游"] FN["融资选择
基于核心企业信用获得融资"] BANK["金融机构 / 银行
依据链上权利链条授信
识别真实贸易背景"] TRACE["穿透式确权
每级转让记录上链
权利链条可回溯至核心企业"] CASES["典型案例
中企云链(云信)
浙商银行应收款链平台"] TITLE --> CORE CORE -- "签发应付账款数字债权凭证" --> L1 L1 -- "凭据拆分 / 转让" --> L2 L2 -- "继续拆分 / 转让" --> L3 L3 -- "逐级传递" --> LN L1 --> F1 L2 --> F2 L3 --> F3 LN --> FN F1 --> BANK F2 --> BANK F3 --> BANK FN --> BANK CORE -. "信用源头" .-> TRACE L1 -. "转让记录" .-> TRACE L2 -. "转让记录" .-> TRACE L3 -. "转让记录" .-> TRACE LN -. "转让记录" .-> TRACE TRACE --> BANK BANK --> CASES classDef title fill:#f8fafc,stroke:#334155,stroke-width:2px,color:#0f172a classDef core fill:#fee2e2,stroke:#dc2626,stroke-width:2px,color:#7f1d1d classDef supplier fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#1e3a8a classDef finance fill:#ecfdf5,stroke:#059669,stroke-width:2px,color:#064e3b classDef bank fill:#fef3c7,stroke:#d97706,stroke-width:2px,color:#78350f classDef trace fill:#f5f3ff,stroke:#7c3aed,stroke-width:2px,color:#4c1d95 class TITLE title class CORE core class L1,L2,L3,LN supplier class F1,F2,F3,FN finance class BANK bank class TRACE,CASES trace

多级流转的关键,是把核心企业的应付账款确权转化为可拆分、可转让、可追溯的数字债权凭证,使核心企业信用能够穿透至 N 级供应商。

5.3 风险关注与核心教学要点

  • 风险关注:
    • 虚假贸易:底层贸易背景不真实,应收账款不存在
    • 重复融资:同一笔应收款在多个平台进行融资
    • 权利瑕疵:底层合同有争议,影响权利链条的完整性
    • 追索链条断裂:核心企业违约或破产时追索路径不清晰
  • 教学要点:技术上"可记录"不等于金融上"可融资"
  • 核心结论:应收账款的金融价值不取决于链上记录,而取决于底层法律关系与信用
  • 最佳实践:法律确权 + 贸易数据核验 + 现金流闭环管理三者缺一不可

6.1 机构场景对区块链平台的要求

  • 机构业务(银行/券商/托管/资管)对其基础设施提出独特要求:
    • 准入控制:只有经过许可的参与方才能加入与读写
    • 隐私保护:交易细节对无关方不可见,仅授权节点可查阅
    • 审计与合规:支持监管机构的实时审查与事后回溯
    • 责任与追责边界:出现错误或争议时能定位责任主体
  • 许可链/联盟链通常更适配这些要求:身份内置、权限分层、数据隔离
  • 技术实现方向:Corda(R3)、Hyperledger Fabric、FISCO BCOS、Quorum

6.2 开放公链 vs 许可链/联盟链的深度对比

  • 关键原则:不是"去中心化越高越好",而是"与场景匹配"
  • 设计权衡:身份、权限、数据可见性、监管接口如何嵌入
维度 开放公链 许可链/联盟链
准入与身份 弱/外置(地址匿名) 强/内置(KYC/KYB 已知)
隐私与数据治理 难(默认全公开) 相对可控(通道/私有数据)
审计与责任界定 复杂(匿名节点追责难) 清晰(已知运营方负责)
智能合约升级 治理投票 / 硬分叉 联盟治理 / 链上投票
对外可组合性 高(DeFi 乐高) 有限(需跨链桥)
合规嵌入能力 挑战大 原生支持

6.3 混合架构与未来的多层次网络

  • 现实趋势:机构正在探索混合架构——许可链执行核心业务,公链用于资产公共注册
  • 核心业务(交易匹配、清算、结算)在许可链中运行
  • 资产锚定证明可发布到公链实现透明性与可验证性
  • 跨链互操作协议(如 Canton Network)连接许可链与公链生态
  • 教学要点:技术选择是"工具盒"思维,不是"非此即彼"的路线之争
flowchart TB subgraph PERMISSIONED["许可链层:核心业务执行"] direction LR MATCH["交易匹配
订单撮合
报价与成交确认"] CLEAR["清算
头寸计算
风险检查
净额 / 全额处理"] SETTLE["结算
资产交割
资金交收
最终性确认"] MATCH --> CLEAR --> SETTLE end subgraph PUBLIC["公链层:公共注册与可验证性"] direction LR ANCHOR["资产锚定证明
Proof of Reserve / Proof of Asset
资产状态摘要"] REG["公共注册
资产标识
发行记录
状态哈希"] VERIFY["外部可验证性
透明披露
第三方审计
市场信任"] ANCHOR --> REG --> VERIFY end subgraph INTEROP["跨链互操作层"] direction TB CANTON["跨链互操作协议
如 Canton Network"] MSG["消息传递
状态同步
权限验证
合规检查"] BRIDGE["连接许可链与公链生态
但不必暴露全部业务数据"] CANTON --> MSG --> BRIDGE end PERMISSIONED -- "核心业务数据
在受控环境中运行" --> INTEROP INTEROP -- "发布摘要 / 哈希 / 证明" --> PUBLIC PUBLIC -- "提供透明性与可验证性" --> INTEROP INTEROP -- "必要状态回传" --> PERMISSIONED classDef title fill:#f8fafc,stroke:#334155,stroke-width:2px,color:#0f172a classDef permissioned fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#1e3a8a classDef public fill:#ecfdf5,stroke:#059669,stroke-width:2px,color:#064e3b classDef interop fill:#fef3c7,stroke:#d97706,stroke-width:2px,color:#78350f classDef teach fill:#f5f3ff,stroke:#7c3aed,stroke-width:2px,color:#4c1d95 class TITLE title class MATCH,CLEAR,SETTLE permissioned class ANCHOR,REG,VERIFY public class CANTON,MSG,BRIDGE interop class TOOLBOX teach style PERMISSIONED fill:#eff6ff,stroke:#bfdbfe,stroke-width:1px,stroke-dasharray: 6 4 style PUBLIC fill:#f0fdf4,stroke:#bbf7d0,stroke-width:1px,stroke-dasharray: 6 4 style INTEROP fill:#fffbeb,stroke:#fde68a,stroke-width:1px,stroke-dasharray: 6 4

混合架构的核心逻辑是:把高敏感、高合规要求的核心业务放在许可链中执行,把需要公共透明度和外部验证的资产证明发布到公链,再通过跨链互操作协议实现多层网络之间的协同。

7.1 产业区块链的概念与发展路径

  • 中国语境下,"产业区块链"强调区块链与实体经济的结合
  • 核心特征:
    • 面向 B 端(企业/政府)而非 C 端(个人/投机)
    • 突出登记、协同、风控、存证等管理功能
    • 通常"无币"或"限制代币",避免金融风险与投机行为
  • 常见落地场景:
    • 供应链金融:应收款链上流转、贸易融资
    • 政务服务:电子证照、政务数据共享
    • 版权保护:数字内容确权与交易
    • 绿色金融:碳排放权交易、ESG 数据验证
  • 核心价值:提升数据可信度与流程协同效率

7.2 中国产业区块链基础设施生态

  • BSN(区块链服务网络):跨云、跨框架的全球性开放基础设施
    • 支持多种底层框架(Fabric、FISCO BCOS、Corda)
    • 降低企业部署区块链的门槛与成本
  • 长安链(ChainMaker):自主可控联盟链基础设施
    • 高性能、高可扩展,适合大规模联盟场景
    • 广泛应用于政务、金融、贸易等领域
  • FISCO BCOS:金融级联盟链底层平台
    • 金链盟(金融区块链合作联盟)出品
    • 在供应链金融、跨境贸易、存证等场景有成熟案例

7.3 "链上无币"的路径与国际比较

  • 中国路径:技术可用于资产登记、数据共享、流程协同,但代币发行与交易受限
  • 国际对比:
    • 美国:侧重资产代币化(tokenization)与合规发行(Reg D/S),市场驱动
    • 欧盟:通过 MiCA 框架规范代币发行与交易,兼顾创新与保护
    • 新加坡:许可制度下试点代币化资产交易(Project Guardian)
  • 不同制度环境形成不同实现路径:技术中立,但政策导向塑造了应用边界
  • 教学要点:同一技术在不同制度环境下会产生截然不同的落地形态
flowchart TB TECH["底层技术能力
分布式账本 / 智能合约 / 数据共享 / 资产登记 / 流程协同"] subgraph PATHS["不同制度环境下的区块链应用路径"] direction LR CN["中国路径
链上无币
技术可用于资产登记、数据共享、流程协同
代币发行与交易受限"] US["美国路径
资产代币化 tokenization
合规发行 Reg D / Reg S
市场驱动"] EU["欧盟路径
MiCA 框架
规范代币发行与交易
兼顾创新与投资者保护"] SG["新加坡路径
许可制度下试点
Project Guardian
代币化资产交易"] end OUTCOME["核心结论
技术中立
但政策导向塑造应用边界"] TECH --> PATHS CN --> OUTCOME US --> OUTCOME EU --> OUTCOME SG --> OUTCOME classDef title fill:#f8fafc,stroke:#334155,stroke-width:2px,color:#0f172a classDef tech fill:#eef2ff,stroke:#4f46e5,stroke-width:2px,color:#312e81 classDef cn fill:#fee2e2,stroke:#dc2626,stroke-width:2px,color:#7f1d1d classDef us fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#1e3a8a classDef eu fill:#ecfdf5,stroke:#059669,stroke-width:2px,color:#064e3b classDef sg fill:#fef3c7,stroke:#d97706,stroke-width:2px,color:#78350f classDef conclusion fill:#f5f3ff,stroke:#7c3aed,stroke-width:2px,color:#4c1d95 class TITLE title class TECH tech class CN cn class US us class EU eu class SG sg class OUTCOME,TEACH conclusion style PATHS fill:#ffffff,stroke:#cbd5e1,stroke-width:1px,stroke-dasharray: 6 4

“链上无币”不是技术能力不足,而是制度选择的结果;同样的区块链技术,在中国更多表现为登记、协同与数据共享,在欧美新等市场则更多表现为代币化资产发行与交易。

8.1 RWA 的法律基石:SPV、托管与受益权

  • RWA 成立的关键:资产隔离、托管安排、受益权(beneficial interest)设计
  • 典型结构:SPV(Special Purpose Vehicle)/ 受托载体持有底层资产
    • 底层资产(国债、贷款、房地产)由 SPV 持有
    • 链上 token 表征对 SPV 资产的"受益权"或"请求权"
    • 投资者持有 token,但不直接持有底层资产
  • 多数 token 并非法律意义上的"所有权",而是合同上的索取权或收益权
  • 法律结构决定:
    • 破产隔离是否有效(投资者 vs. SPV 债权人)
    • 优先级顺序(谁先获得偿付)
    • 追索路径(违约时向谁主张权利)
    • 执行可行性(法律承认 token 持有人的权利)

8.2 资产隔离与破产隔离机制

  • 资产隔离是 RWA 是否"真实"的核心判定标准
  • 若 SPV / 受托结构无效,token 持有人与 SPV 其他债权人混同——token 价值归零
  • 破产隔离的关键环节:
    1. 真实出售(true sale):底层资产从发起人转让至 SPV,不再属于发起人破产财产
    2. SPV 独立性:SPV 自身不从事其他业务,不产生其他负债
    3. 托管安排:独立托管人保管底层资产的法律文件与权利凭证
    4. 法律意见:律师就破产隔离出具专业法律意见
  • 若上述环节缺失或无效,RWA 在法律上可能被认为是"无担保债权"而非"真实资产"

8.3 主要法域的 RWA 法律框架比较

  • 美国
    • 代币可能被认定为证券(Howey 测试),需在 SEC 注册或豁免(Reg D/S/CF)
    • 资产支持证券(ABS)框架适用于某些 RWA 结构
    • 州级信托法与 UCC(统一商法典)影响资产担保权益的设立与登记
  • 欧盟
    • MiCA 为加密资产提供发行与交易统一框架
    • DLT 试点制度(DLT Pilot Regime)支持 DLT 市场基础设施
    • 各国对代币化资产的民法处理有差异(物权法适用性)
  • 新加坡/香港
    • 新加坡 PSA 覆盖数字支付代币与代币化资产
    • 香港明确虚拟资产服务提供商(VASP)发牌制度
    • 两地均在探索代币化存款与代币化资产的互操作

8.4 智能合约的法律效力与执行机制

  • 智能合约在 RWA 中的角色:自动执行资产状态转换、收益分配、抵押品管理
  • 法律层面的关键问题:
    • 是否构成法律合约?——取决于法律管辖区的合同法是否承认代码表达
    • 代码错误 / 漏洞的责任归属——开发者 vs. 运营者 vs. 使用者
    • 司法冻结 / 止付的可操作性——如何在不可逆链上执行法院命令
  • 当前实践:
    • 多数 RWA 结构采用"链上+链下"双轨:智能合约执行状态管理,离线法律协议界顶权利义务
    • 链上代码与链下合同之间通过"合约哈希引用"或"法律条款声明"建立连接
    • 部分法域(亚利桑那、怀俄明、瑞士楚格)出台专门法律明确智能合约法律地位

8.5 RWA 法律结构的评价框架

  • 评价一个 RWA 项目的法律完整性,可从以下维度分析:
    1. 权利边界清晰度:投资者拥有什么权利(受益权/所有权/仅合同请求权)?
    2. 破产隔离有效性:SPV 结构经得起法院审查吗?是否经过真实出售分析?
    3. 执行机制可用性:违约时投资者如何追索?需要经历什么法律程序?
    4. 合规可持续性:法规变化时,结构能否调整?是否依赖特定豁免条款?
    5. 信息披露充分性:底层资产的透明度和评级是否对投资者充分披露?
  • 值得讨论的案例:当 RWA 跨法域运作时,权利冲突应适用哪个国家的法律?

9.1 Project Guardian 概述

  • MAS(新加坡金融管理局)发起的机构 DeFi 倡议(2022 年 5 月启动)
  • 目标:探索受监管机构在公开许可的区块链上进行资产交易与流动性管理
  • 核心理念:身份(Identity)、许可(Permission)、合规(Compliance)嵌入 DeFi 协议
  • 参与方:DBS、JP Morgan、SBI Digital Asset、Standard Chartered、HSBC、Citi、Temasek 等
  • 实验范围:代币化债券、代币化存款、外汇交易、基金管理
  • 教学要点:Project Guardian 说明 DeFi 不必只面向匿名散户,可形成"机构版本"的链上市场

资料来源:MAS Project Guardian 行业报告(wk11 阅读材料)

9.2 关键实验与主要发现

  • 实验一:代币化债券与代币化存款的 DvP 结算

    • DBS 与 JP Morgan 合作,在许可链上完成债券发行与结算
    • 代币化债券通过智能合约发行,代币化存款用于资金结算
    • 实现原子化 DvP:券和款同步交割,结算风险为零
  • 实验二:外汇交易的 PvP 结算

    • 多币种(SGD、JPY、USD)的支付对支付(PvP)结算
    • 消除跨境外汇交易中的 Herstatt 风险(时区不同步的风险)
  • 实验三:代币化基金管理

    • 自动化基金份额注册、转让、分红
    • 降低基金管理后台的人工对账成本
  • 主要发现

    • 合规嵌入(身份+许可+AML 检查)是可行的
    • 原子结算大幅降低对手方风险
    • 流动性汇聚面临跨链、跨平台协调挑战

9.3 机构 DeFi 的未来方向

  • Project Guardian 证明:合规 + 效率并不矛盾,但需要重新设计 DeFi 协议
  • 核心设计要素:
    • 身份层:可验证凭证(VC)替代匿名地址
    • 许可层:智能合约级别控制谁可以交互、交易什么资产、交易量上限
    • 合规层:实时 AML/CTF 筛查、制裁名单比对、交易限额检查
  • 开放性问题:
    • 合规约束在多大程度上削弱了 DeFi 的"可组合性"?
    • 机构 DeFi 的流动性从何而来 —— 是否依靠传统做市商?
    • 许可层的智能合约是否可以做到"足够开放"以保持创新活力?
  • 讨论问题:合规约束下的效率收益来自哪里?成本是什么?

10.1 Unified Ledger(统一账本)概念

  • BIS(国际清算银行)提出的"下一代金融市场基础设施"愿景
  • 核心思想:不同的货币、不同的资产、不同的机构在同一账本上完成发行—交易—清算—结算
  • 解决的核心问题:
    • 传统金融体系:支付系统、证券结算系统、外汇结算系统各自独立运行
    • 独立系统之间的协调成本高、结算周期长、风险暴露窗口大
  • 统一账本的承诺:一套账本同时管理多种资产与货币,实现原子 DvP/PvP
  • Project Agora 是 BIS 主导下测试 Unified Ledger 概念的具体实践
flowchart TB TITLE["Unified Ledger(统一账本)概念
BIS 提出的下一代金融市场基础设施愿景"] subgraph OLD["传统金融体系:多个系统各自独立运行"] direction LR PS["支付系统
货币转移"] SS["证券结算系统
证券登记与交割"] FX["外汇结算系统
不同货币兑换"] OLD_RISK["问题
协调成本高
结算周期长
风险暴露窗口大"] PS -. "系统间协调" .- SS SS -. "系统间协调" .- FX FX -. "系统间协调" .- PS PS --> OLD_RISK SS --> OLD_RISK FX --> OLD_RISK end subgraph NEW["统一账本:多资产 / 多货币 / 多机构在同一账本上清结算"] direction TB LEDGER["统一账本 Unified Ledger
同一账本上完成发行 — 交易 — 清算 — 结算"] subgraph ASSETS["账本内对象"] direction LR M1["货币 A
商业银行存款 / CBDC"] M2["货币 B
外币 / 批发型 CBDC"] A1["资产 A
证券 / 债券 / RWA"] A2["资产 B
票据 / 基金份额 / 抵押品"] I1["机构 A
银行 / 证券机构"] I2["机构 B
央行 / 清算机构"] end DVP["原子 DvP
券款对付
资产交割与资金结算同步完成"] PVP["原子 PvP
款款对付
两种货币同步交割"] M1 --> LEDGER M2 --> LEDGER A1 --> LEDGER A2 --> LEDGER I1 --> LEDGER I2 --> LEDGER LEDGER --> DVP LEDGER --> PVP end AGORA["Project Agora
BIS 主导下测试 Unified Ledger 概念的具体实践"] TITLE --> OLD TITLE --> NEW NEW --> AGORA classDef title fill:#f8fafc,stroke:#334155,stroke-width:2px,color:#0f172a classDef old fill:#fee2e2,stroke:#dc2626,stroke-width:2px,color:#7f1d1d classDef ledger fill:#fef3c7,stroke:#d97706,stroke-width:3px,color:#78350f classDef asset fill:#ecfdf5,stroke:#059669,stroke-width:2px,color:#064e3b classDef result fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#1e3a8a classDef project fill:#f5f3ff,stroke:#7c3aed,stroke-width:2px,color:#4c1d95 class TITLE title class PS,SS,FX,OLD_RISK old class LEDGER ledger class M1,M2,A1,A2,I1,I2 asset class DVP,PVP result class AGORA project style OLD fill:#fff1f2,stroke:#fecdd3,stroke-width:1px,stroke-dasharray: 6 4 style NEW fill:#f8fafc,stroke:#cbd5e1,stroke-width:1px,stroke-dasharray: 6 4 style ASSETS fill:#f0fdf4,stroke:#bbf7d0,stroke-width:1px

Unified Ledger 的核心,是把原本分散在支付、证券、外汇等系统中的资产与货币状态,整合到同一账本中,从而实现更短链条、更低协调成本和更小结算风险。

10.2 Project Agora 的架构设计

  • Project Agora(2024 年 4 月由 BIS 与七家央行联合启动)
  • 参与央行:BIS 创新中心、法国央行、日本央行、韩国央行、墨西哥央行、瑞士央行、英格兰央行、美联储纽约联储
  • 私人部门参与:由超过 40 家金融机构组成的咨询组
  • 核心设计特征:
    • 代币化存款(tokenized deposits):商业银行存款以代币形式存在于统一账本
    • 批发型 CBDC:央行货币也以代币形式存在于同一账本
    • 智能合约调度:自动完成支付、交换、抵押品管理的逻辑编排
  • 目标:验证统一账本能否同时承载代币化存款与央行货币的跨机构清结算

10.3 统一账本的挑战与教学要点

  • 关键挑战:
    1. 标准:不同资产、货币、机构的编码与协议标准如何统一
    2. 治理:谁管理账本?规则变更如何决策?纠纷如何裁决?
    3. 权限与隐私:不同参与方所见的数据范围不同,如何实现隐私保护下的共享?
    4. 法律辖区与责任分配:跨国清算涉及多国法律,发生错误时责任如何划分?
    5. 与现有基础设施的共存 & 过渡:统一账本不意味着立即替换所有现有系统
  • 教学要点:
    • RWA 不是单点产品,而是基础设施协同工程
    • 统一账本的实现进度取决于:标准制定 > 法律框架 > 技术开发
    • 最重要的不是"能不能做",而是"谁在什么时候愿意用什么方式实施"

11.1 不同资产的代币化特征比较

  • 国债:标准化程度高、信用强、流动性好,适合做机构级代币化与抵押品
  • 基金:份额化相对容易,但销售适当性、托管与信息披露要求高
  • 票据/应收:场景丰富、潜在收益高,但尽调与确权难、合规更复杂
  • 房地产:单笔金额大、流动性低、法律转让程序复杂
  • 碳信用:需要第三方核证、标准化程度低、不同标准互认困难
  • 核心对比维度:

    资产类型 标准化/流动性 确权/尽调难度 合规复杂度 优先代币化程度
    国债
    基金 中-高 中-高
    票据/应收 中-低
    房地产 低-中
    碳信用 低-中
  • 结论:越接近"标准化金融资产",越容易先行落地

11.2 代币化国债市场现状

  • 截至 2025 年初,代币化美国国债与货币基金市场规模约 40-50 亿美元(数据来源:rwa.xyz,2025 Q1;含 BUIDL、FOBXX、OUSG 等主要产品)

  • 主要产品:

    • BlackRock BUIDL(Build USD Institutional Digital Liquidity Fund):
      • 基于以太坊的代币化货币基金,2024 年 3 月推出
      • 规模迅速增长至 5 亿+美元
      • 采用 Securitize 作为代币化平台与转让代理
    • Franklin Templeton FOBXX(Franklin OnChain U.S. Government Money Fund):
      • 最早(2021 年)推出的代币化货币基金
      • 在 Stellar 和 Polygon 上发行
      • 规模约 4 亿美元
    • Ondo Finance OUSG / USDY:
      • 面向 DeFi 与机构投资者的代币化国债产品
      • 以贝莱德 ETF(SHV)为底仓,实现每日流动性
  • 增长驱动:高利率环境下,国债收益超越稳定币存款

11.3 代币化国债的技术与法律结构

  • 典型结构(以 BUIDL 为例):
    • 底层资产:短期美国国债 / 政府货币市场基金(由 BlackRock 管理)
    • SPV / 基金结构:投资者购买基金份额,链上 token 代表基金份额权益
    • 转让代理(Transfer Agent):Securitize 负责链上份额登记与转让
    • 每日 NAV 更新:资金管理人提供每日净值,价格 feed 写入或引用到链上
  • 关键特点:
    • token 持有者的权利是"对基金份额的受益权",而非直接持有国债
    • 转让在链上完成,但基金的最终持有人登记仍在传统 TA 系统维护
    • 每天可申购/赎回,赎回通过传统银行渠道完成
flowchart LR subgraph LEGAL["法律与资产层"] direction LR UST["底层资产
短期美国国债 / 政府货币市场基金
由 BlackRock 管理"] FUND["SPV / 基金结构
投资者购买基金份额
基金持有底层资产"] NAV["每日 NAV 更新
资金管理人提供每日净值
价格 feed 写入或引用到链上"] UST --> FUND NAV --> FUND end subgraph ONCHAIN["链上登记与流转层"] direction LR TA["转让代理 Transfer Agent
Securitize
负责链上份额登记与转让"] TOKEN["链上 token
代表基金份额权益
不是直接持有国债"] HOLDER["token 持有人
享有对基金份额的受益权"] TA --> TOKEN --> HOLDER end FUND -- "发行 / 确认基金份额" --> TA TA -- "链上转让记录" --> TOKEN HOLDER -- "每日可申购 / 赎回" --> FUND BANK["传统银行渠道
法币资金收付
赎回清算"] HOLDER -- "赎回申请" --> BANK BANK -- "资金划付" --> HOLDER BANK -. "结算结果回传" .-> FUND REG["最终持有人登记
传统 TA 系统维护
链上记录与法律登记需保持一致"] TA <--> REG NOTE["核心法律关系
token 持有者权利 = 对基金份额的受益权
≠ 直接持有短期美国国债"] NOTE -.-> TOKEN NOTE -.-> FUND classDef asset fill:#ecfdf5,stroke:#059669,stroke-width:2px,color:#064e3b classDef fund fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#1e3a8a classDef nav fill:#eef2ff,stroke:#4f46e5,stroke-width:2px,color:#312e81 classDef ta fill:#fef3c7,stroke:#d97706,stroke-width:2px,color:#78350f classDef token fill:#fff7ed,stroke:#ea580c,stroke-width:2px,color:#7c2d12 classDef holder fill:#fee2e2,stroke:#dc2626,stroke-width:2px,color:#7f1d1d classDef bank fill:#f8fafc,stroke:#64748b,stroke-width:2px,color:#334155 classDef note fill:#f5f3ff,stroke:#7c3aed,stroke-width:2px,color:#4c1d95 class UST asset class FUND fund class NAV nav class TA ta class TOKEN token class HOLDER holder class BANK,REG bank class NOTE note style LEGAL fill:#f8fafc,stroke:#cbd5e1,stroke-width:1px,stroke-dasharray: 6 4 style ONCHAIN fill:#fff7ed,stroke:#fed7aa,stroke-width:1px,stroke-dasharray: 6 4

代币化国债的核心不是“把国债直接放到链上”,而是通过基金 / SPV、转让代理和链上 token,将传统证券权益映射为可链上流转的基金份额权益。

11.4 代币化资产的趋势与展望

  • 中期趋势(2025-2027):
    • 代币化国债/基金继续增长,成为 DeFi 中主要的"无风险"底仓资产
    • 代币化私募信贷与房地产开始吸引机构投资者
    • 更多传统资管公司推出代币化基金产品
  • 长期方向:
    • 从"单一代币化产品"走向"全品类链上清结算基础设施"
    • 代币化存款 + 代币化资产的组合实现完全的链上 DvP
    • 跨境代币化资产交易的互操作标准逐步成型
  • 教学要点:
    • 代币化不仅是"技术升级",更是"制度创新"——法律框架与市场标准需同步演进
    • 传统的 ETF/共同基金结构仍然是合规基础,代币化只是"登记与转让层"的升级

12.1 本讲核心要点回顾

  • RWA 的难点首先是法律与制度协调,而非代码实现
    • 技术可行性只是第一步:权利结构、执行机制、合规框架必须对接
  • 真正价值来自:
    • 流程重构:共享账本取代逐层对账
    • 清结算协同:原子 DvP/PvP 降低对手方风险
    • 审计与风控能力提升:实时、可追溯、可验证
  • 机构路径通常依赖:
    • 许可网络/联盟链实现准入控制与隐私保护
    • 托管/SPV 隔离结构实现资产隔离
    • 合规嵌入式设计实现监管可控
  • 国际前沿:
    • Project Guardian 证明"合规 DeFi"的可行性
    • Project Agora 探索统一账本的未来基础设施模式
    • 代币化国债市场从实验期进入成长期

12.2 延伸思考与讨论问题

  1. 最优先代币化的资产:结合本讲学到的分析框架,哪些资产最适合优先代币化?为什么?
  2. DeFi 与 TradFi 的关系:RWA 是在改造传统金融,还是传统金融在吸收区块链技术?
  3. 技术 vs 制度的瓶颈:当前阶段,RWA 落地的最大障碍是技术(扩容、互操作性、隐私)还是制度(法律确权、监管不确定性、市场标准)?
  4. 合规成本:合规嵌入是否会抵消链上运营的效率收益?如何量化"合规效率比"?
  5. 代币化是否改变资产本质:将国债代币化之后,它在法律性质、风险管理、监管分类上是否发生变化?

12.3 推荐参考资料

学术研究参考

  • Chiu & Koeppl (2019, RFS):"Blockchain-Based Settlement for Asset Trading"——区块链结算对资产交易效率的理论分析
  • Cong, Li & Wang (2021):"Tokenomics: Dynamic Adoption and Valuation"——代币化资产的价值动态与采用模型
  • Zetzsche, Buckley & Arner (2023):代币化证券的法律框架与跨法域协调研究
  • BIS (2024):"Project Agora: Enabling the Future of Money and Finance"——统一账本概念与多资产清结算实验

<style> .mermaid { max-width: 100%; text-align: center; } </style> <script src="https://cdn.jsdelivr.net/npm/mermaid@10.2.3/dist/mermaid.min.js"></script> <script> mermaid.initialize({ startOnLoad: true, theme: 'default' }); </script>

图示占位符:RWA 市场增长曲线与资产类别分布饼图

图示占位符:传统流程痛点图(多系统、多对账、多中介、周期长)

图示占位符:机构采用区块链的驱动力雷达图

图示占位符:地址—权限—操作—审计 层级架构图

图示占位符:法律确权三层金字塔图(主体识别→授权链条→证据与争议解决)

图示占位符:链上票据流程箭头图(开立→背书/流转→贴现→兑付)

图示占位符:DCEP + 数字票据 DvP 流程示意图

资料来源:旧版 p.310(基于区块链和数字货币的数字票据交易)

图示占位符:供应链金融参与方示意图(核心企业/供应商/金融机构/平台/托管与审计)

图示占位符:多级流转示意图(核心企业→一级→二级→...N级供应商,每级可融资)

图示占位符:供应链金融风险矩阵图

图示占位符:混合架构示意图(许可链核心 + 公链锚定 + 跨链连接)

图示占位符:中美欧产业区块链路径对比图

图示占位符:SPV—托管—投资者/持有人—链上 token 的权利映射结构图

图示占位符:链上代码 + 链下法律协议的双轨结构示意图

图示占位符:法律结构评价五维度雷达图

图示占位符:Project Guardian 参与方与资产类型总览图

图示占位符:实验一 DvP 流程的具体示意

图示占位符:机构 DeFi 三层架构图(身份→许可→合规)

图示占位符:统一账本概念图(多资产/多货币/多机构在同一账本上清结算)

图示占位符:Project Agora 架构图(央行+商业银行+统一账本的技术与制度映射)

图示占位符:统一账本的挑战与应对矩阵图

图示占位符:代币化国债结构图(BUIDL 为例:底层资产→基金→TA→链上 token→持有人)

图示占位符:代币化资产规模趋势图(2021-2027E)

图示占位符:本讲课程内容全景图(法律/技术/市场/监管四条线交汇)

- 课程参考:旧版 p.302-310(DCEP+数字票据)、p.322-328(产业区块链与监管框架)