> ## Documentation Index
> Fetch the complete documentation index at: https://docs.raydium.io/llms.txt
> Use this file to discover all available pages before exploring further.

# 2026-05-18 — CLMM: リミットオーダー、単一側フィー、動的フィー

> 3つのオプトイン・後方互換性のあるCLMM機能：ファーストクラスのリミットオーダー、単一側フィー徴収、ボラティリティ追跡型動的フィー、およびPoolStateの再構成と新しいエラーコード。

<Info>
  **このページは AI による自動翻訳です。すべての内容は英語版を正とします。**

  [英語版を表示 →](/reference/changelog/2026-05-18-clmm-limit-orders)
</Info>

<Info>
  ドキュメンテーション変更ログエントリです。すべての更新のインデックスについては、[`reference/changelog`](/ja/reference/changelog) を参照してください。プロトコル自体の歴史的タイムラインについては、[`introduction/history-and-milestones`](/ja/introduction/history-and-milestones) を参照してください。
</Info>

次のCLMMリリースでは、3つのプール レベルの機能が追加されます。これらはプール作成時にオプトインであり、既存のプールとポジションとの後方互換性があります。

## インテグレーター向けTL;DR

* **リミットオーダー**は、現在ファーストクラスのCLMMプリミティブです。LPは、これをサポートするプール上で単一ティックのオーダーを開くことができます。オーダーはスワップがティックを横切るときにFIFO方式で約定し、オフチェーンキーパー（`limit_order_admin`）は所有者がオンラインでなくても約定した出力を決済できます。7つの新しいSDKメソッド（`openLimitOrder`、`increaseLimitOrder`、`decreaseLimitOrder`、`settleLimitOrder`、`closeLimitOrder`、`closeAllLimitOrder`、`settleAllLimitOrder`）と3つの新しいTemp APIエンドポイント（`/limit-order/` 配下：アクティブオーダー、ユーザーごとの履歴、PDAごとのイベントログ）が全フローをカバーします。
* \*\*単一側フィー（`CollectFeeOn`）\*\*により、プールはスワップフィーを入力側から徴収（レガシー、モード `0`）、または常に `token_0` から（モード `1`）、または常に `token_1` から（モード `2`）徴収できます。ペアの一方が正規の会計トークンである場合に便利です。
* **動的フィー**により、プールはボラティリティ追跡型の追加料金にオプトインでき、急速なティック移動で上昇し、時間とともに減衰します。ティアごとの `DynamicFeeConfig` とプールごとの `DynamicFeeInfo` で調整されます。新しい `/main/clmm-dynamic-config` エンドポイントがティアリストを表示します。
* 新しい命令 `CreateCustomizablePool` は、プール作成時にこれら3つのノブをすべて公開します。クラシック `CreatePool` は、デフォルトフィー・リミットオーダーなしのプールで引き続き機能します。
* **インデクサー破壊的変更**：`PoolState` の方向別ボリュームカウンター（`swap_in_amount_token_{0,1}`、`swap_out_amount_token_{0,1}`）とライフタイムフィーカウンター（`total_fees_token_{0,1}`、`total_fees_claimed_token_{0,1}`）は、`fee_on` と `dynamic_fee_info` のためのスペースを作るためにパディングに廃止されました。これらのフィールドを直接読むインデクサーは、オンチェーン `Observation` リングまたはAPIに移行する必要があります。

## これが重要な理由（トレーダー、LP、インテグレーター向け）

* **トレーダー**は、ロングテールおよびイベント駆動型ペアでより厳密なクォートを取得します。動的フィーにより、プールはLPが積極的に範囲を広げることなくテイカーからボラティリティ追加料金を吸収でき、リミットオーダーラダーは範囲全体の資本をコミットすることなく特定の価格でオンチェーン流動性を深くします。
* **LP**は、集中範囲とフルレンジポジションに加えて、3番目の戦略を取得します。正確な価格のオーダーを駐車し、価格がそこを訪れるときに約定し、クォートトークンに決済します。約定部分のアクティブなリバランスは不要です。
* **インテグレーター**は、動的フィープールを決定論的にモデル化できます。アルゴリズムとパラメーターは完全にオンチェーンであり、キャリブレーションティアはクエリ可能であり、スワップパスは形状が変わりません（各ステップのフィーのみが変わります）。

## プログラムで変更されたもの

### 新しいアカウント

* **`DynamicFeeConfig`** — ティアごとのキャリブレーションレコード（フィルター期間、減衰期間、削減係数、動的フィー制御、最大ボラティリティアキュムレーター）。`CreateDynamicFeeConfig`（管理者）で作成され、動的フィーが有効な場合に `CreateCustomizablePool` で参照されます。
* **`LimitOrderState`** — オーダーごとのアカウント（PDAシード：`[owner, limit_order_nonce, order_nonce]`）で、プール、ティック、サイド、入力額、未約定比率、FIFOコホートフェーズ、および簿記スナップショットを保持します。ライフサイクルは暗黙的です（`filled_amount` vs `total_amount`、およびアカウント存在）：`Open → Filled → Settled → Closed`。
* **`LimitOrderNonce`** — オーナーごと、nonce\_indexごとの単調増加カウンター。リミットオーダーPDAシードを取得します。`nonce_index: u8` により、同じオーナーがオーダーを最大256の独立したnonceストリームに分割できます。

[Accounts → DynamicFeeConfig and DynamicFeeInfo](/ja/products/clmm/accounts) および [Accounts → LimitOrderState](/ja/products/clmm/accounts) を参照してください。

### `PoolState` の再構成

| フィールドグループ      | 旧レイアウト                                                                                                | 新レイアウト                                                    |
| -------------- | ----------------------------------------------------------------------------------------------------- | --------------------------------------------------------- |
| 方向別ボリュームカウンター  | `swap_in_amount_token_0`、`swap_out_amount_token_0`、`swap_in_amount_token_1`、`swap_out_amount_token_1` | `padding5: [u128; 4]` に統合                                 |
| ライフタイムフィーカウンター | `total_fees_token_0`、`total_fees_claimed_token_0`、`total_fees_token_1`、`total_fees_claimed_token_1`   | `padding6: [u64; 4]` に統合                                  |
| 単一側フィー         | —                                                                                                     | `fee_on: u8`（0 = FromInput、1 = Token0Only、2 = Token1Only） |
| 動的フィー          | —                                                                                                     | `dynamic_fee_info: DynamicFeeInfo`（埋め込み）                  |

総アカウントサイズは変わりません。**インデクサー**：ボリューム追跡を `PoolState` から `Observation` リングまたはAPIに切り替えてください。廃止されたカウンターは既存のプールではゼロにされません（最後に保持していた値を保持します）。アップグレード後にそれらを再度読むと、古いデータが返されます。

### `TickState` の追加（破壊的変更なし）

4つの新しいフィールドが `TickState` の末尾に追加され、その末尾パディングの一部を置き換えます：

* `order_phase: u64` — このティックのリミットオーダーコホートを区別するカウンター。
* `orders_amount: u64` — このティックのすべてのオープンオーダーによってコミットされた総入力（すべてが完全に未約定であるわけではありません）。
* `part_filled_orders_remaining: u64` — 現在スワップによって消費されているコホートで未約定のままの入力。
* `unfilled_ratio_x64: u128` — 各オーダーの約定シェアを計算するために使用されるQ64.64比率。

ティック配列レイアウト、サイジング、およびPDAシードは変わりません。

### 新しい命令

* **`CreateDynamicFeeConfig`（管理者）** — キャリブレーションされた `DynamicFeeConfig` ティアを作成します。権限：`CreateAmmConfig` と同じトレジャリーマルチシグ。
* **`UpdateDynamicFeeConfig`（管理者）** — 既存のティアのパラメーターを更新します。
* **`CreateCustomizablePool`** — `collect_fee_on`、`enable_dynamic_fee`、および `dynamic_fee_config` を公開するプール作成エントリーポイント。`CreatePool` と共存します。新しいノブが必要な新しいプールには `CreateCustomizablePool` をお勧めします。
* **`OpenLimitOrder`** — 単一ティックのリミットオーダーを開きます。`LimitOrderNonce` をバンプし、`LimitOrderState` を割り当て、ティックのFIFOコホートにオーダーをスロットします。
* **`IncreaseLimitOrder` / `DecreaseLimitOrder`** — オーダーの未約定部分を調整します。完全に約定したオーダーで `InvalidOrderPhase` で戻ります。
* **`SettleLimitOrder`** — 約定した出力をオーナーのATAに掃引します。呼び出し元はオーナーまたはプールの `limit_order_admin` キーパーです。
* **`CloseLimitOrder`** — 完全に決済されたオーダーを閉じてレントを回収します。

### `SwapV2` の動作変更

スワップパス自体は形状が変わりませんが、途中で3つのことが起こります：

1. **動的フィー**（有効な場合）：プールの `DynamicFeeInfo` は各ステップで更新され（減衰 → 蓄積 → キャップ）、結果の追加料金がそのステップの基本フィーの上に追加されます。
2. **リミットオーダーマッチング**（ステップがオープンオーダーを持つ初期化されたティックを横切る場合）：スワップ入力の一部がFIFO方式で消費され、そのティックのコホートを約定させ、`unfilled_ratio_x64` がアトミックに更新されます。
3. **単一側フィールーティング**（`fee_on != 0` の場合）：スワップ方向に関係なく、常に入力側からではなく、`token_0` または `token_1` からフィーが取られます。

これらのそれぞれは、プールがレガシーデフォルトで作成された場合はノーオペレーションです。[Instructions → SwapV2](/ja/products/clmm/instructions) で更新された状態変更マトリックスを参照してください。

### 新しいエラーコード

`ErrorCode` 列挙型はこのリリースで再番号付けされました。5つのレガシーバリアント（`LOK`、`ZeroMintAmount`、`InvalidLiquidity`、`TransactionTooOld`、`InvalidRewardDesiredAmount`）が削除され、11の新しいバリアントが追加されました。Anchorはエラーを列挙型の順序から `6000` で番号付けするため、**削除された位置以降のすべてのエラーコードがシフトしました** — ハードコードされた数値コードを使用するクライアントは再マップする必要があります。

新しいコードは：

* `6040` `OrderAlreadyFilled`
* `6041` `InvalidOrderPhase`
* `6042` `InvalidLimitOrderAmount`
* `6043` `OrderPhaseSaturated`
* `6044` `InvalidDynamicFeeConfigParams`
* `6045` `InvalidFeeOn`
* `6046` `ZeroSqrtPrice`
* `6047` `ZeroLiquidity`
* `6048` `MissingBaseFlag`
* `6049` `MissingMintAccount`
* `6050` `MissingTokenProgram2022`

完全な文字列とすべてのCLMMエラーのシフト後テーブルは [Error codes](/ja/reference/error-codes) にあります。

## SDK（`@raydium-io/raydium-sdk-v2`）で変更されたもの

* **`raydium.clmm` の新しいメソッド**：`createCustomizablePool`、`openLimitOrder`、`increaseLimitOrder`、`decreaseLimitOrder`、`settleLimitOrder`、`settleAllLimitOrder`、`closeLimitOrder`、`closeAllLimitOrder`。
* **`raydium.api` の新しいRESTヘルパー**：`getClmmDynamicConfigs`、`getClmmLimitOrderConfigs`。
* **新しい型**：`CollectFeeOn` 列挙型、`DynamicFeeConfig`、`DynamicFeeInfo`、`LimitOrderState`、`LimitOrderConfig`。
* **内部再構成**：`utils/` が `libraries/` に移動しました。パッケージバレルは変わりません。`@raydium-io/raydium-sdk-v2/utils/...` の下の深いインポートのみ `…/libraries/...` に更新する必要があります。

エンドツーエンドのTypeScriptウォークスルーは [`products/clmm/code-demos`](/ja/products/clmm/code-demos) にあります。

## APIで変更されたもの

* `api-v3` — `/main/` 配下の2つの新しいエンドポイント：
  * `GET /main/clmm-dynamic-config` — `DynamicFeeConfig` ティアのリスト。
  * `GET /main/clmm-limit-order-config` — プールごとのリミットオーダー設定。
* `temp-api-v1` — `/limit-order/` 配下の3つの新しいエンドポイント：
  * `GET /limit-order/order/list?wallet=…` — ウォレットの現在駐車されているオーダー（オープンおよび部分約定、インデクサーのRedisキャッシュから提供；同じペイロードが `totalAmount` / `filledAmount` / `pendingSettle` 経由で両方のフェーズをカバー）。
  * `GET /limit-order/history/order/list-by-user?wallet=…` — ウォレットの履歴リミットオーダー。オプションフィルター：`poolId`、`mint1`、`mint2`、`hideCancel`。`nextPageId` / `size`（最大100）経由でカーソルページネーション。
  * `GET /limit-order/history/event/list-by-pda?pda=…` — PDAごとのイベントログ（`open` / `increase` / `decrease` / `settle` / `close`）1つ以上のカンマ区切りリミットオーダーPDA用。`nextPageId` / `size`（最大100）経由でカーソルページネーション。

すべて5つはAPI参照タブで文書化されています。

## 権限サーフェス

`limit_order_admin` はオフチェーン運用キーパーであり、**マルチシグではありません**。既存のオーダーで `SettleLimitOrder` と `CloseLimitOrder` のみを呼び出すことができ、決済の出力は常に**オーナーの** ATAに着地します。プールフィールドを変更したり、オーダーを開いたり変更したり、他の何かに署名したりすることはできません。[Admin keys and multisig → CLMM](/ja/security/admin-and-multisig) を参照してください。

## 更新されたページ

* `products/clmm/overview` — 新しい「What's new」セクションと更新された次のステップポインター。
* `products/clmm/accounts` — 3つの新しいアカウント、`PoolState` 再構成と移行警告、`TickState` 追加、新しいPDAヘルパー。
* `products/clmm/instructions` — 7つの新しい命令、`SwapV2` 動作補遺、更新された状態変更マトリックス。
* `products/clmm/fees` — 単一側フィーセクション、パラメーターテーブル付き動的フィーセクション。
* `products/clmm/math` — リミットオーダーマッチング疑似コード、動的フィー導出。
* `products/clmm/code-demos` — `createCustomizablePool` デモ、完全なリミットオーダーウォークスルー、新しい落とし穴。
* `algorithms/clmm-math` — マルチティックスワップループのリミットオーダーマッチングと動的フィーへのクロスリファレンス。
* `sdk-api/typescript-sdk` — CLMMモジュール追加セクション、`utils/` → `libraries/` 移行ノート。
* `api-reference/openapi/api-v3.yaml` — レスポンススキーマ付き2つの新しいエンドポイント。
* `api-reference/openapi/temp-api-v1.yaml` — 3つの新しいリミットオーダーエンドポイント（`/limit-order/order/list`、`/limit-order/history/order/list-by-user`、`/limit-order/history/event/list-by-pda`）とそれらのリクエストおよびレスポンススキーマ。
* `api-reference/api-v3/overview` — 新しいCLMMコンフィグエンドポイントのノート。
* `api-reference/temp-api-v1/overview` — 新しいアクティブオーダー、ユーザーごとの履歴、およびPDAごとのイベントエンドポイントのノート。
* `reference/error-codes` — 11の新しいCLMMエラーコード（6040–6050）と5つの削除されたレガシーコード；削除ポイント後の数値コードがシフトしました。
* `security/admin-and-multisig` — 新しい `DynamicFeeConfig` 管理者行と `limit_order_admin` キーパー行、有界権限説明付き。

**検証対象**：

* `raydium-clmm` ソース。
* `@raydium-io/raydium-sdk-v2` ソース。
* `api-v3` および `temp-api-v1` ソース。