> ## 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.
# マーケットメイカー向け
> 両サイドに気配を出すときに効いてくる仕組み。待ち行列の優先順位、取り消しの優先、リベート、抱えられるサイズの制約です。
Intentionでのマーケットメイクは、参加を申し込む特別なプログラムではありません。気配を出せば、未約定注文にはメイカー料率が適用され、一定のしきい値を超えれば、流動性の提供に対して報酬が支払われます。
実装に取りかかる前に押さえておく価値があるのは、多くの取引所と違うこの取引所の構造的な性質三つと、そこから導かれる個々の仕組みです。以下の仕組みはいずれも別のページで詳述しています。このページはそこへの道筋です。
他と異なる三つの点
**ブロックの内側では、レイテンシが結果を決めません**。ある価格帯での優先順位は、まず価格、次にコミット済みブロックのシーケンス内での位置で決まります。パケットがノードに届いた時刻ではありません。同一ブロック内にある二つの注文の優先関係は、どのバリデータも同一に計算します。ブロックとブロックのあいだでは到着順が依然として意味を持ちますが、一つのブロックの内側ではコロケーションは何も買えません。
**同一ブロックでは、取り消しがテイカー注文に勝ちます**。取り消しは、流動性を取りにいく注文より前のフェーズで実行されます。価格が動いて古くなった気配を引くとき、その取り消しと並んで到着した注文が気配を拾うことはできません。多くの取引所ではこれはインフラで勝ち取るレースですが、ここではプロトコルによる保証です。
**ポストオンリー注文は、何かがぶつかってくる前に板に置かれます**。定義上、流動性を取ることがないため、マッチングを伴わないフェーズで、すべてのテイカーフローに先行して処理されます。
これらを合わせると、レイテンシに多額を投じる通常の理由、つまり同一ブロック内の逆選択から気配を守るという理由が、ここでは当てはまりません。[トランザクションの順序付け](/ja/trading/tx-sequencing)を参照してください。
気配の出し方
**ポストオンリーを使う**。メイカーであることが保証されます。クロスしてしまう注文は、テイカーとして約定するのではなく拒否されます。メイカー料率を確実に受け取るか、ときどき事故でテイカー料率を払うかの分かれ目です。[注文タイプ](/ja/trading/order-types)を参照してください。
**同一価格帯の優先順位は位置で決まります**。同じ価格の注文は、シーケンスされた順に約定します。列の先頭は約定し、列の後方は眺めるだけです。[板](/ja/trading/order-book)を参照してください。
**ティックサイズとロットサイズに従う**。適合しない価格は、丸められるのではなく拒否されます。空き担保は切り捨て、証拠金は切り上げで丸められるため、利用可能残高ちょうどのサイズで気配を出すと断続的に拒否されます。[精度と丸め](/ja/trading/precision)を参照してください。
気配の管理
実務上の差が最も大きく出るのは、ここです。
| 変更内容 | 仕組み | 待ち行列の位置 |
| ---------- | -------- | ------- |
| **数量を減らす** | その場で編集 | **維持** |
| 数量を増やす | 取り消して再発注 | 失う |
| 価格を変える | 取り消して再発注 | 失う |
リスク管理のために気配を縮めても、列の位置は失いません。多くの取引所はそう振る舞いませんし、この違いは在庫管理のコストを変えます。判断しているあいだに到着した全員の後ろに並び直すことなく、その価格帯のエクスポージャーを減らせるからです。[注文の変更](/ja/trading/modify-orders)を参照してください。
**すべての注文にクライアント注文IDを付ける**。送信がタイムアウトすると、それが届いたのかどうかは分かりません。自分で生成した識別子があれば、その識別子で取り消しを出し、どちらに転んでも既知の状態で終われます。識別子がなければ、マーケット・売買方向・価格・数量から照会して推測することになります。カウンターではなくランダムに生成してください。再起動でカウンターを失うと、有効な注文と衝突します。[クライアント注文ID](/ja/trading/client-order-id)を参照してください。
**セルフトレード防止は、アカウント内では常時有効です**。発注した注文が自分自身の未約定の気配を取ってしまう場合、その未約定注文は取り消され、専用のステータスが付きます。このステータスは必ず表示に出してください。この理由で気配が消えたということは、自分の戦略どうしが衝突したということです。
サブアカウントどうしも保護され**ます**。セルフトレード防止はウォレットアドレスを基準に判定され、同じウォレットに属するサブアカウントはそれを共有します。したがって、別々のサブアカウントで動かしている2つの戦略でも、突き合わされば取り消しが起きます。2つの戦略が正当に反対側を取り合ってよいのであれば、サブアカウントに分けても**それは実現できません**。別々のウォレットが必要です。[セルフトレード防止](/ja/trading/self-trade-prevention)を参照してください。
報酬
メイカー手数料は直近の累積出来高に応じて下がり、シェアのしきい値を超えるとマイナスになります。つまり、メイカー約定ごとに支払いを受け取ります。
| 取引所のメイカー出来高に占めるシェア | メイカー料率 |
| -----------------: | ------: |
| > 0.5% | −0.001% |
| > 1.5% | −0.002% |
| > 3.0% | −0.003% |
基準の違いに注意してください。手数料**ティア**は自分自身の絶対的な出来高で測り、**リベート**は取引所全体のメイカー出来高に占めるシェアで測ります。別々の資格要件であり、大口トレーダーであること自体ではリベートは得られません。板の中で意味のある割合を占めることが条件です。
マーケットメイクの帳簿には、他に二つの資金フローが効いてきます。[資金調達率](/ja/trading/funding)は、資金調達の決済をまたいで保有した在庫に課されます。翌日にスキューを持ち越す帳簿にとっては、実際のコストにも実際の収益にもなります。強制決済は、まず板に対してクローズされます。それを吸収するのは未約定の板の厚みであり、破産価格で相手方になることは、ストレス下のマーケットに気配を出すことの一部です。[手数料](/ja/programs/fees)と[強制決済](/ja/trading/liquidations)を参照してください。
サイズの制約
**証拠金はポジションだけでなく、未約定注文によっても拘束されます**。多数の価格帯にわたる広い板は、ポジションを建てうるすべての価格帯に対して証拠金を拘束します。[マージンモード](/ja/trading/margin-modes)を参照してください。
**ポジション上限はマーケットの規模に応じて変わります**。片側の上限は、マーケットの建玉に対する一定シェアと固定の下限値のうち大きいほうであり、サブアカウントを合算して判定します。[ポジション上限](/ja/trading/oi-limits)を参照してください。
**在庫はデレバレッジの順位に影響します**。スコアは未実現利益と実効レバレッジの積なので、高いレバレッジで運用している利益の乗ったスキュー帳簿は、列の先頭付近に並びます。[自動デレバレッジ](/ja/trading/adl)を参照してください。
導入の進め方
連携に使う口は誰にとっても同じです。RESTとWebSocket、4言語のSDK、テストネット用のツール群があります。[開発者向け](/ja/developers/overview)から始めてください。
専用料率、正式なメイカー契約、上場支援といった商業的な取り決めについては、`contact@intention.xyz`が窓口です。[ビルダー・連携に関する質問](/ja/help/builder-questions)を参照してください。
次に読む
レイテンシに頼らずに気配を守れるようにしている優先順位です。
気配を縮めても列の位置が残る理由です。
ティア、リベート、出来高の数え方です。
API、SDK、テストネット用ツールです。