源文件:research/quant_digests/2026-04-05_1625_btceth-fairvalue-gap-rv-alpha.md
feature_engine.py / signal_engine.py / interval_profiles.py / engine.py / risk_engine.py / backtest.py / monitor.py)+ Binance 公共 15m/1h live portability probe这轮主看的是一个非常新的 GitHub repo:
joanduso) (2026), _Crypto Relative Value Engine_这次重点审了这些文件:
README.md:项目目标、模式、monitor / dashboard 结构feature_engine.py:核心 fair-value / residual / z-score 计算signal_engine.py:entry gate / ranking / fee 假设interval_profiles.py:15m / 1h / 4h 窗口映射engine.py:主流程与默认 risk limitsrisk_engine.py:position sizing / stop / take-profit / time-stopbacktest.py:历史 outcome 模拟框架monitor.py:把 raw alpha 与 funding / basis / news / regime 叠加成监控器我最后选它,不是因为它有 dashboard,而是因为这里面真正值钱的不是 UI,而是一条非常明确、可独立复现、而且天然适合 15m / 5m 迁移的 raw alpha:
> beta-adjusted relative-value mean reversion。
这条线比再写一篇 filter / overlay 更值得的原因很简单:
5m / 15m 的 liquid perp universe。---
先把最关键的问题说透。
这条策略的核心不是 news,不是 ETF flow,也不是 BTC regime overlay。 真正的 base alpha 是:
> 某个 alt 相对 BTC + ETH 联合解释出来的 fair value 出现了统计上足够大的偏离,而这种偏离倾向于均值回归。
翻成人话:
这不是 filter 伪装成 alpha。 它本身就是一条:
repo 里当然还有:
btc_market_bias_engine.pyregime_engine.pynews_engine.pysignals/funding_arbitrage.pysignals/basis_trade.py但这些更像:
如果 bot7 这一轮要遵守“优先 raw alpha / 可独立复现完整策略”的原则,那最该拿走的显然不是这些附属层,而是:
> BTC+ETH fair-value gap 的 residual z-score 回归壳。
---
因为它直接补的是当前 desk 很需要的一类素材:
而且它有三个对 short-cycle desk 很实用的优点:
它不是只拿 BTC 当 benchmark,而是把 BTC + ETH 一起放进回归里。
这很重要,因为很多 alt 的短周期表现并不是“只跟 BTC 一条线”,而是:
所以用双 benchmark 做 fair value,比单纯 alt vs BTC spread 更接近我们实际看到的盘面结构。
传统 pairs 的问题是:
这条写法更像:
这对 desk 来说,比手工维护很多 pair 更容易工程化。
源码里不只是给了 residual z-score,还把下面这些都写出来了:
也就是说,这不是“有个想法,但离实盘还很远”的材料;而是一个能直接压成最小实验的壳。
---
repo 默认用的是 Binance 公共接口:
api/v3/klines:spot K 线fapi/v1/fundingRate:futures funding默认 alt universe:
XRPUSDTSOLUSDTADAUSDTDOGEUSDTBNBUSDTLTCUSDTLINKUSDTAVAXUSDTbenchmark:
BTCUSDTETHUSDT这意味着最小复现实验不依赖私有数据:
15m / 1h / 4h)feature_engine.py 的核心是一个滚动 OLS:
``python log_alt ~ intercept + beta_btc * log_btc + beta_eth * log_eth ``
在每个时点得到:
predicted_log_pricefair_value = exp(predicted_log_price)residual_log = log_alt - predicted_log_pricez_score = (residual_log - rolling_mean) / rolling_stddeviation_pct = alt_price / fair_value - 1然后交易方向非常直接:
deviation_pct < 0 → LONG(alt 低于 fair value)deviation_pct > 0 → SHORT(alt 高于 fair value)这是非常干净的 raw alpha 结构。
interval_profiles.py 里,15m profile 直接写死为:
96 * 7 = 672 bars(约 7 天)96 * 3 = 288 bars(约 3 天)96 bars(约 1 天)96 bars(约 1 天)这点很关键,因为它说明:
> 这不是日频想法硬搬到盘中;作者本来就在按 15m 口径设计。
signal_engine.py 里 COPILOT 默认阈值是:
abs(z_score) >= 1.75realized_volatility <= 1.40quote_volume >= 2,500,000spread_stability_score >= 0.45abs(funding_rate) <= 0.0015fee_bps = 8top_n = 5翻成人话就是:
engine.py + risk_engine.py 的 COPILOT 默认 risk 框架:
13%7%1% equity48h3%6%而且不是死板固定止损:
edge_after_fees_pct 和 stop 距离联动;所以这条题材满足“可直接落地完整策略(entry/exit/sizing/risk/cost)”这一条。
---
GitHub API 元数据:
created_at = 2026-03-13T04:47:55Zpushed_at = 2026-04-01T19:57:14Z也就是说,这轮确实算得上近 5 年内、而且是最近几周还在活跃的新 repo。
这比很多只说“做 z-score reversion”但不告诉你窗口怎么压缩的材料强很多。
作者已经明确把 15m 结构写成:
7 天回归看 fair value3 天看 residual 是否极端1 天看残差是否稳定、波动是否可接受这非常适合我们直接压成 15m -> 5m 的最小移植实验。
核心 admission 条件:
|z| >= 1.75stability >= 0.45fee = 8 bps这组阈值不是纯学术写法,而是明显在试图兼顾:
15m live probe:信号是活的,但默认流动性门槛对 spot 15m 偏高用 repo 默认 universe + Binance 公共数据,在 2026-04-05 16:15 UTC 的 15m 快检结果里:
z = -2.19spread_stability_score = 0.86z = -1.88spread_stability_score = 0.91但:
quote_volume >= 2.5m 这一条在 spot 15m 上偏严。这很有价值,因为它说明:
> alpha 本体是活的,但 15m 直接照搬 repo 的 spot volume gate,可能会把大部分机会先挡掉。
1h,SOL 当下就能过默认 admission我又按 1h profile 快检了一次,2026-04-05 16:00 UTC:
z = -1.82realized_vol = 0.31quote_volume ≈ 2.50mstability = 0.80这进一步说明:
monitor.py 里还能叠:
但这些没有盖掉 raw alpha 主体,反而让我们更容易做拆件实验:
这正符合现在 desk 需要的“把素材拆成可复现实盘组件”的节奏。
---
我会把这条 repo 里的核心思想,压成下面这个更适合我们 desk 的版本。
> 先用 BTC+ETH 双 benchmark 定义 alt 的 fair value,再做 residual z-score 回归;把 liquidity / vol / stability / funding 当 admission gate,而不是把 news / macro 当主信号。
这意味着它服务的是一条非常标准、但很实用的 raw alpha:
5m / 15m因为这类 fair-value gap 信号最怕两件事:
15m 正好是个还不错的折中层:
1m 那么吃微观结构噪音;如果要往 5m 推,我反而建议:
volume gate 和 fill model 重标定。#### 交易对象
10~20 个最活跃 perpBTCUSDT + ETHUSDT#### fair-value 模型 每个 alt 在每个 bar 做:
``text log(alt) = a + b1*log(BTC) + b2*log(ETH) ``
得到:
fair_valueresidual_logz_score#### 入场
|z| >= z_entryresidual stability >= thresholdrolling realized vol <= max_volquote volume >= liquidity_floor|funding| <= funding_cap其中:
z_entry 初始先测 {1.5, 1.75, 2.0, 2.25}liquidity_floor 不要直接抄死 2.5m,而是改成:{0.5m, 1.0m, 2.0m}过去 30 天本币同周期 volume 的 50% / 70% / 85% 分位#### 方向
#### 离场 优先测三种:
z 回到 0 ~ ±0.25H ∈ {8, 16, 24, 32} bars#### sizing / risk
0.5% ~ 1.0%1~3 个最高分候选2.0% ~ 4.0% 或 k * residual-vol1.25x ~ 2.0x stop2R 或 3R#### 成本
8 ~ 12 bps4 ~ 8 bps1 ~ 3 bps---
这是这篇最重要的部分:别只停在“能看懂源码”。
先验证:
> BTC+ETH fair-value gap 的 residual z-score,在 crypto short-cycle 上是否有稳定回归边。
15m 主测,5m 次测10~20 个高流动 USDT perpBTCUSDT + ETHUSDT{5d, 7d, 10d}{2d, 3d, 5d}|z| ∈ {1.5, 1.75, 2.0, 2.25}z→0 / time-stop / opposite signal6 / 8 / 10 / 12 bps至少看这 8 个:
这轮 live probe 已经给了一个很明确的信号:
2.5m quote-volume gate 会过严。所以第二轮最该做的不是先叠 news,而是先做:
> absolute liquidity floor vs rolling percentile liquidity floor
也就是比较:
2.5m1.0m看看哪种更适合 15m。
把下面几种并排:
alt ~ BTCalt ~ ETHalt ~ BTC + ETHalt ~ market basket这一步很关键,因为如果 BTC+ETH 没明显优于 BTC only,那实盘就该选更简单、更稳的版本。
---
这在研究阶段不是致命问题,但在实盘迁移上要小心:
所以 desk 版最好直接改成:
fair-value 模型本身不是圣杯:
所以后续可加:
但这些是第二阶段,不应该妨碍先做最小实验。
当偏离来自:
那 fair-value gap 可能不是 mispricing,而是真实 re-pricing。
所以后续要加一个很实用的 veto:
但注意:这仍然是给 raw alpha 加保护,不是把主题改成 filter digest。
---
如果只用一句话总结:
> 这份 2026 新 repo 最值得 desk intake 的,不是它的 dashboard,也不是它附带的宏观/新闻模块,而是那条很清楚的 raw alpha:用 BTC+ETH 双 benchmark 定义 alt fair value,再做 residual z-score mean reversion。
它为什么值得进研究池:
15m 上 SOL / XRP 都出现了明显 fair-value gap,只是 default volume gate 对 spot 15m 偏严。如果本轮只留一个“下一步就该测”的任务,我的答案是:
> 先把这条 BTC+ETH fair-value gap alpha 用统一的 Binance perp 口径,在 15m 上做一轮 volume-gate 重标定 + z-score / exit 网格测试。
这一步做完,才能判断它到底是:
---
feature_engine.py: <https://github.com/joanduso/crypto-relative-value-engine-/blob/main/feature_engine.py>signal_engine.py: <https://github.com/joanduso/crypto-relative-value-engine-/blob/main/signal_engine.py>interval_profiles.py: <https://github.com/joanduso/crypto-relative-value-engine-/blob/main/interval_profiles.py>engine.py: <https://github.com/joanduso/crypto-relative-value-engine-/blob/main/engine.py>risk_engine.py: <https://github.com/joanduso/crypto-relative-value-engine-/blob/main/risk_engine.py>backtest.py: <https://github.com/joanduso/crypto-relative-value-engine-/blob/main/backtest.py>monitor.py: <https://github.com/joanduso/crypto-relative-value-engine-/blob/main/monitor.py>