メインコンテンツへスキップ
このページは AI による自動翻訳です。すべての内容は英語版を正とします。英語版を表示 →
ドキュメンテーション変更ログエントリです。すべての更新のインデックスについては、reference/changelog を参照してください。プロトコル自体の歴史的タイムラインについては、introduction/history-and-milestones を参照してください。
次の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 および Accounts → LimitOrderState を参照してください。

​
PoolState の再構成

フィールドグループ旧レイアウト新レイアウト
方向別ボリュームカウンターswap_in_amount_token_0、swap_out_amount_token_0、swap_in_amount_token_1、swap_out_amount_token_1padding5: [u128; 4] に統合
ライフタイムフィーカウンターtotal_fees_token_0、total_fees_claimed_token_0、total_fees_token_1、total_fees_claimed_token_1padding6: [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 で更新された状態変更マトリックスを参照してください。

​
新しいエラーコード

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 にあります。

​
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 にあります。

​
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 を参照してください。

​
更新されたページ

  • 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 ソース。