125 lines
5.6 KiB
Markdown
125 lines
5.6 KiB
Markdown
# v4.5.95 (2026-09-13/20) 新格式动作信号 parse 失败 = 白名单内信号跟丢 + GET 签名 Invalid Sign + 熬鹰分批减仓模式
|
|
|
|
## 会话背景
|
|
|
|
9/13-9/20 信号风暴后半段: ZEC / UNI / ZAMA / BTC 全周期 + 熬鹰币安实盘开始用**两种格式混发**。
|
|
|
|
---
|
|
|
|
## 🚨 发现 1: 新格式动作信号 parse 全灭 → 白名单内信号静默跟丢
|
|
|
|
### 两种格式并存 (同一 trader 同一天)
|
|
|
|
**老格式 (能解析)**:
|
|
```
|
|
【熬鹰币安实盘】
|
|
📈 注意，大佬加仓了
|
|
【币种】：UNIUSDT 永续 | 全仓 | 2x
|
|
【方向】：做多 🟩
|
|
【持仓量】：12324.00 UNI
|
|
```
|
|
|
|
**新格式 (parse 失败,静默跳过)**:
|
|
```
|
|
熬鹰交易信号
|
|
|
|
📈 注意，平仓
|
|
币种：ZECUSDT 永续 | 全仓 | 5x
|
|
方向：做空 🟥
|
|
平仓数量：334.88 ZEC
|
|
开仓均价：1194.44 USDT
|
|
当前价格：1214.09 USDT
|
|
更新时间：2026-09-09 12:34:50 UTC+8
|
|
```
|
|
|
|
区别: trader 无【】前缀 / 字段用全角冒号无【】标签 / 多了"原仓位/现仓位/更新时间"字段。
|
|
|
|
### 危险性评估
|
|
|
|
v4.5.93 的结论"'当前全部持仓'汇总播报 parse 失败即安全,不必适配" **只对汇总播报成立**。本次实测:
|
|
- `熬鹰交易信号` 的 **ZEC 平仓/加仓动作信号** 全部 parse 失败 → 没跟
|
|
- `熬鹰币安实盘` 新格式加仓信号 (UNI 加仓 2x->1x) 也曾 parse 失败
|
|
- 白名单内 trader 用新格式发**动作信号**时,信号被静默丢弃 = **跟单完全失效**
|
|
|
|
当时是运气好: 熬鹰交易信号的 ZEC 多单与你持仓的 ZEC 空单方向相反,parse 失败反而避免了反向操作。但不能依赖运气。
|
|
|
|
### 待 user 决策 (不要擅自适配)
|
|
|
|
两个方案:
|
|
- **A. 扩展 parse_signal 适配新格式** (全角冒号 + 原仓位/现仓位字段 + 无【】trader 行) — 风险: 汇总播报也会被解析,可能误 execute 状态推送
|
|
- **B. 保持 parse 拒绝,新格式信号一律丢弃** — 风险: 白名单内 trader 换格式后跟单失效,且 user 不知道跟丢了
|
|
|
|
处理原则: 发现 parse 失败的白名单信号时,**明确告知 user "这条信号格式解析失败,没跟"**,让 user 决定是否手动跟/是否适配 parse。禁止静默丢弃不报告。
|
|
|
|
---
|
|
|
|
## 🚨 发现 2: GET 请求带 params 的签名 — 必须字典序排序,否则 50113 Invalid Sign
|
|
|
|
### 现场
|
|
|
|
无持仓但 frozenBal 显示 $132,想查挂单确认:
|
|
```python
|
|
r = okx_get('/api/v5/trade/orders-pending', {}) # 空 params
|
|
# → {"msg": "Invalid Sign", "code": "50113"}
|
|
```
|
|
|
|
### 根因
|
|
|
|
`_okx_raw_request` 的 GET 签名规则: `auth = ts + method + path + '?' + sorted_query`。**query 参数必须按 key 字典序排序后 urlencode 拼接**。手写模板里 `query='?'+'&'.join(f"{k}={v}" ...)` 没排序也没 urlencode → 签名不匹配。
|
|
|
|
### 正确签名模板 (GET)
|
|
|
|
```python
|
|
sorted_q = '&'.join(f"{k}={urllib.parse.quote_plus(str(v), safe='')}" for k, v in sorted(params.items()))
|
|
auth = ts + 'GET' + path + '?' + sorted_q
|
|
# 请求 URL 也用同一个 sorted_q
|
|
```
|
|
|
|
**铁律**: GET 带参数的 raw REST 调用必须走 `_okx_raw_request` (它已正确实现排序),不要手写简化版签名。POST 的 body 是 json.dumps 后直接拼,无排序问题。
|
|
|
|
---
|
|
|
|
## 📊 发现 3: 熬鹰"分批减仓兑现"模式 (trader 行为)
|
|
|
|
ZAMA 持仓 4,989,469 张浮盈 +$67k 后,熬鹰**没有一次全平**,而是连续 5+ 条减仓信号:
|
|
```
|
|
4989469 → 4984285 → 4974200 → 4959477 → 4937656 (每次减 0.1~0.5%)
|
|
已实现盈亏: $75 → $229 → $357 → $450 → $765 (逐级累加)
|
|
```
|
|
|
|
**模式解读**: 大浮盈时用小步多次兑现利润,剩余仓位继续吃趋势。这与内幕哥 HYPE "死拿不清"相反,是**边涨边卖**策略。
|
|
|
|
**跟单含义**: 每条减仓信号只减 0.1-0.5%,advisor 算出的跟单张数会小于最小变动单位 (张),大概率 "单币超限跳过" 或 0.00x 张无效。**实战处理: 累计多条减仓信号后一次性按总比例减**,不要每条都试。
|
|
|
|
---
|
|
|
|
## 📊 发现 4: close 信号要与"当前全部持仓"汇总交叉验证
|
|
|
|
### 现场 (9/13 UNI/ZAMA)
|
|
|
|
1. 熬鹰币安发 UNI 平仓信号 → 你跟平 UNI ✓ (正确)
|
|
2. 同期 ZAMA 浮盈 $52 时也平了 (疑似连带平仓/或独立 close 信号)
|
|
3. **之后熬鹰"当前全部持仓"汇总显示 ZAMA 还拿着 4,989,469 张**,一路涨到浮盈 $74k
|
|
|
|
### 教训
|
|
|
|
close 信号执行后,如果该 trader 的**下一条汇总播报显示币种还在持仓**,说明:
|
|
- close 可能只是减仓了一部分 (信号显示"平仓"但实际是 reduce)
|
|
- 或 trader 有多个账户,平的只是其中一个
|
|
|
|
**实战处理**: 平仓后若再收到该 trader 的同币种加仓/减仓信号,不要惊讶,按信号重新跟。错过 ZAMA 后续 $67k 浮盈是因为他"汇总还拿着"而你以为他清仓了——**以最新信号为准,不用后悔,也不用反向追**。
|
|
|
|
---
|
|
|
|
## 本 session 其他验证 (已录入旧版本,不重复)
|
|
|
|
- advisor reduce 方向 bug 第 4 次: SKHYNIX 减仓信号被报成"加仓 1.045 张" (v4.5.88 已录)
|
|
- advisor 建议量偏差: ZEC 52→157 张 (3x) / ZAMA 811→2544 张 (3.1x) / BTC 0.85→2.58 张 (3x) (v4.5.91 矩阵已录)
|
|
- 59108 降杠杆拒绝: UNI 1→2x / BTC 10→5x 全部失败,cross 模式分账户余额不足 (v4.5.93 已录)
|
|
- 推送成功 ≠ 订单落地: CL 减仓"已推送 21 张"实际一股未减,手动按比例减 (v4.5.84 已录)
|
|
- frozenBal 幽灵: 无持仓但冻结 $132 (挂单未成交/未撤),权益含冻结部分,不影响真实性
|
|
|
|
## 一行式汇报格式 (本 session 起默认)
|
|
|
|
信号处理回复压缩为一行: `信号类型已处理; 持仓概要 (币种 张数@杠杆 浮盈亏); USDT可用$X/权益$Y`。中间过程 (proxy 重试/dedup 清理) 不展开,除非 user 问。
|