hybrid-perps-spec

L6 对冲系统架构设计

本文档是 07-risk-management.md 的补充，专注于对冲系统的底层架构设计。

一、对冲的本质：平台在做什么？

当用户在平台做多 BTC（INTERNAL），平台作为对手方自动持有 BTC 空头。如果 BTC 涨了，平台亏钱。

对冲 = 平台去 HL 开一个与平台内部持仓方向相反的单，抵消风险。

用户做多 BTC $500K（INTERNAL）
  → 平台内部持有 BTC 空头 $500K（对赌对手方）
  → BTC 涨 → 平台亏
  → 对冲动作：去 HL 做多 BTC $400K（对冲 80%）
  → BTC 涨 → 平台在 HL 上赚，内部亏 → 互相抵消

即：对冲方向 = 用户方向（= 平台内部敞口的反方向）。

二、HL 账户模型：单账户 vs 多账户

当前方案：单一统一账户

HL 技术限制：同一账户 + 同一币种 + 同一方向 = 只能有一个仓位。

平台 HL 账户
├── BTC 多头 $400K（对冲仓位）
├── ETH 空头 $200K（对冲仓位）
├── BTC 多头 $50K（用户大单路由）← 与对冲仓位自动合并！
└── 全仓模式，共享 $500K 保证金

问题：用户路由到 HL 的仓位和对冲仓位在 HL 端自动合并（同币种同方向），无法分开管理。

推荐方案：双账户分离

账户	用途	资金规模	杠杆策略
交易账户（Trading Account）	用户大单路由到 HL（L4 代理执行）	≥ $500K	跟随用户选择（5x-50x）
对冲账户（Hedge Account）	L6 对冲引擎专用	≥ $200K	固定低杠杆（2x-3x）

分离的好处：

风险隔离：对冲仓位不会被用户大单影响，反之亦然
杠杆独立：对冲账户始终低杠杆（安全），交易账户按需调整
保证金率独立监控：一个账户压力大不会拖垮另一个
会计清晰：对冲盈亏和用户路由盈亏分开核算

HL 多账户可行性：HL 支持通过不同钱包地址创建独立子账户。每个地址是一个独立的 HL 交易账户。平台使用两个不同的 Turnkey 托管地址即可实现。

双账户资金管理

平台资金池
  ├── 交易账户 ≥ $500K
  │     └── 保证金率 > 500%（安全线）
  ├── 对冲账户 ≥ $200K
  │     └── 保证金率 > 500%（安全线）
  ├── 风险准备金 ≥ $500K
  └── 热钱包（各链提现资金）

账户间资金调拨：

交易账户保证金率 < 300% → 从资金池补充
对冲账户保证金率 < 300% → 从资金池补充
均走 Arbitrum 链上操作，延迟约 10-30 分钟

三、小额 INTERNAL 订单：监控而非忽视

每笔 INTERNAL 成交后的系统行为

用户下单 $5,000 BTC 多（INTERNAL）
  │
  ▼
[L3] 内部记账 → 成交确认
  │
  ▼
[L6] 接收敞口变更事件
  │
  ▼
[L6] 重算 BTC 净敞口（增量更新，非全量扫描）
  │   净敞口 += $5,000（用户多头方向）
  │
  ▼
[L6] 对冲阈值判断
  │
  ├── 净敞口 < $100K → 仅记录，不对冲（当前状态大概率在此）
  ├── $100K ~ $500K → 标记"待对冲 50%"
  ├── $500K ~ $1M   → 标记"待对冲 80%"
  └── > $1M         → 停止对赌 + 对冲 80%

关键点：

每笔成交都触发敞口重算，但不一定触发对冲
对冲有去抖动机制（Debounce）：净敞口变化后等待 5 秒，再决定是否对冲。避免频繁小额变化导致大量对冲操作
对冲是批量执行的：不是每笔 $5K 都去 HL 开一单，而是累积到一定变化量后批量操作

四、大额敞口场景深度分析

场景：200 用户各 $5,000 做多 BTC → 净敞口 $1M

时间线：
T1: 前 20 个用户（$100K）→ 无对冲（< $100K 阈值）
T2: 第 21-100 个用户（$500K）→ 对冲 50% = 在 HL 做多 BTC $250K
T3: 第 101-200 个用户（$1M）→ 对冲 80% = 目标 HL 持仓 $800K
    → 增量对冲：$800K - $250K = 再加仓 $550K
T4: 超过 $1M → 停止 BTC INTERNAL 新开仓

对冲资金需求计算

对冲 $800K 名义价值 BTC 多头：
  2x 杠杆：保证金 = $400K
  3x 杠杆：保证金 = $266K
  5x 杠杆：保证金 = $160K ← 风险更高但资金效率更高

对冲账户 $200K 本金：
  2x 可对冲 = $400K 名义
  3x 可对冲 = $600K 名义
  5x 可对冲 = $1M 名义

杠杆阶梯策略（推荐）

对冲名义规模	使用杠杆	理由
≤ $300K	2x	安全第一，BTC 50% 跌幅才爆仓
$300K ~ $600K	3x	中等风险，BTC 33% 跌幅才爆仓
$600K ~ $1M	5x	资金效率，但需更密切监控
> $1M	5x + 停止对赌	不再新增敞口，等待缩减

核心原则：宁可少对冲也不要对冲仓位被爆。对冲仓位被清算 = 风险瞬间回到裸露状态 + 实现亏损。

对冲账户资金不足时的应对

对冲需求 > 对冲账户承载力：
  │
  ├── 第一步：提高对冲杠杆（3x → 5x）
  │
  ├── 第二步：从资金池紧急补充对冲账户
  │           （链上操作，延迟 10-30 分钟）
  │
  ├── 第三步：切换到 HL_MODE（全量路由 HL，不再新增 INTERNAL 仓位）
  │
  └── 第四步：等待对冲账户补资完成后恢复

五、预对冲模型（Standing Hedge / Delta Pool）

概念

平台预先在 HL 对冲账户上维持一个基础对冲仓位（Delta Pool），而不是等净敞口累积到阈值才开始对冲。

平台启动时：
  在 HL 对冲账户开 BTC 多头 $100K（3x，保证金 $33K）
  在 HL 对冲账户开 BTC 空头 $100K（3x，保证金 $33K）
  → 初始净仓位 = 0（Delta Neutral）
  → 但已经预留了 ±$100K 的对冲容量

工作原理

初始状态：HL 多 $100K + HL 空 $100K = 净仓位 $0

用户做多 BTC $50K（INTERNAL）：
  → 平台内部敞口 = 空头 $50K
  → 需要对冲 = 做多
  → 操作：HL 减空 $50K（而非加多）
  → HL 变成：多 $100K + 空 $50K = 净多 $50K
  → 对冲完成，无需新开仓

用户做空 BTC $30K（INTERNAL）：
  → 平台内部敞口变化 = 空头 $50K - $30K = 空头 $20K
  → 操作：HL 加空 $30K
  → HL 变成：多 $100K + 空 $80K = 净多 $20K

优势

响应速度更快：减仓比开仓更快、滑点更低
双向灵活：无论用户做多做空，都可以通过调整现有仓位对冲
避免频繁开平仓：减少 HL 手续费

劣势

资金成本：持有双向仓位需要双倍保证金（$33K × 2 = $66K）
资金费成本：多空同时持仓会持续产生资金费支出
HL 同账户同币种只能一个方向：HL 不支持同一账户同一币种同时持多和空！

HL 的技术限制

HL 同一账户同一币种只能有一个仓位（多或空），不能同时双向。

这意味着纯粹的 Delta Pool（同时持多和空）在单账户内不可行。

可行的替代方案：单方向预对冲 + 动态调整

方式一：单方向基础仓

  如果历史数据显示用户偏好做多（散户常见）：
    → 预开 BTC 多头 $100K（预对冲用户多头方向）
    → 用户做多时：已有对冲覆盖，无需操作
    → 用户做空时：减仓 HL 多头

  优点：资金效率高（只用一方向保证金）
  缺点：方向判断错误时需要翻转，成本高

方式二：跨账户双向（如果用双账户）

  对冲账户 A：BTC 多头 $100K
  对冲账户 B：BTC 空头 $100K
  → 实现真正的 Delta Neutral
  → 但需要三个 HL 账户（1 交易 + 2 对冲），管理复杂

MVP 建议：不做预对冲

预对冲增加了资金占用和操作复杂度，但 MVP 阶段敞口规模有限（初期用户少），被动对冲（敞口达阈值再动作）已足够。

预对冲留到 Phase 4 优化阶段，届时有足够的用户行为数据来判断预对冲方向。

六、未覆盖的边缘场景

场景 A：对冲仓位被 HL 清算（灾难性）

触发条件：
  对冲账户使用 5x 杠杆对冲 BTC 多头
  BTC 急跌 20% → 对冲仓位接近清算价
  HL 清算对冲仓位 → 平台对冲消失
  同时用户 INTERNAL 多头也在亏钱 → 平台双重亏损

防护措施：
  1. 对冲账户保证金率 < 300% → 自动补资
  2. 对冲账户保证金率 < 200% → P0 告警 + 紧急降杠杆
  3. 对冲仓位未实现亏损 > 保证金 50% → 自动减仓（止损）
  4. 对冲仓位绝不使用 > 5x 杠杆（硬性上限）

场景 B：HL 极端波动导致对冲滑点巨大

触发条件：
  需要对冲 $500K BTC 多头
  BTC 瞬间下跌 10%，HL 订单簿薄
  市价对冲单滑点 3-5%

防护措施：
  1. 大额对冲使用限价单 + 超时回退市价
  2. 对冲单设滑点上限（默认 1%），超出则拆分多笔
  3. 极端行情下暂停对冲 + 切换 HL_MODE（停止新增敞口）

场景 C：对冲方向与用户路由方向冲突

触发条件：
  BTC 净敞口 = 用户多头 $800K → 对冲：HL 多头 $640K
  此时一个大用户下 BTC 多头 $50K，路由到 HL（> $10K）
  HL 交易账户也开 BTC 多头

  → 两个账户都在做多 BTC
  → 如果 BTC 跌，两个账户同时亏损

这不是问题，因为：
  - 交易账户的多头 = 用户要求的（用户承担盈亏）
  - 对冲账户的多头 = 覆盖 INTERNAL 对赌敞口（平台风控需要）
  - 两者独立核算，不存在"冲突"

场景 D：多币种同时触发对冲

触发条件：
  BTC 净敞口 $600K → 需对冲 $480K
  ETH 净敞口 $400K → 需对冲 $200K
  SOL 净敞口 $200K → 需对冲 $100K
  合计对冲需求 $780K

  对冲账户 $200K，3x 杠杆最大承载 = $600K

应对策略：
  1. 按净敞口大小排序，优先对冲敞口最大的币种
  2. 对冲不足的币种 → 切换该币种为 HL_MODE
  3. 触发资金池补充到对冲账户
  4. 告警通知 Risk Manager

场景 E：用户集中平仓导致对冲仓位过大

触发条件：
  用户 INTERNAL 多头 $800K → 对冲 HL 多头 $640K
  大量用户同时平仓（获利了结 / 止损）
  用户 INTERNAL 多头降到 $100K
  此时 HL 对冲仓位 $640K 远超需要

应对策略：
  1. 每次 INTERNAL 仓位减少 → L6 重算净敞口
  2. 对冲仓位 > 净敞口 × 对冲比例 → 触发减仓
  3. 批量减仓，控制滑点
  4. 设置最大减仓速率（如每分钟减仓不超过 $200K）

场景 F：资金费侵蚀对冲利润

触发条件：
  对冲账户长期持有 BTC 多头 $500K
  资金费率持续为正（多头付空头）
  每 8 小时支付：$500K × 0.01% = $50
  一天 = $150，一个月 = $4,500

应对策略：
  1. 对冲成本（手续费 + 资金费）实时累计
  2. 如果对冲成本 > 预期客损收益 → 缩减对赌（降低路由阈值）
  3. 对冲仓位的资金费支出纳入风控成本报表
  4. 后台仪表盘展示"对冲 ROI"指标

七、对冲系统完整架构图

INTERNAL 仓位变更事件（开仓 / 平仓 / 清算）
  │
  ▼
[L6 敞口聚合器] ← 增量更新，每笔成交触发
  │
  ├── 各币种净敞口（实时）
  ├── 各币种对冲仓位（从对冲账户读取）
  └── 对冲缺口 = 应对冲量 - 已对冲量
  │
  ▼
[去抖动 + 批量合并]（5 秒窗口）
  │
  ▼
[对冲决策引擎]
  │
  ├── 缺口 > 0 → 需要加仓对冲
  │     ├── 检查对冲账户可用保证金
  │     ├── 选择杠杆（阶梯策略）
  │     └── 生成对冲指令 → [L4 对冲账户代理] → HL
  │
  ├── 缺口 < 0 → 需要减仓对冲
  │     └── 生成减仓指令 → [L4 对冲账户代理] → HL
  │
  └── 缺口 ≈ 0 → 无操作
  │
  ▼
[对冲仓位管理器]
  ├── 追踪每个币种的对冲仓位
  ├── 对冲仓位保证金率监控
  ├── 对冲仓位未实现 PnL 监控
  └── 对冲成本累计（手续费 + 资金费 + 滑点）

八、HL 账户架构最终方案

MVP 推荐：双账户

┌─────────────────────────────────────────┐
│              平台资金池                    │
│  （热钱包 / 冷钱包 / 风险准备金）          │
└────────┬───────────────┬────────────────┘
         │               │
    ┌────▼─────┐   ┌────▼──────┐
    │ 交易账户  │   │ 对冲账户   │
    │ Trading  │   │ Hedging   │
    │ ≥$500K   │   │ ≥$200K    │
    ├──────────┤   ├───────────┤
    │ L4 代理   │   │ L6 对冲    │
    │ 用户大单  │   │ 敞口对冲   │
    │ 路由执行  │   │ 低杠杆     │
    │ 跟随用户  │   │ 2x-5x     │
    │ 杠杆      │   │ 阶梯杠杆   │
    └──────────┘   └───────────┘

配置要求

配置项	交易账户	对冲账户
HL 地址	独立 Turnkey 托管地址 A	独立 Turnkey 托管地址 B
保证金模式	Cross（全仓）	Cross（全仓）
最低保证金率	> 500%	> 500%
告警保证金率	< 300%	< 300%
紧急保证金率	< 150%	< 150%
最大杠杆	跟随用户（≤ HL 最大）	5x（硬上限）
Agent Key	专用 Agent Key A	专用 Agent Key B

九、核心设计原则

对冲仓位永远不能被清算：宁可少对冲，也不要对冲仓位爆仓
对冲是成本，不是利润中心：对冲的目的是保护客损收益，对冲本身会产生手续费、资金费、滑点成本
渐进式对冲：不一口气对冲到位，分批次、分时间段执行
对冲不等于 1:1 覆盖：只对冲超过阈值的部分，保留一定裸露敞口（因为统计上用户整体是亏损的）
资金效率优先：用最少的资金实现足够的风险覆盖，而非追求完全中性