Original Title: 私はPolymarketのボットを構築し、複数のパラメータ設定をテストしました。こちらが結果です。

Original Author: @the_smart_ape, 暗号研究者

Original Translation: 比推 Bitpush News

数週間前、私は自分自身のPolymarketボットを構築することに決めました。完成版を作るのに数週間かかりました。

私がこれに取り組む理由は、Polymarketには実際に効率の悪さが存在するためです。市場には既にいくつかのボットがこの低効率を利用しているものの、それだけでは足りず、この市場の機会は依然としてボットの数よりもはるかに多いと考えています。

ボットの構築ロジック

このボットのロジックは、過去に手動で実行した戦略に基づいており、効率を向上させるために自動化しました。このボットは「BTC 15分 上昇/下降（BTC 15-minute UP/DOWN）」市場で実行されます。

ボットはリアルタイムの監視プログラムを実行しており、現在のBTC 15分のセッションに自動的に切り替わり、WebSocketを介して最適な買い注文/売り注文価格（best bid/ask）をストリーミングし、固定されたターミナルUIを表示し、テキストコマンドで完全に制御できます。

手動モードでは、直接注文を出すことができます。

buy up <usd> / buy down <usd>: 特定の米ドル金額を購入します。

buyshares up <shares> / buyshares down <shares>: 特定の株式数を購入し、ユーザーフレンドリーなLIMIT（指値）+ GTC（有効前にキャンセル）注文を使用し、現在の最適な売り注文価格（best ask）で取引されます。

自動モードでは、2段階のループを繰り返します。

まず第一段階では、各ラウンド開始後のwindowMin分間だけ価格変動を監視します。どちらかが十分に急落（約3秒でmovePct分だけ下落）した場合、それは「第一段（Leg 1）」をトリガーし、急落した側を購入します。

Leg 1 完了後、ロボットは同じサイドを再度購入しません。それは「Leg 2（ヘッジ）」を待ち、次の条件を満たす場合にのみトリガーされます：leg1EntryPrice + oppositeAsk <= sumTarget。

この条件を満たすと、ロボットは逆サイドを購入します。Leg 2 完了後、このサイクルは終了し、ロボットは観察状態に戻り、次に同じパラメータを使用したフラッシュクラッシュシグナルを待ちます。

サイクル中にラウンドが変更された場合、ロボットは開いているサイクルを放棄し、次のラウンドで同じ設定を使用して再スタートします。

自動モードのパラメータ設定は次のとおりです：auto on <shares> [sum=0.95] [move=0.15] [windowMin=2]

· shares：両方の取引に使用されるポジションサイズ。

· sum：ヘッジングが許可される閾値。

· move (movePct)：フラッシュクラッシュの閾値（たとえば、0.15 = 15%）。

· windowMin：各ラウンドの開始から、Leg 1 を実行する許容時間。

バックテスト

このロボットの論理は非常にシンプルです：フラッシュクラッシュを待ち、直前に急落した方を購入し、その後価格が安定し、反対側を購入することによりヘッジし、同時に、priceUP + priceDOWN < 1 が確保されます。

ただし、この論理をテストする必要があります。長期的に有効なのでしょうか？さらに重要なのは、ロボットには多くのパラメータがあります（株数、合計額、移動割合、ウィンドウ分数など）。どのパラメータセットが最適であり、利益を最大化できるのでしょうか？

最初の考えは、ロボットを1週間ライブ実行して結果を観察することです。ただし、これには時間がかかりすぎる上、1つのパラメータセットしかテストできず、多くのパラメータセットをテストする必要があります。

2番目のアイデアは、Polymarket CLOB API からのオンラインヒストリカルデータを使用してバックテストを実行することです。残念ながら、BTCの15分足市場に対して、ヒストリカルデータエンドポイントは常に空のデータセットを返しています。価格のヒストリカルティックがない場合、Leg 1 をトリガーできないため、フラッシュクラッシュを検出できず、どのようなパラメータを使用しても、サイクルが0回、投資収益率（ROI）は0%となります。

さらなる調査の結果、他のユーザーも特定の市場の過去データを取得する際に同じ問題に遭遇していることが分かりました。他の市場では過去データが正常に返されることを確認し、この特定の市場では過去データがまったく保存されていないと結論付けました。

この制限のため、このストラテジーをバックテストする唯一の信頼できる方法は、ロボットが実行されている間にリアルタイムのベストアスク価格を記録して独自の過去データセットを作成することです。

レコーダーはディスクにスナップショットを書き込み、以下を含みます：

・タイムスタンプ

・ラウンド識別子（round slug）

・残り秒数

・UP/DOWN トークン ID

・UP/DOWN ベストアスク価格

その後、「記録されたバックテスト」はこれらのスナップショットをリプレイし、同じ自動ロジックを決定論的に適用します。これにより、フラッシュクラッシュの検出やヘッジ条件に必要なハイフリクエンシーデータを取得できるようになります。

私は合計して 4 日で 6 GB のデータを収集しました。もっと記録することができましたが、異なるパラメータセットをテストするにはこの量が十分だと判断しました。

私はこのパラメータセットをテストし始めました：

・初期残高：$1,000

・取引ごとに 20 株

・sumTarget = 0.95

・フラッシュクラッシュ閾値 = 15%

・windowMin = 2 分

また、0.5% の手数料と 2% の価格差を適用し、保守的なシナリオを維持しました。

バックテストによると、ROI は 86% であり、わずか数日で $1,000 が $1,869 に変わりました。

次に、より積極的なパラメータセットをテストしました：

・初期残高：$1,000

・取引ごとに 20 株

・sumTarget = 0.6

・フラッシュクラッシュ閾値 = 1%

・windowMin = 15 分

結果：2 日後、投資利益率は -50% になりました。

これはパラメータの選択が最も重要な要素であることを明確に示しています。これにより多額の利益を得ることができる一方、大きな損失を被る可能性もあります。

バックテストの限界

手数料やスプレッドを含めても、バックテストにはその限界があります。

· まず、それはわずか数日のデータしか使用しておらず、これでは市場全体を理解するには不十分かもしれません。

· これは記録された最適売値のスナップショットに依存しており、実際の取引では注文が部分的に約定されたり、異なる価格で約定されたりする可能性があります。さらに、オーダーブックの深さや利用可能な取引量はモデル化されていません。

· マイクロ秒以下の微小な価格変動が捉えられていません（データは1秒ごとにサンプリングされています）。バックテストには1秒のタイムスタンプがありますが、1秒の間に多くのことが起こる可能性があります。

· バックテストではスリッページが一定であり、変動する遅延（たとえば 200–1500 ミリ秒）、ネットワークのピークがシミュレートされていません。

· すべての取引セグメントが「即時」に実行されたものと見なされます（オーダーのキューイングはなく、オーダーはありません）。

· 手数料は一律に請求されますが、実際には手数料は市場/トークン、オーダーブック作成者と成行注文作成者の関係、手数料率や条件によって異なる可能性があります。

慎重を期すために、私は以下の規則を適用しました：もし Leg 2 が市場が閉まる前に実行されなかった場合、Leg 1 は全損失と見なされます。

これは意図的に慎重な手法ですが、常に現実に即しているわけではありません：

· 時には Leg 1 が早期にクローズされることがあります。

· 時には最終的にイズミモン内に位置し、勝利します。

· 時には損失が部分的であり、完全なものではありません。

損失が過大評価されているかもしれませんが、これは実用的な「最悪のシナリオ」を提供しています。

何よりも重要なのは、バックテストが取引所のオーダーブックに対する大口の取引の影響や他のトレーダーによるあなたへの狩猟行動をシミュレートすることができないことです。現実では、あなたの注文は以下のような影響を与える可能性があります：

· オーダーブックの乱れ、

· 他のトレーダーの引き寄せや排斥、

· 非線形なスリッページ。

バックテストはあなたが純粋なプライステイカーであり、何の影響も及ぼさないという仮定をしています。

最後に、それは頻度制限、API エラー、注文の拒否、一時停止、タイムアウト、再接続、または取引シグナルを見逃すためにロボットがビジー状態になる状況をシミュレートしていません。

バックテストは適切なパラメーター範囲を特定するために非常に有益ですが、すべての場合をカバーするものではないため、100% の保証ではありません。現実世界のいくつかの効果はモデル化できません。

インフラ

この取引ボットを稼働させるために、Raspberry Pi 上で実行する予定です。これにより、自分のホストリソースを消費せずに、24時間365日稼働を実現します。

ただし、これにはまだ大幅な改善の余地があります：

・ JavaScript の代わりに Rust を使用すると、はるかに優れたパフォーマンスと処理時間が提供されます。

・ 専用の Polygon RPC ノードを実行すると、遅延がさらに低減されます。

・ Polymarket のサーバーに近いVPSに展開すると、遅延が大幅に低下します。

まだ発見していない他の最適化方法もあるかもしれません。現在、私は Rust を学んでいます。Web3 開発で不可欠な言語になりつつあるからです。

Original Link

BlockBeats の公式コミュニティに参加しよう：

Telegram 公式チャンネル：https://t.me/theblockbeats

Telegram 交流グループ：https://t.me/BlockBeats_App

Twitter 公式アカウント：https://twitter.com/BlockBeatsAsia