订单系统问题修复文档 文档概述 创建日期: 2026-02-13 版本: v1.0 状态: ✅ 已完成 影响范围: 订单下单、订单跟踪、平仓逻辑 本文档记录了订单系统中发现的所有关键问题（BUG #1 - #5）及其完整的解决方案。 📋 问题总览 BUG ID 问题描述 严重程度 状态 BUG #1 仓位同步竞态条件 🔴 CRITICAL ✅ 已修复 BUG #2/#3 limit_open 异常处理不完整 🟠 HIGH ✅ 已修复 BUG #4 订单状态解析和追踪逻辑 🔴 BLOCKER ✅ 已修复 BUG #4.1 订单取消验证不完整 🟠 HIGH ✅ 已修复 BUG
L2 订单簿快照优化 - 实施总结 ✅ 实施完成状态 状态: 🎉 所有步骤已完成 日期: 2026-02-13 分支: adaptive_algri 📋 实施概览 架构变更 旧架构（已完全废弃）: 下单 → _calculate_limit_price() → get_l2_best_prices() → API 调用 延迟: 100-500ms | API 频率: 100% 新架构（已完全采用）: WebSocket L2 订阅 → 实时缓存 → 信号触发时读取快照 → 下单直接使用 延迟: < 10ms | API 频率: < 1%（仅降级） 核心优势 * ✅ 零 API
它 没有“代码历史的时间维度模型” 它 没有“系统全局拓扑图” 它 没有“未来维护成本函数” AI 做的是： 在当前问题表述下做最小改动 1️⃣ 把 AI 限制为“纯函数工具” 不让它设计架构，只让它做： * 纯函数实现 * 算法实现 * 单文件逻辑 * 单元测试生成 架构层全部人工主导 2️⃣ 强制“上下文断代” ❌ 别说：帮我重构这段代码 ✅ 要说：下面是“全新架构定义”，旧代码全部作废 你要主动制造“无历史状态”假象 3️⃣ 让 AI 先“找垃圾”，再让它“写代码” 不要直接改代码，而是： 第一步：让它列出 - 死代码 -
Welford 在线算法 是专门用来： 在数据一条一条进来时，稳定地计算“均值 + 方差/标准差” 而且不会炸精度，这是它封神的地方。 🌟 它解决什么痛点？ 普通做法算方差是： [ \sigma^2 = E[x^2] - (E[x])^2 ] 问题是： * 两个很大的数相减 * 浮点数精度损失（catastrophic cancellation） * 数据量大时误差会越来越离谱 在金融高频、传感器数据、实时系统里，这会慢慢把结果算歪。 Welford = 数值稳定 + 实时更新 + 不用存历史数据 🎯 核心思想 每来一个新数据 (x_n)，只更新 3 个量： 变量含义n当前数据个数mean当前均值M2“平方偏差累计量” 最终： [ \text{方差} = \frac{M2}{n}
核心算法: Adaptive Bollinger Z-Score + 多周期协整验证 目录 1. 系统概览 2. 信号生成全链路 3. 第一层：相关性分析 4. 第二层：协整检验 (Engle-Granger 两步法) 5. 第三层：Z-Score 计算 6. 多周期验证门控 7. Adaptive Bollinger Z-Score 策略引擎 8. 入场与退场决策逻辑 9. 风控体系 10. 关键参数速查表 11. 回测与参数优化 12. 架构总结 1. 系统概览 本系统是一个加密货币配对交易平台，专注于 Hyperliquid 交易所上的 HYPE/PURR 交易对。核心思路是利用统计套利——当两个高度相关的资产价格偏离均衡关系时入场，
前面的计算结果信号发掘是针对于一般情况行情的正常波动，当行情极端波动的时候，两种资产的价格表现可能就不同了。你比如说山寨币在行情好的时候价格暴涨，比方说ETH，相对于比特币价格暴涨，平时的时候价格还相对比较均衡的。嗯，他们价差是稳定的，但到某个时间点的时候，价格突然暴涨，连续暴涨好几天，但是比特币价格没没涨，它可能连续会暴涨一周，比特比特币价格没动，那这个时候就会出现一个问题。前面选择的统计周期，比方说是20天，那么20天算出来的价差的平均值是比价小的。 标准差呢，可能也会被，稍微拉大那么一点。 但是由于行情变化得比较快啊，当前最新的行情和过去 20 天的平均价差比起来，那可能偏离的幅度就比较大了，也就是说最新的价格可能远远超过了。它过去 20 天平均该有的价差水平，超过的程度非常高，而且这种超过的程度短期之内不会回归，持续好几天都是这种状态。 那这个时候你再用当前最新价格去和过去 2 最近 20 天。价差的平均值去比较，然后再除以它的标准差，得到的这个标准差偏离幅度，它可能就会变得极大，而且这种极大它不回归这种极大值，它会呈现出一种趋势特征，一直保持在这样一个极大值，有可能持
两种资产的绝对价格长期是存在某种协整关系的均衡关系的。嗯，这种均衡关系就体现在价差上。价差是相对平稳的，这是一个大的假设前提 哎，如何计算这种价差呢？那就是对历史数据进行采样，采样点非常关键，每个采样点之间的间距大或小，控制在多少比较合理。这是要非常关注的，不同采样点间距，不同采样点的密度，得出来的结果可能都是不一样，太小，太密集，不精准，会上下跳动，会随机游走。太长呢，那可能敏感度又太低啊，不能够跟随行情的变化和它们之间协整关系的变化，来能够实时反馈出来。所以要精确把握好这个采样点之间的间距。那当这个间距达到理想值的时候，真正确定好这个间距的时候，再去采样。 好，基于采样结果计算这个加强序列的平均值和它的标准差。 然而，这个平均值和标准差，这个不同的采样周期，也就是说，采样点落在不同的周期可能都是不同的。那怎么样能够贴近的反反馈真实的情况呢？当前市场的正实状态呢？那就是让采样周期尽可能的贴近于当前，比方说最近的最近的10天、20天或者是5天3天，尽可能的贴近当前的周期。哎，贴近当前周期多长，这个阈值要很好的去衡量啊，一定要找到最合理最精确的阈值，然后来确定这个采样周期 当采样
import asyncio import json import websockets # 替换为你的实际 Hyperliquid 钱包地址 USER_ADDRESS = "0x你的钱包地址" # 示例: "0x123abc..." WS_URL = "wss://api.hyperliquid.xyz/ws" # 主网 WebSocket 地址（测试网用 wss://api.hyperliquid-testnet.xyz/ws） async def monitor_user_twap_slice_fills(): async with websockets.connect(WS_URL) as
Scale 和 TWAP 都是 Hyperliquid 上用于大额订单“拆单”（分批执行）的两种高级订单类型，主要目的是减少对市场的冲击、降低滑点，尤其适合像 PURR-USDC 这种流动性好但你想谨慎建仓/离场的资产（从你的截图看，PURR 24h 成交量超 200 万刀，OI 超 300 万，相对活跃）。 它们的核心区别在于拆单的依据和执行逻辑不同： 1. Scale 订单（缩放订单 / 分级限价订单） * 本质：基于价格区间自动放置多个限价单（limit orders）。 * 工作方式： * 你设置一个价格范围（Start Price 到 End Price）。 * 系统在该区间内均匀（或按 Size Skew 偏斜）分布多个限价单。 * 总
#!/usr/bin/env python3 """ 测试 user_non_funding_ledger_updates 接口 获取用户出入金记录（充值、提现、转账） """ import asyncio import sys from pathlib import Path import time from datetime import datetime from collections import defaultdict # 添加项目路径 sys.path.insert(0, str(Path(__file__).parent)) from address_
官方文档地址 Info endpoint | Hyperliquid DocsThe info endpoint is used to fetch information about the exchange and specific users. The different request bodies result in different corresponding response body schemas.Hyperliquid Docs 这是一个 Hyperliquid fill（成交记录） 的响应体示例（常见于 userFills 接口、WebSocket userFills 推送或类似地方），下面逐字段解释： { "coin": "xyz:AMD"
接口详情 * Endpoint：POST https://api.hyperliquid.xyz/info （主网；测试网用 https://api.hyperliquid-testnet.xyz/info） * type：固定为 "portfolio" * user：要查询的账户地址（0x 开头的 hex 字符串，支持主账户或子账户） * 响应内容（简化示例，实际包含更多字段）： 响应是一个数组，按时间粒度分组（如 "day"、"week"、"month" 等），每个分组内包含： * 这些历史数据对应平台 Portfolio 页面显示的 24h/7d/30d