CeDeFi 理财产品设计方案 —— 链上资金、链下量化的信任架构与效率设计

maodaishan 发布于 2026-06-25 阅读 37

# 一、问题的出发点:到底在解决什么问题
## 1.1 此处的 CeDeFi 是什么
本方案讨论的 CeDeFi,是一类特定的金融产品形态:
1.	在链上向用户收集资金(USDC、BTC、ETH 等);
2.	将这些资金通过受监管的托管机构(Custody)持有;
3.	通过 Mirror(镜像)机制,把托管账户的资产作为额度,映射到中心化交易所(CEX);
4.	由量化团队在 CEX 上执行 Delta 中性等策略,获取收益;
5.	收益最终回流到链上,分配给持有产品凭证(LP Token)的用户。
简而言之:链上募集负债,链下经营资产。
## 1.2 为什么要这样做
一个自然的反问是:既然资金来自链上,为什么不直接在链上(DeFi)跑策略?答案集中在三点:
- 链上深度不足。 主流 DeFi 永续合约和期权市场的流动性、滑点、可承载规模,距离币安、Bybit、OKX 这种顶级 CEX 还差 1–2 个数量级。规模一旦上来,链上根本撑不住。
- 策略丰富度不足。 跨所套利、基差套利、资金费率套利、做市等成熟的中性策略,绝大部分有效执行场所仍然在 CEX。链上能跑的策略集合是 CEX 的子集。
- 执行成本与速度。 Gas 费、出块时间、MEV 等因素让高频量化在链上几乎不可行。
所以,CeDeFi 的本质是一个权衡:放弃链上的纯粹性,去换取链下的深度、丰富度和效率。
## 1.3 这种做法的核心问题:信任
一旦资金从链上转移到链下账户,
用户不再持有自己的资产,而是持有一份「平台承诺把这笔钱还给我」的凭证。
于是问题不再是 DeFi 式的「智能合约会不会被黑」,而是 CeFi 式的:
- 平台会不会跑路?
- 平台会不会挪用资金去填别的坑?
- 平台破产时,我的钱算谁的?
- 我能在多大程度上验证「钱还在那里」?

FTX、Celsius、3AC 这一连串事件已经反复证明:在 CeFi 链路里,信任不是一个软问题,而是一个会让用户血本无归的硬问题。任何 CeDeFi 产品如果不能给出系统性的、可验证的信任方案,本质上和「相信我,我不会跑」没有区别。
因此本方案的第一个、也是最核心的设计目标,不是收益率,而是:用结构而非承诺来构建信任。
## 1.4 一个关键观察:不同体量用户的敏感点完全不同
不同体量的用户,对风险的敏感点并不相同:
| 用户类型 | 最关心什么 | 对什么不敏感 |
|----------|------------|--------------|
| 小额用户（< $100K） | 收益率、申赎便利、操作体验 | 底层法律结构、追索权细节 |
| 中额用户（$100K – $1M） | 收益率、平台稳定性、PoR（Proof of Reserve） | 复杂的合规结构 |
| 大额用户（> $1M，机构） | 资金归属权、追索权、流动性、破产隔离 | 几个百分点的收益差异 |

简单说:
小钱看收益,大钱看安全。
一个 1000 万美金的用户,最害怕的不是平台量化亏掉 5%(量化亏损有限),而是平台卷款跑路(损失 100%)。所以同一套产品,对小户要在收益和体验上做到位;对大户要在法律和物理隔离上做到位。这是后文里很多分层设计的源头。
# 二、设计这个系统最需要考虑的几件事
把第一部分的问题翻译成设计目标,本方案围绕以下四个维度展开:
## 2.1 信任与安全性的构建(最重要)
**信任**不是一个单一的东西,它由三层独立的保障叠加而成。任何一层缺失,整体信任都会塌掉。

**第一层:法理上的安全性**
回答的问题:「如果平台明天倒闭,我的钱在法律上是谁的?」
核心手段:
- SPV / SPC 架构。 将理财业务装入独立的法律实体(独立投资组合公司)。用户的钱在法律上不是平台的资产,而是 SPV 受托管理的资产。平台破产时,这部分资金不会进入清算财产池。
- LP Token 作为参与股份凭证。 链上 LP Token 在法律上对应 SPV 下的 Participating Shares。用户持有 LP Token = 持有对底层资产的法律追索权,可以绕过平台直接向清算人主张权益。
- 可选:用户自有账户模式。 对超大型机构客户,允许其使用自有的 Custody 与 CEX 账户,平台仅获得 API 操作权限。这种模式下,资金物理上从未离开过客户的账户。

**第二层:资金流转与操作上的安全性**
回答的问题:「就算法理上钱是我的,我怎么知道钱物理上确实还在?怎么知道平台没在挪用?」
核心手段:
- 资金不离开 Custody。 用户资金始终存放在受监管的第三方托管机构。CEX 上跑量化用的不是真资产,而是通过 Mirror 机制映射出来的「交易额度」。即便 CEX 倒闭(FTX 重演),本金依然安全地躺在 Custody 的隔离账户里。
- 白名单锁死资金路径。 所有划转目的地都是白名单地址:「Custody 充值地址 — 理财合约 — Mirror 到指定 CEX 子账户 — 回流到指定地址」。资产无法流向白名单之外的任何钱包。
- 权限三方分离。 同一个 CEX 子账户上,量化团队、风控团队、Dashboard 数据源各持一把不同权限的 Key — 量化只有下单权限、风控只有强平权限、数据源只有只读权限。任何一方丢失 Key 都不会导致资金被提走。
- Proof of Reserve(PoR)+ 第三方审计。 由 Custody 周期性出具签名的资产证明,由独立审计机构定期校验「物理资产 ≥ 链上负债」。负债数据来自链上(透明可查),资产数据来自托管(可由 Custody 背书)。两边对齐即可证明平台未挪用。
- 操作透明的 Dashboard。 用户实时看到:自己的资金在哪个产品、产品投向了哪些策略、策略目前的 NAV 是多少、覆盖率是多少。把所有「黑盒」摊开。

**第三层:资金本身的安全性**
回答的问题:「就算钱没被挪用,量化策略本身会不会把钱亏没?」
核心手段:
- Delta 中性策略。 策略收益与市场涨跌无关。无论 BTC 涨还是跌,策略目标都是稳定输出收益,从根本上消除了方向性敞口。系统实时监控 Delta 值,超过阈值即报警并冻结资金拨付,防止量化团队偷偷加方向性赌注。
- 劣后资金(Junior Tranche)。 平台自有资金(或愿意承担风险的用户提供的劣后资金)作为「首损层」。策略亏损先吃劣后金,吃完之后才会触及用户本金。对固定收益产品来说,这是一个直接的安全垫。
- 流动性安全。 通过 T+N 赎回期、单日赎回上限(Daily Cap)、紧急熔断等机制,避免挤兑导致的强制平仓与滑点损失。

## 2.2 资金效率
仅有安全是不够的。如果资金大部分时间在闲置,产品收益率撑不起来。资金效率的构建主要靠两点:
**收益叠加(Yield Stacking)**
典型例子:美债增强产品。
1.	用户存入 USDC;
2.	USDC 在链上购买代币化美债(吃到 ~4–5% 的国债收益);
3.	代币化美债托管至 Custody;
4.	Custody 把美债作为抵押品,Mirror 到 CEX,生成保证金额度;
5.	CEX 上用这部分额度跑 Delta 中性量化(再吃一层收益)。
最终用户拿到的是「国债收益 + 量化收益」的叠加。这是 CeDeFi 相对纯链上 DeFi 的关键优势之一:可以同时利用链上 RWA 和链下交易场所。
**约束条件:**
- 通常要求 USD 本位(因为美债是 USD 计价);
- 依赖 Custody + CEX 的特定支持组合(例如 ByCustody + Bybit);
- 需要确保 Mirror 的法律和操作链路稳健。

**每日轧差与空闲资金管理**
- 每日申赎轧差。 如果某天有人存 100W,有人取 80W,物理层面那 80W 根本不动,直接内部抵销。仅 20W 净额发起真实的物理调拨。这大幅降低了 Custody 转账成本、Gas 与滑点。
- 跨产品流动性调度。 在所有产品间统一调度流动性。A 产品净流出、B 产品净流入时,物理资金可以在内部轧账,不必都走外部。
- 空窗期资金套利。 赎回锁定期内、轧差残留的资金会有几天到几周的空窗,自动路由到链上蓝筹 DeFi(Aave / 代币化货币基金)赚取额外收益。这部分收益归平台所有,是支持低费率运营的来源之一。
## 2.3 产品多样性与可组合性
一个能长期跑下去的理财平台,必须提供足够丰富的产品矩阵,让不同风险偏好、不同资金体量、不同币种偏好的用户都能找到合适的标的:
- 收益类型维度: 固定收益(适合保守用户和机构) vs. 浮动 NAV(适合愿意承担波动博取超额的用户)。
- 期限维度: 活期 T+0 / 短期 T+7 / 长期 T+30+,分别匹配不同流动性需求。
- 币种维度: USD 本位(最容易接 RWA)/ BTC 本位 / ETH 本位。
- 底层映射维度: 直接映射单一策略 vs. 包装多策略组合产品。允许第三方在底层产品之上做二次包装。

这部分不是核心安全考量,但对产品的商业成立至关重要。
## 2.4 可验证的透明度
透明度本身就是一种安全机制。即使前面三层安全都做了,如果用户没法验证,对用户来说就等于没做。所以本方案把透明度作为一个独立维度:
- 链上侧的负债数据天然透明(产品合约、LP Token 余额公开可查);
- 链下侧的资产数据通过 PoR + 审计周期性公开;
- 两者通过精细到「每个产品」的颗粒度对齐,避免「整体覆盖、局部亏空」的情况。
# 三、方案设计
## 3.1 三层抽象:用户 → 产品 → 策略
系统在产品端有三层抽象:
- 用户层: 用户持有 LP Token,代表对某个产品的份额与法律追索权。用户只看到产品 —— APY、起息期、赎回期、风险等级 —— 不需要知道底下的策略细节。
- 产品层: 一个理财产品(Vault)是一个标准化的合约模板,带一组确定的参数(币种、收益类型、起息/赎回规则、容量上限、是否含劣后等)。一个产品在底层可以购买多个策略,按预设权重分配资金(例如:产品 A = 40% 跨所套利 + 60% Delta 中性)。
- 策略层: 一个策略是一种具体的盈利模式 —— 跨所套利、基差套利、Delta 中性、做市等。策略是抽象的,它最终表现在一组 CEX 子账户上:同一个策略往往会同时运行在多个 CEX 的多个子账户里(例如跨所套利天然就是多账户协作)。

这三层是「多对多」的关系:
一个产品可以买多个策略;一个策略可以服务多个产品;一个策略运行在多个 CEX 子账户上;一个 CEX 可以同时承载多个策略。
这套抽象的好处在于:
- 用户视角简单 —— 只需理解产品。
- 策略可复用 —— 同一个策略可以被多个产品按不同权重组合。
- 资金可分组核算 —— 任何时点都能精确算出「某产品在某策略上有多少钱」。
- 风控可分层施加 —— 既可以在策略层(限仓位、限杠杆),也可以在子账户层(强平、提币锁死)。

整个系统的存入资金流如下图所示。它以「Vault A(稳健活期)」为代表,完整展示了用户存入 → 链上合约 → Custody → CEX → 量化/风控/Dashboard 这整条链路。
 
![3.1.png](https://img.learnblockchain.cn/attachments/2026/06/3xK0vJtu6a3d1edcccb10.png)
图 3.1 — 存入资金流:产品 → 策略 → CEX 子账户三层映射,以及量化/风控/Dashboard 三方权限分离
下面分层展开。
## 3.2 链上层:理财合约矩阵
链上层是用户能直接验证的部分,也是法律凭证(LP Token)的发行地。所有产品作为独立的 Vault 合约部署在用户资金所在的链上 —— Solana / Ethereum / BSC / 等等。
### 3.2.1 Vault 合约的内部组成
以 Vault A(稳健活期)为例,合约内部由三部分组成:
- 备付金子区(10% AUM): 留在合约内的链上储备金,专用于 T+0 即时赎回。用户 burn LP Token 后,资金直接从这个子区转账给用户,不经过 Custody、不调用任何 API、交易内到账。这是「链上备付金」的关键意义所在 —— 把它放在合约里而非 Custody 里,才能真正实现即时赎回。
- 待调出资金子区(90% AUM): 等待被调拨到 Custody 的资金。这里的关键约束是:目的地址在合约里写死(白名单),只能转到 Custody 的指定接入钱包,无法转去任何其他地址。即使后端被入侵,资金也只能在白名单内流动。
- 账本子区: 维护每个用户的 LP Token 持仓、累计本金、累计收益,以及产品的整体 NAV、APY。这部分数据完全在链上,任何人都可以独立验证「我应得多少钱」。

### 3.2.2 产品矩阵与可组合性
Vault A 只是一个产品。系统支持同时部署多种产品,以匹配不同用户需求:
- Vault B(美债增强):USDC 本位,固定 APR,T+7 赎回,KYC 准入,面向机构。
- Vault C(BTC 进取):BTC 本位,浮动 NAV,T+14 赎回,含劣后层,面向 Web3 用户。
- ……以及更多。

更重要的是,这些 Vault 是可组合的 —— 第三方可以部署一个「组合 Vault」,在合约层面同时申购 Vault A 和 Vault B,按自定义权重提供新的产品形态。这是相对传统 CeFi 平台的一个关键优势:产品本身是开放可组合的链上原语。
### 3.2.3 一个尚未解决的问题:链上 KYT
一个诚实的承认:如何在链上做 KYT(Know Your Transaction,反洗钱链上检查)目前还没有理想方案。
可选项与各自的问题:
- 合约调用链上 KYT Oracle(如 Chainalysis Oracle、TRM): deposit 时静态调用 oracle,黑名单地址直接 revert。问题:oracle 数据滞后、覆盖不全;Oracle 自身是中心化的,且本身就是一个新的攻击面。
- 链下监控 + 黑名单同步: 监控到黑名单后由管理员推送到合约里。问题:这回到了「信任管理员」的老路。
- 把 KYT 推迟到 Custody 侧: 资金到达 Custody 接入钱包时,由 Custody 履行其合规义务做 KYT。问题:钱已经进合约再查没有意义,资金已经混入了产品池。

在更好的方案出来之前,本方案的现实选择是:链上层暂不做 KYT,依靠 Custody 侧的合规检查兜底。这是一个公开承认的缺陷,留待后续方案改进(包括第五章提到的主权 Agent 方向)。
## 3.3 Custody 层:接入钱包 + 统一映射源
Custody(Ceffu / Copper / Cactus / ByCustody 等)是物理持有用户资产的受监管第三方。所有用户资金的实际存储位置都在这里,CEX 上跑的只是通过 Mirror 映射出来的「交易额度」。
Custody 在系统中分两层:
### 3.3.1 第一层:产品接入钱包
每个产品在 Custody 内有一个单一接入钱包,作为合约白名单写死的归集地址。这个地址承担的角色:
- 唯一接收来自链上 Vault 合约的资金。
- 作为产品级资产隔离的最小单元 —— 不同产品的资金,在 Custody 内严格分开。
### 3.3.2 第二层:统一映射源(按策略组织)
接入钱包归集的资金,在 Custody 内部进入「统一映射源」—— 一个按策略组织的资金池子。
注意:这里的「统一映射源」是个示意概念,实际实现取决于 Custody 厂商。例如:
- Ceffu 要求 1:1 映射:一个 Ceffu 钱包对应一个 Binance 子账户。
- Copper 允许一个统一映射源同时映射到多家 CEX 的多个子账户。

无论物理实现是哪种,逻辑上都可以表达成:接入钱包的资金,按策略分组,每个策略对应一组 Mirror 目标(CEX 子账户)。比如产品 A 的资金:
- 40% 进入「策略 #1:跨所套利」资金池 → Mirror 到 Bybit 子-1、OKX 子-1 等多个子账户;
- 60% 进入「策略 #2:Delta 中性」资金池 → Mirror 到 Bybit 子-2、OKX 子-2、Binance 子-1 等。

策略层是这套结构的核心 —— 它把「资金归类」和「具体子账户」解耦,既让同一策略可以分布在多 CEX 多子账户(分散风险、增加深度),又让 NAV 计算时能按策略聚合(不必关心物理子账户级别)。
## 3.4 CEX 层:多家交易所、多个子账户
最底层是各家 CEX —— Bybit、OKX、Binance 等。资金不在这里,只有「Mirror 出来的交易额度」在这里。
**CEX 层的关键设计:**
- 无法直接提币，只能Mirror。CEX的子账户资金是通过Custody Mirror过来的，无法直接提币，必须结算回Custody (包括本金和收益)。
- 一个子账户运行一种策略。 不在同一个子账户里混跑多种策略,便于风险归因和 Delta 监控。
- 一个策略分布在多个子账户。 例如跨所套利天然就是多账户协作 —— Bybit 子-1、OKX 子-1 同时存在头寸。Delta 中性策略也常分散在多家 CEX 提高深度与抗冲击能力。
## 3.5 三个外部角色与权限隔离
CEX 子账户上同时存在三方角色,每方持一把不同权限的 API Key。这是整个系统「权限三分」的核心机制 —— 也是回答「为什么资金能放心交给量化团队跑策略」的关键。
### 3.5.1 量化团队 — 下单 Key
- 权限:在子账户内下单、撤单、调仓。
- 没有:提币权限、调拨资金权限。
- 职责:运行各类策略,产生收益。

即使量化团队的 Key 被攻击者拿到,攻击者最多能在子账户内胡乱交易造成有限损失,但无法把钱提走,也无法触发资金调度。
### 3.5.2 风控团队 — 强平 Key
- 权限:强制平仓、撤单。
- 没有:开仓权限、提币权限。
- 职责:独立监控每个子账户的 Delta、杠杆率、风险敞口,异常时强制清仓止损。

风控 Key 与下单 Key 严格分离,意味着量化和风控形成互相制衡的关系 —— 量化能开仓,但风控能在必要时把仓位关掉。这是防止「量化团队偷偷加方向性赌注」的核心机制。
### 3.5.3 Dashboard 数据源 — 只读 Key
- 权限:只读 —— 抓取持仓、NAV、订单等数据。
- 没有:任何写权限。
- 职责:把 CEX 数据写入后端数据仓库,后端按策略聚合算出产品 NAV,然后输出给用户 Dashboard。

Dashboard 数据源使用独立的只读 Key,确保:即使所有写权限 Key(下单、强平、Custody 调拨)都失效,展示给用户的数据通道依然完整;用户看到的资产数据来自 CEX 直出,中间经过的只是「读取 + 聚合」,没有任何方有篡改空间。
### 3.5.4 隐含的第四方:资金调度模块
除了上面三方,还有一个隐含角色 —— 资金调度模块。它持有 Custody 的写 API,负责发起 Custody 内部和跨 Custody 的资金调拨，以及将资金Delegate/Undelegate到CEX子账户。这个模块完全独立于量化和风控,且只能在合约白名单 + Custody 白名单的双重约束内调拨,无法转出系统。
综合起来,系统中触及资金的所有权限被分散到了四个独立的密钥持有者:
| 角色 | Key 权限 | 若 Key 丢失最坏情况 |
|------|----------|---------------------|
| 量化团队 | 下单 / 撤单（CEX 子账户） | 子账户内恶意交易，造成有限亏损 |
| 风控团队 | 强平 / 撤单（CEX 子账户） | 子账户被恶意强平，但无法转出资金 |
| Dashboard 数据源 | 只读（CEX 子账户） | 数据展示中断，资金不受影响 |
| 资金调度模块 | 写 API（Custody） | 仅能在白名单内调拨资金，无法将资金转出系统 |

没有任何单一密钥或单一模块可以独立把资金提走。这是本方案在「操作安全」维度上的核心保障。
## 3.6 赎回资金流:两个订单的解耦
### 3.6.1 一个澄清:T+0 活期产品没有真正的「赎回流程」
T+0 活期产品(Vault A)的设计前提就是:用 10% AUM 的备付金覆盖所有日常的小额即时赎回需求。用户 burn LP Token 后,资金直接从合约内的备付金子区转账给用户,交易内到账,完全不触发 Custody / CEX 的任何动作。换句话说,T+0 产品的「赎回」就是合约内部的一笔转账,没有需要画出来的完整流程。备付金水位被消耗后,后端通过日常调度从「待调出资金子区」或「策略层回款」补足备付金,这部分是周期性的运维动作,不在每次赎回的触发链路上。
真正需要走完整链路的,是有赎回等待期的产品 —— T+7、T+14 等。它们的设计前提就是:用户的钱大部分时间在策略层跑收益,赎回时需要把钱从策略层一路回流。下面以 Vault A(T+7) 为例展开。
### 3.6.2 两个订单:用户视角 vs. 系统视角
理解赎回流程的关键,是认识到这里其实存在两个独立的订单,它们在生命周期、发起方、完成条件上都不相同:
- 订单 A — 用户 → 产品的赎回订单。由用户在链上发起(burn LP Token,进入赎回队列),T+7 后用户领回本金 + 收益时订单完成。这是用户视角能感知到的唯一订单,中间过程对用户透明。
- 订单 B — 产品 → 策略的平仓订单。由后端在日终轧差后发起,按各策略权重分配净流出金额,通知策略层平仓;策略层在自己负责的 CEX 子账户上平仓、Undelegate 资金回到策略钱包,再把资金打回产品钱包,订单 B 完成。这是系统内部的订单,用户看不到。

两个订单解耦的好处在于:用户的赎回承诺(T+7)和系统内部的资金调度节奏(每日轧差后批量处理)是分离的。后端可以按效率最高的节奏处理订单 B,而不必为每一次用户赎回都立即触发一次 CEX 平仓。
### 3.6.3 「产品」和「策略」是账本概念,资金在物理钱包里流动
3.1 节已说明,产品和策略是三层抽象中的两层。其中一处容易混淆:「产品」和「策略」本质上是账本概念,资金真正的物理位置在不同的钱包里。
- 产品的钱,物理上分布在两处: 
链上 Vault 合约(备付金 + 待调出资金) + Custody 里的产品钱包(单一归集地址)。但这只是产品直接持有的现金部分——产品的大部分价值,是它投进各策略的份额(物理上落在下面「策略的钱」那两处:策略钱包 + CEX 子账户),以及为按期兑付而暂时停在链上 DeFi 的待兑付资金(Earmarked)。产品的全部物理资产 = 这两处现金 + 所持各策略份额对应的价值 + 停在 DeFi 的部分,合起来覆盖该产品在链上发行的全部 LP Token 负债(完整聚合口径见 3.9.1)。
- 策略的钱,物理上也分布在两处: 
Custody 里的策略钱包(统一映射源里属于该策略的部分) + CEX 子账户里的 Mirror 额度。这两处加起来,就是该策略对应的全部物理资产 —— 而它的「负债」是各个产品在账本上记录的「我对这个策略投了多少份」。

这个区分非常重要,因为它解释了赎回时资金为什么要在几个钱包之间流动:CEX 子账户 → 策略钱包 → 产品钱包 → 链上 Vault → 用户。每一步都是真实的钱包到钱包的转账,因为「产品」和「策略」在账本上有明确的资产归属,资金必须跟着账本归属流动。
### 3.6.4 资金流 vs. 控制流
下面这张图解释了赎回流程，它同时承载了两类不同性质的流:
- 资金流(实线): 钱包到钱包的真实转账,发生在 Custody / CEX 体系内。
- 控制流(虚线): 后端发出的订单和指令。后端本身不在 Custody / CEX 体系内,它在外部,通过 API 调用驱动资金动作。具体来说:资金调度模块(持 Custody 写 API)发起钱包间划转,量化模块(持 CEX 下单 Key)发起 CEX 子账户上的平仓。

把这两类流分开看,能更清楚地理解每一步动作的发起方和性质 —— 哪些是真正的资产位移,哪些只是后端在指挥位移。
 
![3.2.png](https://img.learnblockchain.cn/attachments/2026/06/GpoQuewF6a3d1f1215ff9.png)
图 3.2 — 赎回资金流(以 Vault A T+7 为例):资金流走钱包,控制流由外部后端发起;两个订单(用户→产品、产品→策略)解耦
### 3.6.5 完整链路:七步走完
把上面所有的概念合到一起,赎回的完整链路是:
- ① 用户 burn LP Token,进入赎回队列。 链上动作,锁定 LP Token,开始 T+7 计时。这是订单 A 的发起。
- ② 后端日终轧差后,发出平仓订单(订单 B)。 后端聚合当天的申购和赎回,做产品内轧差,得出该产品的净流出量。按各策略的权重分配净额,向相关策略发出平仓订单。策略内再次轧差，如果策略内部轧差后其当天净流入,则无需发起平仓订单。
- ③ 策略接到订单,按各子账户的持仓比例下平仓指令。 例如策略 #2 同时跑在 Bybit 子-2、OKX 子-2、Binance 子-1,策略层会按预定比例分配平仓量。实际执行由后端量化模块通过 CEX 下单 Key 完成。
- ④ CEX 平仓完成,Undelegate 资金回到 Custody 的策略钱包。 这是第一段真实的资金位移 —— Mirror 额度被销毁,对应的资金从 CEX 子账户回流到 Custody 的策略钱包。
- ⑤ 策略钱包 → 产品钱包(Custody 内部划转)。 这是 Custody 内的钱包间转账,由资金调度模块通过 Custody 写 API 发起。划转金额对应该产品在该策略中应得的份额。订单 B 在这一步完成。
- ⑥ 产品钱包通过专用接口注入资金回链上 Vault。 Custody 的产品钱包配置了链上 Vault 合约地址作为白名单出口,通过专用接口把资金注入回链上(对应存入流程里「链上 → Custody」的反向操作)。资金到达 Vault A 后,合约准备兑付给到期用户。
- ⑦ T+7 到期,用户 claim 本金 + 收益,订单 A 完成。 用户在链上发起领取,合约把资金从 Vault 转回用户钱包,LP Token 被销毁。
### 3.6.6 日终轧差:为什么不每次赎回都立即触发平仓
订单 B 的发起时机不是「用户一发起赎回就立刻触发」,而是「每日日终轧差之后,按净额触发」。原因是:
- 产品内轧差: 同一个产品当天可能既有人申购、又有人赎回。如果当天净流入,则不仅不需要平仓,反而需要新增建仓;如果当天净流出小于产品备付金水位的可调节范围,有时也无需触发底层平仓。
- 策略内轧差: 产品的建仓/平仓请求需要发送到对应的策略。如果某策略内产品 A 当天要求平仓100 万、

产品 B 当天要求建仓80 万,策略可以在内部完成轧差结算,只对剩下 20 万净额触发实际平仓。这能大幅减少 CEX 平仓的频次和摩擦成本(建仓/平仓成本和风险)。
轧差机制本身的细节(优先级、跨产品兼容性判断、跨策略调配规则等)比较复杂,完整方案见 3.8 流动性管理;图中以底部黄色注释的方式提示其存在。
## 3.7 控制流与数据流
3.1–3.6 讲清了系统的静态结构和两个方向的资金流。这一节回答最后一个问题:外部后端是如何驱动整个系统的?核心有两点——其一,后端把三方原始数据整理成一个内部数据库,而这个数据库的本质是一个状态机;其二,后端对外只做两件事:单向读数据、单向发指令,且任何资金动作都必须经过相互隔离的写权限模块、锁死在白名单内。
### 3.7.1 内部数据库的本质:一个状态机
后端持有两把 Key(Custody 只读、CEX 只读),把链上合约、Custody、CEX 三方的原始数据(Raw Data)持续抓取进来,清洗整合后写入核心数据库。这个数据库不是一堆零散的表,它的核心可以抽象成一个状态机:由三部分构成——状态(State)、订单(Transactions)、以及状态转移函数 F(n)。State 是系统在某一时点的快照,Transactions 是发生过的所有动作,F(n) 描述「一笔订单如何把 State N 变成 State N+1」。
State 在三层抽象上各有自己的内容:
- 客户状态:持有哪些产品、各产品份额、累计收益、当前订单。
- 产品状态:AUM、准备金、NAV、收益率,以及持有每个策略多少份额、每个用户的持有情况。
- 策略状态:单位 NAV、份额、运行在哪些 CEX 的哪些子账户、被哪些产品持有及持有多少。

订单(Transactions)分两层,与三层抽象对应:
- 客户侧<->产品侧(用户买入 / 卖出产品、产品 APR 变化)
- 产品侧<->策略侧(产品买入 / 卖出策略、更新单位 NAV)。

这个状态机有一个关键性质:订单最终都对应着真实的 Raw Data。每一笔订单都能在链上、Custody 或 CEX 的原始数据里找到可验证的支撑;因此由订单推导出来的状态也就有了数据支撑,最终对外披露的所有 Dashboard 数据都是可追溯、可验证的。这正是 2.4 节所说「可验证的透明度」的技术落点。
 
![3.3.png](https://img.learnblockchain.cn/attachments/2026/06/0IZdxluh6a3d1f20e2e7d.png)
图 3.3 — 系统的状态机抽象:订单(Transactions)驱动状态(State)转移;每笔订单都对应可验证的 Raw Data,因此状态与 Dashboard 全程可追溯
### 3.7.2 控制流 vs. 数据流:后端如何驱动系统
把后端放进整张图里看,它对外只有两类箭头:实线的数据流和虚线的控制流,二者方向相反、严格分离。
- 数据流(实线,单向流入):三方原始数据汇入数据库后台服务,经数据整合处理写入核心数据库;核心数据库再通过只读接口对外披露给运营 / 风控团队和用户 Dashboard。其中 NAV 的计算路径是:先据各 CEX 子账户的 NAV 统计出策略 NAV,再按「产品 × 策略」的权重加总得到产品 NAV。
- 控制流(虚线,单向流出):后端经三个相互隔离、各持一把写权限的执行模块对外发指令:
◦	量化执行模块(下单 Key)在 CEX 子账户内下单 / 撤单 / 平仓;
◦	风控执行模块(强平 Key)在异常时一键平仓;
◦	资金调配模块(Custody 写 API)在各 Custody 之间转账、做 Mirror / 结算。
后端的「后台服务」本身是一个管理后台,不在 Custody / CEX 体系内。它内部包含角色与权限管理、配置管理(产品 / 策略 / Custody / CEX 配置)、订单管理(客户 / 产品 / 策略三层)、KEY 管理(只读 Key),以及上面说的数据库后台服务。它只读外部数据、只在白名单内发指令。几个权限设计要点:
- 四把 Key 严格隔离。下单(量化)、强平(风控)、只读(数据汇入)、Custody 写(调配)分属不同模块,任何一把 Key 泄露都不足以把资产转走。
- 风控是独立模块。它不接受编排层的指令,自己监控 Delta / 杠杆 / 限额 / 敞口,触发阈值即自动强制平仓——与下单权限彻底分离,因此图中没有「后端 → 风控」的触发线。
- 量化 → 资金调配。当量化需要在 CEX 子账户之间挪动资金时,由量化向资金调配模块发出请求,由后者执行;量化自身不持有Custody相关权限。
- 资金调配只动 Custody。它在合约 + Custody 双重白名单内做钱包间划转,目的地写死,不直接连 CEX。
 
![3.4.png](https://img.learnblockchain.cn/attachments/2026/06/I1tfbxTF6a3d1f2a8c814.png)

图 3.4 — 控制流与数据流:后台服务为数据与决策中枢;数据单向汇入并对外披露,控制经独立写权限模块单向流出,全部锁在白名单内
综合来看,这套结构给出一个清晰的安全边界:数据只能单向流入并对外披露,资金动作只能经独立写权限模块、单向流出且锁死在白名单内。后端、任何一把单独的 Key、任何一个单独的模块,都无法把资产转出系统之外。这也呼应了第二章关于安全性的分层论述。
## 3.8 流动性管理
本节解决一个贯穿全局的问题:在「既要保证按期兑付、又要尽量少动底层策略」这对矛盾下,资金应该怎么调度。
先探讨产品的资金池：所有资金分成两个互斥的池子,并约定一条不变量:
- 运营现金池(Unassigned):新流入、轧差残差、尚未指派给任何到期负债的钱。可参与轧差、可投入链上 DeFi 做机会性增益。
- 兑付储备池(Earmarked):已为某笔到期赎回锁定的钱(含为兑付而临时停在 DeFi 的部分)。只认到期日,不参与再次轧差。

不变量:任何一笔资金一旦从 Unassigned 进入 Earmarked,就退出轧差引擎的可用范围,直到它兑付完成。这条不变量是整套流动性方案的安全核心——下文「跨时间轧差不依赖未来流入」「DeFi 里的钱不能再轧差」「了结即出池」都是它的不同侧面。
### 3.8.1 两类产品,两套流动性策略
流动性管理的起点,是 T+0 活期产品与 T+N 定期产品有本质不同的流动性形态:
- T+0 活期产品:留备付金,牺牲一部分资金利用率换即时性。用户随时可赎,所以必须在金库里留一笔随时可动的现金(备付金),代价是这部分钱不在策略层吃满收益。
- T+N 定期产品:不留备付金,全额投入策略,只需在到期日前把钱备齐。用户的钱在锁定期内全程在策略层跑收益,资金利用率接近 100%;赎回是一个有确定到期日的负债,系统只要保证「到期那天 Vault 里有那么多钱」即可。

这两套形态对应两套机制:备付金的水位管理(3.8.2),和定期负债的到期兑付调度(3.8.5–3.8.7)。
### 3.8.2 T+0 备付金:目标水位 + 容差带
备付金管理采用「目标水位 + 容差带」模型,这是现金管理的标准做法。例如:目标水位 20% AUM,容差带 [10%, 30%];现金升破 30% 说明闲置太多,应择机买入策略;跌破 10% 说明缓冲不足,应回补到目标。但有四点必须细化,否则会踩到 3.8.3 说的 churn 陷阱:
- 容差带是「触发关注」的信号,不是「立即执行」的命令。不要一碰到带边就单独发一笔开/平仓——那恰好制造了本方案要避免的频繁开平仓。正确做法是:带只决定「今天这个产品净需要调多少现金」,真正的买卖金额放进当日策略层轧差(3.8.4),与别的产品的反向流动先内部抵销,只对净额动底层。
- 上下越界的紧迫性不对称。越上界(现金太多)是「好问题」,不急,顺着当日轧差慢慢调出去;越下界(现金不足)才是「硬问题」,且回补来源有优先级:先动停在链上 DeFi 的暖层(秒级~分钟级,见 3.8.7)→ 再走当日轧差里的策略平仓 → 只有极端情况才盘中强制平仓。
- 水位数值应由数据校准,而非拍死。合理水位取决于该产品每日净流出的分布:大致要能覆盖历史 95–99 分位的多日累计净流出,再叠加单日赎回上限(3.8.8)。波动剧烈期可临时调高。10/20/30 是合理的初始默认值。
- 容差带宽度本身是个权衡。带越宽,触发越少、churn 越低,但闲置现金拖累(drag)越大;带越窄反之。用净流出分布去调这个宽度。

备付金内部还可再分两层以兼顾「毫秒级」承诺:热层(真正留在合约里、毫秒到账,覆盖日常小额)+ 暖层(停在可即时赎回的链上 DeFi,覆盖容差带的缓冲部分,秒级~分钟级动用)。3.2.1 说的「备付金放合约里才能即时赎回」指的是热层。
### 3.8.3 少动底层的理由:开平仓的真实成本
本节所有机制的共同目标只有一个:让申赎运维尽可能不额外触发底层开平仓。原因在于,频繁开平仓会从**四个层面侵蚀收益:**
- 显性交易成本:taker 手续费 + 买卖价差。Delta 中性/基差类策略通常是多腿(现货+永续),一次完整往返要付多次费。
- 滑点 / 市场冲击:这是大额平仓的主成本,且随规模超线性放大。小额无所谓,大额平仓会自己把价格打坏。
- carry 中断(最隐蔽、最重要):Delta 中性的收益本质是持续持有仓位换来的 carry。为了腾现金平掉仓位,等于主动关掉收益引擎;过几天再开,市场给的收益率档位可能已经变差。
- 再入场时点风险:平了再开,入场点位未必比原来好,还要再付一次手续费和滑点。
关于 carry 中断有两种情况:
- 资金费是离散事件,不是连续累积。永续合约的资金费在固定结算时点(通常每 8 小时)按那一刻的瞬时费率一次性结算——只有结算时点持有仓位的人才收/付一次款。决定单次资金费正负与大小的,是结算时点的瞬时费率,不是这 8 小时的平均。它的「时间属性」体现在频次上:持有的周期越多、经历的结算次数越多,期望上累积越多。
- 基差是随时间连续收敛的。期货/现货基差随到期临近向 0 收敛,这个收敛是时间的连续函数,持有越久吃到越多,不依赖某个离散结算时点。

所以平仓兑付赎回伤害收益,准确的说法是:(对资金费)减少了未来会经历的结算次数,并可能恰好错过即将到来的结算时点,且重新建仓时市场费率档位可能已变差;(对基差)中断了正在进行的连续收敛;外加重建的手续费、滑点与入场点位风险。
一个必须澄清的边界:结算前临时平仓以避开一次预期为负的资金费,有时反而是策略层基于费率预测做的正确主动操作。它与本节要避免的「为凑赎回现金而被动平仓」是两回事。流动性管理要消除的是后者(被运维需求逼出来的、非策略意愿的平仓),不是前者。
### 3.8.4 轧差按层发生:产品内申赎轧差 + 策略内份额轧差,跨策略不能轧
轧差不是只发生在某一层,而是在每一层按该层的「同质单位」各做一次;跨策略之间无法轧差。
- 产品内申赎轧差(产品层): 同一产品当天的申购与赎回,是同一产品、同一 NAV 下的同质份额,可以直接对冲——赎回方支取的现金由申购方补上,这部分无需触及底层策略。产品对外报出的「当日净流入 / 净流出」即这一步轧差之后的净额,而非申赎的原始总量。
- 策略内份额轧差(策略层): 产品的净流量按权重拆成「对各策略的份额增减意图」后,同一策略上一个产品的增持与另一个产品的减持,是策略单位 NAV 下的同质份额,可零 churn 对冲(份额换手、底层仓位不动)。这是 3.8.5 展开的两池对冲。
- 跨策略无法轧差: 不同策略各有自己的单位 NAV,产品对每个策略的目标持仓也不同,两者的份额不是同质物,彼此之间没有可对冲的对象。产品 A 卖策略 S1、产品 B 买策略 S2,在物理上是 S1 平仓、S2 开仓两个无关动作,强行配对只是现金在账户之间搬动——顶多省一次 Custody 转账,carry 与 churn 均无节省。

层级关系因此是:
- 产品层:先做产品内申赎轧差,再拆意图。 第一步把当天的申购与赎回对冲,得出对外净流量;第二步把净流量按权重拆成「对每个策略的份额增减意图」下发;第三步管理自己尚未到提款期的资金(投入 DeFi 吃息,见 3.8.7)。产品层的轧差止于「同一产品的申赎对冲」,不具备份额级、跨产品的对冲能力。
- 策略层:做份额级轧差,每个策略各自独立进行。 策略 S 收齐所有产品对它的增 / 减意图,在内部对冲买卖,内部消化的是零 churn 的份额换手;仅净残差去其 CEX 子账户真实开 / 平仓,完成后将结果(成交价、份额变动、现金收付)返回产品层,产品层据此更新所持各策略的份额。

策略层的份额轧差是 3.1「策略作为核心抽象层、把资金归类与具体子账户解耦」的运行时体现:它是策略作为「基金」的内部操作,产品只是其持份人。由此可得一个直接推论——产品间能否省下策略层的 churn,取决于是否共用同一策略,因此鼓励产品共用策略池本身即是一种流动性优化。此外,同一策略本就是单一本位币,「轧差池按本位币分组」这一约束在策略层自动满足。
### 3.8.5 策略内轧差:两池对冲 + 时间优先级
每个策略各自把当天来自各产品的增减意图汇成两个池,直接对冲:
- 平仓池(净流出方向):所有要减仓的需求,不管它处于什么阶段——还没下指令的、已下指令在途未成交的——统统是「想把仓位变成现金」的需求。
- 建仓池(净流入方向):所有要加仓的需求,不管是新进来的申购还是早先记下的待买入,统统是「想把现金变成仓位」的需求。

每轮轧差就是两池对冲,取 min(平仓池, 建仓池) 内部消化、份额按结算 NAV 换手(底层仓位一动不动、不影响 Delta),只有净残差才发真实指令:净正→开仓,净负→平仓,约等于零→当天完全内部消化。不必追踪「这笔去冲那笔」,因为池子是无差别的,要做的物理动作本来就同质、可互相抵销。
两池之外还有一个关键参数:出池的时间优先级。 当建仓池不足以覆盖整个平仓池时,有限的对冲量必须先满足到期日最近的赎回。所以平仓池按到期日升序排队,用建仓池(它没有到期压力,作为无序供给)从队头逐笔填满;填满一笔,这笔就彻底了结、出池。例如同时有 T+3 与 T+7 两笔赎回,优先轧 T+3——让时间上最紧的那笔尽早彻底锁定兑付来源,先紧后松永远是对的方向。

结算必须做好:任何一笔意图一旦了结(无论是被内部对冲了结、还是走真实成交了结),立刻退出两个池。 被内部对冲的,双方了结、份额换手即出池;走真实平仓的,换回的现金锁进 Earmarked、同样出池。没做好这步就会重复轧同一笔——要么把一笔钱许给两个赎回(期限错配),要么以为还有仓位可平、实际早平完了。落到 3.7.1 的状态机上,这天然就是订单的状态流转:每笔增减意图是一笔订单,池 = 当前处于「未了结」状态的订单净额,轧差引擎每轮只扫未了结订单、算净额、推进状态。
一个用例:产品 A(T+0)当日净流出 100、需减持策略 S 的份额;产品 B(T+7)当日净流入 80、想增持 S。内部撮合:B 按结算 NAV 接下 A 的 80,付现金 80;A 还差 20 → 策略 S 只平仓 20,而不是 180,churn 降约 89%。
 
![3.5.png](https://img.learnblockchain.cn/attachments/2026/06/c87EyKi66a3d1f3ff31fd.png)
图 3.5 — 轧差分两层:产品内先做申赎轧差,策略内再做份额「两池对冲」,只对净残差动底层
### 3.8.6 跨时间轧差与「按期兑付」的硬约束
一个自然的想法是跨天轧差:今天某笔赎回先不平仓,指望后面几天的新申购来兑付。这是个错误的方法。 它产生两个独立风险:流入不及预期(市场恐慌时所有人一起赎、申购同时枯竭),以及平仓来不及(临到期才发现钱不够,而有序平仓需要时间)。两者叠加就是「到期日没钱、又来不及补」——这正是期限错配,是 Celsius 一类暴雷的机制本身。
硬约束因此是:每一笔有到期日的负债,必须能用「已经实现的现金来源」在到期日前备齐,绝不依赖「还没到账的预期流入」。
但跨时间轧差有一个安全的退化版,只取好处、不留敞口:
- 默认按确定来源备付。一笔定期赎回在发起当天就进入兑付安排:要么当天被份额内部转移消化(零 churn),要么就安排底层平仓、把现金锁进 Earmarked。兑付来源默认是确定的,不依赖任何未来。
- 新流入做「事后冲销」,而非「事前指望」。若到期前真的来了反向流入,就用它撤掉一笔尚未成交的平仓指令(零成本),或在仍划算时把已平的仓位重建回来(挽回 carry,但要付重开成本,需 carry 收益 > 重开成本才做)。它来了就赚到、不来也早已备好钱——从不为它的到来留敞口。
- 临到期收敛(硬兜底)。设一条截止线(例如到期前 T-2 仍未备齐的部分,无条件平仓锁定),在还来得及有序平仓时就动手,绝不拖到最后一天。用确定性换掉对未来流入的依赖。
这样跨时间轧差就退化成纯增益、无风险敞口的优化:运气好省一次开平仓,运气差也因早已按确定来源备好钱而兑付无损。它在文档中应被明确标注为「机会性优化」,而非流动性的依赖项;若实现成本不划算,退回到只做同日的策略内轧差(3.8.5)也完全成立——同日轧差是无条件安全的。
### 3.8.7 空窗期资金:投入可即时赎回的链上 DeFi
在 3.8.6 里被提前平仓、锁定给某个未来到期日的资金,以及备付金的暖层,都会有时间空窗。这部分自动路由到蓝筹、可即时赎回的链上 DeFi(Aave、代币化货币基金等)赚一层额外收益,到期前赎回回 Vault。
这里要紧扣 3.8 开头那条不变量:停在 DeFi 的这笔钱属于 Earmarked、已经「有主人」(已指派给某个确定的到期日和负债),只是人还没来取,所以它绝不能再被当作轧差的对手。 用它去满足别的产品的流动性需求,等于把同一笔钱许给两个到期日,又变回期限错配。
约束:只用可即时(或远早于到期日)赎回的低风险协议;按协议设集中度上限,不把空窗资金堆在单一池子;DeFi 的可赎回时间必须 ≤ 到期日 − 安全边际。 收益归属沿用 2.2 的口径(归平台、支撑低费率运营),也可按产品配置调整。
### 3.8.8 大额赎回与其他流动性风险
除了水位与轧差,还有这些必须纳入流动性管理:
- 单日赎回上限(Daily Cap)与大额预约。T+0 的「即时」隐含单笔/单日规模上限:超过备付金可承受范围的大额赎回,超出部分排队(临时降级为 T+N),或对超过阈值的大额要求提前预约(如 >$1M 需 T+2 通知),让交易台有时间有序平仓、不打坏市场。
- （尚需考虑是否合理）滑点归因 / Swing Pricing。逼迫底层平仓的大额赎回者,应自行承担其造成的滑点(赎回费 / 退出 NAV 调整),而不是把成本摊给留下来的持有人。既公平,也抑制「先跑者占便宜」的挤兑动机。
- 挤兑时的按比例闸门(Gating)。某窗口内赎回总申请超过可用流动性时,按比例兑付、其余排队。
- 覆盖率监控与压力测试。对每个产品及全局持续监控「可用流动性 / 近期潜在流出」的覆盖率,并对极端情景(集中赎回、跨产品相关流出、CEX 宕机、稳定币脱锚)做压力测试。
## 3.9 NAV、申赎定价与收益来源
3.8 的轧差反复用到「结算 NAV」,申赎也要按某个 NAV 成交。这一节定义 NAV 怎么算、申赎按哪个 NAV 成交、以及运营方的利润从哪来。
先明确 NAV 在本系统里要服务三件事,它们对 NAV 的要求并不相同,因此最终要拆成两个口径:
- 给申赎定价:用户侧$X 申购能换多少份额、Y 份额赎回拿回多少钱。
- 给轧差结算:产品间转移策略份额时,按哪个数转才公平(前面一直叫它「结算 NAV」)。
- 给用户披露:Dashboard 上的收益率从哪来。
### 3.9.1 自下而上的三层聚合
NAV 自下而上分三层聚合,正好对应三层抽象:
- 子账户 NAV(从 CEX 只读 Key 抓快照算):一个子账户跑一个策略,其价值贡献 = 现货腿市值 + 永续腿保证金 + 未实现盈亏 + 已结算待提的资金费 − 应计费用。
- 策略 NAV:把策略当成一只有「份额」与「单位 NAV」的基金。策略总 NAV ÷ 策略总份额 = 单位 NAV;产品投现金进策略按当时单位 NAV 换份额,策略赚钱→单位 NAV 涨→所有持份产品按份额比例同步受益。这正是轧差里「按 NAV 转份额」成立的前提。
- 产品 NAV:= 链上 Vault(备付金+待调出)+ Custody 产品钱包 + Σ_策略(产品持该策略份额 × 该策略单位 NAV)+ Earmarked 停在 DeFi 的部分市值;再 ÷ LP Token 总供给 = 产品对外的单位 NAV。
需注意：抵押品不能重复计算。 因为 CEX 上的钱是 Mirror 出来的额度、真实抵押品在 Custody，而Mirror 的记账方式因厂商而异。因此抵押品在整条聚合链路里有且只被计一次,「Custody 计 vs CEX 计」的边界要一次性画死。 否则容易造成NAV算错，资产被凭空多计，造成损失。
 
![3.6.png](https://img.learnblockchain.cn/attachments/2026/06/ll5mnv7p6a3d1f5040d05.png)
图 3.6 — NAV 自下而上三层聚合:子账户 → 策略 → 产品;同一笔抵押品在整条链路只计一次
### 3.9.2 结算 NAV vs 展示 NAV
结算 NAV 直接关系到钱(份额怎么转、申赎怎么定价),所以它有两个关键点:
- 所有腿必须在同一时点 mark。Delta 中性是现货+永续两腿对冲,若两腿取价时点不一致,会算出根本不存在的 PnL 和 Delta。因此定一个固定快照时点(如每日某个 UTC 时刻日终 mark,一日一次),所有腿、所有子账户按同一快照取价。
- 用 mark price,不用 last price。用最新成交价,有人可在快照前几秒在薄盘口「画线」推价、操纵 NAV 占便宜。用交易所 mark price(指数价)抗操纵,也避免薄盘噪声。
所以在用户侧有两个NAV:
- 结算 NAV(binding)——每日日终快照、mark price 计,用于申赎定价与轧差份额转移,是「认账」的那个;
- 展示 NAV(indicative)——给 Dashboard 用,可更高频、参考性质,不用来结算。
因此当用户申购某浮动收益率产品时，能获得的份额不是立刻通过展示NAV计算获得的，而是需事后完成当日结算后，由结算NAV计算获得。因此：用户购买产品时获得的份额是延迟知道的，详见3.9.5.
### 3.9.3 固定收益 vs 浮动:一个产品可能有两条 NAV 线
- 浮动 NAV 产品:对外单位 NAV 直接透传底层真实表现,涨跌用户自负。一个 NAV,简单。
- 固定收益产品:用户看到的对外 NAV 按固定 APR 确定性增长,与底层当天赚多赚少无关;但底层策略的真实 NAV 是浮动的。这中间的差额由劣后层吸收:底层超额→归劣后/平台,底层不足→先吃劣后金垫付。所以固定收益产品同时存在两条 NAV 线——「对用户 NAV」(确定的、APR 算出来的)与「底层真实 NAV」(浮动的),劣后夹在中间。
产品间转移策略份额,用的是「策略真实单位 NAV」,不是产品「对用户 NAV」。 轧差发生在策略层、认的是策略的真实价值;固定收益那层 APR 包装与劣后垫付,是叠在产品之上的另一层会计,跟策略层的份额转移是两回事,不能混着算。
### 3.9.4 NAV 与轧差的定序:T1 定价 → T2 轧差
NAV 与轧差之间藏着一个循环依赖:轧差要用 NAV,而 NAV 来自策略当前持仓,可轧差本身又会改变持仓。打破它的办法是把一天切成严格有序的两个时点,中间不交叉:
- T1 · 日终快照 + 定 NAV(认账,先发生):到结算时点,对所有 CEX 子账户 + Custody 余额做同一时点 mark 快照,聚合算出每个策略的结算单位 NAV。这个 NAV 基于「今天还没轧差、还没动任何仓位」的存量状态算出,认的是过去一天策略自己跑出来的真实损益,与今天的申赎无关;一旦定下,当天冻结不变。
- T2 · 用冻结的 NAV 做轧差 + 执行(后发生):拿 T1 冻结的单位 NAV,把各产品对每个策略的增减意图换算成份额、两池对冲、时间优先级出池、净残差下单。整个轧差过程只读 T1 的 NAV、不重算;即使净残差去 CEX 改变了持仓,那也是今天的动作,只反映到明天 T1 的下一次快照里,绝不回头改今天已冻结的 NAV。

于是整个流程:昨日存量 →(T1 快照)→ 今日结算 NAV(冻结)→(T2)→ 今日轧差与申赎按此 NAV 成交 → 产生今日新仓位 →(明日 T1 快照)→ 明日 NAV。 纪律只有一条:NAV 定价用「轧差前的存量状态」,轧差用「已冻结的 NAV」,当天进来的钱不参与当天 NAV 的计算,它们只是按这个 NAV 成交的对象。
 
![3.7.png](https://img.learnblockchain.cn/attachments/2026/06/8ULU9eWG6a3d1f5b848b0.png)
图 3.7 — 一天切成 T1 定价(认账并冻结)与 T2 轧差 / 执行两个严格有序的时点;当天进来的钱不参与当天 NAV 计算
### 3.9.5 申赎定价:浮动 NAV 产品必须前瞻定价
申赎按哪个 NAV 成交,有两个选项:历史定价(用昨日已公布 NAV,申购当场知道份额)与 前瞻定价(用当日 cutoff 后才算出的 NAV,申购时只知金额、份额待结算后回填)。
浮动 NAV 产品必须选前瞻定价,这不是体验问题、是会漏钱的硬漏洞: 若允许按昨日 NAV 申购,当白天底层大涨、而涨幅要到今晚 T1 才进 NAV 时,套利者可用昨日的旧价买入实际已增值的份额,当晚 NAV 一更新就白赚,这部分钱是从老持有人兜里稀释出来的(赎回侧反向同理)。这就是共同基金史上专门出过丑闻的 stale-price / late-trading 套利。
所以规则是:当日 cutoff(即 T1 快照时点)之前提交的申赎,统一按当日 T1 算出的 NAV 成交;cutoff 之后的顺延到下一日。申购提交时只定金额、份额于当晚 NAV 定出后回填;赎回对称(定份额、不定金额)。 前端须明确告知「按当日日终 NAV 成交,份额于结算后确认」。
前瞻定价只对浮动 NAV 产品是强制的。 T+0 稳定收益率产品没有套利窗口,可即时成交。
### 3.9.6 执行与定价解耦:没买完不影响已定的 NAV
另一种情况:某天用户买入特别大,当天 CEX 侧没把净残差买完(建仓池仍有剩余)。这不影响 NAV。
因为 NAV 在 T2 执行之前就已冻结(T1),执行成不成、成多少都改不了一个已定下的数。那笔「还没铺进 CEX」的现金没有消失,只是物理上还停在 Custody 策略钱包,是现金形态的策略资产——而策略 NAV 的口径本来就包含「还没 Mirror 出去的闲置现金」,这笔钱按现金 1:1 计入 NAV即可。
「没买完」改变的是策略资产的形态(现金 vs 已建仓位),不改变它的价值。 真正产生的差异不是 NAV 偏差,而是机会成本——这笔钱停在现金、没及时吃到 carry,少赚了,但没算错。处理规则:这部分(缺失的)收益由该策略全体持份产品按份额比例共担(现金不生息,NAV 里自然体现),不让某笔新申购单独承受或单独受益——一旦按 T1 NAV 成交,他就是普通持份人,与存量用户同担同享。
还要分清两种「没完成」的待遇:未完成的「买」是机会成本问题(可容忍,按现金计入 NAV);未完成的「卖/平仓」若撞上某笔到期日,才是风险问题,由 3.8.6 的 T-2 收敛兜底。 此外,若某策略净残差实在太大,合理做法是多日平滑铺仓(避免自己把 CEX 价格打坏),这期间那部分钱一直以现金计入 NAV、按比例共担机会成本——这与大额赎回要「有序平仓」是对称的:大额申购也该允许「有序建仓」,不强求当天铺满。
3.9.7 对外披露:产品 NAV 上链与可见性边界
产品对外的单位 NAV 需要上链,供链上 Vault 合约给申赎定价、给 LP Token 计值。后端按三层聚合在链下算出产品单位 NAV(日终 T1 那个),通过 Oracle 喂到合约里。Oracle 上链是成熟问题,选型、更新频率、防操纵延迟等引用业界常规做法即可,此处不展开;只需注意上链的仅是产品层 NAV,且它背后对应着 T1 那笔「更新 NAV」订单及其 Raw Data,因此链上拿到的 NAV 是可回溯到原始快照的状态,而非孤立的数。(Oracle 更新有延迟,但申赎本就按日终 T1 NAV 成交、节奏一致,只要 Oracle 在 T1 之后、下一交易窗口之前更新到位即可,不额外引入套利窗。)
与此相关的是一条可见性边界:对用户只展示产品层 NAV,策略层与子账户层 NAV 是内部账,默认不展示。 根本理由是:用户持有的 LP Token 在链上代表的是产品份额,他对策略没有任何链上凭证;策略 NAV、子账户持仓只是算出产品 NAV 的中间量,属于运营/风控视角。这与 3.1「用户只需理解产品」是同一条原则。
但是「不展示给用户」 ≠ 「不可验证」。 下两层 NAV 依然完整记在状态机里、依然可被审计方与 PoR 核验,只是默认不出现在散户 Dashboard 主界面上。对用户简化展示,对审计完全可验证,两者不冲突。大额/机构客户可按客户分层、可选地开放策略层视图。
### 3.9.8 收益分配与运营方利润
收入侧,浮动与固定两类的利润来源不同:
- 浮动 NAV 产品 → 显式收费。底层真实收益全额透传用户,平台不赚差价,利润来自:管理费(按 AUM 年化、从 NAV 每日计提)、业绩费/carry(对超额收益抽成,配 high-water mark,只对创新高部分抽)、以及赎回费/swing pricing(逼迫平仓的赎回者自担滑点,部分留存)。
- 固定收益产品 → 利差。用户拿固定 APR,底层真实收益超过 APR 承诺的部分归平台/劣后层(作为承担垫付风险的对价),底层不足时先吃劣后金垫付。平台赚的是「真实收益 − 固定 APR」的利差,代价是承担下方风险。
- 横跨两类:空窗期 DeFi 收益归平台。Earmarked 停 DeFi 赚的那层归平台,支撑低费率运营(2.2)。

再看成本侧,这些都计入运营成本:
- Custody 成本:托管费(按 AUM 年化 bp)+ 每笔划转/结算费——所以轧差减少物理调拨:少动钱 = 少付 Custody 转账费。
- CEX 成本:交易手续费、子账户/API 费——与 3.8.3 开平仓四层成本里的显性费用同源。
- 链上成本:Gas(申赎、NAV 上链 Oracle 更新、跨链桥)。
- 第三方服务:审计费、PoR 出具、Oracle 喂价、KYT/合规服务(3.2.3 兜底在 Custody 的合规检查也有成本)。
- 劣后/兑付风险准备:固定收益产品备劣后金,占用平台自有资金,是一项机会成本。
- 基础设施与人力:量化、风控、运维团队与系统。
用户在 Dashboard 上看到的是所有费用与成本计提后的净 NAV。
## 3.10 储备证明(PoR)与负债对账
PoR(Proof of Reserve)的目标是周期性地、可被独立审计校验地证明一个不等式:物理资产 ≥ 链上负债,且覆盖到每个产品。3.9 建立的三层 NAV 让这个不等式的两边都可计算。本节定义对账的两边、颗粒度、资产侧的穿透核验方式、固定收益的特殊处理,以及 PoR 能力的边界。
### 3.10.1 对账的两边:链上负债 vs 物理资产
- 链上负债侧 = Σ(用户持有 LP Token × 产品对外单位 NAV)。 这是产品在链上对用户的总兑付承诺。LP Token 总供给链上公开可查,对外单位 NAV 是 3.9.7 上链的那个值(日终 T1、Oracle 喂入),因此负债侧完全由链上数据算出,不依赖任何链下账本。
- 物理资产侧 = 3.9.1 自下而上聚合出的产品真实 NAV。 即「链上 Vault(备付金 + 待调出)+ Custody 产品钱包 + Σ_策略(产品持该策略份额 × 策略真实单位 NAV)+ Earmarked 停在 DeFi 的部分」,是产品名下散落在各物理位置的全部真实资产。

PoR 周期性核验的是:每个产品的物理资产侧 ≥ 它的链上负债侧。 两边 NAV 口径不同——负债侧用「对用户 NAV」(对固定收益是 APR 算出的承诺值),资产侧用「真实 NAV」(底层实际值);二者的差额由 3.10.4 的劣后层处理。
 
![3.8.png](https://img.learnblockchain.cn/attachments/2026/06/wqEDM5UP6a3d1f6aab41a.png)
图 3.8 — PoR 对账:按产品逐个核「物理资产 ≥ 链上负债」,资产侧穿透到子账户、抵押品只计一次
### 3.10.2 颗粒度:per 产品对齐,而非全局对齐
对账单元是单个产品,而非全局总量。这是 2.4「避免整体覆盖、局部亏空」在 PoR 上的落点:
- 对账要把同一产品散落在各处的资产——链上 Vault(备付金 + 待调出)、Custody 产品钱包、以及所持各策略份额对应的价值——按产品归并后整体核验,而非只看某一个地址的余额。
- 只有 per 产品对齐,才能暴露「产品 A 超额、产品 B 亏空、加总看着平」这种情形。全局对账会把局部亏空藏起来,而它恰是挪用最常见的形态:拆东墙补西墙。
- 隔离在 3.4 一直做到 CEX 子账户层,对账因此也能核到那一层。
### 3.10.3 资产侧的穿透核验:从子账户到产品
负债侧由链上公开数据算出,核验简单;难点在资产侧——它是三层聚合出来的数,审计方不能只接受平台上报的总数,需要逐层穿透验真。3.9.7 为此预留了钩子:策略 NAV、子账户 NAV 默认不展示给散户,但对审计方与 PoR 完整可验证。 资产侧的核验路径自下而上:
- 子账户层: 审计方以独立的 CEX 只读权限(或 Custody 出具、CEX 背书的持仓快照)直接读子账户真实持仓,核出子账户 NAV,不接受平台单方面报数。
- 策略层: 子账户 NAV 按策略归集,核出策略真实 NAV 与单位 NAV。
- 产品层: 按「产品持各策略份额 × 策略单位 NAV」加总,再加链上 Vault 与 Custody 产品钱包余额,得到产品真实 NAV——这才是与负债侧比对的数。
### 3.10.4 固定收益的覆盖率:对账线里要算进劣后
3.9.3 的两条 NAV 线使固定收益产品的对账不同于浮动产品:
- 浮动 NAV 产品: 对外 NAV 直接透传真实 NAV,两条线重合,对账即「真实资产 ≥ LP × 真实 NAV」,覆盖率围绕 1 波动属正常。
- 固定收益产品: 对用户负债按 APR 增长(确定),底层真实资产浮动,差额由劣后层吸收。其对账标准是 真实资产 + 劣后金 ≥ APR 负债——劣后金作为首损垫,必须计入覆盖率资产侧。
因此固定收益产品的 PoR 需同时报两个数:真实覆盖率(真实资产 ÷ APR 负债)反映劣后被消耗的程度;含劣后覆盖率((真实资产 + 劣后)÷ APR 负债)反映用户本金是否仍被覆盖。前者跌破 1 意味着开始吃劣后金,后者跌破 1 即 3.9.3 的「劣后吃穿临界点」——优先级用户本金开始受损、固定承诺被打破。这个临界点须在 PoR 报告中显式监控,并依 3.9.3 的要求事先向用户披露。
### 3.10.5 PoR 证明什么、不证明什么
**PoR 能证明**:在出证时点,Custody 签名背书的物理资产确实 ≥ 链上可独立计算的负债,且覆盖精细到每个产品。它把「平台是否挪用」从口头承诺,变成周期性、可被独立审计校验、且负债侧无需信任平台的数值结论。
**PoR 不能证明的**:
- 它依赖 Custody 签名诚信。 资产侧数据由 Custody 出具并签名,若 Custody 与平台合谋伪造持仓证明,PoR 同样显示健康。这是 PoR 的信任根,也是第四章「对 Custody 的信任」的来源。
- 它是时点快照,不是连续保证。 两次出证之间,资产可能被动过又补回。提高出证频率、引入实时 PoR 可缩小窗口,但无法消除。
- 它核「够不够」,不核「怎么来的」。 PoR 证明资产覆盖负债,但不证明资产来源合规。
PoR 的准确定位是:把信任从「相信平台自述未挪用」,收窄到「相信 Custody 签名 + 独立审计这一组外部背书」。 这是实实在在的收窄,而非归零;残留的信任根——Custody 是否合谋、运营层是否在快照间作弊——正是第五章用主权 Agent 进一步收窄的对象。
# 四、方案的边界:信任问题没有被完全消除
把上面所有的设计加起来:SPV、LP Token、Custody 隔离、Mirror、白名单、PoR、Delta 中性、劣后池、流动性断路器、分级 Dashboard、量化/风控/数据源三方权限分离 …… 本方案构建出一个相比传统 CeFi 安全得多的体系。但必须诚实承认:
本方案不能从根上消除信任问题,它只是把信任从「单点信任平台」分散到「信任一组相互制衡的角色」。
具体来说,残留的信任点包括:
- 对 Custody 的信任。 PoR 由 Custody 签名出具,如果 Custody 与平台合谋,理论上仍可能伪造证明。
- 对运营团队的信任。 资金调度模块、风控执行模块、API Key 管理 …… 这些链下系统的实际运行仍依赖运营团队的内控、密钥管理与多签治理。再严格的内控也不能 100% 排除「内贼」与重大误操作的可能。
- 对法律执行的信任。 SPV 架构在法理上保护用户,但实际清算过程仍依赖法院、清算人、法律体系正常运作。在极端司法环境下,这个保护未必能及时兑现。
- 对量化团队的信任。 Delta 监控可以发现偏离,但发现到处置之间仍有窗口;策略风格漂移、内部对敲等问题仍需事后追究。
- 对链上 KYT 缺失的容忍。 如 3.2.3 所述,链上 KYT 目前没有理想方案,本方案选择把这层兜底交给 Custody。这是已知缺陷。

换言之,本方案的安全模型是「N 方制衡 + 多重监控 + 法律兜底」。这对绝大多数普通用户而言已经足够;但对追求极致信任最小化的用户,特别是大型机构而言,仍存在「为什么我必须信任你的运营团队」这个根本性疑问。
# 五、主权 Agent + CeDeFi:把运营层从人手里拿走
第四章诚实地列出了五个残留信任点。本章给出收窄它们的方向——用「主权 Agent」接管运营层。主权 Agent 的定义和技术实现已在《主权 Agent》一文中完整展开;本章默认读者已读过该文,不再复述。
## 5.1 五个残留信任点的共同根源
第四章的五点里,「对 Custody 的信任」与「对法律执行的信任」是架构之外的两条物理 / 法律约束;剩下三点——对运营团队、对量化团队、对链上 KYT 兜底的信任——本质是同一个根源:运营层仍然由人持有密钥、做出决策。再严密的内控、多签与监控,落到底都是「请相信这组人不会作恶、也不会出大错」。主权 Agent 要做的,就是把这句话换成另一句:请相信一段任何单一方都签不动、部署后改不了、且每个决策都链上可审计的代码。这正是《主权 Agent》一文「把死的信任变活、却仍不可作恶」的范式落到本架构上的样子。
## 5.2 哪些角色交给 Agent,哪些保留(映射到第三章)
第三章把运营层拆成了几个各持独立 Key 的模块:资金调度(Custody 写 API)、量化下单(下单 Key)、风控强平(强平 Key)、数据汇入(只读 Key),以及内部状态机与后台。主权 Agent 不是去替换其中某一个模块,而是成为持有这些权限的执行体本身;各模块按风险等级,落到 Agent 的不同层:
- 资金调度 / Custody 写 → Agent 主账户级操作。 白名单地址直接写进 Soul，每一笔调拨都走门限签名 + 链上挂载 + 前置挑战延迟窗口。任何单一方——包括 Agent 的创立者——都无法把资金移出白名单。这正是 3.5 三把 Key 隔离想要、但「人持密钥」永远做不到的强度。
- 量化下单 → Agent 的 Skill 层 + 实例账户(高频小额)。 这与第三章「下单 Key 无提币权」天然吻合:量化策略(含可选的 LLM 辅助)只决定在白名单内怎么交易,判断出错最多是收益不佳,动不了金库——对应论文那句「LLM 出错 = 收益不佳,资金安全」。
- 风控强平 → Agent 的认知防火墙。 Delta、杠杆、敞口的阈值作为 Soul 红线,触发即由 Agent 自动平仓。它的失败模式是温和的:误判最多让仓位多等一个挑战期,而不会造成资金损失。是否再叠一层人类风控,见 5.4。
- 数据汇入 + 内部状态机 → Agent 的 Memory 与可审计留痕。 第三章「每笔订单对应 Raw Data、状态机可重放、Dashboard 全程可追溯」(2.4 / 3.7.1),与论文「每个决策附带链上证明、Merkle 批量锚定、任何人可独立审计」几乎是一一对应的同构——本架构的状态机,本就是为这种可审计性准备的底座。
## 5.3 逐条回应第四章的残留信任点
把第四章的五点放到这套接管关系下,逐条看它被收窄到什么程度——并诚实标出哪些只是收窄、哪些根本没动:
- 对运营团队的信任(基本消除)。 私钥以门限签名分布在可问责的共识网络,白名单写进不可篡改的 Soul,资金动作走前置挑战。「内贼挪用 / 跑路」在密码学层面被堵死,「重大误操作」被挑战窗口与账户分层封顶。这是 Agent 收益最大的一条。
- 对量化团队的信任(部分消除)。 下单纳入 Skill、参数边界由 Soul 强制、每笔动作链上留痕:越界与对敲要么被 Soul 当场拦下、要么留痕可追责。但策略本身设计得好不好、要不要漂移风格,仍是写 Skill 的人的判断——Agent 不替人做投资决策。
- 对链上 KYT 缺失的容忍(部分缓解)。 认知防火墙可以把资金来源与地址画像的检查嵌进执行环路(论文判断的是「行为合理」而非仅「语法正确」),比纯合约强;但 KYT 根上仍需外部身份与数据源,Agent 改善它、并不解决它。3.2.3 那个缺口依然在。
- 对 Custody 的信任(未消除)。 Agent 约束的是平台侧;但真实资产仍由第三方 Custody 物理保管,Agent 并不持有那把物理保管的钥匙。论文的多厂商 TEE、多托管能加固 Agent 自己的密钥,却不能保证 Custody 不与平台合谋。第四章列的这条边界,在这里原样保留。
- 对法律执行的信任(未消除)。 SPV 清算仍依赖法院与清算人。Agent 是算法层,不触及法律层。
## 5.4 主权 Agent 带来的新信任面,以及它消不掉的边界
必须同样诚实:Agent 不是把信任降到零,而是把它从「信运营团队」搬到一组更难合谋、且可验证的根上——TEE 厂商根、共识托管节点、证明系统。论文用多厂商纵深防御、定期 RA 轮换、挑战机制,以及未来的 FHE / ZKML 把这个根的风险压到很低;但它仍是一个信任假设,只是更小、更分散、可审计。再加上 5.3 里 Agent 也消不掉的两条——Custody 物理合谋与法律执行——本架构的诚实结论是:信任被大幅收窄,而非清零。
一个有意保留的人类环节:风控的否决权。让人类(或一个独立的风控 Agent)只能把系统推向更保守——强制平仓、暂停大额——而不能放松限额或解锁提币。它与论文账户分层「额度是密码学事实」叠加,是纵深而非冗余:任何一方失手,系统只会更安全,不会更危险。

一、问题的出发点:到底在解决什么问题

1.1 此处的 CeDeFi 是什么

本方案讨论的 CeDeFi,是一类特定的金融产品形态:

在链上向用户收集资金(USDC、BTC、ETH 等);
将这些资金通过受监管的托管机构(Custody)持有;
通过 Mirror(镜像)机制,把托管账户的资产作为额度,映射到中心化交易所(CEX);
由量化团队在 CEX 上执行 Delta 中性等策略,获取收益;
收益最终回流到链上,分配给持有产品凭证(LP Token)的用户。简而言之:链上募集负债,链下经营资产。

1.2 为什么要这样做

一个自然的反问是:既然资金来自链上,为什么不直接在链上(DeFi)跑策略?答案集中在三点:

链上深度不足。主流 DeFi 永续合约和期权市场的流动性、滑点、可承载规模,距离币安、Bybit、OKX 这种顶级 CEX 还差 1–2 个数量级。规模一旦上来,链上根本撑不住。
策略丰富度不足。跨所套利、基差套利、资金费率套利、做市等成熟的中性策略,绝大部分有效执行场所仍然在 CEX。链上能跑的策略集合是 CEX 的子集。
执行成本与速度。 Gas 费、出块时间、MEV 等因素让高频量化在链上几乎不可行。所以,CeDeFi 的本质是一个权衡:放弃链上的纯粹性,去换取链下的深度、丰富度和效率。

1.3 这种做法的核心问题:信任

一旦资金从链上转移到链下账户, 用户不再持有自己的资产,而是持有一份「平台承诺把这笔钱还给我」的凭证。于是问题不再是 DeFi 式的「智能合约会不会被黑」,而是 CeFi 式的:

平台会不会跑路?
平台会不会挪用资金去填别的坑?
平台破产时,我的钱算谁的?
我能在多大程度上验证「钱还在那里」?

1.4 一个关键观察:不同体量用户的敏感点完全不同

不同体量的用户,对风险的敏感点并不相同:

用户类型	最关心什么	对什么不敏感
小额用户（< $100K）	收益率、申赎便利、操作体验	底层法律结构、追索权细节
中额用户（$100K – $1M）	收益率、平台稳定性、PoR（Proof of Reserve）	复杂的合规结构
大额用户（> $1M，机构）	资金归属权、追索权、流动性、破产隔离	几个百分点的收益差异

简单说: 小钱看收益,大钱看安全。一个 1000 万美金的用户,最害怕的不是平台量化亏掉 5%(量化亏损有限),而是平台卷款跑路(损失 100%)。所以同一套产品,对小户要在收益和体验上做到位;对大户要在法律和物理隔离上做到位。这是后文里很多分层设计的源头。

二、设计这个系统最需要考虑的几件事

把第一部分的问题翻译成设计目标,本方案围绕以下四个维度展开:

2.1 信任与安全性的构建(最重要)

信任不是一个单一的东西,它由三层独立的保障叠加而成。任何一层缺失,整体信任都会塌掉。

第一层:法理上的安全性 回答的问题:「如果平台明天倒闭,我的钱在法律上是谁的?」核心手段:

SPV / SPC 架构。将理财业务装入独立的法律实体(独立投资组合公司)。用户的钱在法律上不是平台的资产,而是 SPV 受托管理的资产。平台破产时,这部分资金不会进入清算财产池。
LP Token 作为参与股份凭证。链上 LP Token 在法律上对应 SPV 下的 Participating Shares。用户持有 LP Token = 持有对底层资产的法律追索权,可以绕过平台直接向清算人主张权益。
可选:用户自有账户模式。对超大型机构客户,允许其使用自有的 Custody 与 CEX 账户,平台仅获得 API 操作权限。这种模式下,资金物理上从未离开过客户的账户。

第二层:资金流转与操作上的安全性 回答的问题:「就算法理上钱是我的,我怎么知道钱物理上确实还在?怎么知道平台没在挪用?」核心手段:

资金不离开 Custody。用户资金始终存放在受监管的第三方托管机构。CEX 上跑量化用的不是真资产,而是通过 Mirror 机制映射出来的「交易额度」。即便 CEX 倒闭(FTX 重演),本金依然安全地躺在 Custody 的隔离账户里。
白名单锁死资金路径。所有划转目的地都是白名单地址:「Custody 充值地址 — 理财合约 — Mirror 到指定 CEX 子账户 — 回流到指定地址」。资产无法流向白名单之外的任何钱包。
权限三方分离。同一个 CEX 子账户上,量化团队、风控团队、Dashboard 数据源各持一把不同权限的 Key — 量化只有下单权限、风控只有强平权限、数据源只有只读权限。任何一方丢失 Key 都不会导致资金被提走。
Proof of Reserve(PoR)+ 第三方审计。由 Custody 周期性出具签名的资产证明,由独立审计机构定期校验「物理资产 ≥ 链上负债」。负债数据来自链上(透明可查),资产数据来自托管(可由 Custody 背书)。两边对齐即可证明平台未挪用。
操作透明的 Dashboard。用户实时看到:自己的资金在哪个产品、产品投向了哪些策略、策略目前的 NAV 是多少、覆盖率是多少。把所有「黑盒」摊开。

第三层:资金本身的安全性 回答的问题:「就算钱没被挪用,量化策略本身会不会把钱亏没?」核心手段:

Delta 中性策略。策略收益与市场涨跌无关。无论 BTC 涨还是跌,策略目标都是稳定输出收益,从根本上消除了方向性敞口。系统实时监控 Delta 值,超过阈值即报警并冻结资金拨付,防止量化团队偷偷加方向性赌注。
劣后资金(Junior Tranche)。平台自有资金(或愿意承担风险的用户提供的劣后资金)作为「首损层」。策略亏损先吃劣后金,吃完之后才会触及用户本金。对固定收益产品来说,这是一个直接的安全垫。
流动性安全。通过 T+N 赎回期、单日赎回上限(Daily Cap)、紧急熔断等机制,避免挤兑导致的强制平仓与滑点损失。

2.2 资金效率

仅有安全是不够的。如果资金大部分时间在闲置,产品收益率撑不起来。资金效率的构建主要靠两点: 收益叠加(Yield Stacking) 典型例子:美债增强产品。

用户存入 USDC;
USDC 在链上购买代币化美债(吃到 ~4–5% 的国债收益);
代币化美债托管至 Custody;
Custody 把美债作为抵押品,Mirror 到 CEX,生成保证金额度;
CEX 上用这部分额度跑 Delta 中性量化(再吃一层收益)。最终用户拿到的是「国债收益 + 量化收益」的叠加。这是 CeDeFi 相对纯链上 DeFi 的关键优势之一:可以同时利用链上 RWA 和链下交易场所。 约束条件:

通常要求 USD 本位(因为美债是 USD 计价);
依赖 Custody + CEX 的特定支持组合(例如 ByCustody + Bybit);
需要确保 Mirror 的法律和操作链路稳健。

每日轧差与空闲资金管理

每日申赎轧差。如果某天有人存 100W,有人取 80W,物理层面那 80W 根本不动,直接内部抵销。仅 20W 净额发起真实的物理调拨。这大幅降低了 Custody 转账成本、Gas 与滑点。
跨产品流动性调度。在所有产品间统一调度流动性。A 产品净流出、B 产品净流入时,物理资金可以在内部轧账,不必都走外部。
空窗期资金套利。赎回锁定期内、轧差残留的资金会有几天到几周的空窗,自动路由到链上蓝筹 DeFi(Aave / 代币化货币基金)赚取额外收益。这部分收益归平台所有,是支持低费率运营的来源之一。

2.3 产品多样性与可组合性

一个能长期跑下去的理财平台,必须提供足够丰富的产品矩阵,让不同风险偏好、不同资金体量、不同币种偏好的用户都能找到合适的标的:

收益类型维度: 固定收益(适合保守用户和机构) vs. 浮动 NAV(适合愿意承担波动博取超额的用户)。
期限维度: 活期 T+0 / 短期 T+7 / 长期 T+30+,分别匹配不同流动性需求。
币种维度: USD 本位(最容易接 RWA)/ BTC 本位 / ETH 本位。
底层映射维度: 直接映射单一策略 vs. 包装多策略组合产品。允许第三方在底层产品之上做二次包装。

这部分不是核心安全考量,但对产品的商业成立至关重要。

2.4 可验证的透明度

透明度本身就是一种安全机制。即使前面三层安全都做了,如果用户没法验证,对用户来说就等于没做。所以本方案把透明度作为一个独立维度:

链上侧的负债数据天然透明(产品合约、LP Token 余额公开可查);
链下侧的资产数据通过 PoR + 审计周期性公开;
两者通过精细到「每个产品」的颗粒度对齐,避免「整体覆盖、局部亏空」的情况。

三、方案设计

3.1 三层抽象:用户 → 产品 → 策略

系统在产品端有三层抽象:

用户层: 用户持有 LP Token,代表对某个产品的份额与法律追索权。用户只看到产品 —— APY、起息期、赎回期、风险等级 —— 不需要知道底下的策略细节。
产品层: 一个理财产品(Vault)是一个标准化的合约模板,带一组确定的参数(币种、收益类型、起息/赎回规则、容量上限、是否含劣后等)。一个产品在底层可以购买多个策略,按预设权重分配资金(例如:产品 A = 40% 跨所套利 + 60% Delta 中性)。
策略层: 一个策略是一种具体的盈利模式 —— 跨所套利、基差套利、Delta 中性、做市等。策略是抽象的,它最终表现在一组 CEX 子账户上:同一个策略往往会同时运行在多个 CEX 的多个子账户里(例如跨所套利天然就是多账户协作)。

这三层是「多对多」的关系: 一个产品可以买多个策略;一个策略可以服务多个产品;一个策略运行在多个 CEX 子账户上;一个 CEX 可以同时承载多个策略。这套抽象的好处在于:

用户视角简单 —— 只需理解产品。
策略可复用 —— 同一个策略可以被多个产品按不同权重组合。
资金可分组核算 —— 任何时点都能精确算出「某产品在某策略上有多少钱」。
风控可分层施加 —— 既可以在策略层(限仓位、限杠杆),也可以在子账户层(强平、提币锁死)。

整个系统的存入资金流如下图所示。它以「Vault A(稳健活期)」为代表,完整展示了用户存入 → 链上合约 → Custody → CEX → 量化/风控/Dashboard 这整条链路。

3.1.png 图 3.1 — 存入资金流:产品 → 策略 → CEX 子账户三层映射,以及量化/风控/Dashboard 三方权限分离下面分层展开。

3.2 链上层:理财合约矩阵

链上层是用户能直接验证的部分,也是法律凭证(LP Token)的发行地。所有产品作为独立的 Vault 合约部署在用户资金所在的链上 —— Solana / Ethereum / BSC / 等等。

3.2.1 Vault 合约的内部组成

以 Vault A(稳健活期)为例,合约内部由三部分组成:

备付金子区(10% AUM): 留在合约内的链上储备金,专用于 T+0 即时赎回。用户 burn LP Token 后,资金直接从这个子区转账给用户,不经过 Custody、不调用任何 API、交易内到账。这是「链上备付金」的关键意义所在 —— 把它放在合约里而非 Custody 里,才能真正实现即时赎回。
待调出资金子区(90% AUM): 等待被调拨到 Custody 的资金。这里的关键约束是:目的地址在合约里写死(白名单),只能转到 Custody 的指定接入钱包,无法转去任何其他地址。即使后端被入侵,资金也只能在白名单内流动。
账本子区: 维护每个用户的 LP Token 持仓、累计本金、累计收益,以及产品的整体 NAV、APY。这部分数据完全在链上,任何人都可以独立验证「我应得多少钱」。

3.2.2 产品矩阵与可组合性

Vault A 只是一个产品。系统支持同时部署多种产品,以匹配不同用户需求:

Vault B(美债增强):USDC 本位,固定 APR,T+7 赎回,KYC 准入,面向机构。
Vault C(BTC 进取):BTC 本位,浮动 NAV,T+14 赎回,含劣后层,面向 Web3 用户。
……以及更多。

更重要的是,这些 Vault 是可组合的 —— 第三方可以部署一个「组合 Vault」,在合约层面同时申购 Vault A 和 Vault B,按自定义权重提供新的产品形态。这是相对传统 CeFi 平台的一个关键优势:产品本身是开放可组合的链上原语。

3.2.3 一个尚未解决的问题:链上 KYT

一个诚实的承认:如何在链上做 KYT(Know Your Transaction,反洗钱链上检查)目前还没有理想方案。可选项与各自的问题:

合约调用链上 KYT Oracle(如 Chainalysis Oracle、TRM): deposit 时静态调用 oracle,黑名单地址直接 revert。问题:oracle 数据滞后、覆盖不全;Oracle 自身是中心化的,且本身就是一个新的攻击面。
链下监控 + 黑名单同步: 监控到黑名单后由管理员推送到合约里。问题:这回到了「信任管理员」的老路。
把 KYT 推迟到 Custody 侧: 资金到达 Custody 接入钱包时,由 Custody 履行其合规义务做 KYT。问题:钱已经进合约再查没有意义,资金已经混入了产品池。

在更好的方案出来之前,本方案的现实选择是:链上层暂不做 KYT,依靠 Custody 侧的合规检查兜底。这是一个公开承认的缺陷,留待后续方案改进(包括第五章提到的主权 Agent 方向)。

3.3 Custody 层:接入钱包 + 统一映射源

Custody(Ceffu / Copper / Cactus / ByCustody 等)是物理持有用户资产的受监管第三方。所有用户资金的实际存储位置都在这里,CEX 上跑的只是通过 Mirror 映射出来的「交易额度」。 Custody 在系统中分两层:

3.3.1 第一层:产品接入钱包

每个产品在 Custody 内有一个单一接入钱包,作为合约白名单写死的归集地址。这个地址承担的角色:

唯一接收来自链上 Vault 合约的资金。
作为产品级资产隔离的最小单元 —— 不同产品的资金,在 Custody 内严格分开。

3.3.2 第二层:统一映射源(按策略组织)

接入钱包归集的资金,在 Custody 内部进入「统一映射源」—— 一个按策略组织的资金池子。注意:这里的「统一映射源」是个示意概念,实际实现取决于 Custody 厂商。例如:

Ceffu 要求 1:1 映射:一个 Ceffu 钱包对应一个 Binance 子账户。
Copper 允许一个统一映射源同时映射到多家 CEX 的多个子账户。

无论物理实现是哪种,逻辑上都可以表达成:接入钱包的资金,按策略分组,每个策略对应一组 Mirror 目标(CEX 子账户)。比如产品 A 的资金:

40% 进入「策略 #1:跨所套利」资金池 → Mirror 到 Bybit 子-1、OKX 子-1 等多个子账户;
60% 进入「策略 #2:Delta 中性」资金池 → Mirror 到 Bybit 子-2、OKX 子-2、Binance 子-1 等。

策略层是这套结构的核心 —— 它把「资金归类」和「具体子账户」解耦,既让同一策略可以分布在多 CEX 多子账户(分散风险、增加深度),又让 NAV 计算时能按策略聚合(不必关心物理子账户级别)。

3.4 CEX 层:多家交易所、多个子账户

最底层是各家 CEX —— Bybit、OKX、Binance 等。资金不在这里,只有「Mirror 出来的交易额度」在这里。 CEX 层的关键设计:

无法直接提币，只能Mirror。CEX的子账户资金是通过Custody Mirror过来的，无法直接提币，必须结算回Custody (包括本金和收益)。
一个子账户运行一种策略。不在同一个子账户里混跑多种策略,便于风险归因和 Delta 监控。
一个策略分布在多个子账户。例如跨所套利天然就是多账户协作 —— Bybit 子-1、OKX 子-1 同时存在头寸。Delta 中性策略也常分散在多家 CEX 提高深度与抗冲击能力。

3.5 三个外部角色与权限隔离

CEX 子账户上同时存在三方角色,每方持一把不同权限的 API Key。这是整个系统「权限三分」的核心机制 —— 也是回答「为什么资金能放心交给量化团队跑策略」的关键。

3.5.1 量化团队 — 下单 Key

权限:在子账户内下单、撤单、调仓。
没有:提币权限、调拨资金权限。
职责:运行各类策略,产生收益。

即使量化团队的 Key 被攻击者拿到,攻击者最多能在子账户内胡乱交易造成有限损失,但无法把钱提走,也无法触发资金调度。

3.5.2 风控团队 — 强平 Key

权限:强制平仓、撤单。
没有:开仓权限、提币权限。
职责:独立监控每个子账户的 Delta、杠杆率、风险敞口,异常时强制清仓止损。

风控 Key 与下单 Key 严格分离,意味着量化和风控形成互相制衡的关系 —— 量化能开仓,但风控能在必要时把仓位关掉。这是防止「量化团队偷偷加方向性赌注」的核心机制。

3.5.3 Dashboard 数据源 — 只读 Key

权限:只读 —— 抓取持仓、NAV、订单等数据。
没有:任何写权限。
职责:把 CEX 数据写入后端数据仓库,后端按策略聚合算出产品 NAV,然后输出给用户 Dashboard。

Dashboard 数据源使用独立的只读 Key,确保:即使所有写权限 Key(下单、强平、Custody 调拨)都失效,展示给用户的数据通道依然完整;用户看到的资产数据来自 CEX 直出,中间经过的只是「读取 + 聚合」,没有任何方有篡改空间。

3.5.4 隐含的第四方:资金调度模块

除了上面三方,还有一个隐含角色 —— 资金调度模块。它持有 Custody 的写 API,负责发起 Custody 内部和跨 Custody 的资金调拨，以及将资金Delegate/Undelegate到CEX子账户。这个模块完全独立于量化和风控,且只能在合约白名单 + Custody 白名单的双重约束内调拨,无法转出系统。综合起来,系统中触及资金的所有权限被分散到了四个独立的密钥持有者:

角色	Key 权限	若 Key 丢失最坏情况
量化团队	下单 / 撤单（CEX 子账户）	子账户内恶意交易，造成有限亏损
风控团队	强平 / 撤单（CEX 子账户）	子账户被恶意强平，但无法转出资金
Dashboard 数据源	只读（CEX 子账户）	数据展示中断，资金不受影响
资金调度模块	写 API（Custody）	仅能在白名单内调拨资金，无法将资金转出系统

没有任何单一密钥或单一模块可以独立把资金提走。这是本方案在「操作安全」维度上的核心保障。

3.6 赎回资金流:两个订单的解耦

3.6.1 一个澄清:T+0 活期产品没有真正的「赎回流程」

T+0 活期产品(Vault A)的设计前提就是:用 10% AUM 的备付金覆盖所有日常的小额即时赎回需求。用户 burn LP Token 后,资金直接从合约内的备付金子区转账给用户,交易内到账,完全不触发 Custody / CEX 的任何动作。换句话说,T+0 产品的「赎回」就是合约内部的一笔转账,没有需要画出来的完整流程。备付金水位被消耗后,后端通过日常调度从「待调出资金子区」或「策略层回款」补足备付金,这部分是周期性的运维动作,不在每次赎回的触发链路上。真正需要走完整链路的,是有赎回等待期的产品 —— T+7、T+14 等。它们的设计前提就是:用户的钱大部分时间在策略层跑收益,赎回时需要把钱从策略层一路回流。下面以 Vault A(T+7) 为例展开。

3.6.2 两个订单:用户视角 vs. 系统视角

理解赎回流程的关键,是认识到这里其实存在两个独立的订单,它们在生命周期、发起方、完成条件上都不相同:

订单 A — 用户 → 产品的赎回订单。由用户在链上发起(burn LP Token,进入赎回队列),T+7 后用户领回本金 + 收益时订单完成。这是用户视角能感知到的唯一订单,中间过程对用户透明。
订单 B — 产品 → 策略的平仓订单。由后端在日终轧差后发起,按各策略权重分配净流出金额,通知策略层平仓;策略层在自己负责的 CEX 子账户上平仓、Undelegate 资金回到策略钱包,再把资金打回产品钱包,订单 B 完成。这是系统内部的订单,用户看不到。

两个订单解耦的好处在于:用户的赎回承诺(T+7)和系统内部的资金调度节奏(每日轧差后批量处理)是分离的。后端可以按效率最高的节奏处理订单 B,而不必为每一次用户赎回都立即触发一次 CEX 平仓。

3.6.3 「产品」和「策略」是账本概念,资金在物理钱包里流动

3.1 节已说明,产品和策略是三层抽象中的两层。其中一处容易混淆:「产品」和「策略」本质上是账本概念,资金真正的物理位置在不同的钱包里。

产品的钱,物理上分布在两处: 链上 Vault 合约(备付金 + 待调出资金) + Custody 里的产品钱包(单一归集地址)。但这只是产品直接持有的现金部分——产品的大部分价值,是它投进各策略的份额(物理上落在下面「策略的钱」那两处:策略钱包 + CEX 子账户),以及为按期兑付而暂时停在链上 DeFi 的待兑付资金(Earmarked)。产品的全部物理资产 = 这两处现金 + 所持各策略份额对应的价值 + 停在 DeFi 的部分,合起来覆盖该产品在链上发行的全部 LP Token 负债(完整聚合口径见 3.9.1)。
策略的钱,物理上也分布在两处: Custody 里的策略钱包(统一映射源里属于该策略的部分) + CEX 子账户里的 Mirror 额度。这两处加起来,就是该策略对应的全部物理资产 —— 而它的「负债」是各个产品在账本上记录的「我对这个策略投了多少份」。

这个区分非常重要,因为它解释了赎回时资金为什么要在几个钱包之间流动:CEX 子账户 → 策略钱包 → 产品钱包 → 链上 Vault → 用户。每一步都是真实的钱包到钱包的转账,因为「产品」和「策略」在账本上有明确的资产归属,资金必须跟着账本归属流动。

3.6.4 资金流 vs. 控制流

下面这张图解释了赎回流程，它同时承载了两类不同性质的流:

资金流(实线): 钱包到钱包的真实转账,发生在 Custody / CEX 体系内。
控制流(虚线): 后端发出的订单和指令。后端本身不在 Custody / CEX 体系内,它在外部,通过 API 调用驱动资金动作。具体来说:资金调度模块(持 Custody 写 API)发起钱包间划转,量化模块(持 CEX 下单 Key)发起 CEX 子账户上的平仓。

把这两类流分开看,能更清楚地理解每一步动作的发起方和性质 —— 哪些是真正的资产位移,哪些只是后端在指挥位移。

3.2.png 图 3.2 — 赎回资金流(以 Vault A T+7 为例):资金流走钱包,控制流由外部后端发起;两个订单(用户→产品、产品→策略)解耦

3.6.5 完整链路:七步走完

把上面所有的概念合到一起,赎回的完整链路是:

① 用户 burn LP Token,进入赎回队列。链上动作,锁定 LP Token,开始 T+7 计时。这是订单 A 的发起。
② 后端日终轧差后,发出平仓订单(订单 B)。后端聚合当天的申购和赎回,做产品内轧差,得出该产品的净流出量。按各策略的权重分配净额,向相关策略发出平仓订单。策略内再次轧差，如果策略内部轧差后其当天净流入,则无需发起平仓订单。
③ 策略接到订单,按各子账户的持仓比例下平仓指令。例如策略 #2 同时跑在 Bybit 子-2、OKX 子-2、Binance 子-1,策略层会按预定比例分配平仓量。实际执行由后端量化模块通过 CEX 下单 Key 完成。
④ CEX 平仓完成,Undelegate 资金回到 Custody 的策略钱包。这是第一段真实的资金位移 —— Mirror 额度被销毁,对应的资金从 CEX 子账户回流到 Custody 的策略钱包。
⑤ 策略钱包 → 产品钱包(Custody 内部划转)。这是 Custody 内的钱包间转账,由资金调度模块通过 Custody 写 API 发起。划转金额对应该产品在该策略中应得的份额。订单 B 在这一步完成。
⑥ 产品钱包通过专用接口注入资金回链上 Vault。 Custody 的产品钱包配置了链上 Vault 合约地址作为白名单出口,通过专用接口把资金注入回链上(对应存入流程里「链上 → Custody」的反向操作)。资金到达 Vault A 后,合约准备兑付给到期用户。
⑦ T+7 到期,用户 claim 本金 + 收益,订单 A 完成。用户在链上发起领取,合约把资金从 Vault 转回用户钱包,LP Token 被销毁。

3.6.6 日终轧差:为什么不每次赎回都立即触发平仓

订单 B 的发起时机不是「用户一发起赎回就立刻触发」,而是「每日日终轧差之后,按净额触发」。原因是:

产品内轧差: 同一个产品当天可能既有人申购、又有人赎回。如果当天净流入,则不仅不需要平仓,反而需要新增建仓;如果当天净流出小于产品备付金水位的可调节范围,有时也无需触发底层平仓。
策略内轧差: 产品的建仓/平仓请求需要发送到对应的策略。如果某策略内产品 A 当天要求平仓100 万、

产品 B 当天要求建仓80 万,策略可以在内部完成轧差结算,只对剩下 20 万净额触发实际平仓。这能大幅减少 CEX 平仓的频次和摩擦成本(建仓/平仓成本和风险)。轧差机制本身的细节(优先级、跨产品兼容性判断、跨策略调配规则等)比较复杂,完整方案见 3.8 流动性管理;图中以底部黄色注释的方式提示其存在。

3.7 控制流与数据流

3.1–3.6 讲清了系统的静态结构和两个方向的资金流。这一节回答最后一个问题:外部后端是如何驱动整个系统的?核心有两点——其一,后端把三方原始数据整理成一个内部数据库,而这个数据库的本质是一个状态机;其二,后端对外只做两件事:单向读数据、单向发指令,且任何资金动作都必须经过相互隔离的写权限模块、锁死在白名单内。

3.7.1 内部数据库的本质:一个状态机

后端持有两把 Key(Custody 只读、CEX 只读),把链上合约、Custody、CEX 三方的原始数据(Raw Data)持续抓取进来,清洗整合后写入核心数据库。这个数据库不是一堆零散的表,它的核心可以抽象成一个状态机:由三部分构成——状态(State)、订单(Transactions)、以及状态转移函数 F(n)。State 是系统在某一时点的快照,Transactions 是发生过的所有动作,F(n) 描述「一笔订单如何把 State N 变成 State N+1」。 State 在三层抽象上各有自己的内容:

客户状态:持有哪些产品、各产品份额、累计收益、当前订单。
产品状态:AUM、准备金、NAV、收益率,以及持有每个策略多少份额、每个用户的持有情况。
策略状态:单位 NAV、份额、运行在哪些 CEX 的哪些子账户、被哪些产品持有及持有多少。

订单(Transactions)分两层,与三层抽象对应:

客户侧<->产品侧(用户买入 / 卖出产品、产品 APR 变化)
产品侧<->策略侧(产品买入 / 卖出策略、更新单位 NAV)。

这个状态机有一个关键性质:订单最终都对应着真实的 Raw Data。每一笔订单都能在链上、Custody 或 CEX 的原始数据里找到可验证的支撑;因此由订单推导出来的状态也就有了数据支撑,最终对外披露的所有 Dashboard 数据都是可追溯、可验证的。这正是 2.4 节所说「可验证的透明度」的技术落点。

3.3.png 图 3.3 — 系统的状态机抽象:订单(Transactions)驱动状态(State)转移;每笔订单都对应可验证的 Raw Data,因此状态与 Dashboard 全程可追溯

3.7.2 控制流 vs. 数据流:后端如何驱动系统

把后端放进整张图里看,它对外只有两类箭头:实线的数据流和虚线的控制流,二者方向相反、严格分离。

数据流(实线,单向流入):三方原始数据汇入数据库后台服务,经数据整合处理写入核心数据库;核心数据库再通过只读接口对外披露给运营 / 风控团队和用户 Dashboard。其中 NAV 的计算路径是:先据各 CEX 子账户的 NAV 统计出策略 NAV,再按「产品 × 策略」的权重加总得到产品 NAV。
控制流(虚线,单向流出):后端经三个相互隔离、各持一把写权限的执行模块对外发指令: ◦ 量化执行模块(下单 Key)在 CEX 子账户内下单 / 撤单 / 平仓; ◦ 风控执行模块(强平 Key)在异常时一键平仓; ◦ 资金调配模块(Custody 写 API)在各 Custody 之间转账、做 Mirror / 结算。后端的「后台服务」本身是一个管理后台,不在 Custody / CEX 体系内。它内部包含角色与权限管理、配置管理(产品 / 策略 / Custody / CEX 配置)、订单管理(客户 / 产品 / 策略三层)、KEY 管理(只读 Key),以及上面说的数据库后台服务。它只读外部数据、只在白名单内发指令。几个权限设计要点:
四把 Key 严格隔离。下单(量化)、强平(风控)、只读(数据汇入)、Custody 写(调配)分属不同模块,任何一把 Key 泄露都不足以把资产转走。
风控是独立模块。它不接受编排层的指令,自己监控 Delta / 杠杆 / 限额 / 敞口,触发阈值即自动强制平仓——与下单权限彻底分离,因此图中没有「后端 → 风控」的触发线。
量化 → 资金调配。当量化需要在 CEX 子账户之间挪动资金时,由量化向资金调配模块发出请求,由后者执行;量化自身不持有Custody相关权限。
资金调配只动 Custody。它在合约 + Custody 双重白名单内做钱包间划转,目的地写死,不直接连 CEX。

3.4.png

3.8 流动性管理

本节解决一个贯穿全局的问题:在「既要保证按期兑付、又要尽量少动底层策略」这对矛盾下,资金应该怎么调度。先探讨产品的资金池：所有资金分成两个互斥的池子,并约定一条不变量:

运营现金池(Unassigned):新流入、轧差残差、尚未指派给任何到期负债的钱。可参与轧差、可投入链上 DeFi 做机会性增益。
兑付储备池(Earmarked):已为某笔到期赎回锁定的钱(含为兑付而临时停在 DeFi 的部分)。只认到期日,不参与再次轧差。

不变量:任何一笔资金一旦从 Unassigned 进入 Earmarked,就退出轧差引擎的可用范围,直到它兑付完成。这条不变量是整套流动性方案的安全核心——下文「跨时间轧差不依赖未来流入」「DeFi 里的钱不能再轧差」「了结即出池」都是它的不同侧面。

3.8.1 两类产品,两套流动性策略

流动性管理的起点,是 T+0 活期产品与 T+N 定期产品有本质不同的流动性形态:

T+0 活期产品:留备付金,牺牲一部分资金利用率换即时性。用户随时可赎,所以必须在金库里留一笔随时可动的现金(备付金),代价是这部分钱不在策略层吃满收益。
T+N 定期产品:不留备付金,全额投入策略,只需在到期日前把钱备齐。用户的钱在锁定期内全程在策略层跑收益,资金利用率接近 100%;赎回是一个有确定到期日的负债,系统只要保证「到期那天 Vault 里有那么多钱」即可。

这两套形态对应两套机制:备付金的水位管理(3.8.2),和定期负债的到期兑付调度(3.8.5–3.8.7)。

3.8.2 T+0 备付金:目标水位 + 容差带

备付金管理采用「目标水位 + 容差带」模型,这是现金管理的标准做法。例如:目标水位 20% AUM,容差带 [10%, 30%];现金升破 30% 说明闲置太多,应择机买入策略;跌破 10% 说明缓冲不足,应回补到目标。但有四点必须细化,否则会踩到 3.8.3 说的 churn 陷阱:

容差带是「触发关注」的信号,不是「立即执行」的命令。不要一碰到带边就单独发一笔开/平仓——那恰好制造了本方案要避免的频繁开平仓。正确做法是:带只决定「今天这个产品净需要调多少现金」,真正的买卖金额放进当日策略层轧差(3.8.4),与别的产品的反向流动先内部抵销,只对净额动底层。
上下越界的紧迫性不对称。越上界(现金太多)是「好问题」,不急,顺着当日轧差慢慢调出去;越下界(现金不足)才是「硬问题」,且回补来源有优先级:先动停在链上 DeFi 的暖层(秒级~分钟级,见 3.8.7)→ 再走当日轧差里的策略平仓 → 只有极端情况才盘中强制平仓。
水位数值应由数据校准,而非拍死。合理水位取决于该产品每日净流出的分布:大致要能覆盖历史 95–99 分位的多日累计净流出,再叠加单日赎回上限(3.8.8)。波动剧烈期可临时调高。10/20/30 是合理的初始默认值。
容差带宽度本身是个权衡。带越宽,触发越少、churn 越低,但闲置现金拖累(drag)越大;带越窄反之。用净流出分布去调这个宽度。

备付金内部还可再分两层以兼顾「毫秒级」承诺:热层(真正留在合约里、毫秒到账,覆盖日常小额)+ 暖层(停在可即时赎回的链上 DeFi,覆盖容差带的缓冲部分,秒级~分钟级动用)。3.2.1 说的「备付金放合约里才能即时赎回」指的是热层。

3.8.3 少动底层的理由:开平仓的真实成本

本节所有机制的共同目标只有一个:让申赎运维尽可能不额外触发底层开平仓。原因在于,频繁开平仓会从四个层面侵蚀收益:

显性交易成本:taker 手续费 + 买卖价差。Delta 中性/基差类策略通常是多腿(现货+永续),一次完整往返要付多次费。
滑点 / 市场冲击:这是大额平仓的主成本,且随规模超线性放大。小额无所谓,大额平仓会自己把价格打坏。
carry 中断(最隐蔽、最重要):Delta 中性的收益本质是持续持有仓位换来的 carry。为了腾现金平掉仓位,等于主动关掉收益引擎;过几天再开,市场给的收益率档位可能已经变差。
再入场时点风险:平了再开,入场点位未必比原来好,还要再付一次手续费和滑点。关于 carry 中断有两种情况:
资金费是离散事件,不是连续累积。永续合约的资金费在固定结算时点(通常每 8 小时)按那一刻的瞬时费率一次性结算——只有结算时点持有仓位的人才收/付一次款。决定单次资金费正负与大小的,是结算时点的瞬时费率,不是这 8 小时的平均。它的「时间属性」体现在频次上:持有的周期越多、经历的结算次数越多,期望上累积越多。
基差是随时间连续收敛的。期货/现货基差随到期临近向 0 收敛,这个收敛是时间的连续函数,持有越久吃到越多,不依赖某个离散结算时点。

3.8.4 轧差按层发生:产品内申赎轧差 + 策略内份额轧差,跨策略不能轧

轧差不是只发生在某一层,而是在每一层按该层的「同质单位」各做一次;跨策略之间无法轧差。

产品内申赎轧差(产品层): 同一产品当天的申购与赎回,是同一产品、同一 NAV 下的同质份额,可以直接对冲——赎回方支取的现金由申购方补上,这部分无需触及底层策略。产品对外报出的「当日净流入 / 净流出」即这一步轧差之后的净额,而非申赎的原始总量。
策略内份额轧差(策略层): 产品的净流量按权重拆成「对各策略的份额增减意图」后,同一策略上一个产品的增持与另一个产品的减持,是策略单位 NAV 下的同质份额,可零 churn 对冲(份额换手、底层仓位不动)。这是 3.8.5 展开的两池对冲。
跨策略无法轧差: 不同策略各有自己的单位 NAV,产品对每个策略的目标持仓也不同,两者的份额不是同质物,彼此之间没有可对冲的对象。产品 A 卖策略 S1、产品 B 买策略 S2,在物理上是 S1 平仓、S2 开仓两个无关动作,强行配对只是现金在账户之间搬动——顶多省一次 Custody 转账,carry 与 churn 均无节省。

层级关系因此是:

产品层:先做产品内申赎轧差,再拆意图。第一步把当天的申购与赎回对冲,得出对外净流量;第二步把净流量按权重拆成「对每个策略的份额增减意图」下发;第三步管理自己尚未到提款期的资金(投入 DeFi 吃息,见 3.8.7)。产品层的轧差止于「同一产品的申赎对冲」,不具备份额级、跨产品的对冲能力。
策略层:做份额级轧差,每个策略各自独立进行。策略 S 收齐所有产品对它的增 / 减意图,在内部对冲买卖,内部消化的是零 churn 的份额换手;仅净残差去其 CEX 子账户真实开 / 平仓,完成后将结果(成交价、份额变动、现金收付)返回产品层,产品层据此更新所持各策略的份额。

3.8.5 策略内轧差:两池对冲 + 时间优先级

每个策略各自把当天来自各产品的增减意图汇成两个池,直接对冲:

平仓池(净流出方向):所有要减仓的需求,不管它处于什么阶段——还没下指令的、已下指令在途未成交的——统统是「想把仓位变成现金」的需求。
建仓池(净流入方向):所有要加仓的需求,不管是新进来的申购还是早先记下的待买入,统统是「想把现金变成仓位」的需求。

每轮轧差就是两池对冲,取 min(平仓池, 建仓池) 内部消化、份额按结算 NAV 换手(底层仓位一动不动、不影响 Delta),只有净残差才发真实指令:净正→开仓,净负→平仓,约等于零→当天完全内部消化。不必追踪「这笔去冲那笔」,因为池子是无差别的,要做的物理动作本来就同质、可互相抵销。两池之外还有一个关键参数:出池的时间优先级。当建仓池不足以覆盖整个平仓池时,有限的对冲量必须先满足到期日最近的赎回。所以平仓池按到期日升序排队,用建仓池(它没有到期压力,作为无序供给)从队头逐笔填满;填满一笔,这笔就彻底了结、出池。例如同时有 T+3 与 T+7 两笔赎回,优先轧 T+3——让时间上最紧的那笔尽早彻底锁定兑付来源,先紧后松永远是对的方向。

3.5.png 图 3.5 — 轧差分两层:产品内先做申赎轧差,策略内再做份额「两池对冲」,只对净残差动底层

3.8.6 跨时间轧差与「按期兑付」的硬约束

一个自然的想法是跨天轧差:今天某笔赎回先不平仓,指望后面几天的新申购来兑付。这是个错误的方法。它产生两个独立风险:流入不及预期(市场恐慌时所有人一起赎、申购同时枯竭),以及平仓来不及(临到期才发现钱不够,而有序平仓需要时间)。两者叠加就是「到期日没钱、又来不及补」——这正是期限错配,是 Celsius 一类暴雷的机制本身。硬约束因此是:每一笔有到期日的负债,必须能用「已经实现的现金来源」在到期日前备齐,绝不依赖「还没到账的预期流入」。但跨时间轧差有一个安全的退化版,只取好处、不留敞口:

默认按确定来源备付。一笔定期赎回在发起当天就进入兑付安排:要么当天被份额内部转移消化(零 churn),要么就安排底层平仓、把现金锁进 Earmarked。兑付来源默认是确定的,不依赖任何未来。
新流入做「事后冲销」,而非「事前指望」。若到期前真的来了反向流入,就用它撤掉一笔尚未成交的平仓指令(零成本),或在仍划算时把已平的仓位重建回来(挽回 carry,但要付重开成本,需 carry 收益 > 重开成本才做)。它来了就赚到、不来也早已备好钱——从不为它的到来留敞口。
临到期收敛(硬兜底)。设一条截止线(例如到期前 T-2 仍未备齐的部分,无条件平仓锁定),在还来得及有序平仓时就动手,绝不拖到最后一天。用确定性换掉对未来流入的依赖。这样跨时间轧差就退化成纯增益、无风险敞口的优化:运气好省一次开平仓,运气差也因早已按确定来源备好钱而兑付无损。它在文档中应被明确标注为「机会性优化」,而非流动性的依赖项;若实现成本不划算,退回到只做同日的策略内轧差(3.8.5)也完全成立——同日轧差是无条件安全的。

3.8.7 空窗期资金:投入可即时赎回的链上 DeFi

在 3.8.6 里被提前平仓、锁定给某个未来到期日的资金,以及备付金的暖层,都会有时间空窗。这部分自动路由到蓝筹、可即时赎回的链上 DeFi(Aave、代币化货币基金等)赚一层额外收益,到期前赎回回 Vault。这里要紧扣 3.8 开头那条不变量:停在 DeFi 的这笔钱属于 Earmarked、已经「有主人」(已指派给某个确定的到期日和负债),只是人还没来取,所以它绝不能再被当作轧差的对手。用它去满足别的产品的流动性需求,等于把同一笔钱许给两个到期日,又变回期限错配。约束:只用可即时(或远早于到期日)赎回的低风险协议;按协议设集中度上限,不把空窗资金堆在单一池子;DeFi 的可赎回时间必须 ≤ 到期日 − 安全边际。收益归属沿用 2.2 的口径(归平台、支撑低费率运营),也可按产品配置调整。

3.8.8 大额赎回与其他流动性风险

除了水位与轧差,还有这些必须纳入流动性管理:

单日赎回上限(Daily Cap)与大额预约。T+0 的「即时」隐含单笔/单日规模上限:超过备付金可承受范围的大额赎回,超出部分排队(临时降级为 T+N),或对超过阈值的大额要求提前预约(如 >$1M 需 T+2 通知),让交易台有时间有序平仓、不打坏市场。
（尚需考虑是否合理）滑点归因 / Swing Pricing。逼迫底层平仓的大额赎回者,应自行承担其造成的滑点(赎回费 / 退出 NAV 调整),而不是把成本摊给留下来的持有人。既公平,也抑制「先跑者占便宜」的挤兑动机。
挤兑时的按比例闸门(Gating)。某窗口内赎回总申请超过可用流动性时,按比例兑付、其余排队。
覆盖率监控与压力测试。对每个产品及全局持续监控「可用流动性 / 近期潜在流出」的覆盖率,并对极端情景(集中赎回、跨产品相关流出、CEX 宕机、稳定币脱锚)做压力测试。

3.9 NAV、申赎定价与收益来源

3.8 的轧差反复用到「结算 NAV」,申赎也要按某个 NAV 成交。这一节定义 NAV 怎么算、申赎按哪个 NAV 成交、以及运营方的利润从哪来。先明确 NAV 在本系统里要服务三件事,它们对 NAV 的要求并不相同,因此最终要拆成两个口径:

给申赎定价:用户侧$X 申购能换多少份额、Y 份额赎回拿回多少钱。
给轧差结算:产品间转移策略份额时,按哪个数转才公平(前面一直叫它「结算 NAV」)。
给用户披露:Dashboard 上的收益率从哪来。

3.9.1 自下而上的三层聚合

NAV 自下而上分三层聚合,正好对应三层抽象:

子账户 NAV(从 CEX 只读 Key 抓快照算):一个子账户跑一个策略,其价值贡献 = 现货腿市值 + 永续腿保证金 + 未实现盈亏 + 已结算待提的资金费 − 应计费用。
策略 NAV:把策略当成一只有「份额」与「单位 NAV」的基金。策略总 NAV ÷ 策略总份额 = 单位 NAV;产品投现金进策略按当时单位 NAV 换份额,策略赚钱→单位 NAV 涨→所有持份产品按份额比例同步受益。这正是轧差里「按 NAV 转份额」成立的前提。
产品 NAV:= 链上 Vault(备付金+待调出)+ Custody 产品钱包 + Σ_策略(产品持该策略份额 × 该策略单位 NAV)+ Earmarked 停在 DeFi 的部分市值;再 ÷ LP Token 总供给 = 产品对外的单位 NAV。需注意：抵押品不能重复计算。因为 CEX 上的钱是 Mirror 出来的额度、真实抵押品在 Custody，而Mirror 的记账方式因厂商而异。因此抵押品在整条聚合链路里有且只被计一次,「Custody 计 vs CEX 计」的边界要一次性画死。否则容易造成NAV算错，资产被凭空多计，造成损失。

3.6.png 图 3.6 — NAV 自下而上三层聚合:子账户 → 策略 → 产品;同一笔抵押品在整条链路只计一次

3.9.2 结算 NAV vs 展示 NAV

结算 NAV 直接关系到钱(份额怎么转、申赎怎么定价),所以它有两个关键点:

所有腿必须在同一时点 mark。Delta 中性是现货+永续两腿对冲,若两腿取价时点不一致,会算出根本不存在的 PnL 和 Delta。因此定一个固定快照时点(如每日某个 UTC 时刻日终 mark,一日一次),所有腿、所有子账户按同一快照取价。
用 mark price,不用 last price。用最新成交价,有人可在快照前几秒在薄盘口「画线」推价、操纵 NAV 占便宜。用交易所 mark price(指数价)抗操纵,也避免薄盘噪声。所以在用户侧有两个NAV:
结算 NAV(binding)——每日日终快照、mark price 计,用于申赎定价与轧差份额转移,是「认账」的那个;
展示 NAV(indicative)——给 Dashboard 用,可更高频、参考性质,不用来结算。因此当用户申购某浮动收益率产品时，能获得的份额不是立刻通过展示NAV计算获得的，而是需事后完成当日结算后，由结算NAV计算获得。因此：用户购买产品时获得的份额是延迟知道的，详见3.9.5.

3.9.3 固定收益 vs 浮动:一个产品可能有两条 NAV 线

浮动 NAV 产品:对外单位 NAV 直接透传底层真实表现,涨跌用户自负。一个 NAV,简单。
固定收益产品:用户看到的对外 NAV 按固定 APR 确定性增长,与底层当天赚多赚少无关;但底层策略的真实 NAV 是浮动的。这中间的差额由劣后层吸收:底层超额→归劣后/平台,底层不足→先吃劣后金垫付。所以固定收益产品同时存在两条 NAV 线——「对用户 NAV」(确定的、APR 算出来的)与「底层真实 NAV」(浮动的),劣后夹在中间。产品间转移策略份额,用的是「策略真实单位 NAV」,不是产品「对用户 NAV」。轧差发生在策略层、认的是策略的真实价值;固定收益那层 APR 包装与劣后垫付,是叠在产品之上的另一层会计,跟策略层的份额转移是两回事,不能混着算。

3.9.4 NAV 与轧差的定序:T1 定价 → T2 轧差

NAV 与轧差之间藏着一个循环依赖:轧差要用 NAV,而 NAV 来自策略当前持仓,可轧差本身又会改变持仓。打破它的办法是把一天切成严格有序的两个时点,中间不交叉:

T1 · 日终快照 + 定 NAV(认账,先发生):到结算时点,对所有 CEX 子账户 + Custody 余额做同一时点 mark 快照,聚合算出每个策略的结算单位 NAV。这个 NAV 基于「今天还没轧差、还没动任何仓位」的存量状态算出,认的是过去一天策略自己跑出来的真实损益,与今天的申赎无关;一旦定下,当天冻结不变。
T2 · 用冻结的 NAV 做轧差 + 执行(后发生):拿 T1 冻结的单位 NAV,把各产品对每个策略的增减意图换算成份额、两池对冲、时间优先级出池、净残差下单。整个轧差过程只读 T1 的 NAV、不重算;即使净残差去 CEX 改变了持仓,那也是今天的动作,只反映到明天 T1 的下一次快照里,绝不回头改今天已冻结的 NAV。

于是整个流程:昨日存量 →(T1 快照)→ 今日结算 NAV(冻结)→(T2)→ 今日轧差与申赎按此 NAV 成交 → 产生今日新仓位 →(明日 T1 快照)→ 明日 NAV。纪律只有一条:NAV 定价用「轧差前的存量状态」,轧差用「已冻结的 NAV」,当天进来的钱不参与当天 NAV 的计算,它们只是按这个 NAV 成交的对象。

3.7.png 图 3.7 — 一天切成 T1 定价(认账并冻结)与 T2 轧差 / 执行两个严格有序的时点;当天进来的钱不参与当天 NAV 计算

3.9.5 申赎定价:浮动 NAV 产品必须前瞻定价

申赎按哪个 NAV 成交,有两个选项:历史定价(用昨日已公布 NAV,申购当场知道份额)与前瞻定价(用当日 cutoff 后才算出的 NAV,申购时只知金额、份额待结算后回填)。浮动 NAV 产品必须选前瞻定价,这不是体验问题、是会漏钱的硬漏洞: 若允许按昨日 NAV 申购,当白天底层大涨、而涨幅要到今晚 T1 才进 NAV 时,套利者可用昨日的旧价买入实际已增值的份额,当晚 NAV 一更新就白赚,这部分钱是从老持有人兜里稀释出来的(赎回侧反向同理)。这就是共同基金史上专门出过丑闻的 stale-price / late-trading 套利。所以规则是:当日 cutoff(即 T1 快照时点)之前提交的申赎,统一按当日 T1 算出的 NAV 成交;cutoff 之后的顺延到下一日。申购提交时只定金额、份额于当晚 NAV 定出后回填;赎回对称(定份额、不定金额)。前端须明确告知「按当日日终 NAV 成交,份额于结算后确认」。前瞻定价只对浮动 NAV 产品是强制的。 T+0 稳定收益率产品没有套利窗口,可即时成交。

3.9.6 执行与定价解耦:没买完不影响已定的 NAV

另一种情况:某天用户买入特别大,当天 CEX 侧没把净残差买完(建仓池仍有剩余)。这不影响 NAV。因为 NAV 在 T2 执行之前就已冻结(T1),执行成不成、成多少都改不了一个已定下的数。那笔「还没铺进 CEX」的现金没有消失,只是物理上还停在 Custody 策略钱包,是现金形态的策略资产——而策略 NAV 的口径本来就包含「还没 Mirror 出去的闲置现金」,这笔钱按现金 1:1 计入 NAV即可。「没买完」改变的是策略资产的形态(现金 vs 已建仓位),不改变它的价值。真正产生的差异不是 NAV 偏差,而是机会成本——这笔钱停在现金、没及时吃到 carry,少赚了,但没算错。处理规则:这部分(缺失的)收益由该策略全体持份产品按份额比例共担(现金不生息,NAV 里自然体现),不让某笔新申购单独承受或单独受益——一旦按 T1 NAV 成交,他就是普通持份人,与存量用户同担同享。还要分清两种「没完成」的待遇:未完成的「买」是机会成本问题(可容忍,按现金计入 NAV);未完成的「卖/平仓」若撞上某笔到期日,才是风险问题,由 3.8.6 的 T-2 收敛兜底。此外,若某策略净残差实在太大,合理做法是多日平滑铺仓(避免自己把 CEX 价格打坏),这期间那部分钱一直以现金计入 NAV、按比例共担机会成本——这与大额赎回要「有序平仓」是对称的:大额申购也该允许「有序建仓」,不强求当天铺满。 3.9.7 对外披露:产品 NAV 上链与可见性边界产品对外的单位 NAV 需要上链,供链上 Vault 合约给申赎定价、给 LP Token 计值。后端按三层聚合在链下算出产品单位 NAV(日终 T1 那个),通过 Oracle 喂到合约里。Oracle 上链是成熟问题,选型、更新频率、防操纵延迟等引用业界常规做法即可,此处不展开;只需注意上链的仅是产品层 NAV,且它背后对应着 T1 那笔「更新 NAV」订单及其 Raw Data,因此链上拿到的 NAV 是可回溯到原始快照的状态,而非孤立的数。(Oracle 更新有延迟,但申赎本就按日终 T1 NAV 成交、节奏一致,只要 Oracle 在 T1 之后、下一交易窗口之前更新到位即可,不额外引入套利窗。) 与此相关的是一条可见性边界:对用户只展示产品层 NAV,策略层与子账户层 NAV 是内部账,默认不展示。根本理由是:用户持有的 LP Token 在链上代表的是产品份额,他对策略没有任何链上凭证;策略 NAV、子账户持仓只是算出产品 NAV 的中间量,属于运营/风控视角。这与 3.1「用户只需理解产品」是同一条原则。但是「不展示给用户」 ≠ 「不可验证」。下两层 NAV 依然完整记在状态机里、依然可被审计方与 PoR 核验,只是默认不出现在散户 Dashboard 主界面上。对用户简化展示,对审计完全可验证,两者不冲突。大额/机构客户可按客户分层、可选地开放策略层视图。

3.9.8 收益分配与运营方利润

收入侧,浮动与固定两类的利润来源不同:

浮动 NAV 产品 → 显式收费。底层真实收益全额透传用户,平台不赚差价,利润来自:管理费(按 AUM 年化、从 NAV 每日计提)、业绩费/carry(对超额收益抽成,配 high-water mark,只对创新高部分抽)、以及赎回费/swing pricing(逼迫平仓的赎回者自担滑点,部分留存)。
固定收益产品 → 利差。用户拿固定 APR,底层真实收益超过 APR 承诺的部分归平台/劣后层(作为承担垫付风险的对价),底层不足时先吃劣后金垫付。平台赚的是「真实收益 − 固定 APR」的利差,代价是承担下方风险。
横跨两类:空窗期 DeFi 收益归平台。Earmarked 停 DeFi 赚的那层归平台,支撑低费率运营(2.2)。

再看成本侧,这些都计入运营成本:

Custody 成本:托管费(按 AUM 年化 bp)+ 每笔划转/结算费——所以轧差减少物理调拨:少动钱 = 少付 Custody 转账费。
CEX 成本:交易手续费、子账户/API 费——与 3.8.3 开平仓四层成本里的显性费用同源。
链上成本:Gas(申赎、NAV 上链 Oracle 更新、跨链桥)。
第三方服务:审计费、PoR 出具、Oracle 喂价、KYT/合规服务(3.2.3 兜底在 Custody 的合规检查也有成本)。
劣后/兑付风险准备:固定收益产品备劣后金,占用平台自有资金,是一项机会成本。
基础设施与人力:量化、风控、运维团队与系统。用户在 Dashboard 上看到的是所有费用与成本计提后的净 NAV。

3.10 储备证明(PoR)与负债对账

PoR(Proof of Reserve)的目标是周期性地、可被独立审计校验地证明一个不等式:物理资产 ≥ 链上负债,且覆盖到每个产品。3.9 建立的三层 NAV 让这个不等式的两边都可计算。本节定义对账的两边、颗粒度、资产侧的穿透核验方式、固定收益的特殊处理,以及 PoR 能力的边界。

3.10.1 对账的两边:链上负债 vs 物理资产

链上负债侧 = Σ(用户持有 LP Token × 产品对外单位 NAV)。这是产品在链上对用户的总兑付承诺。LP Token 总供给链上公开可查,对外单位 NAV 是 3.9.7 上链的那个值(日终 T1、Oracle 喂入),因此负债侧完全由链上数据算出,不依赖任何链下账本。
物理资产侧 = 3.9.1 自下而上聚合出的产品真实 NAV。即「链上 Vault(备付金 + 待调出)+ Custody 产品钱包 + Σ_策略(产品持该策略份额 × 策略真实单位 NAV)+ Earmarked 停在 DeFi 的部分」,是产品名下散落在各物理位置的全部真实资产。

PoR 周期性核验的是:每个产品的物理资产侧 ≥ 它的链上负债侧。两边 NAV 口径不同——负债侧用「对用户 NAV」(对固定收益是 APR 算出的承诺值),资产侧用「真实 NAV」(底层实际值);二者的差额由 3.10.4 的劣后层处理。

3.8.png 图 3.8 — PoR 对账:按产品逐个核「物理资产 ≥ 链上负债」,资产侧穿透到子账户、抵押品只计一次

3.10.2 颗粒度:per 产品对齐,而非全局对齐

对账单元是单个产品,而非全局总量。这是 2.4「避免整体覆盖、局部亏空」在 PoR 上的落点:

对账要把同一产品散落在各处的资产——链上 Vault(备付金 + 待调出)、Custody 产品钱包、以及所持各策略份额对应的价值——按产品归并后整体核验,而非只看某一个地址的余额。
只有 per 产品对齐,才能暴露「产品 A 超额、产品 B 亏空、加总看着平」这种情形。全局对账会把局部亏空藏起来,而它恰是挪用最常见的形态:拆东墙补西墙。
隔离在 3.4 一直做到 CEX 子账户层,对账因此也能核到那一层。

3.10.3 资产侧的穿透核验:从子账户到产品

负债侧由链上公开数据算出,核验简单;难点在资产侧——它是三层聚合出来的数,审计方不能只接受平台上报的总数,需要逐层穿透验真。3.9.7 为此预留了钩子:策略 NAV、子账户 NAV 默认不展示给散户,但对审计方与 PoR 完整可验证。资产侧的核验路径自下而上:

子账户层: 审计方以独立的 CEX 只读权限(或 Custody 出具、CEX 背书的持仓快照)直接读子账户真实持仓,核出子账户 NAV,不接受平台单方面报数。
策略层: 子账户 NAV 按策略归集,核出策略真实 NAV 与单位 NAV。
产品层: 按「产品持各策略份额 × 策略单位 NAV」加总,再加链上 Vault 与 Custody 产品钱包余额,得到产品真实 NAV——这才是与负债侧比对的数。

3.10.4 固定收益的覆盖率:对账线里要算进劣后

3.9.3 的两条 NAV 线使固定收益产品的对账不同于浮动产品:

浮动 NAV 产品: 对外 NAV 直接透传真实 NAV,两条线重合,对账即「真实资产 ≥ LP × 真实 NAV」,覆盖率围绕 1 波动属正常。
固定收益产品: 对用户负债按 APR 增长(确定),底层真实资产浮动,差额由劣后层吸收。其对账标准是真实资产 + 劣后金 ≥ APR 负债——劣后金作为首损垫,必须计入覆盖率资产侧。因此固定收益产品的 PoR 需同时报两个数:真实覆盖率(真实资产 ÷ APR 负债)反映劣后被消耗的程度;含劣后覆盖率((真实资产 + 劣后)÷ APR 负债)反映用户本金是否仍被覆盖。前者跌破 1 意味着开始吃劣后金,后者跌破 1 即 3.9.3 的「劣后吃穿临界点」——优先级用户本金开始受损、固定承诺被打破。这个临界点须在 PoR 报告中显式监控,并依 3.9.3 的要求事先向用户披露。

3.10.5 PoR 证明什么、不证明什么

PoR 能证明:在出证时点,Custody 签名背书的物理资产确实 ≥ 链上可独立计算的负债,且覆盖精细到每个产品。它把「平台是否挪用」从口头承诺,变成周期性、可被独立审计校验、且负债侧无需信任平台的数值结论。 PoR 不能证明的:

它依赖 Custody 签名诚信。资产侧数据由 Custody 出具并签名,若 Custody 与平台合谋伪造持仓证明,PoR 同样显示健康。这是 PoR 的信任根,也是第四章「对 Custody 的信任」的来源。
它是时点快照,不是连续保证。两次出证之间,资产可能被动过又补回。提高出证频率、引入实时 PoR 可缩小窗口,但无法消除。
它核「够不够」,不核「怎么来的」。 PoR 证明资产覆盖负债,但不证明资产来源合规。 PoR 的准确定位是:把信任从「相信平台自述未挪用」,收窄到「相信 Custody 签名 + 独立审计这一组外部背书」。这是实实在在的收窄,而非归零;残留的信任根——Custody 是否合谋、运营层是否在快照间作弊——正是第五章用主权 Agent 进一步收窄的对象。

四、方案的边界:信任问题没有被完全消除

把上面所有的设计加起来:SPV、LP Token、Custody 隔离、Mirror、白名单、PoR、Delta 中性、劣后池、流动性断路器、分级 Dashboard、量化/风控/数据源三方权限分离 …… 本方案构建出一个相比传统 CeFi 安全得多的体系。但必须诚实承认: 本方案不能从根上消除信任问题,它只是把信任从「单点信任平台」分散到「信任一组相互制衡的角色」。具体来说,残留的信任点包括:

对 Custody 的信任。 PoR 由 Custody 签名出具,如果 Custody 与平台合谋,理论上仍可能伪造证明。
对运营团队的信任。资金调度模块、风控执行模块、API Key 管理 …… 这些链下系统的实际运行仍依赖运营团队的内控、密钥管理与多签治理。再严格的内控也不能 100% 排除「内贼」与重大误操作的可能。
对法律执行的信任。 SPV 架构在法理上保护用户,但实际清算过程仍依赖法院、清算人、法律体系正常运作。在极端司法环境下,这个保护未必能及时兑现。
对量化团队的信任。 Delta 监控可以发现偏离,但发现到处置之间仍有窗口;策略风格漂移、内部对敲等问题仍需事后追究。
对链上 KYT 缺失的容忍。如 3.2.3 所述,链上 KYT 目前没有理想方案,本方案选择把这层兜底交给 Custody。这是已知缺陷。

换言之,本方案的安全模型是「N 方制衡 + 多重监控 + 法律兜底」。这对绝大多数普通用户而言已经足够;但对追求极致信任最小化的用户,特别是大型机构而言,仍存在「为什么我必须信任你的运营团队」这个根本性疑问。

五、主权 Agent + CeDeFi:把运营层从人手里拿走

第四章诚实地列出了五个残留信任点。本章给出收窄它们的方向——用「主权 Agent」接管运营层。主权 Agent 的定义和技术实现已在《主权 Agent》一文中完整展开;本章默认读者已读过该文,不再复述。

5.1 五个残留信任点的共同根源

第四章的五点里,「对 Custody 的信任」与「对法律执行的信任」是架构之外的两条物理 / 法律约束;剩下三点——对运营团队、对量化团队、对链上 KYT 兜底的信任——本质是同一个根源:运营层仍然由人持有密钥、做出决策。再严密的内控、多签与监控,落到底都是「请相信这组人不会作恶、也不会出大错」。主权 Agent 要做的,就是把这句话换成另一句:请相信一段任何单一方都签不动、部署后改不了、且每个决策都链上可审计的代码。这正是《主权 Agent》一文「把死的信任变活、却仍不可作恶」的范式落到本架构上的样子。

5.2 哪些角色交给 Agent,哪些保留(映射到第三章)

第三章把运营层拆成了几个各持独立 Key 的模块:资金调度(Custody 写 API)、量化下单(下单 Key)、风控强平(强平 Key)、数据汇入(只读 Key),以及内部状态机与后台。主权 Agent 不是去替换其中某一个模块,而是成为持有这些权限的执行体本身;各模块按风险等级,落到 Agent 的不同层:

资金调度 / Custody 写 → Agent 主账户级操作。白名单地址直接写进 Soul，每一笔调拨都走门限签名 + 链上挂载 + 前置挑战延迟窗口。任何单一方——包括 Agent 的创立者——都无法把资金移出白名单。这正是 3.5 三把 Key 隔离想要、但「人持密钥」永远做不到的强度。
量化下单 → Agent 的 Skill 层 + 实例账户(高频小额)。这与第三章「下单 Key 无提币权」天然吻合:量化策略(含可选的 LLM 辅助)只决定在白名单内怎么交易,判断出错最多是收益不佳,动不了金库——对应论文那句「LLM 出错 = 收益不佳,资金安全」。
风控强平 → Agent 的认知防火墙。 Delta、杠杆、敞口的阈值作为 Soul 红线,触发即由 Agent 自动平仓。它的失败模式是温和的:误判最多让仓位多等一个挑战期,而不会造成资金损失。是否再叠一层人类风控,见 5.4。
数据汇入 + 内部状态机 → Agent 的 Memory 与可审计留痕。第三章「每笔订单对应 Raw Data、状态机可重放、Dashboard 全程可追溯」(2.4 / 3.7.1),与论文「每个决策附带链上证明、Merkle 批量锚定、任何人可独立审计」几乎是一一对应的同构——本架构的状态机,本就是为这种可审计性准备的底座。

5.3 逐条回应第四章的残留信任点

把第四章的五点放到这套接管关系下,逐条看它被收窄到什么程度——并诚实标出哪些只是收窄、哪些根本没动:

对运营团队的信任(基本消除)。私钥以门限签名分布在可问责的共识网络,白名单写进不可篡改的 Soul,资金动作走前置挑战。「内贼挪用 / 跑路」在密码学层面被堵死,「重大误操作」被挑战窗口与账户分层封顶。这是 Agent 收益最大的一条。
对量化团队的信任(部分消除)。下单纳入 Skill、参数边界由 Soul 强制、每笔动作链上留痕:越界与对敲要么被 Soul 当场拦下、要么留痕可追责。但策略本身设计得好不好、要不要漂移风格,仍是写 Skill 的人的判断——Agent 不替人做投资决策。
对链上 KYT 缺失的容忍(部分缓解)。认知防火墙可以把资金来源与地址画像的检查嵌进执行环路(论文判断的是「行为合理」而非仅「语法正确」),比纯合约强;但 KYT 根上仍需外部身份与数据源,Agent 改善它、并不解决它。3.2.3 那个缺口依然在。
对 Custody 的信任(未消除)。 Agent 约束的是平台侧;但真实资产仍由第三方 Custody 物理保管,Agent 并不持有那把物理保管的钥匙。论文的多厂商 TEE、多托管能加固 Agent 自己的密钥,却不能保证 Custody 不与平台合谋。第四章列的这条边界,在这里原样保留。
对法律执行的信任(未消除)。 SPV 清算仍依赖法院与清算人。Agent 是算法层,不触及法律层。

5.4 主权 Agent 带来的新信任面,以及它消不掉的边界

必须同样诚实:Agent 不是把信任降到零,而是把它从「信运营团队」搬到一组更难合谋、且可验证的根上——TEE 厂商根、共识托管节点、证明系统。论文用多厂商纵深防御、定期 RA 轮换、挑战机制,以及未来的 FHE / ZKML 把这个根的风险压到很低;但它仍是一个信任假设,只是更小、更分散、可审计。再加上 5.3 里 Agent 也消不掉的两条——Custody 物理合谋与法律执行——本架构的诚实结论是:信任被大幅收窄,而非清零。一个有意保留的人类环节:风控的否决权。让人类(或一个独立的风控 Agent)只能把系统推向更保守——强制平仓、暂停大额——而不能放松限额或解锁提币。它与论文账户分层「额度是密码学事实」叠加,是纵深而非冗余:任何一方失手,系统只会更安全,不会更危险。