binance-prediction-updown

Binance Prediction Up/Down

定期的に開催される BTC Up/Down ラウンドを取引するためのひな型です。ラウンドスケジューラー、スクリーニングゲート、提示価格と比較する確率の判定コントラクト、注文と決済の処理、償還、2 つのオフライン評価ハーネスが含まれます。

最初にお読みください

ここに記載されているリスク管理、賭け金、しきい値はすべて、保護策ではなく「提案」です。

• このスキルには戦略が含まれていません。 同梱のフックはパイプラインを動かすための例であり、読み込む数値はご自身で測定して設定するものです。「戦略フック」に記載された参照シグナルは、誤差範囲が ±1.9pp のとき、ラウンドあたり約 +0.65% の純利益となります。これは基準の例であり、そのままコピーする設定ではありません。
• 的中率は優位性を意味しません。 シグナルが注目する状態を市場がすでに織り込んでいる場合、的中率が 58% でも利益はゼロです。それを見極められるのは、ウォークスルーのステップ 3 だけです。
• ポジションは無価値で失効する可能性があり、ラウンドごとの最大損失は賭け金です。損切り注文を出す必要はありません。ポジションは自動的に決済されます。

依存関係

スキル	用途
binance-agentic-wallet	prediction *、wallet *

ローソク足データは Binance の公開マーケットデータエンドポイント（api/v3/klines）から取得します。API キーもセッションも必要ありません。

baw --version
baw cli-check --required-version "$(grep -m1 requiredCliVersion SKILL.md | tr -dc '0-9.')" --json

未公開です。 このスキルはインストールした場所でのみ利用できます。binance-agentic-wallet は https://github.com/binance/binance-skills-hub から入手できますが、このスキルはまだそこから提供されていません。

はじめに

ステップ 1 と 3 は無料で、どちらもこのアイデアを断念する判断につながる可能性があります。ライブモードの前に両方を実行してください。

1 · オフラインでバックテストする — ログイン、設定、資金は不要です。

python3 backtest.py fetch --symbol BTCUSDT --interval 1h
python3 backtest.py eval  --interval 1h --hurdle 0.521

取引するラウンドの時間間隔（5m／15m／1h／1d）を使ってください。同じシグナルでも、時間間隔によって測定結果は大きく異なります。eval は、設定に貼り付ける hit_table を出力します。

2 · 設定を書く — 初回実行時に空のテンプレートが書き出され、終了します。

python3 updown.py                        # writes the template
$EDITOR $UPDOWN_HOME/config.json         # mode: dry-run, expected_slippage_bps: 0

3 · 提示価格を収集してから、シグナルがすでに価格に織り込まれているかをテストする。

python3 updown.py                        # dry-run: decides and records, places nothing
python3 backtest.py pricedin             # reads it back

 streak  dir     n  implied P(up)  realized P(up)     gap   read as
      3    1    64          0.421           0.428  +0.007   PRICED IN — no edge here

シグナルが発生したときの差がゼロに近ければ、市場はすでにその情報を把握しています。そこで停止してください。数十回分の発生データが必要です。1h で min_streak が 3 の場合、数日分に相当します。

4 · 配線を確認する — tail -f $UPDOWN_HOME/updown.log を実行します。長時間何も起きないこともあります。動作中か停止中かは、注文がないことではなく、HEARTBEAT の集計で判断してください。

5 · 独自のフックを書く — rounds.jsonl には、ラウンドごとの確率、両方の売値、オーバーラウンド、損益分岐点、エッジが記録されます。

6 · ライブ取引を開始する — 資金の流れが確認できるまでは最低賭け金にしてください。その後、約定ログの ALL-IN 行を参考に expected_slippage_bps を設定します。

機能一覧

段階	コマンド
ラウンドの列挙	prediction market list --l1Category crypto --l2Category up-down
板／最終価格	prediction market order-book · market last-trade-price
価格取得、注文、キャンセル	prediction trade quote · place-order · cancel
ポジション、決済	prediction position list · settled-history · pnl
償還	prediction trade redeem
注文状況	prediction order history
ガードレールの読み取り	wallet balance · left-quota · settings

ラウンドのライフサイクル

常時 12 個のトピックが表示されます。3 つの銘柄 × 4 つの時間間隔（5 min、15 min、1 hour、daily）で、それぞれに独自の板、手数料、価格フィードがあります。symbol と timeframe は必須の設定項目です。1 つのデーモンが取引するのは、組み合わせ 1 つだけです。

enumerate → gates → probability hook (cannot see quotes) → compare to quote
  → guards → quote → place → confirm fill → settlement → redeem

現物取引のパイプラインと異なる点は 2 つあります。

• 損切りも決済計画もありません。 ポジションは自動的に決済されるため、判断はすべてエントリー時に行います。
• 勝っても報酬は自動的に支払われません。 払い出しは償還されるまで PENDING_CLAIM に留まります。デーモンはタイマーで払い出しを処理します。通常稼働時には PENDING_CLAIM が空になっているはずです。

ラウンドの決済に使われるフィード

頻度	フィード
5 min、15 min	CHAINLINK
1 hour、daily	BINANCE 現物

各トピックで variantData.priceFeedProvider として公開されています。値を読み取り、推測しないでください。バックテストで使用すべき系列はこれによって決まります。また、トピックでは startPrice も公開されるため、ラウンド終了後に結果を独立して確認できます。

判断の契約

気配値が示唆確率です。 3つの分岐があり、3つ目が一般的です。

分岐	条件
Up を買う	P(up) − up_ask − cost > edge_threshold
Down を買う	(1 − P(up)) − down_ask − cost > edge_threshold
取引なし	上記以外

損益分岐の的中率は、気配値にコストを加えた値です。手数料 2% のとき、0.55 で Up を買うなら、57% を超える的中率が必要です。これは戦略に委ねず、メカニズム層が各ラウンドで計算してログに記録します。

コスト = トピックの feeRateBps + expected_slippage_bps。注文の slippage_bps はコストではなく、許容幅です。めったに起きない最悪のケースを想定して毎ラウンドに課金することになります。

スクリーニングゲート

フックを呼び出す前に、メカニズム層で3つのハードゲートを実行します。

#	ゲート	ソース
1	オーバーラウンド up_ask + dn_ask − 1	market order-book
2	片側ごとのスプレッド	同上
3	決済までの時間	トピックの endDate

ゲート1が最も効果的です。予測ではなく、板から確認できる事実に基づいています。BTC の1時間ラウンドでのライブ計測例では、売り気配が 0.55 / 0.46 → オーバーラウンド 1.0%、スプレッド 0.01 でした。同じラウンドの22秒後には 3.0% になりました。注文の直前にスクリーニングしてください。

ステーキング額に依存するため、スクリーニングではなくサイズ決定時に実行する4つ目のチェックがあります。

チェック	動作
最良売り気配の板の厚み	ステーキング額が板の最良価格に残っている USDT を超えると、注文は拒否されます。スクリーニングはその価格を基準に行われています。その価格を超える注文はより不利な価格へ進み、判断に使った価格と約定価格が異なります。最良売り気配で $5 が確認されています。予算ではなく、板に合わせてサイズを決めてください

公正価値からの乖離と「損益分岐点 ≤ 実証済みのキャリブレーション」は、メカニズム層ではなくフック側の役割です。どちらも、このスキャフォールドにはないモデルに依存するためです。ここに記載しているのは役割分担を明確にするためであり、デーモンが強制するからではありません。

しきい値は未設定の状態で提供されます。他の取引所の数値は、その取引所の板の状況を示すものです。

2種類の市場

種類	公正価値	結果
アット・ザ・マネー	自然に ≈0.50	モデル上の優位性はありません。 あるのは、その 0.50 の誤価格だけです
ストライクまたはバンド	時間とボラティリティから算出可能	乖離を測定できます。群衆が誤るのはテール部分です

戦略フック

estimate_probability(rnd, ctx) -> float | None   # P(round closes UP); None skips
size_position(rnd, ctx, edge)  -> float          # USD; clamped to stake_usd and budget

ctx には cfg、policy（そのままの値）、streak、streak_dir、open、now_ms が含まれます。

ctx に気配値は意図的に含まれていません。 価格を見られる推定器はその値に引きずられ、キャリブレーションレポートは優位性がないのに正確に見えるものを測定してしまいます。これは規律に委ねず、インターフェースで強制されます。範囲外の値や数値でない戻り値は、クランプされず ALERT とともに拒否されます。

提供されるものと、読み取るシグナルについてわかっていること

フックは戦略を記述する場所です。提供されるのはパイプラインを動かすためのサンプルです。そこに含まれるすべての判断と数値は、ご自身の分析結果に基づいて置き換えてください。

同梱の実装が読み取る機械的な特徴は、同じ方向のローソク足が現在何本続いているかの1つだけで、**ご自身で用意するpolicy.hit_table**から答えを参照します。テーブルは銘柄と時間足ごとに異なるため、何も表さないテーブルを借用することのないよう、数値は同梱していません。backtest.py eval --interval <iv>を実行すると、貼り付けて使えるテーブルが出力されます。

参考までに、決済価格の時系列で、記載されている各時間足について同じ系列を測定した結果を示します。

ローソク足	連続数 2	3	4	5	単調増加か？
5m（n≈9.8k）	0.520	0.509	0.512	0.514	いいえ
15m（n≈9.6k）	0.536	0.538	0.544	0.540	いいえ
1h（n≈5.8k）	0.539	0.544	0.552	0.559	はい
1d（n≈1.6k）	0.538	0.531	0.536	0.535	いいえ

• 15m、1h、1dでは、約+3ppの広範な反転傾向が見られます。これは再現されています。
• 「連続数が長いほど、反転が強い」という傾向は再現されません。4つの時間足のうち1つでしか見られず、サンプル期間によって変化します。4分の1という割合は、ノイズに見られるものです。

測定されたコストを差し引いた、アット・ザ・マネーのラウンドでのstreak ≥ 3の場合：

的中率	0.544
− 公正価値	−0.500
− オーバーラウンド、片側	−0.005
− 手数料、200 bps	−0.020
− 約定時に観測されたスリッページ	−0.0125
ラウンドあたりの純額	+0.0065

的中率の誤差範囲は**±0.019で、エッジの2.9倍です**。+0.65%とゼロを見分けるには、約22,700ラウンドが必要です。min_streakが3の場合、11.5年分に相当します。これは「損をする」でも「利益が出る」でもなく、この頻度で発生するラウンドでは検証できないということです。また、すべての数値はラウンドが公正価値で提示されることを前提としており、これを確認するのがウォークスルーのステップ3です。

上の表は判断基準を示す実例として扱い、そのままコピーして設定に使わないでください。

budget_usdで上限を設定できるもの、できないもの

上限を設定するのは損失であり、取引高ではありません。以下を満たす場合にのみラウンドが許可されます。

realised losses  +  capital currently at risk  +  this stake   ≤   budget_usd

したがって、すべてのオープンラウンドがゼロで決済される最悪のケースでも、承認した金額の範囲内に収まります。勝ち分のステークはプールに戻り、デーモンは処理を続けます。

長時間の実行では、これは重要です。以前のビルドではこの金額を累積取引高として扱い、決済時に解放しなかったため、結果にかかわらず、$50の予算は$1のステークで50ラウンド後に停止していました。これはリスクと無関係な停止であり、この戦略ファミリーに必要なサンプル数とも両立しません。一定のラウンド数で停止したい場合は、max_rounds_per_dayを使用してください。

メカニズムのガードレール

ここで強制され、フックから回避することはできません。値はご自身で設定します。

ガード	動作
budget_usd	総損失の上限。実現損失 + 現在リスクにさらされている資金 ≤ budget_usdとして適用されます。ラウンドの決済時にステークが返却されるため、このゲートが追跡するのは取引高ではなくリスクです
stake_usd	ポジションサイズ設定フックの実行後に適用される、ラウンドごとの上限。下限は1 USDT（プラットフォームの最低額）です
max_open_rounds	未決済ラウンドの同時保有数
max_rounds_per_day	UTCの午前0時にリセットされます。この時間足での実質的なコスト管理です
max_consecutive_losses	新規エントリーを停止し、その理由を記録します
単一インスタンス	flockを使用します。プロセスが終了するとカーネルがロックを解放します
ライブゲート	承認ファイルに現在のbudget_usdが記録されていない場合、起動を拒否します
STOP / KILL	新規オープンを停止 / 終了します

設定

$UPDOWN_HOME/config.json（デフォルトは ~/.local/updown）。初回実行時に空のテンプレートが書き込まれます。

資金に関わる設定にデフォルト値はありません。 例外は mode だけです。省略すると dry-run になるため、省略によって実取引が始まることはありません。

必須（仕組み）

キー	決め方
chain	baw wallet chains --json
symbol	BTCUSDT / ETHUSDT / BNBUSDT
timeframe	5 min / 15 min / 1 hour / daily — 文字列は完全一致が必要です。誤記は起動時にライブカタログとともに拒否されます
budget_usd	総損失を許容できる金額です。文字どおりに適用されます。ラウンドを開始できるのは、そのラウンドでこの金額を失い、さらにすでに失った金額と現在リスクにさらされている金額を合わせても、この上限内に収まる場合だけです。実取引を開始するときにもう一度入力します
stake_usd	1 USDT 以上で、最良売気配にある数量未満
max_open_rounds	口座で資金の流れが確認できるまでは 1
max_rounds_per_day	予算とは独立した取引頻度の制御値です。ラウンドあたり 2% の場合、静かな戦略における手数料を制限するのはこの値です。budget_usd から導き出される値ではありません
max_consecutive_losses	的中率が約 55% なら、4 連敗は珍しいことではありません

必須（ポリシー — 同梱フックが読み取ります）

キー	決め方
min_streak	4 以上なら発生頻度は低いものの、最も強い値を測定します。2 なら頻繁に発生しますが、最も弱い値を測定します
edge_threshold	自身の的中率推定における不確実性を上回る値にしてください。そうでなければノイズを取引することになります
max_overround	まず 1 時間、板を観察してください。数分の間隔で 1%～3% が観測されています
max_spread	同じ方法で決めます。流動性の高い BTC ラウンドでは 0.01 が観測されています
min_seconds_to_close / max_seconds_to_close	決済間際の成行注文は完全に失敗したことがあります。余裕を持たせてください
slippage_bps	コストではなく、注文の許容幅です
hit_table	取引する頻度に対応する {"2": 0.53, "3": 0.54, …}。backtest.py eval --interval <iv> で取得します。デフォルト値はありません。借り物のテーブルでは何も説明できません
expected_slippage_bps	まず 0 から始めます。最小のステークで実行し、約定ごとにログに記録される ALL-IN … = +N bps を確認し、手数料を差し引いて、観測した値を設定します。1 回の約定では、手数料 200 bps に対し、オールインで +325 bps でした

任意 — kline_interval（ラウンドの頻度がデフォルトです）· フックが読み取るその他の項目

デフォルト値あり（配線） — mode · poll_sec · settle_poll_sec · kline_refresh_sec · l1_category · l2_category

実行時ファイルと評価

$UPDOWN_HOME には config.json · state.json · rounds.jsonl（取引したものを含むすべての判断）· orders.jsonl · outcomes.jsonl · quotes.jsonl · updown.log が保存されます。 rounds.jsonl と outcomes.jsonl は key で結合します。

ハーネス	確認できること
backtest.py eval	シグナルはアウトオブサンプルでコストのハードルをクリアできるか。オフラインで実行でき、デーモンを信用しない人でも監査できます
backtest.py pricedin	それはすでに価格に織り込まれているか。バックテストでは答えられない問いです

eval は学習／テスト分割を適用し、点推定ではなく信頼区間を出力し、検証した仮説の数を数え、全サンプルで用量反応を確認します。ライブ以外の実行では quotes.jsonl に、読み取り可能なすべての板が記録されます。ゲートで拒否された板も含まれます。取引可能な板だけをサンプリングすると、価格織り込み分析に偏りが生じます。

キャリブレーションで重要なのは 3 つの列です。自身の確率、一定値 0.50、そして気配値です。気配値の列を上回れなければ、的中率がどれほどよく見えても戦略はありません。

プラットフォームの動作に関する注意事項

停止したセッションが、値動きのない市場のように見えてはいけません。 予測を読み取るたびに認証済みセッションが必要であり、セッションには有効期限があります。事前チェックでは予測エンドポイント自体を確認します（予測セッションが停止していても、wallet status は応答する場合があります）。実行時に認証エラーが発生した場合は、ALERT としてログに記録し、そのラウンドのスキップ理由として記録します。

order-book が受け取るのは --marketId であり、--marketTopicId ではありません。 これらは異なる識別子です。トピックには複数の市場が含まれます。

注文の最小額は 1 USDT です — quote はこれを下回る額を拒否します。

注文を出しても、失敗することがあります。 確認された例では、place-order は成功を返しましたが、注文は約定ゼロのまま FAILED（「Failed to execute the market order」）で決済されました。注文の発注は受領確認にすぎません。デーモンは終端ステータスまでポーリングし、失敗した場合は賭け金を予算に戻して、そのラウンドを破棄します — そうしないと、失敗した注文が予算を永久に消費し、実在しない未決済ラウンドが残ります。

決済済みの PnL は realizedPnl にあり、pnl は null で返されます。 間違った方を読み取ると、すべての勝ちがゼロとして記録され、調整台帳が破損します。

償還はアカウント全体が対象であり、デーモンの管理範囲に限られません。スイープは、このデーモンが開いていないポジションも含め、アカウント内の償還可能なものをすべて請求します。決済の記録管理は、このデーモン自身の state.json にあるラウンドだけを対象とします。

見積もりは見積もり取得から注文発注までの間に期限切れになることがあります。デーモンは見積もりを一度だけ再取得します。

未約定の売り注文は、同じ株式を重複して予約することがあります。 予約が解除されるのは決済時です。その後も市場が開いている間は、ポジション不足により追加の売り注文が失敗します。ポジションごとに未約定注文は最大 1 件にしてください。

事前チェック

読み取り専用 — 注文を出して確認してはいけません。

baw wallet status --json
baw wallet chains --json
baw wallet balance --binanceChainId <chain> --json
baw prediction category list --json             # confirm crypto / up-down exists
baw prediction position list --limit 1 --json   # confirm the prediction session is alive

実行

cd <skill-dir>/scripts && python3 updown.py                     # foreground
nohup python3 -u updown.py >> runner.log 2>&1 & disown          # long-running
python3 updown.py --collect-quotes                              # records only

操作	コマンド
新しいラウンドの開始を停止	touch $UPDOWN_HOME/STOP
プロセスを終了	touch $UPDOWN_HOME/KILL
リスクにさらす金額を確認	echo <budget_usd> > $UPDOWN_HOME/I_UNDERSTAND_THE_RISK
ライブゲートを復元	rm $UPDOWN_HOME/I_UNDERSTAND_THE_RISK

ライブ運用を開始する場合：mode を live に設定します。確認ファイルに現在の budget_usd が記載されていないと、実行は開始を拒否します — そのため、ランタイムディレクトリをコピーしても確認は引き継がれず、budget_usd を増額すると確認は無効になります。オペレーターが金額を確認した後で、エージェントが一度だけこのファイルを書き込むことができます。

終了しても、未決済のラウンドはクローズされません。 これらは個別に決済され、償還も引き続き必要です。

実行を継続する

これは 内部ループを持つフォアグラウンドプロセス であり、Unix デーモンではありません。フォークも setsid も行いません。nohup … & はログアウト後もプロセスを維持しますが、再起動後は維持しません。プロセスが保証すること、しないことは次のとおりです。

一時的なエラーからの回復	はい — ループがエラーを捕捉して ERROR main loop として記録し、15 秒 → 300 秒のバックオフを行います
クラッシュや再起動後の継続	いいえ — プロセスを再起動するものはありません。それはスーパーバイザーの役割です
安全な再起動	はい — state.json に予算、未決済ラウンド、日次カウンターが保存されます。flock が複数インスタンスの起動を防ぎます
見逃した決済の回復	はい — スイープは各パスでポジションと PENDING_CLAIM を再読み込みします
セッション期限切れ後の継続	いいえ — プロセスは実行を続けますが、すべてのラウンドを大きく通知してスキップします（ALERT）。再認証してください

launchd（macOS）— ~/Library/LaunchAgents/local.updown.plist：

<plist version="1.0"><dict>
  <key>Label</key><string>local.updown</string>
  <key>ProgramArguments</key>
  <array><string>/usr/bin/python3</string><string>/ABSOLUTE/PATH/scripts/updown.py</string></array>
  <key>EnvironmentVariables</key><dict><key>UPDOWN_HOME</key><string>/Users/you/.local/updown</string></dict>
  <key>RunAtLoad</key><true/>
  <key>KeepAlive</key><true/>
  <key>StandardOutPath</key><string>/Users/you/.local/updown/runner.log</string>
  <key>StandardErrorPath</key><string>/Users/you/.local/updown/runner.log</string>
</dict></plist>

launchctl load ~/Library/LaunchAgents/local.updown.plist

systemd（Linux）— ~/.config/systemd/user/updown.service：

[Service]
Environment=UPDOWN_HOME=%h/.local/updown
ExecStart=/usr/bin/python3 /ABSOLUTE/PATH/scripts/updown.py
Restart=always
RestartSec=30
[Install]
WantedBy=default.target

systemctl --user enable --now updown

スーパーバイザーが再起動するのはプロセスであり、再認証は行いません。 セッションの有効期限が切れると、誰かが再度サインインするまで取引はすべて停止します。その点は別途計画し、静かな状態を正常と決めつけず、ALERT の行に注意してください。

既知の制限事項

制限事項	詳細
同梱の戦略は検証できません	±1.9ppの誤差範囲に対して、1ラウンドあたり約+0.65％です。確認には約22,700ラウンドが必要です。これは、シグナルが超えるべき基準の実例であり、資金を投じるためのシグナルではありません
的中率は優位性ではありません	気配値が状態を反映している場合、的中率が高くても収益はゼロです。それを除外できるのはpricedinだけです
アット・ザ・マネーのラウンド	公正価値は約0.50です。そこで得られる利益はすべて、予測ではなく価格の誤りによるものです
手数料が利益を圧迫します	プラットフォームが公表している、1ラウンドあたり200 bpsです
決済も損切りもありません	判断はすべてエントリー時に行います
払い戻しの手続きが必要です	利益は回収されるまで未請求のまま残ります
セッションは有効期限が切れます	アラートで軽減できますが、解決はできません。長時間の実行には再認証が必要です
ドライランでは資金の流れを確認できません	注文、約定、決済、払い戻しはライブ実行時のみ行われます
板が薄い場合があります	最良売り気配の数量が一桁ドルのケースが確認されています
監視プロセスはありません	launchd、systemd、またはコンテナーの再起動ポリシーを使用してください

免責事項

これは取引製品ではなく、足場となるものです。

• 同梱の戦略は、コスト控除後にプラスの期待値が実証されていない、測定済みの参照例です。パイプラインが動作し、ハーネスが識別能力を持つことを示すために提供されています。
• ここに記載されているすべてのリスク管理策とパラメーターは、安全策ではなく提案です。デーモンは設定されたチェックを実行しますが、それらが十分かどうかは判断しません。
• ここに記載されている内容は、投資、金融、取引に関する助言ではありません。
• ポジションが無価値のまま期限切れになることがあります。自動取引では、予期しなかった市場状況、プラットフォームの動作変更、このソフトウェアの不具合、または作成した戦略の不具合によって損失が発生する可能性があります。
• 本ソフトウェアは現状有姿で提供され、保証はありません。法律で認められる最大限の範囲において、本ソフトウェアの使用から生じるいかなる損失についても責任を負いません。
• 実行する内容、選択するパラメーター、適用される法律の遵守、および投入する資金については、すべてお客様が単独で責任を負います。

budget_usdの全額を失う覚悟がない場合は、modeをliveに設定しないでください。