> ## Documentation Index
> Fetch the complete documentation index at: https://docs.intention.xyz/llms.txt
> Use this file to discover all available pages before exploring further.
# クライアント注文ID
> 注文に自分で決めた識別子を付け、チェーンが割り当てる値ではなく自分が選んだ値で取り消しや突合を行えるようにします。
注文を送信すると、チェーンがその注文に注文IDを割り当てます。このIDが正式なものですが、値を知れるのは注文が受理された*後*です。受理を確認できなかった注文を取り消したい、という場合にはこれが問題になります。
クライアント注文IDはそれを解決します。識別子は自分で生成して送信時に付与し、送った瞬間からその識別子で注文を操作できます。
見た目以上に効いてくる理由
送信がタイムアウトした場合を考えます。チェーンに届いたのかどうかは分かりません。クライアント注文IDがなければ、直近の注文を照会してマーケット・売買方向・価格・数量から推測するか、何もせずに祈るかの二択です。
識別子があれば、この曖昧さは消えます。自分で生成した識別子で取り消しを出すだけです。注文が存在していれば取り消され、届いていなければ取り消しは何も見つけません。どちらの場合も既知の状態で終わります。人が張り付いていない状態で動くシステムに本当に必要なのは、これです。
突合が現実的になるのも同じ理由です。自分側の記録は自分が付けた識別子をキーにしているため、自分の状態とチェーン側の状態を突き合わせる作業は、推測ではなく単純な参照になります。
識別子は**16バイトの値**で、`0x`から始まる32文字の小文字16進文字列として送信します。
```
0xa1b2c3d4e5f6789012345678901234ab
```
プロトコルが強制するルールは三つあります。
* **小文字のみ**。大文字の16進数は正規化されず、拒否されます。
* **長さは厳密**。これより短くても長くても拒否されます。
* **オールゼロは予約済み**。`0x00000000...0000`は「未指定」を表すセンチネル値であり、識別子としては使えません。
このフィールドは任意です。付けずに出した注文も、あらゆる点で通常どおり動作します。クライアント注文IDでは取り消せず、チェーンが割り当てた注文IDでのみ取り消せる、というだけです。
一意性
一意性のスコープは**サブアカウント**です。署名アドレスと、その配下のサブアカウントの組み合わせが単位になります。
ここから二つの帰結が出ます。同一アドレス配下の異なるサブアカウントは、同じ識別子を衝突なく使えます。それぞれが独自にIDを生成する独立した戦略を走らせる場合に便利です。一方、同じサブアカウントの中で、有効な注文が使っている識別子を再利用すると、置き換えではなくエラーになります。
識別子は連番ではなくランダムに生成してください。カウンターは順序が見える点で魅力的ですが、再起動でカウンターを失うと、まだ有効な注文と衝突します。16バイトのランダム値なら、実用上まず衝突しません。
識別子でできること
| 操作 | 挙動 |
| ------------------- | --------------------------------- |
| **クライアント注文IDで取り消し** | チェーン割り当てのIDなしで、その識別子を持つ有効な注文を取り消し |
| **クライアント注文IDで照会** | その注文の現在の状態と履歴を取得 |
| **突合** | 自分が付けた識別子で、自分の記録とチェーン上の記録を突き合わせ |
識別子が残る期間
識別子はセッションではなく注文に属します。注文が約定または取り消された後も照会でき、これが事後の突合に役立ちます。
その注文が有効でなくなった時点で、識別子は再利用可能になります。ただし実務上、再利用する理由はほとんどありません。新しいランダム値の生成にコストはかからず、履歴上のレコードがどの注文を指すのかという疑問も残りません。
次に読む
有効な注文を変更したとき、識別子がどうなるのかです。
識別子を付けられる注文の種類です。
注文の送信と、曖昧なレスポンスをコードで扱う方法です。
同じブロックで送った取り消しが、テイカー注文より先に実行される理由です。