BitFlyer/BitMEXの多重注文対策のススメ

BTCFXをやってるみなさん、こんにちは。テクニカル分析大好きな CryptoMori です。

今のところ利食いドテン君はスリッページもだいぶ回避できるようになって順調です。今日はチャート分析的な話ではなく開発向けの技術的なお話をしようと思います。対象者はボット作成者・カスタマイズしようとしている人向けです。

BitFlyer、BitMEXの取引所が公開しているAPIを使う上で高負荷時等にトラブりやすい点として多重注文があると思います。指定のロット数を上回るリスクがあります。レバレッジを調整して回避されている方も多いようですが根本的な解決になっておらず、今回は私が開発を続けている利食いドテン君で多重注文問題に苦労したのでその内容を共有したいと思います。

取引所の大まかな仕組み

成行注文の場合、注文発行から約定までの大まかな流れはおおよそ下記のようになります。

※あくまでイメージ的な図なのでサーバー内がどのように実装されているかは不明です。

注文を出す上で注意点はは下記の３点です。
・(1), (4)は高負荷状態でエラーが返却される可能性がある
・(2)の正常レスポンスが返ってから(3)の約定処理までタイムラグがある
　　(※高負荷状態で10分以上かかる)
・(3)の約定完了からポジション反映までタイムラグがある
　　(※BitMEXのみ、高負荷状態で30秒程度)

トレードボットの構造

トレードボットの一般的な構造を解説します。ここでは一番単純な成行注文を例にとっています。
基本構造として下記の処理を定期的(例えば30秒置き等)に実行しています。

ここでAPIサーバー遅延が大きな障害となります。上記のボットの仕組みだけでは多重注文が発生する可能性があります。

5の注文の送信が発行された後、次の定期処理実行時に2で取得したポジションが反映されていないことに起因します。

解決策

注文実行時にポジション反映されるまで、定期実行を待つ方法が一番確実です。
具体的には下記の処理を追加する必要があります。

6.は注文ID か 注文受付IDで注文詳細情報を取得しのSTATUSがCloseされるまで待機します。
7.はポジションが確実に変更されていることを確認するまで待機します。
※BitFlyerでは6の注文の状態が変更されたタイミングでポジションに反映が完了しているので7の処理は不要です。

取引所のAPI

BitFlyer

＜注文の送信＞
POST /v1/me/sendchildorder

child_order_acceptance_id が 取得できれば注文の受付が完了している。

ビットコイン取引所【bitFlyer Lightning】

＜注文の状態確認＞
GET /v1/me/getchildorders
params: child_order_acceptance_id

child_order_state が ACTIVEの場合は、注文の処理待ち状態のため待機する必要がある。

ビットコイン取引所【bitFlyer Lightning】

＜ポジションの取得＞
GET /v1/me/getpositions

sideが方向、sizeが数量を表す。

ビットコイン取引所【bitFlyer Lightning】

BitMEX

＜注文の送信＞
POST /order

orderID が取得できれば注文の受付が完了している。

BitMEX API Explorer

＜注文の状態確認＞
GET /order
params: orderID

statusがclosedになれば約定は完了しているが、ポジションの反映は保証されていない。

BitMEX API Explorer

＜ポジションの取得＞
GET /position

currentQtyで数量を表す

BitMEX API Explorer

成行注文のベストプラクティス

私が考えるベストプラクティスを下記に記載します。他にもっといい方法があるかもしれませんが利食いドテン君では下記を採用しています。

BitFlyerの場合

1. 注文処理
　/v1/me/sendchildorderを発行し、child_order_acceptance_idが取得できるまで繰り返す
（※高負荷時のエラーをハンドリングして成功するまでリトライ）

2. 反映待機処理
　/v1/me/getchildorders を使用して 1で取得したchild_order_acceptance_id を元にデータを取得しSTATUSがACTIVEではなくなるまで取得し続け待機する

BitMEXの場合

1. 注文事前処理
　注文発行前に GET /position を使用し現在のポジションを取得する

2. 注文処理
　POST /orderを発行し、orderIDが取得できるまで繰り返す
（※高負荷時のエラーをハンドリングして成功するまでリトライ）

3. 反映待機処理
　GET /position を使用し、1で取得したポジションから変動するまで取得し続け待機する

LIMIT・STOP注文の場合

指値注文・STOP成行注文に関しては約定のタイミングが即時ではないために定期的に注文を監視し続ける必要があります。若干、ロジックは複雑にはなりますが基本的な考え方は同じなのでポジションの反映さえ確認できれば対応可能だと思います。

宣伝

本稿で記載した内容は利食いドテン君の最新バージョンで成行注文・指値注文・STOP注文に対応しています。有料にはなりますがソースコードを公開しています。

AKAGAMI LOUNGE (Discodeアカウント) : @crypto_mori
Twitterアカウント： @crypto_mori