多币种回测验证 v2 分析报告（Gate1+Gate2 + 4H 相关系数过滤） 1. 报告元信息 项目 说明 脚本 validate_multicoin_btc_base_v2 运行参数 --min-bars 1000 报告生成 基于 2026-02-17 单次运行终端输出整理 数据范围 94 个币种，4H 级别，与 BTC 配对 过滤链路 4H 相关系数 ≥ TARGET_CORR_THRESHOLD → Gate1 协整 → Gate2 健康监控，三者均通过才纳入回测 2. 执行概要 * Gate 预计算：94 币 × 时间桶，
多币种回测验证 v2 分析报告（Gate1+Gate2） 1. 报告元信息 项目 说明 脚本 validate_multicoin_btc_base_v2 运行参数 --min-bars 1000 报告生成 基于 2026-02-17 单次运行终端输出整理 数据范围 94 个币种，4H 级别，与 BTC 配对协整 + 健康监控 2. 执行概要 * Gate 预计算：94 币 × 时间桶，协整 Gate1 + 健康 Gate2，耗时约 690s。 * 有效币种：31 个币种至少有一次通过 Gate（通过率 >
BUG 分析：网络恢复后 API 限流排队深度始终卡在 30 摘要 * 现象：WebSocket 重连成功后，日志中「API 限流排队拥塞」的「排队深度」长期停留在约 29～30 个请求，「需等待」约 74s，看似队列不消化。 * 影响：重连后 K 线 HTTP 拉取缓慢、日志持续刷拥塞告警，易被误判为限流或配置错误。 * 根因：「排队深度」表示的是当前请求前已预约的时间槽个数，不是队列长度上限；分析 worker 数为 30，全局限流每 2.5s 一个槽位，稳态下 30 个 worker 持续占满槽位，故排队深度恒为约 30。
完整因果链：Gate1/Gate2 阻塞 Adaptive Z 回归平仓 Bug ID: GATE-EXIT-BLOCK-001 严重级别: 🚨 Critical 发现日期: 2026-02-16 状态: 已识别，待修复 执行摘要 现象：开仓成功后，若后续K线周期Gate1或Gate2未通过，该仓位无法通过Adaptive Z回归触发平仓。 影响：平仓仅能依赖止损、移动止损、持仓超时；无法在均值回归时主动平仓，违背策略设计初衷。 根因：退场检查与入场共用"分析结果存在"前置条件，Gate误伤了仅需zscore的退场路径。 1. 输入（Input / Trigger） 1.1 初始状态（T0） 维度 状态 持仓状态 ETH/USDC:USDC
BUG 分析：Gate 不通过时无法通过 Adaptive Z 回归平仓 摘要 * 现象：某 symbol（如 ETH/USDC:USDC）开仓成功后，若在后续 K 线周期里 Gate1 或 Gate2 无法通过，则该仓位无法再通过 Adaptive Z 回归触发平仓。 * 影响：平仓仅能依赖止损、移动止损、持仓超时；无法在均值回归时主动平仓，持仓时间与风险偏离策略设计（严重 Bug）。 * 根因：退场检查与入场共用「分析结果存在」这一前置条件；Gate 本意过滤入场质量，却误伤了仅需 zscore 的退场路径。 完整因果链 1. 输入（Input） 类型 描述
BTC 基准多币种回测 v2 — Gate1+Gate2 真实协整验证结果 运行时间: 2026-02-16 19:31 ~ 20:35 脚本: src/scripts/validate_multicoin_btc_base_v2.py 基准: BTC/USDC:USDC | 回测天数: 30 | min-bars: 1000 1. 背景与目标 v1 回测脚本 (validate_multicoin_btc_base.py) 跳过了 Gate1（协整检验）和 Gate2（健康监控），导致回测结果比实盘宽松。实盘中 analyze_multi_period() 会在策略评估前强制执行两个门控：
PURR 单币种 EMA/STD 解耦全参数回测报告 回测日期: 2026-02-16 标的: PURR/USDC:USDC (base=HYPE/USDC:USDC) 回测区间: 2026-01-23 08:50 ~ 2026-02-16 10:25 数据点数: 6641 (23.1 天) 目录 * 数据概况 * 方案A: 耦合 EMA=STD * 方案B: 解耦 EMA!=STD * 方案C: 仅调 threshold * 方案D: 全参数网格搜索 * 方案E: 最终对比 * 结论与推荐配置 数据概况 数据点: 6641 | z4h 均值=
BTC 基准多币种全参数回测报告 回测日期: 2026-02-16 基准代币: BTC/USDC:USDC 目标代币: 94 个有效代币 (≥1000 bars) 回测天数: 30 目录 * 数据概况 * 方案A: 耦合 EMA=STD * 方案B: 解耦 EMA!=STD * 方案C: 仅调 threshold * 方案D: 全参数网格搜索 * 方案E: 最终对比 * 全局最优各币种明细 * 方案F: 解耦vs耦合直接对比 * 结论与推荐配置 数据概况 前10个代币的数据量和z4h分布: 代币 数据点 z4h 均值 z4h 标准差 z4h 范围 SOL 2059 +0.512
数据库设计文档 TimescaleDB 数据库结构、索引策略与自动化运维 概览 * 数据库: TimescaleDB（基于 PostgreSQL 16） * 数据库名: crypto_data * 容器名: crypto_timescaledb * 版本: 1.2（含交易模块表结构） 指标 数值 表数量 7 张 Hypertable 4 个 索引总数 21+ 压缩策略 4 个 连续聚合 1 个 表结构详解 1. klines — K 线数据表（Hypertable） 存储多币种、多周期的 K 线 OHLCV 数据。 字段 类型
合并方案：fixed_merge_to_allcoins → main 生成日期：2026-02-16 目标：将 fixed_merge_to_allcoins 分支合并到 main，使 main 同时支持通用多币种服务和 HYPE 专用服务 1. 概述 1.1 合并目标 在 main 分支上同时管理两个独立运行的服务： 服务 入口模块 监控范围 Workers 通用版 src.services.realtime_kline_service 全部活跃币种（动态） 30 HYPE 专用版 src.services.realtime_kline_service_hype
"开仓信号详细告警"模块完整因果链分析 📋 分析目标 建立从输入到BUG的完整因果链：输入 → 状态变化 → 调用路径 → 出错点 → 根因 1️⃣ 输入（Input） 触发条件 # orchestrator.py:515-533 open_result = self._position_manager.open_position(signal, adaptive_z=adaptive_z) if open_result: position, order_result = open_result # ...保存信号、更新统计... # 发送开仓告警（触发点） self._send_entry_alert( signal, # 交易信号对象 multi_period_
开仓信号详细告警模块设计分析报告 结论：未发现严重 BUG 整体设计具备多层降级与异常隔离，递归有界，关键依赖有兜底，不存在会导致崩溃、死循环或错误告警内容的严重缺陷。以下为完整因果链与审查要点。 完整因果链：输入 → 状态变化 → 调用路径 → 出错点 → 根因 输入 (Input) 来源 内容 策略/服务层 on_entry_signal(symbol, multi_period_result, latest_alt_price, avg_zscore_4h, direction, signal_strength, adaptive_z, l2_snapshot) 开仓成功后 signal（本函数内构造）、multi_period_result（原样透传）、position,