戦略開発ガイド
設定ガイド
Injective Traderは、動作、コンポーネント、戦略パラメーターを定義するためにYAML設定ファイルを使用します。 特に注目すべき重要な設定セクションは以下の通りです:LogLevelComponentsセクション内のInitializerにおけるNetworkとMarketTickersStrategiesセクション
トップレベルパラメーター
Componentsセクション
Components セクションはフレームワークコンポーネントを設定します:
Note: ほとんどのユーザーは、
Network の設定と、リッスンしたいすべてのマーケットを MarketTickers に含めることだけを行えば十分です。
これらの高度なコンポーネント設定を変更する必要はありません。デフォルト値はほとんどのユースケースで適切に機能します。Strategiesセクション
Strategies セクションは各トレーディング戦略を定義します:
Class: Pythonクラス名と正確に一致する必要がありますMarketIds: この戦略でトレードするマーケットIDのリスト(hexフォーマットを使用)AccountAddresses: この戦略でトレーディングに使用するアカウントのリストTradingAccount: 注文執行に使用するアカウント(AccountAddressesに含まれている必要があります)[詳細は Trading Mode Configuration を参照]
CIDPrefix: client order IDのプレフィックス(自分の注文を識別するのに役立ちます)Name: ログとモニタリング用の人間可読な名前
- 戦略が必要とする任意のカスタムパラメーターを追加できます
- 戦略名の下にあるすべてのパラメーターは
self.configで利用可能になります - 関連パラメーターは明確化のために
Parametersセクションでグループ化してください
Trading Modeの設定
フレームワークは2つのトレーディングモードをサポートします:Direct Execution Mode
Authorization (Authz) Mode
Note: direct executionのための
TradingAccount か、authorizationモードのための Granter および Grantees のいずれかを指定する必要があります。
フレームワークは初期化時にこの要件を強制します。RetryConfigセクション
RetryConfig セクションは、ネットワーク操作のリトライ動作を制御します:
Note: RetryConfigには妥当なデフォルトがあり、特定の接続性の問題に遭遇しない限り、通常はカスタマイズの必要はありません。
全体構造を理解したところで、いよいよカスタム戦略を開発する準備ができました!
戦略開発ガイド
Injective Traderの戦略は、Strategy ベースクラスをベースとする一貫した構造に従います。このセクションでは、効果的な戦略を構築する方法を説明します。
Strategyクラスの構造
戦略クラスはベースのStrategy クラスを継承します:
Strategyコンストラクタ(__init__)
戦略クラスには、親クラスのコンストラクタを呼び出すコンストラクタを含めることができます:
- パラメーターのバリデーションと抽出
- 標準のメトリクスとハンドラのセットアップ(自分のハンドラを書く方法については [block link] を参照)
- 状態トラッキングコンテナの初期化
- トレーディングモード(directまたはauthz)のセットアップ
Important:
__init__ メソッドはマーケットデータやアカウント情報にアクセスできません。
これらのリソースを必要とする操作には on_initialize を使用してください。__init__ によって提供される利用可能なプロパティは以下の通りです:
初期化メソッド(on_initialize)
on_initialize メソッドは、フレームワーク起動時にマーケットとアカウントがロードされた後に一度だけ呼び出されます。
目的: 戦略の状態とパラメーターを初期化する パラメーター:
accounts: account_address →Accountオブジェクトの辞書markets: market_id →Marketオブジェクトの辞書
StrategyResult
- フレームワークがこの戦略で必要なマーケットとアカウントをロードする
- ロードされたデータを引数として
on_initializeメソッドが呼び出される - 返された注文があれば即座に提出される
- 戦略がrunning stateへ移行する
Tip: マーケットやアカウントデータを必要とするパラメーター初期化、および戦略に必要な初期注文の発注には
on_initialize を使用してください。
Account と Market のデータ構造については、以下を参照してください。戦略ロジック(_execute_strategy)メソッド
_execute_strategy メソッドは「Strategy Execution(execute)Method」の一部です。ベースクラスの execute メソッドが完全な実行フローを処理します:
- 初期化チェック: 必要に応じて戦略を初期化
- 状態更新: 戦略のアカウントおよびマーケット参照を更新
- データ処理: 適切なハンドラを通じて生の更新データを処理
- 戦略実行: 処理済みデータを使って
_execute_strategyメソッドを呼び出し - 注文の補完: 注文にデフォルト値(fee recipient、client ID)を追加
_execute_strategy の実装に集中してください:
目的: マーケットデータを分析し、トレーディングシグナルを生成する パラメーター:
update_type: 処理される更新のタイプ [詳細は Update Types and Corresponding Data Fields を参照]processed_data: 関連フィールドを含むハンドラ処理済みデータの辞書
StrategyResult または None
_execute_strategy では以下のことができます:
- 特定のイベントをハンドルするためにupdate typeでフィルタリング
- 現在のマーケットデータとアカウント状態にアクセス
- 注文発注前に既存ポジションをチェック
- マーケット条件に基づくカスタムトレーディングロジックを実装
- 新規注文を作成し、既存注文をキャンセル
- derivativeマーケットでのポジションマージンを更新
- モニタリングおよびデバッグのために戦略の意思決定をログ出力
StrategyResult に基づき、トランザクション作成、シミュレーション、ブロードキャストなどの執行詳細を処理します。
ベストプラクティス
- すべてのパラメーターを
on_initializeで初期化する- パラメーターを
self.configから取得 - 不足パラメーターに対するデフォルト値を設定
- 内部状態変数を初期化
- パラメーターを
- update typeをフィルタリングする
- 戦略が気にする update type のみを処理
- 常に processed_data 内の必須フィールドをチェック
- マーケットデータをバリデートする
- bid/askが存在することを使用前に確認
- ポジションが存在することを意思決定前に検証
- マーケット制約を尊重する
- 価格と数量をマーケットのtick sizeに丸める
- 最低注文サイズおよびnotional要件をチェック
- トレーディングアカウントを適切にハンドルする
- トレーディングアカウントがAccountAddressesに含まれることを確認
- 注文に対して正しいsubaccount_idを指定
- 適切なロギングを実装する
- 戦略の意思決定および重要なイベントをログ出力
- 適切なログレベル(info、warning、error)を使用
- カスタムパラメーターを設定する
- 戦略固有の値には
Parametersセクションを使用 - 期待されるパラメーターをドキュメント化
- 戦略固有の値には
カスタムハンドラ
フレームワークは、戦略にデータを渡す前に、特殊化されたハンドラを通じて更新を処理します。データ処理をより詳細に制御するために、カスタムハンドラを作成できます。Handlerベースクラス
すべてのハンドラはUpdateHandler ベースクラスから継承します:
カスタムハンドラの作成
カスタムハンドラを作成するには:- 適切なハンドラベースクラスから継承する
_process_updateメソッドをオーバーライドする- 戦略のコンストラクタでハンドラを登録する
カスタムハンドラの登録
戦略のコンストラクタでカスタムハンドラを登録します:利用可能なハンドラタイプ
フレームワークは、拡張可能な以下のハンドラタイプを提供します:主要データ構造
Update TypeとそれぞれのデータFields
フレームワークは、戦略が反応できる以下の主要なイベントタイプを処理します:Strategy Result
戦略がアクションを取る決定をするとき、以下を含むStrategyResult オブジェクトを返します:
