DepthFeed/Polymarket·Backtesting

Polymarketのオーダーブックで戦略をバックテストする方法

1時間に一度サンプリングされたラスト・プライスでは、あなたの注文が約定したかどうかは分かりません。Polymarketを、実際に取引相手となったはずのブックそのものに対してバックテストする方法を解説します。

DepthFeed··8 min

Polymarketの戦略を正しくバックテストするには、その戦略が実際に取引相手としたはずの過去のオーダーブックをリプレイし——変化ごとの完全な買い・売りのラダー(板)を再現し——本当にそこに置かれていた流動性に対して約定サイズを当てはめます。ラスト・プライスや単一のミッド(仲値)でバックテストすると、スプレッドと実際の注文が支払うスリッページを隠してしまうため、あなたのエッジを構造的に過大評価してしまいます。

なぜラスト・プライスのバックテストは嘘をつくのか

無料で入手できるPolymarketデータのほとんどは、しばしば1時間に一度サンプリングされたラスト・プライス(最終約定価格)です。これはチャートを描くには十分ですが、それ以上のことはできません。バックテストはより難しい問いに答えなければなりません。すなわち、もし自分の注文があの瞬間に板に置かれていた(あるいはスプレッドをクロスしていた)としたら、約定したのか、どれだけのサイズで、いくらで約定したのか、という問いです。

その答えを出すには、単一の数値ではなく、サイズを伴うすべての買い指値・売り指値、つまりオーダーブックが必要です。ミッドに対してバックテストした戦略は、常にミッドでスリッページゼロで約定したと仮定しますが、それは決して真実ではありません。決済が近づくとスプレッドが拡大する短期の暗号資産マーケットでは、この仮定が負ける戦略を見かけ上の勝ち戦略へとひっくり返してしまうことがあります。

ステップ1 — フルデプスのオーダーブックデータを入手する

固定された時計ではなく、変化が起きるたびに捕捉された、両サイドの完全な板を記録するデータから始めましょう。DepthFeedはPolymarketのイベント駆動のデータをCLOBのwebsocketから直接捕捉するため、すべてのブックおよび価格変動イベントが、完全な買い・売りのラダーとともに記録されます——5分間マーケットの一生を取りこぼす、1時間ごとや1分ごとのサンプルではありません。

欲しいマーケットはREST API経由で取得します。まずGET /v3/{coin}/marketsで探索し、次に/v3/{coin}/markets/{id}/snapshotsからデプスを取得します。各スナップショットには、買い・売りの価格とサイズの配列に加え、エポックミリ秒単位の取引所側タイムスタンプと受信タイムスタンプが含まれます。

ステップ2 — 各時点でブックを再構築する

スナップショットをタイムスタンプ順にリプレイすれば、任意の瞬間にブックがどう存在していたかを再現できます。データがイベント駆動であるため、イベントとイベントの間の再構築は厳密であり——補間による当て推量は存在しません。これがあなたの戦略が反応する状態です。すなわちベスト・ビッド、ベスト・アスク、その背後の各デプス、そしてスプレッドです。

ステップ3 — 実際のデプスに対して約定をモデル化する

ここで約定を正直にシミュレートします。成行に近い注文はブックを歩きます。まずベストの板に対して約定し、次の板、さらに次の板へと、サイズが尽きるまで約定していきます——したがって最上位の板を超えて消費するときには、その平均価格はタッチ(最良気配)よりも悪くなります。指値の待機注文はキューに並び、十分なサイズを背後に伴ってマーケットがその価格を抜けて取引したときにのみ約定します。

記録されたラダーに対して約定サイズを当てはめることこそが核心です。これにより、常にミッドで取引できたという作り話ではなく、現実的なスリッページと約定確率が得られます。

ステップ4 — 原資産価格を結合する

Polymarketの暗号資産アップ/ダウン・マーケットは、原資産のスポットの値動きに駆動されます。DepthFeedのすべてのスナップショットは、エポックミリ秒のタイムスタンプによって高頻度のBinance参照価格に結合されるため、ブックの状態と、その契約を再プライシングしたスポットの値動きとを揃えることができます——暗号資産価格とマーケットの示唆する確率との関係を取引するあらゆる戦略にとって不可欠です。

ステップ5 — 同じコードでライブへ移行する

過去データのREST APIとライブのWebSocketストリームは、同一のJSONスナップショット・オブジェクトを出力します。つまり、過去をリプレイするために書いたローダーが、そのままライブフィードを読み込めるということです——リサーチから本番への書き直しは不要です。バックテストし、検証し、そして同じコードをwss://api.depthfeed.com/v3/streamに向けて取引してください。

よくある落とし穴

  • ラスト・プライスのデータを使う:スプレッドとスリッページを隠し、バックテストのリターンを水増しする。
  • 固定間隔のスナップショット:1時間ごとや1分ごとのサンプルは、5分間マーケットの一生の大半を取りこぼす。
  • キューポジションを無視する:指値の待機注文が常に約定すると仮定すると、パッシブ戦略を過大評価する。
  • 先読みバイアス:意思決定時刻と同時かそれ以前の受信タイムスタンプを持つデータにのみ反応すること。
  • 原資産を省く:暗号資産アップ/ダウンのエッジは、たいていスポットと確率の関係の中に存在する。

Key takeaways

  • 01ラスト・プライスではなくオーダーブックに対してバックテストする——約定を決めるのはデプスである。
  • 02イベント駆動のデータを使う:固定間隔のサンプルは短期マーケットの一生を取りこぼす。
  • 03成行に近い注文はブックを歩き、指値の待機注文はキューで待つ——その両方をモデル化する。
  • 04原資産の暗号資産価格を結合し、スポットと確率の関係を捉える。
  • 05過去データとライブフィードが一つのフォーマットを共有するデータを選び、バックテストしたコードのまま取引する。

1時間に一度サンプリングされたラスト・プライスでは、あなたの注文が約定したかどうかは分かりません。Polymarketを、実際に取引相手となったはずのブックそのものに対してバックテストする方法を解説します。

無料で始める

よくある質問にお答えします。

部分的にしかできません。Polymarketの公開APIは現在のマーケット、約定、そして価格履歴のエンドポイントを提供しますが、過去のオーダーブックのスナップショットは提供しません——そのため、戦略が取引相手としたはずの待機状態のブックをリプレイすることはできません。この過去のデプスこそが、サードパーティのオーダーブックデータが埋める具体的な空白です。