86% APYのイールドファーミング？Polymarketでボットを使って「寝ている間に稼ぐ」方法

Original Title: I built a Polymarket bot and tested multiple parameter setups, here are the results.

Original Author: @the_smart_ape, Crypto Researcher

Original Translation: Bitpush News

数週間前、私は独自のPolymarketボットを構築することにしました。フルバージョンを完成させるまでに数週間かかりました。

私がこの努力を惜しまなかったのは、Polymarketには確かに効率性のギャップが存在するからです。市場に出回っている一部のボットはすでにこれらの非効率性を利用していますが、それだけでは全く不十分であり、この市場にはボットの数よりも遥かに大きなチャンスが眠っています。

ボット構築のロジック

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

ボットはリアルタイム監視プログラムを実行し、現在のBTC 15分ラウンドに自動的に切り替え、WebSocketを通じて最良のビッド/アスクを効率化し、固定ターミナルUIを表示し、テキストコマンドによる包括的な制御を可能にします。

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

buy up <usd> / buy down <usd>: 特定のUSD額で購入。

buyshares up <shares> / buyshares down <shares>: 正確なシェア数で購入。ユーザーフレンドリーなLIMIT + GTC（Good 'Til Canceled）注文を使用し、現在の最良アスク価格で実行されます。

自動モードは、繰り返しの2レッグループを実行します。

まず、各ラウンド開始時のwindowMin分以内の価格変動のみを監視します。どちらかの側が十分に速く下落した場合（約3秒でmovePctの下落率に達する）、それが「レッグ1」をトリガーし、急落した側を購入します。

レッグ1完了後、ボットは二度と同じ側を購入しません。「セカンドレッグ（レッグ2、つまりヘッジ）」を待ち、次の条件が満たされた場合にのみトリガーされます：leg1EntryPrice + oppositeAsk <= sumTarget。

この条件が満たされると、反対側を購入します。レッグ2完了後、サイクルは終了し、ボットは監視モードに戻り、同じパラメータを使用して次のフラッシュクラッシュシグナルを待ちます。

サイクル中にラウンドが変更された場合、ボットはオープンサイクルを放棄し、次のラウンドで同じ設定で再起動します。

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

· shares: 2段階トレードのポジションサイズ。

· sum: 許容されるヘッジのしきい値。

· move (movePct): フラッシュクラッシュのしきい値（例：0.15 = 15%）。

· windowMin: 各ラウンド開始からレッグ1の実行を許可するまでの時間。

バックテスト

ボットのロジックは単純です：激しいフラッシュクラッシュを待ち、下落した側を購入し、価格が安定するのを待ってから反対側を購入してヘッジし、priceUP + priceDOWN < 1を確保します。

しかし、このロジックはテストする必要があります。長期的に本当に効果があるのでしょうか？さらに重要なことに、ボットには多くのパラメータ（シェア、合計、移動パーセンテージ、ウィンドウ分など）があります。どのパラメータセットが最適で、利益を最大化できるのでしょうか？

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

私の2番目の考えは、Polymarket CLOB APIのオンライン履歴データを使用してバックテストすることでした。残念ながら、BTC 15分アップ/ダウン市場の場合、履歴データエンドポイントは一貫して空のデータセットを返します。履歴価格ティックがないと、バックテストは「約3秒のフラッシュクラッシュ」を検出できず、レッグ1をトリガーできず、どのパラメータを使用しても0サイクル、0%の投資収益率（ROI）になります。

調査を進めると、他のユーザーも特定の市場の履歴データを取得する際に同じ問題に遭遇していることがわかりました。履歴データを実際に返す他の市場をテストした結果、この特定の市場では履歴データが単に保存されていないと結論付けました。

この制限のため、この戦略をバックテストする唯一の信頼できる方法は、ボットの実行中にリアルタイムの最良アスク価格を記録して、独自の履歴データセットを作成することです。

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

· タイムスタンプ

· ラウンドスラグ

· 残り秒数

· UP/DOWNトークンID

· UP/DOWN最良アスク価格

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

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

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

· 初期残高：1,000ドル

· トレードあたり20シェア

· sumTarget = 0.95

· フラッシュクラッシュしきい値 = 15%

· windowMin = 2分

また、保守的なシナリオを維持するために、0.5%の手数料と2%のスプレッドを一定に適用しました。

バックテストでは86%のROIが示され、わずか数日で1,000ドルが1,869ドルになりました。

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

· 初期残高：1,000ドル

· トレードあたり20シェア

· sumTarget = 0.6

· フラッシュクラッシュしきい値 = 1%

· windowMin = 15分

結果：2日後、投資の収益率は-50%でした。

これは、パラメータの選択が最も重要な要素であることを明確に示しています。それはあなたに多額の利益をもたらすことも、大きな損失につながることもあります。

バックテストの限界

コストとスプレッドを含めても、バックテストには限界があります。

· 第一に、数日分のデータしか使用しておらず、包括的な市場の視点を得るには不十分な場合があります。

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

· 秒未満の微細な変動はキャプチャされません（データは1秒ごとにサンプリング）。バックテストには1秒レベルのタイムスタンプがありますが、各秒の間には多くのことが起こり得ます。

· スリッページはバックテストでは一定であり、可変遅延（例：200〜1500ミリ秒）やネットワークの混雑のピークはシミュレートされません。

· 各トレードセグメントは「即時」に実行されると想定されています（注文のキューイングなし、指値注文なし）。

· コストは一律に請求されますが、実際にはコストは以下に依存する可能性があります：市場/トークン、メイカー・テイカー、手数料階層、または条件。

悲観的（慎重）なアプローチを維持するために、ルールを適用しました：レッグ2が市場終了前に実行されない場合、レッグ1は全損とみなされます。

意図的に保守的ではありますが、これは常に現実と一致するわけではありません：

· レッグ1が早期に終了することもあります、

· イン・ザ・マネー（ITM）になり、勝利することもあります、

· 損失が全損ではなく部分的なものになることもあります。

損失は過大評価されている可能性がありますが、これは実用的な「最悪のケース」のシナリオを提供します。

最も重要なことは、バックテストは、あなたの大きな注文がオーダーブックに与える影響や、他のトレーダーからの略奪的な行動をシミュレートできないことです。実際には、あなたの注文は：

· オーダーブックを混乱させる、

· 他のトレーダーを引き付けたり遠ざけたりする、

· 非線形なスリッページを引き起こす可能性があります。

バックテストは、あなたが影響力を持たない純粋な流動性抽出者（プライステイカー）であると想定しています。

最後に、レート制限、APIエラー、注文拒否、停止、タイムアウト、再接続、またはボットが忙しくてシグナルを見逃す状況はシミュレートされません。

バックテストは、パラメータの良い範囲を特定するには非常に価値がありますが、現実世界のいくつかの影響はモデル化できないため、100%の保証ではありません。

インフラストラクチャ

メインマシンでリソースを消費しないように、このボットをRaspberry Piで24時間年中無休で実行する予定です。

しかし、改善の余地はまだ十分にあります：

· JavaScriptの代わりにRustを使用すると、パフォーマンスと処理時間が大幅に向上します。

· 専用のPolygon RPCノードを実行すると、レイテンシがさらに短縮されます。

· Polymarketサーバーに近いVPSにデプロイすると、レイテンシも大幅に短縮されます。

私がまだ発見していない他の最適化方法も確実にあるはずです。現在、RustはWeb3開発において不可欠な言語になりつつあるため、私はRustを学んでいます。

元の記事リンク