← 返回 Quant Digests · 站点首页

别把这份 2026 新 repo 只读成“费率排行榜”:对 short-cycle desk,更该先测的是「fee-coverage gated cross-venue funding carry」这条完整 raw alpha

更新时间:2026-04-02 17:37 UTC 研究时间:2026-04-02 17:34 UTC 类型:2026 GitHub 新 repo source audit(`README.md` + `config.yaml` + `scripts/scan_all.py` + `scripts/auto_selector.py` + `scripts/fee_coverage_calculator.py` + `scripts/rolling_position.py` + `scripts/trailing_stop.py`) 主题标签:raw-alpha/carry/funding/cross-venue/perp-perp/relative-value/stat-arb/fee-coverage/cost-gate/rolling-position/trailing-stop/gate-bitget-aster-okx/1m/3m/5m/15m/repo/public-data/cost/risk 证据类型:repo-based source audit(工程证据为主,含 README 披露的实盘样例与源码规则)

源文件:research/quant_digests/2026-04-02_1734_feecoverage-gated-crossvenue-funding-carry-alpha.md

1. 这次看了什么

一句话核心结论

这轮最值得 intake 的,不是“又一个 funding scanner”,而是 repo 里那条很实在的完整 raw alpha:先找同币跨所 funding spread,再用明确的 fee coverage 门槛决定这笔 carry 到底值不值得做;而 rolling build、trailing stop、exchange reliability 这些都已经把它往完整策略推了一步。

一句话它是怎么证明的

2. 先回答一句:这篇东西的 base alpha 是什么?

这次 base alpha 很清楚,而且是 raw alpha

不是 regime,不是 filter,也不是 risk overlay 假装成 alpha。

alpha 本体就是:

  1. 同一 underlier 在不同 perp venue 的 funding 不同步;
  2. 如果某个 venue 更“贵”(更高正 funding)而另一个更“便宜”(更低甚至负 funding),就可以做跨 venue delta-neutral carry;
  3. 真正的收益来源是 funding differential,价格方向尽量被对冲掉。

所以它的正确归类是:

fee coveragerolling buildtrailing stop 很重要,但它们都不是 alpha 本体;它们是这条 alpha 能不能活到实盘的执行壳。

3. 为什么这轮值得写,而不是继续堆一个泛 funding 摘要

虽然项目最近已经 intake 过不少 funding / basis / carry 方向,但这轮仍然值得写,原因很简单:

  1. 它仍然是 raw alpha,不是纯 overlay。
  2. 这点先过线了。它服务的是 raw alpha 素材池,而不是又写一个“可以给别的 alpha 当 gate”的低优先级组件。

  3. 它补的是“显式费用门槛”这一块。
  4. 最近 desk 的 funding 主题很多都强调 richest vs cheapestbasis diffasync clock,但这份 repo 最值得拿走的是:能不能开仓,不先看 headline APR,而先看成本覆盖。

  5. 它更像完整策略骨架,而不是一句研究结论。
  6. 这里不是只给你一个排序器;它把 entry / ranking / position management / stop / risk preference 都做了模块化拆解。

  7. 它很适合映射到 1m / 3m / 5m / 15m
  8. funding 本体不是逐根 1m 主信号,但完全可以用:

也就是说,这轮不是“又来一篇 funding”,而是把 funding carry 从思路池往可执行素材池又推进了一步

4. 这次看了什么来源

4.1 主工程来源

4.2 本轮实际审阅的关键文件

4.3 原始可读链接

5. 这份 repo 真正给了 desk 什么

5.1 先别看 fancy 词,主线其实很朴素

repo 的策略主线就是:

config.py / config.yaml 里给出的默认骨架很直接:

翻成人话: 它不是在找“理论上最大 spread”,而是在找“你真能下得动、且 venue 风险不离谱的 spread”。

5.2 README 披露的样例收益,只能当工程线索,不能当学术事实

README 给出的实盘样例是:

这些数字当然不能直接信成 desk 结论,因为:

但它至少提供了一个很重要的信息: 作者在实际关注的是“小票 funding 高离散窗口”,不是 BTC/ETH 这种被挤平的成熟 carry。

5.3 这轮最值钱的不是扫描器,而是 fee coverage 这层 honesty gate

fee_coverage_calculator.py 用 taker fee 假设:

并默认:

我按源码口径重算了几个最关键的阈值(以 Gate + Bitget 为例):

  1. rate diff = 0.10% / settlement
  1. rate diff = 0.20% / settlement
  1. 若按这段代码的假设,

这三个数字非常重要。因为它们直接告诉 desk: 这条 alpha 不是 always-on 收租,更像“高 spread、高手续费覆盖、高离散窗口”才值得碰的 pocket carry。

5.4 这份 repo 其实已经把 alpha 与 overlay 分开了

repo 里的模块分工很清楚:

也就是说,它非常适合按 desk 语言重述成:

这就是为什么它不是“只会扫表”的玩具,而是可拆成完整策略骨架的来源。

6. 但这份 repo 也有两个必须先修的地方

6.1 funding 方向口径疑似有反向风险

scan_all.py 里是这样排机会的:

如果这些交易所 funding API 采用的是标准口径(正 funding = longs pay shorts),那么经济方向应该通常是:

换句话说,源码里的 leg 命名和真实资金流方向之间,至少存在 sign-convention risk

这不意味着这条 alpha 失效,反而说明: alpha 本体是对的,但第一版复现必须自己统一 funding 符号与收付款方向,不能直接照抄 scanner 输出。

6.2 不同脚本里的单位口径并不完全一致

源码里至少有三种容易混淆的写法:

这提示一个非常实际的问题: spread 在不同脚本里到底是 decimal、百分数,还是 bps,没有被统一到底。

所以第一轮最小实验里,必须先做一件很无聊但很关键的事:

否则回测会很容易“看起来很赚钱,其实只是单位没对齐”。

7. 对当前 1m / 3m / 5m / 15m desk 的正确读法

7.1 这条 alpha 服务短周期,但不是逐根 1m 主信号

更诚实的拆法应该是:

也就是说:

7.2 它和近期 raw alpha 素材池的关系

这条线和最近 desk 的 accumulation 是互补的:

而且它的价值不在“Funding carry 这个词新不新”,而在: 把 funding carry 的真正门槛——费用壳、venue 可靠性、滚动建仓——写得很直白。

8. 策略拆解(按 desk 口径重述)

9. 最小可复现实验(下一步怎么测)

9.1 研究假设

H1: 同币跨 venue funding differential 在 alt-heavy、流动性尚可的币上,仍能形成可交易的 carry pocket。 H2: 真正决定这条 alpha 能不能活下来的,不是 raw spread 本身,而是 fee coverage gateH3: 在统一符号和单位后,很多 headline 高 APR 机会会被费用壳和执行壳大幅筛掉。

9.2 数据源、公开性、更新频率

9.3 first-pass 实验设计

先不要卷复杂优化,第一轮只跑三组:

  1. A:raw spread only
  1. B:raw spread + fee coverage gate
  1. C:B + rolling build / profit protection

统一比较:

9.4 先测什么,不先测什么

先测:

先不测:

9.5 建议的第一刀参数

10. 风险与限制

  1. repo 的收益展示偏 showcase,不是标准化回测。
  2. 小票 funding carry 很容易被执行细节吃掉。 headline APR 再高,腿没法同步就没意义。
  3. sign / unit consistency 是本轮最大工程风险。 不先修这两个,后面的“优化”都不可信。
  4. 跨 venue carry 有额外 operational risk。 包括 API 稳定性、资金调拨、单边爆仓、仓位不同步、提现延迟等。
  5. 这条 alpha 更像 pocket,不像 always-on。 从 fee coverage 的阈值就能看出来,它天然更依赖高离散窗口。

11. 一句话结论

如果这轮只拿走一件事,我会拿走这句:跨 venue funding carry 当然还是 raw alpha,但真正值得 desk 先复现的,不是“谁 funding 高就冲谁”,而是“统一 funding 符号与单位后,只做那些 spread 足够厚、费用壳真能覆盖、venue 也够可靠 的 pocket carry”。