人類はCodexの開発にたった1%も貢献していない！
昨日、APIを手に入れたばかりで少し時間を使って指値の注文スクリプトを作りました
口座の初期総資産は311.8u
一晩回して取引量8k、利益は1.31u
この手数コストは実質マイナスみたいなものです
主に今のプラットフォームの流動性がめちゃくちゃ良いおかげです
こんなスクリプトを作るには考えるべきことがたくさんあります：
- どのタスクを並列化できて、どの動作は必ず直列にするべき？
読み取りは並列でOKですが、注文の発行・撤回はできるだけ直列にすべきです。そうしないと、注文を出した直後に別スレッドが誤って削除・誤撤回したり、重複で指値を出してしまいやすくなります
- BUY と SELL はスレッドを分けるべき？
BUY は市場と板情報を走査する必要があり、比較的遅いです；SELL は保有ポジションを監視する必要があり、応答を素早くする必要があります。分ければ、SELL が BUY の全量スキャンに引きずられません
- ローカルの state はどう設計する？
APIの open orders だけに頼ってはいけません。取引所の状態はリアルタイムで完全に一致しません。create order が成功しても、open orders が見えるまで数秒かかることがあります。ローカル state は短期的な重複排除、重複送信の防止、誤ったクリーンアップの防止を担う必要があります
- eventual consistency はどう扱う？
作成したばかりの注文が、次の秒に open orders で見つからないからといって無効だと判断してはいけません。待機ウィンドウを設定する必要があります。たとえば30〜60秒。口座同期のスレッドが新規注文を誤って消さないようにするためです
- 注文価格はどう取得する？
Yes/No、Over/Under のような反転 outcome は誤差が出やすく、簡単に計算がズレます。特に SELL のときは、Yes 側のオーダーブックを盲目的に補完するより、現在の保有 outcome の bestAsk を使うのが良いです
- 取り分（シェア）の精度はどう扱う？
フロント表示の 17.86 は「本当に売れるのが17.86」を意味しません。注文数量は必ず小数を切り捨てる必要があり、四捨五入はダメです。そうしないと insufficient shares（不足シェア）になってしまいます
- API の異常はどう分類する？
hash mismatch、残高不足、シェア不足、遠端切断、レスポンスの切り詰め、注文同期遅延。処理方法は全部違います。単純に無限リトライしてはいけません
- リスク管理の境界はどう書く？
成行で売らない、テイカーを食べない、post-only、BUY の範囲を制限する、開幕前に買い注文を撤回する。これらはすべてコード内のハード制約に変換する必要があります
AIがあれば気軽に、長期的に安定して納品できるシステムが作れる、という話ではありません。必ずエンジニアリングの観点から、安定性テストや風控（リスク管理）をきちんと実装していく必要があります
興味ある方、一緒に交流しましょう〜
@Predictdotfun
昨日、APIを手に入れたばかりで少し時間を使って指値の注文スクリプトを作りました
口座の初期総資産は311.8u
一晩回して取引量8k、利益は1.31u
この手数コストは実質マイナスみたいなものです
主に今のプラットフォームの流動性がめちゃくちゃ良いおかげです
こんなスクリプトを作るには考えるべきことがたくさんあります：
- どのタスクを並列化できて、どの動作は必ず直列にするべき？
読み取りは並列でOKですが、注文の発行・撤回はできるだけ直列にすべきです。そうしないと、注文を出した直後に別スレッドが誤って削除・誤撤回したり、重複で指値を出してしまいやすくなります
- BUY と SELL はスレッドを分けるべき？
BUY は市場と板情報を走査する必要があり、比較的遅いです；SELL は保有ポジションを監視する必要があり、応答を素早くする必要があります。分ければ、SELL が BUY の全量スキャンに引きずられません
- ローカルの state はどう設計する？
APIの open orders だけに頼ってはいけません。取引所の状態はリアルタイムで完全に一致しません。create order が成功しても、open orders が見えるまで数秒かかることがあります。ローカル state は短期的な重複排除、重複送信の防止、誤ったクリーンアップの防止を担う必要があります
- eventual consistency はどう扱う？
作成したばかりの注文が、次の秒に open orders で見つからないからといって無効だと判断してはいけません。待機ウィンドウを設定する必要があります。たとえば30〜60秒。口座同期のスレッドが新規注文を誤って消さないようにするためです
- 注文価格はどう取得する？
Yes/No、Over/Under のような反転 outcome は誤差が出やすく、簡単に計算がズレます。特に SELL のときは、Yes 側のオーダーブックを盲目的に補完するより、現在の保有 outcome の bestAsk を使うのが良いです
- 取り分（シェア）の精度はどう扱う？
フロント表示の 17.86 は「本当に売れるのが17.86」を意味しません。注文数量は必ず小数を切り捨てる必要があり、四捨五入はダメです。そうしないと insufficient shares（不足シェア）になってしまいます
- API の異常はどう分類する？
hash mismatch、残高不足、シェア不足、遠端切断、レスポンスの切り詰め、注文同期遅延。処理方法は全部違います。単純に無限リトライしてはいけません
- リスク管理の境界はどう書く？
成行で売らない、テイカーを食べない、post-only、BUY の範囲を制限する、開幕前に買い注文を撤回する。これらはすべてコード内のハード制約に変換する必要があります
AIがあれば気軽に、長期的に安定して納品できるシステムが作れる、という話ではありません。必ずエンジニアリングの観点から、安定性テストや風控（リスク管理）をきちんと実装していく必要があります
興味ある方、一緒に交流しましょう〜
@Predictdotfun
