CLMM インストラクション

​

インストラクション一覧

​

CreatePool

sqrt_price_x64: u128           // 初期価格
open_time:      u64            // この時間前のスワップは拒否されます

• token_mint_0 < token_mint_1（バイト順）。
• amm_config.disable_create_pool == false。
• ミントは Token-2022 拡張ホワイトリストで拒否されていません。

• pool_state.sqrt_price_x64 = sqrt_price_x64、tick_current = floor(log_{1.0001}(price))。
• pool_state.liquidity = 0（ポジションなし）。
• pool_state.fee_on = FromInput（レガシー デフォルト）。
• pool_state.dynamic_fee_info はゼロ化（動的手数料無効）。

​

CreateCustomizablePool

pub struct CreateCustomizableParams {
    pub sqrt_price_x64:    u128,
    pub collect_fee_on:    CollectFeeOn,   // FromInput | Token0Only | Token1Only
    pub enable_dynamic_fee: bool,
}

• pool_state.fee_on は選択された CollectFeeOn バリアントに設定されます。
• 動的手数料が有効な場合：pool_state.dynamic_fee_info は提供された DynamicFeeConfig から初期化されます（5 つのキャリブレーション パラメータがコピーされ、状態フィールドはゼロ化）。
• それ以外の場合：pool_state.dynamic_fee_info はゼロ化（= このプールでは動的手数料は永遠に非アクティブ）。

​

CreatePermissionedPool

customizable_params: CreateCustomizableParams   // CreateCustomizablePool と同じ構造体
seed_index:          u16                          // ゼロ以外である必要があります。プール PDA シードに折り込まれます

• seed_index != 0。seed_index が 0 はレガシー プール用に予約されており、ここで拒否されます。[0, 0] シード コンポーネントは、レガシー プール アドレスを古典的な 4 シード形式に折りたたむものです。
• payer の permission PDA が存在します（管理者が CreatePermissionPda で作成）。
• CreatePool と同じミント/ホワイトリスト ルール。

• 新しい pool_state が seed_index 派生アドレスに存在し、pool_state.seed_index = seed_index。
• その他すべての事後状態は CreateCustomizablePool と一致（手数料モード、オプションの動的手数料）。

​

OpenPositionV2 / OpenPositionWithToken22Nft

tick_lower_index: i32
tick_upper_index: i32
tick_array_lower_start_index: i32
tick_array_upper_start_index: i32
liquidity:  u128              // 希望する L（または下記の金額を使用する場合は 0）
amount_0_max: u64
amount_1_max: u64
with_metadata: bool           // NFT メタデータを書き込む（Metaplex）
base_flag: Option<bool>       // true = amount0 に合わせる。false = amount1 に合わせる

• tick_lower < tick_upper、両方とも pool.tick_spacing の倍数、[MIN_TICK, MAX_TICK] 内。
• 必要なティック配列が渡され、初期化されます（またはトランザクション内で InitTickArray CPI を介してここで作成されます）。
• ユーザーはソース ATA に少なくとも amount_0_max と amount_1_max を持っています。

• personal_position が存在し、liquidity が設定され、fee_growth_inside_last がスナップショットされます。
• tick_lower と tick_upper のティック配列エントリが更新されます（liquidity_gross += L、liquidity_net ± L、手数料成長スナップショットが保持）。
• ポジションが範囲内の場合（tick_lower ≤ tick_current < tick_upper）、pool_state.liquidity += L。
• ポジション NFT ミントは pool_state をフリーズ権限として記録します。ミント権限は単一の NFT がミントされた後に削除されます。フリーズ権限を記録しても、NFT トークン アカウントの状態は変わりません。
• NFT トークン アカウントは、インストラクションが OpenPositionV2 または OpenPositionWithToken22Nft かついずれかのボルト ミントのフリーズ権限が CLMM の制限発行者リストと一致する場合を除き、フリーズされたままです。その一致する V2 パスのみがアカウントをフリーズします。OpenPosition V1 はフリーズしません。

​

IncreaseLiquidityV2

liquidity: u128
amount_0_max: u64
amount_1_max: u64
base_flag: Option<bool>

• ユーザー → ボルトから amount_0_actual / amount_1_actual を転送します。
• personal_position.liquidity と pool_state.liquidity（範囲内の場合）をインクリメントし、エンドポイント ティックの liquidity_gross / liquidity_net をそれに応じて調整します。
• 最後のタッチ以降に owed フィーとリワードを回収し、tokens_fees_owed_{0,1} / reward_amount_owed にクレジットします。これらは DecreaseLiquidity または CollectReward でのみ支払われ、増加時には支払われません。

​

DecreaseLiquidityV2

liquidity: u128
amount_0_min: u64
amount_1_min: u64

• 現在の sqrt_price_x64 が与えられた場合、削除された L の (amount_0, amount_1) を計算します。
• 最後のタッチ以降に発生したフィー/リワードを決済します（IncreaseLiquidity と同じ）。
• amount_0 + fees_owed_0 と amount_1 + fees_owed_1 をボルトからユーザーに転送します。
• リクイディティ カウンターをデクリメントします。新しい personal_position.liquidity == 0 の場合、ポジションは ClosePosition の対象になります。

​

ClosePosition

• フリーズされていない NFT：不要。追加のプール アカウントはハンドラーがそれを読み取らないため無害です。
• フリーズされた NFT：最初の残りのアカウントとして personal_position.pool_id を追加します。プログラムはそれを PoolState として読み込み、その PDA シードを使用してシャーに署名します。

• personal_position.liquidity == 0。
• tokens_fees_owed_{0,1} == 0。
• すべてのリワード カウンター reward_amount_owed == 0。

• NFT トークン アカウントがフリーズされている場合、最初の残りのアカウントが personal_position.pool_id と等しいことを確認し、プール PDA でそれをシャーします。
• NFT をバーンします。
• NFT トークン アカウントと personal_position を閉じ、レント払い戻しを nft_owner に返します。ポジション NFT が Token-2022 を使用する場合、NFT ミントも閉じます。classic SPL Token ミントは閉じることができず、供給量ゼロのままです。

​

SwapV2

amount: u64                  // is_base_input=true の場合は入力、それ以外は出力
other_amount_threshold: u64  // 最小出力または最大入力
sqrt_price_limit_x64: u128   // ハード バウンド。0 ⇒ 無制限
is_base_input: bool

• pool_state.status はスワップを許可します。
• now >= open_time。
• sqrt_price_limit_x64 は方向に対して sqrt_price_x64 の正しい側にあります。

1. 動的手数料サーチャージ — pool.dynamic_fee_info がゼロ以外の場合、プログラムは最後のスワップ以降に走査されたティック距離を使用して変動性アキュムレータを更新し（products/clmm/fees のフィルター/減衰ルール付き）、AmmConfig.trade_fee_rate の上に dynamic_fee_component を追加します。総手数料は 10%（MAX_FEE_RATE_NUMERATOR / 1_000_000）でキャップされます。
2. リミット オーダー マッチング — 価格ウォークがオープン リミット オーダーを保有するティックを交差するとき、プログラムはまずそのティックで利用可能なリミット オーダー リクイディティを約定させ（order_phase による FIFO）、その後 LP リクイディティ曲線に沿って進みます。約定した金額は tick.unfilled_ratio_x64 と tick.part_filled_orders_remaining を後の決済用に更新します。オーダー自体は所有者が SettleLimitOrder を呼び出すまで未消費のままです。
3. 片側手数料ルーティング — pool.fee_on = Token0Only または Token1Only の場合、スワップ ステップは同じ入力出力トレードを計算します。その後、手数料は設定された側にルーティングされます。設定された手数料側が出力である方向では、手数料はスワップ出力から差し引かれます（ユーザーは out − fee を受け取ります）。設定された手数料側が入力である方向では、動作は FromInput と一致します。PoolState の is_fee_on_input(zero_for_one) と is_fee_on_token0(zero_for_one) を参照してください。

​

OpenLimitOrder

nonce_index:    u8       // ユーザーが選択した nonce アカウント インデックス（ウォレットあたり 0..255）
zero_for_one:   bool     // true：token0 を token1 で売却。false：token1 を token0 で売却
tick_index:     i32      // pool.tick_spacing の倍数である必要があります
amount:         u64      // 入力トークン金額

• input_token_account も output_token_account もフリーズされていません（そうでない場合は NotApproved）。
• pool_state.status はスワップ（ビット 4）とリミット オーダー（ビット 5）操作の両方を許可します（そうでない場合は NotApproved）。
• tick_index % pool.tick_spacing == 0 かつ [MIN_TICK, MAX_TICK] 内。
• tick_index は選択された方向に対して pool.tick_current の右側にあります（token0 を売却 → ティックは現在より上である必要があり、その逆も同様）。既に交差したティックで売却することは即座に約定され、拒否されます。

• limit_order が存在し、開く時点で tick.order_phase と tick.unfilled_ratio_x64 をスナップショットします。
• tick.orders_amount += amount（現在のコホート内）。
• limit_order_nonce.order_nonce += 1。
• OpenLimitOrderEvent が発行されます。

​

IncreaseLimitOrder

amount: u64    // 追加の入力トークン金額

• limit_order.owner == signer。
• オーダーはまだ同じコホート内にあります（tick.order_phase == limit_order.order_phase）。コホートが既に約定を開始している場合、オーダーは部分的に決済されています。呼び出し元は最初に DecreaseLimitOrder または SettleLimitOrder を呼び出して前に進める必要があります。

• 所有者 ATA から input_vault に amount を転送します。
• limit_order.total_amount += amount。tick.orders_amount += amount。

​

DecreaseLimitOrder

amount:     u64    // 引き出す入力トークン金額（最大 = 未約定の残り）
amount_min: u64    // 入力側の引き出しのスリッページ フロア

• 開く以降のコホートの unfilled_ratio_x64 からオーダーの約定金額を再計算します。
• 約定した出力を output_token_account に送信します。
• 未約定の入力の amount を input_token_account に返します。
• limit_order をそれに応じて更新します。新しい未約定の残りがゼロの場合、プログラムはアカウントを閉じ、レント払い戻しを owner に返します。

​

SettleLimitOrder

• (limit_order.unfilled_ratio_x64, tick.unfilled_ratio_x64) を使用して、owed の累積出力を計算します。
• デルタを output_token_account に転送します。
• limit_order.settled_output を更新します。
• オーダーを閉じません。未約定の入力に対してまだ開いています。

​

CloseLimitOrder

• オーダーの未約定の残りがゼロです（amount == total_amount が約定して決済されたか、所有者が以前にオーダーをゼロに減らして閉じるのを忘れた）。

• limit_order を閉じます。レント払い戻しは limit_order.owner に送信されます。

​

CreateDynamicFeeConfig（管理者）

index:                       u16
filter_period:               u16   // 秒。例：30
decay_period:                u16   // 秒。例：600。filter_period より大きい必要があります
reduction_factor:            u16   // 1..10_000。例：5_000 = 減衰ウィンドウあたり 50% 保持
dynamic_fee_control:         u32   // 1..100_000。変動性対手数料曲線のゲイン
max_volatility_accumulator:  u32   // 上限

​

UpdateDynamicFeeConfig（管理者）

​

CollectProtocolFee / CollectFundFee

​

InitializeReward

open_time:     u64
end_time:      u64
emissions_per_second_x64: u128   // Q64.64

• プールで現在 3 未満のストリームがアクティブ。
• ファンダーは total_emission = emissions_per_second × (end_time − open_time) 相当のリワード トークンをこのインストラクションの一部としてボルトに預金します。
• operation_state ごとのホワイトリスト リワード ミント。

​

SetRewardParams

​

UpdateRewardInfos

​

CollectReward

• リワード成長を決済します（手数料と同じパターン）。
• owed 金額を受取人 ATA に転送し、reward_amount_owed[i] をゼロにします。

​

状態変更マトリックス

​

次のステップ

• products/clmm/code-demos — 実行可能な TypeScript サンプル。
• products/clmm/fees — 手数料とリワード発生の詳細。
• reference/error-codes — 完全な CLMM Anchor エラー テーブル。

• raydium-io/raydium-clmm — programs/amm/src/instructions
• Raydium SDK v2 — @raydium-io/raydium-sdk-v2