币安事件合约 API：用开源库实现自动下单，以及 55.56% 那道线

有粉丝问怎么把事件合约做成自动化，这类需求很集中，所以我把接口层单独写一篇。

接口实现不是我写的——用的是一位开发者开源在 GitHub 上的库 （thuhollow2/Binance-Event-Contract-Interface， MIT，Python）。下面讲的是怎么用、以及哪里会踩坑，顺带把它和策略的关系说清楚。

一、事件合约是什么：一句话和三个参数

币安的事件合约是一种超短周期二元期权：

t 时刻按当前指数价入场
t + N 分钟后按结算价结算
结算价 > 入场价 → 赢，得 +payoutRatio × 本金
结算价 < 入场价 → 输，亏 −1.0 × 本金

下单接口的 payload 直接把这几个参数暴露出来：

{
  "orderAmount": "5",
  "timeIncrements": "TEN_MINUTE",
  "symbolName": "BTCUSDT",
  "payoutRatio": "0.80",
  "direction": "LONG"
}

三个关键参数就是：金额（orderAmount）、周期（timeIncrements）、 方向（direction）。而 payoutRatio 是交易所给的赔率，你改不了。

二、★ 0.80 这个数字决定了一切

payoutRatio: "0.80" 意味着：赢一次赚 0.8 倍本金，输一次亏 1.0 倍本金。

设胜率为 p，期望值：

EV = 0.8p − 1.0(1 − p) = 1.8p − 1

要 EV > 0：

p > 1 / 1.8 = 55.56%

这也是为什么我把这篇和另一篇拆开写：

文章	回答的问题
本篇	怎么把订单自动发出去
事件合约量化研究纪实	在 55.56% 之上站住到底有多难

三、接口形式：两个端点，两套凭证

币安的账号允许同时登录 1 个 App 端和 1 个 Web 端，所以有两套可用的调用方式。

App 端：用 x-token

curl 'https://www.binance.com/bapi/futures/v2/private/future/event-contract/place-order' \
  -H 'content-type: application/json' \
  -H 'clienttype: android' \
  -H 'x-token: app.<ID>.<TOKEN>' \
  -X POST \
  --data-binary '{"orderAmount":"5","timeIncrements":"TEN_MINUTE",
                  "symbolName":"BTCUSDT","payoutRatio":"0.80","direction":"LONG"}'

Web 端：用 p20t + csrftoken

curl 'https://www.binance.com/bapi/futures/v2/private/future/event-contract/place-order' \
  -H 'content-type: application/json' \
  -H 'clienttype: web' \
  -H 'csrftoken: <CSRF_TOKEN>' \
  -b 'p20t=web.<ID>.<TOKEN>' \
  -X POST \
  --data-binary '{"orderAmount":"5","timeIncrements":"TEN_MINUTE",
                  "symbolName":"BTCUSDT","payoutRatio":"0.80","direction":"LONG"}'

两者的区别（这是最容易踩坑的地方）

	App 端	Web 端
凭证字段	x-token	p20t（Cookie）+ csrftoken（Header）
格式	登录方式.ID.Token	p20t 同格式；csrftoken 是 www.binance.com 的 CSRF token
获取方式	抓包工具	浏览器开发者工具
有效期	未知	最长 5 天

四、它怎么拿到凭证：扫码登录 + 持久化

它选择了模拟 Web 端登录这条路（而不是让你手工抓 App 端的 x-token），因为对使用者更友好：

1. 用 Playwright 启动浏览器，打开币安登录页
2. 终端里渲染二维码，你用币安 App 扫码
3. 登录成功后，从浏览器上下文里取出 p20t 与 csrftoken
4. 写入 token.json（含 expirationTimestamp）
5. 之后调用 place_order_web() 时读取该文件

依赖很轻：

requests
playwright     ← 用于扫码登录
qrcode         ← 终端渲染二维码
pillow

pip install -r requirements.txt
playwright install chromium
playwright install-deps
python main.py

跑完会在当前目录生成 token.json。

五、工程层面的风险（法律风险见文首声明）

文首那份声明讲的是法律与合规。这里讲工程层面会实际遇到的问题：

风险	具体表现	应对
没有兼容性承诺	币安随时可改接口、加签名、加风控，你的程序直接失效	监控下单失败率，失败率突变时先怀疑接口而非策略
凭证静默过期	Web 端最长 5 天；过期后所有下单失败但不报错	显式检查 expirationTimestamp，临期自动重新登录
凭证泄露 = 资金风险	token.json 是明文的、可直接下单的凭据	加 .gitignore；不放同步盘；泄露后改密码使全部会话失效
无官方支持	出问题只能自己排查	保留详细的请求/响应日志（但注意别把凭据写进日志）

这些不是”注意一下”就能规避的，而是需要写进代码里的处理逻辑。

顺带说一句我在别处踩过的坑：“交易所跟用户对赌”这个结构本身也是一种风险。 在事件合约这类产品上，你的对手方就是平台。持续盈利会提高你被风控关注的概率—— 这是我在另一个平台上真实经历过的事，写在 另一篇文章里了。

六、所以：接口有了，然后呢

这是我最想强调的一点。

把下单自动化，只是把”手动亏钱”变成”自动亏钱”。 它不改变期望值。

而在 0.80 的赔率下，你需要稳定站在 55.56% 之上才能赚钱。这个门槛有多难？

我把同一批研究的完整纪实单独写了一篇，里面有：

• 十条研究军规（因果性检查、密封 holdout、参数平台、方向分离、多重比较）
• 八个真实被否掉的方向，包括一个因未来函数让胜率从 79.9% 掉到 53.7% 的策略
• 诚实的结论：真实前向约 56%–57.5%，薄、正，但统计上还不显著

→ 事件合约量化研究纪实：过程、结果和失败档案

七、给你的使用顺序建议

如果你确实要用这个库，我建议这个顺序：

1. 先把平衡点算清楚            ← 55.56%，写在墙上
2. 用它只做【信号记录】，不下单  ← 累积你自己的前瞻样本
3. 累计够样本后，算胜率的置信区间 ← 看下界有没有过平衡线
4. 只在样本足够、下界过线时才考虑上真钱
5. 上真钱后先小仓位跑纸面观察期   ← 样本外到实盘之间还有一道折扣

第 2 步是关键，也是最多人跳过的一步。 大部分人拿到自动化工具后第一反应是”接个信号跑起来”， 但你没有前瞻样本时，你根本不知道自己的信号在真实口径下是什么胜率。

这个库真正的价值不是”帮你赚钱”，而是让你能低成本地积累真实口径的前瞻记录。 把它当测量工具用，不是当赚钱工具用——这个定位差别，决定你是先亏钱还是先有数据。

---

本文仅供技术交流，不构成投资建议。文中提到的接口库为第三方开源作品，与作者无隶属关系。 接口逆向与自动化交易存在账号与资金风险，请自行判断。