binance-api/specs/001-specManager-perp/research.md

Phase 0 调研记录：多平台 Delta 中性控制平面

调研目标概览

• 设计多层行情回退策略（WebSocket → HTTP → 合成价格），满足 10 秒内恢复交易的 SLA。
• 明确资金利用率 50%-80% 边界的测量方式与触发流程。
• 评估跨交易所 Delta 对冲与风险指标的实现方案。
• 优化代理网络与凭证隔离方案，保障高频请求的稳定性。
• 设计可插拔策略模块的接口标准与沙箱验证路径。

调研成果

1. 行情回退与 Failover

• 决策：
  • 主通道使用各交易所官方 WebSocket；为每个交易所配置 HTTP 深度接口作为同步回退。
  • 当 WebSocket 数据陈旧 >2 秒或连接失败时，立即拉取 HTTP 深度并触发告警；若连续 3 次 HTTP 拉取失败，则使用最近 30 秒的中位价合成报价。
  • 整个切换流程需在 10 秒内完成，恢复后需重新验证 Delta 中性状态并记录日志。
• 理由：
  • WebSocket 具备低延迟、高频刷新能力；HTTP 拉取可覆盖短暂断线；合成报价保障交易不中断。
  • 10 秒 SLA 与宪章和 Spec 要求一致，可最大限度降低刷量中断时间。
• 备选方案：
  • 仅使用 WebSocket + 缓存（被否决：主源断开时无法迅速获得新数据）。
  • 引入第三方行情聚合（被否决：依赖额外服务且增加成本与延迟）。

2. 资金利用率与再平衡策略

• 决策：
  • 利用率公式：（账户总余额 − 可用余额）÷ 账户总余额；当利用率 <50% 触发开仓增加持仓，当 >80% 触发行权/平仓释放保证金。
  • 再平衡流程：
  • 计算账户利用率与 Delta；若利用率越界且 Delta 允许，则优先调整限价单队列；
  • 若越界同时 Delta 偏离 ±0.0005 BTC 等值，则优先执行对冲单恢复 Delta，再处理限价单；
  • 整个流程需要在 8 秒内完成一次评估循环。
• 理由：
  • 采用账户余额视角衡量利用率，更贴近资金占用情况，与用户澄清一致。
  • 将 Delta 调整优先级置于利用率之前，可避免为满足利用率而放大风险敞口。
• 备选方案：
  • 使用保证金占用 / 可用保证金，需依赖交易所差异化字段，不易统一；
  • 在利用率越界时直接使用市价单（被否决：可能血亏且不符合“限价优先”策略）。

3. Delta 中性与风险指标

• 决策：
  • 统一使用 BTC 等值作为敞口度量单位；针对非 BTC 交易对，按实时价格折算。
  • 设定 Delta 容忍区间 ±0.0005 BTC 等值；超过阈值立即触发对冲交易（跨账户或跨交易所）。
  • 将风险指标拆分为：净敞口、未实现 PnL、利用率、滑点预估、止损执行时间。
• 理由：
  • BTC 等值便于比较不同交易所、不同币种的敞口。
  • 分层指标可支持仪表盘和告警联动，符合宪章中的透明可观测性要求。
• 备选方案：
  • 为每个币种单独设定阈值（维护成本高，且对冲策略复杂）。

4. 代理网络与凭证隔离

• 决策：
  • 所有带权限的 HTTP 请求通过授权代理池（支持账号隔离与 Session 轮换）。
  • WebSocket 在可行的情况下直连，若交易所限制需走代理，则为特定账户配置独立代理通道。
  • 凭证存储采用加密文件 + 内存热加载；密钥轮换脚本每季度复测。
• 理由：
  • 代理池保障来源 IP 多样性并隔离账号风险；限定关键请求经代理符合用户“防止女巫”要求。
  • 区分 HTTP 与 WS 代理策略能兼顾性能与稳定性。
• 备选方案：
  • 所有网络流量都走代理（被否决：行情延迟大，且部分交易所对 WS 代理支持不佳）。

5. 策略模块接口与沙箱

• 决策：
  • 定义策略模块对外接口：init(config)、generateSignals(state)、onFill(event)、onRiskAlert(alert)。
  • 沙箱模式：提供 Dry-run 仿真环境，使用真实行情与订单簿，但所有下单写入虚拟撮合引擎；成功通过后才可接入生产。
  • 新策略上线需提供 profit-after-fee 模型与回退方案，自动化测试需要覆盖 signal 生成、下单、撤单、对冲流程。
• 理由：
  • 统一接口有利于增量扩展；沙箱保障策略安全上线；测试要求与宪章 Principle V 对齐。
• 备选方案：
  • 策略模块直接依赖底层 TradeExecutor API（被否决：耦合度高且不利于未来维护）。

待跟进事项

• 针对资金费率套利策略，需要在 Phase 1 中明确长期仓位的资金费率聚合逻辑。
• 确认各交易所 WebSocket 心跳与鉴权细节，填入 contracts/ 中的订阅契约。
• 研究行情合成时的精度处理，确定是否需要简单移动平均或加权中位数（Phase 1 data-model.md 中补充）。

参考资料

• Pacifica 官方 API 文档（行情与交易接口）
• Aster DEX 文档（WebSocket、订单簿订阅）
• Binance Futures API 速率限制说明
• 现有仓库中的 docs/PRICE_MANAGEMENT_SOLUTION.md 与 docs/ASTER_TESTS.zh.md