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] 内。
• 2 つのティック配列 PDA が渡されます。それらは既に存在する必要はありません。get_or_create_tick_array は、このインストラクション内で payer の費用で不足しているものを割り当てます。個別の init-tick-array インストラクションはありません。
• ユーザーはソース 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 をそれに応じて調整します。
• 最後のタッチ以降に発生した手数料とリワードを回収し、token_fees_owed_{0,1} / reward_amount_owed にクレジットします。これらは DecreaseLiquidity / DecreaseLiquidityV2 でのみ支払われ、増加時には支払われません。スタンドアロン回収インストラクションはありません。

​

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 ミントも閉じます。従来の 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) を使用して累積出力を計算します。
• デルタを 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（管理者）