Skip to main content
このページは AI による自動翻訳です。すべての内容は英語版を正とします。英語版を表示 →
このページは products/clmm/accounts(アカウントの説明)および products/clmm/math(数学の説明)と対になっています。引数とアカウント順序については権威的ですが、具体的なバイト レイアウトは IDL から取得されます。

インストラクション一覧

init-tick-array 命令は存在せず、必要もありません。 ティック配列は OpenPosition* / IncreaseLiquidity* の 内部 で TickArrayState::get_or_create_tick_array によって作成され、 payer が費用を負担します。(まだ未初期化でシステム所有かもしれない)ティック配列 PDA を tick_array_lower / tick_array_upper として渡せば、存在しない場合はプログラムが確保します。 OpenLimitOrder も単一の tick_array に対して同じことを行います。
ほとんどの管理者専用インストラクション(CreateAmmConfig、UpdateAmmConfig、UpdatePoolStatus、CreateOperationAccount、UpdateOperationAccount、CloseProtocolPosition)は、プログラムのハードコードされた admin 公開鍵によってゲートされます。CreatePermissionPda / ClosePermissionPda は admin 公開鍵または専用の permission_pda_admin キーのいずれかを受け入れます。CreateSupportMintAssociated / CloseSupportMintAssociated は admin 公開鍵または専用のサポート ミント オーナー キーのいずれかを受け入れます。リワード ストリーム管理インストラクション(TransferRewardOwner、CollectRemainingRewards)は、プログラム管理者ではなくリワード ファンダーによってゲートされます。 V2 サフィックスは「ボルト/NFT で Token-2022 をサポート、ビットマップ拡張スロットが必要」を意味します。SDK は新しいプールに対してデフォルトで V2 を選択します。

CreatePool

引数
アカウント(簡略版)
スロット 10 と 11 は「SPL Token、次に Token-2022」ではなく、ミントごとです。それぞれ対応する ミント上の mint::token_program によって制約されるため、token_mint_0 が Token-2022 で token_mint_1 がクラシックな SPL であるプールでは、スロット 10 に Token-2022、スロット 11 に SPL Token を渡す必要があります。CreateCustomizablePool と CreatePermissionedPool も同じ 2 つのスロットを使用します。
前提条件
  • 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

新しいプールに推奨されます。CreatePool と同じ効果に加えて、プール単位の手数料回収モードとオプションの動的手数料オプトイン。 引数
アカウント — ちょうど CreatePool の 13 個の宣言済みアカウントです。dynamic_fee_config は宣言済みアカウントでは ありません。
enable_dynamic_fee = true の場合、スナップショットする DynamicFeeConfig は 最後の remaining_account として渡さなければなりません — ハンドラは ctx.remaining_accounts.last() を 読み取ります。したがって SupportMintAssociated のバイパス PDA はその 前 に置く必要があります。 そうしないとプログラムは誤ったアカウントをスナップショットし、デシリアライズに失敗します。 フラグが立っているのにこれを省略すると AccountLack で失敗します。
前提条件 — CreatePool と同じ。enable_dynamic_fee = false の場合、remaining_account は不要で、渡されたものはサポート ミント レコードのスキャンにのみ使用されます。 事後条件
  • pool_state.fee_on は選択された CollectFeeOn バリアントに設定されます。
  • 動的手数料が有効な場合:pool_state.dynamic_fee_info は提供された DynamicFeeConfig から初期化されます(5 つのキャリブレーション パラメータがコピーされ、状態フィールドはゼロ化)。
  • それ以外の場合:pool_state.dynamic_fee_info はゼロ化(= このプールでは動的手数料は永遠に非アクティブ)。
fee_on と動的手数料有効化ビットはプール作成時のみ設定されます。インプレース アップグレードはありません。レガシー CreatePool で作成されたプールは、動的手数料または片側手数料を遡及的に取得することはできません。新しいデプロイメントはこのインストラクションをデフォルトにする必要があります。

CreatePermissionedPool

CreatePool と CreateCustomizablePool は両方とも、プール PDA を ["pool", amm_config, token_mint_0, token_mint_1] から派生させるため、(config, mint0, mint1) トリプルごとに正確に1 つの正規プール アドレスが存在します。同じシードで 2 番目の init は失敗します。CreatePermissionedPool は、クライアント提供の seed_index: u16 をプール PDA シードに折り込むことでその制限を解除し、同じペアと手数料ティアに対して複数のプールを許可します。各プールは独自のアドレスにあります。任意のプール アドレスは特権機能であるため、支払者はそれを認可する Permission PDA を保有する必要があります。 プールに関するその他すべては CreateCustomizablePool と同じです。同じ CreateCustomizableParams を取り、片側手数料と動的手数料オプトインをサポートします。 引数
アカウント(簡略版) — CreateCustomizablePool と同じに加えて、前面に: pool_state PDA は ["pool", amm_config, token_mint_0, token_mint_1, seed_index.to_le_bytes()] から派生します。 前提条件
  • 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 と一致(手数料モード、オプションの動的手数料)。
このインストラクションは一般的なプール作成アクセスを拡大しません。パーミッションレス作成は CreatePool / CreateCustomizablePool を通じて継続され、これらは 1 プール/ペアのままです。CreatePermissionedPool は、ホワイトリストに登録されたオペレーターが同じペアに対して複数のプール(例:異なる初期価格またはローンチ コホート)が必要で、管理者から付与された Permission PDA を保有する特定のケースのために存在します。

OpenPositionV2 / OpenPositionWithToken22Nft

既存のプール内に新しいポジションを作成します。 引数
アカウント(簡略版) OpenPositionWithToken22Nft は同じリストから metadata_account(5)と metadata_program(19)を 削除 したもので — 代わりに NFT ミント上の Token-2022 メタデータ拡張を通じてポジションのメタデータを書き込みます — 合計 20 アカウントになります。その position_nft_mint は素の Signer、position_nft_account は UncheckedAccount です。
tick_array_bitmap_extension はどちらのバリアントでも宣言済みアカウントではありません。 ポジションのレンジがプールのインライン tick_array_bitmap(±512 ティック配列)の外に出る場合は、 シード ["pool_tick_array_bitmap_extension", pool_state] の TickArrayBitmapExtension PDA を remaining_accounts[0] として追加してください。
数学 — products/clmm/math を参照してください。base_flag が与えられた場合、プログラムは liquidity または (amount_0_max, amount_1_max) のいずれかを実際の L と消費された実際のトークン金額に解決します。 前提条件
  • 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 はフリーズしません。
一般的なエラー — TickInvalidOrder(tick_lower >= tick_upper)、TickAndSpacingNotMatch(エンドポイントが tick_spacing の倍数でない)、InvalidTickIndex([MIN_TICK, MAX_TICK] 外)、MissingTickArrayBitmapExtensionAccount(レンジがインライン ビットマップの外で拡張が追加されていない)、NotApproved(pool_state.status が開設をブロック)、ZeroAmountSpecified。
ポジション フリーズは宣言されたインストラクション アカウントまたは引数を追加しません。クライアントは既存の V2 レイアウトでこれらのポジションを開くことができます。動作はオンチェーンから vault_0_mint と vault_1_mint で選択されます。

IncreaseLiquidityV2

既に開いているポジションにリクイディティを追加します。 引数
アカウント — 15 個で、OpenPosition から導出できるものでは ありません:rent も system_program も associated_token_program もメタデータ アカウントもありません。 ポジションのレンジがインライン ビットマップの外にある場合は、TickArrayBitmapExtension PDA を remaining_accounts[0] として先頭に追加してください。 効果
  • ユーザー → ボルトへ 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 のときのみで、増加時には支払われません — 単独の collect 命令は存在しません。

DecreaseLiquidityV2

ポジションからリクイディティを削除します。 引数
アカウント — 16 個で、IncreaseLiquidityV2 と同じ形状も順序も ありません:personal_position と pool_state が入れ替わり、ボルトがティック配列より前に来て、ユーザー側のアカウントは recipient_token_account_* という名前になり、さらに memo_program が追加されています。 残りのアカウント — 回収するアクティブなリワードごとに 3 つ、reward_token_vault(W)、recipient_token_account(W)、reward_vault_mint の順です。ポジションのレンジがインライン ビットマップの外にある場合は、TickArrayBitmapExtension PDA を先頭に追加してください。
これはフィーとリワードを回収する 唯一の 方法でもあります。ポジションを変更せずに回収するには、 liquidity = 0、amount_0_min = 0、amount_1_min = 0 で呼び出してください。
効果
  • 現在の sqrt_price_x64 が与えられた場合、削除された L の (amount_0, amount_1) を計算します。
  • 最後のタッチ以降に発生したフィー/リワードを決済します(IncreaseLiquidity と同じ)。
  • amount_0 + fees_owed_0 と amount_1 + fees_owed_1 をボルトからユーザーに転送します。
  • リクイディティ カウンターをデクリメントします。新しい personal_position.liquidity == 0 の場合、ポジションは ClosePosition の対象になります。
スリッページ — amount_0_min と amount_1_min は、出力側の Token-2022 転送手数料を差し引いた後、ユーザーが受け入れる最小値です。

ClosePosition

ポジション NFT をバーンし、PersonalPositionState を閉じます。 宣言されたアカウント 残りのアカウント
  • フリーズされていない 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 ミントは閉じることができず、供給量ゼロのままです。
シャー、バーン、クローズはアトミックです。NFT はこれらのステップ間で転送可能になることはできません。 条件付きクライアント ブレーク — 宣言された IDL レイアウトは変更されていないため、レガシー クライアントは既存のフリーズされていないポジションを閉じ続けます。プール残りのアカウントを省略するレガシー ビルダーは、フリーズされたポジションを閉じるときに AccountLack で失敗します。すべてのクローズに対してプールを渡すことが最も単純な互換性のある戦略です。

SwapV2

リクイディティ曲線を歩きます。is_base_input に応じて正確な入力または正確な出力。 引数
アカウント(簡略版) 呼び出し元は、予想されるスワップ ウォークをカバーするランク付けされたティック配列のリストを渡します。プログラムは必要なだけ使用します。SDK は PoolUtils.computeAmountOutFormat または API のクォート エンドポイント経由でこのリストを計算します。 前提条件
  • pool_state.status はスワップを許可します。
  • now >= open_time。
  • sqrt_price_limit_x64 は方向に対して sqrt_price_x64 の正しい側にあります。
一般的なエラー — TooLittleOutputReceived(exact-in のスリッページ)、TooMuchInputPaid(exact-out のスリッページ)、SqrtPriceLimitOverflow、NotEnoughTickArrayAccount、InvalidFirstTickArrayAccount、MissingTickArrayBitmapExtensionAccount、LiquidityInsufficient、NotApproved(pool_state.status でスワップ ビットが設定されている)。CLMM に ExceededSlippage バリアントは存在せず(その名前は CPMM のものです)、TickArrayNotFound も存在しません。 SwapV2 が内部で行うこと(呼び出し元が知っておくべき)(2025 年リリース後):
  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) を参照してください。
Swap(V1)は SwapV2 と同じ動的手数料、片側手数料ルーティング、リミット オーダー マッチングを実装します。唯一欠けている機能は Token-2022 サポートです。両方のボルトは classic SPL Token である必要があります。Token-2022 ミントを持つプールは SwapV2 経由でスワップする必要があります。アグリゲーターと SDK は既にすべての CLMM レッグに対して V2 を優先するため、呼び出し元はミント タイプで分岐する必要がありません。

OpenLimitOrder

特定のティックで売却オーダーを配置します。オーダーはティックごとの FIFO コホートに留まり、価格が通過するときに約定します。 引数
アカウント(簡略版) 残りのアカウント — [0] は tick_array_bitmap_extension で、開始インデックスがプールのインライン ビットマップの外に落ちるティック配列を初期化する場合にのみ必要です。それ以外の場合は何も渡しません。
rent アカウントは存在しません:この構造体は system_program で終わり、宣言済みアカウントは 13 個です。位置 14 に余分な rent を入れると、オプションのビットマップ拡張が読み取られる場所に ちょうど当たるため、インライン ビットマップの外のティック配列を初めて作成する必要が生じるまでは オーダーが動作しているように見え、その時点で失敗します。
アカウント リスト変更(2026-07 リリース)。 OpenLimitOrder は入力側に加えて出力側アカウント — output_token_account、output_vault、output_vault_mint — も取得するようになりました。これらは検証にのみ使用されます。プログラムは所有者の入力または出力トークン アカウントがフリーズされている場合、オーダーを拒否します。これにより、約定が実際に所有者の出力 ATA に決済できることが保証されます。これは、アカウントがまだシャーされていない可能性があるホワイトリスト/デフォルト フリーズ Token-2022 ミント(例:許可トークン)の場合に重要です。古い片側アカウント リストに対して構築されたクライアントは、3 つの出力アカウントを追加する必要があります。
前提条件
  • 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 が発行されます。
一般的なエラー — NotApproved(入力または出力トークン アカウントがフリーズ、またはプールがスワップ/リミット オーダー無効)、ZeroAmountSpecified(入力側のトランスファーフィー後に amount == 0)、InvalidLimitOrderAmount(その量ではそのティックで出力が 1 ベース単位を下回る、または u64 をオーバーフローする)、InvalidTickIndex([MIN_TICK, MAX_TICK] 外、または選択された方向に対して tick_current の間違った側)、TickAndSpacingNotMatch(tick_index % pool.tick_spacing != 0)、OrderPhaseSaturated。

IncreaseLimitOrder

既存のオープン オーダーに追加します。オーダーの owner のみが呼び出し可能です。 引数
アカウント — 8 個、入力側のみです。nonce アカウント、出力側の 3 つのアカウントすべて、さらに system_program も除かれます。 前提条件
  • 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

オープン オーダーを削減または完全にキャンセルします。未約定の残りを所有者に返し、過去の部分約定で既に決済された出力も返します。 引数
アカウント — 入力と出力トークン側の両方: 効果
  • 開く以降のコホートの unfilled_ratio_x64 からオーダーの約定金額を再計算します。
  • 約定した出力を output_token_account に送信します。
  • 未約定の入力の amount を input_token_account に返します。
  • limit_order をそれに応じて更新します。新しい未約定の残りがゼロの場合、プログラムはアカウントを閉じ、レント払い戻しを owner に返します。

SettleLimitOrder

オーダーの未約定の残りを変更せずに、約定した出力トークンを所有者にプッシュします。auto_withdraw キーパーが長時間実行される部分約定をドリップ払いしたい場合に便利です。 呼び出し元 — オーダーの owner、またはプログラムの limit_order_admin(自動化されたキーパー ループを実行するオフチェーン操作ホット ウォレット)。キーパーは他の権限を持ちません。オーダーの owner ATA に約定した出力をプッシュする以外に、ユーザー ファンドを移動することはできません。 アカウント 効果
  • (limit_order.unfilled_ratio_x64, tick.unfilled_ratio_x64) を使用して、owed の累積出力を計算します。
  • デルタを output_token_account に転送します。
  • limit_order.settled_output を更新します。
  • オーダーを閉じません。未約定の入力に対してまだ開いています。

CloseLimitOrder

完全に消費されたオーダー アカウントを閉じます。誰が署名するかに関わらず、レント払い戻しは常に limit_order.owner に返されます。 呼び出し元 — owner または limit_order_admin。 前提条件
  • オーダーの未約定の残りがゼロです(amount == total_amount が約定して決済されたか、所有者が以前にオーダーをゼロに減らして閉じるのを忘れた)。
効果
  • limit_order を閉じます。レント払い戻しは limit_order.owner に送信されます。

CreateDynamicFeeConfig(管理者)

u16 インデックスの下に再利用可能なパラメータ セットを作成します。 引数
アカウント 一般的なエラー — InvalidDynamicFeeConfigParams(decay_period <= filter_period または任意のゼロ値フィールドが範囲外)。

UpdateDynamicFeeConfig(管理者)

既存の DynamicFeeConfig を変更します。作成時に既に設定をスナップショットしたプールは遡及的に更新されません。このコンフィグを参照する新しく作成されたプールのみが新しい値を取得します。 引数 — CreateDynamicFeeConfig と同じ 5 つのキャリブレーション フィールド(filter_period、decay_period、reduction_factor、dynamic_fee_control、max_volatility_accumulator)。index は作成時に固定され、ここで再度渡されません。

CollectProtocolFee / CollectFundFee

発生したプロトコル/ファンド手数料をプール ボルトから受取人にスイープし、対応する PoolState.protocol_fees_* / fund_fees_* フィールドをゼロにします。これは CPMM のレイアウトではありません — CLMM には authority アカウントがなく、受取人のフィールド名は recipient_token_{0,1}_account ではなく recipient_token_account_{0,1} です。 引数 — amount_0_requested: u64、amount_1_requested: u64。

InitializeReward

プールに新しいリワード ストリームを追加します。最大 3 つのストリームが同時にアクティブになる場合があります。 引数
ワイヤ エンコーディングは 3 つのフィールドを連続して並べたものなので、手作りの命令は影響を受けません — ただし IDL 駆動のクライアントは、3 つの位置引数ではなく 1 つの param オブジェクトを渡す必要があります。 アカウント 前提条件
  • プールで現在 3 未満のストリームがアクティブ。
  • ファンダーは total_emission = emissions_per_second × (end_time − open_time) 相当のリワード トークンをこのインストラクションの一部としてボルトに預金します。
  • operation_state ごとのホワイトリスト リワード ミント。

SetRewardParams

既存のリワード ストリームを拡張、トップアップ、または発行レートを変更します。通常、プール作成者または Raydium マルチシグによって呼び出されます。制約はオンチェーンに存在します。通常、end_time を拡張したり、発行を増やしたりできますが、遡及的に縮小することはできません。operation_state の所有者リストを確認してください。

UpdateRewardInfos

純粋な簿記 — reward_growth_global_x64 を現在の時刻に決済します。emissions_per_second × Δt / liquidity を乗算します。すべてのリクイディティ タッチ インストラクションによって内部的に呼び出されます。外部アクター(UI、クランク)が時々それをトリガーしたいため、スタンドアロン インストラクションとして公開されます。

Collecting rewards

単独の collect-reward 命令は存在しません。 プログラムは CollectReward エントリポイントを 公開しておらず、公開されている IDL にも存在しません。
ポジションに対して発生したリワードは、DecreaseLiquidity / DecreaseLiquidityV2 によって支払われます。 ポジションを変更せずに回収するには、liquidity = 0、amount_0_min = 0、amount_1_min = 0 で 呼び出してください。リワード ボルトと受取人アカウントは、アクティブなリワードごとに 3 つずつ、 reward_token_vault(W)、recipient_token_account(W)、reward_vault_mint の順で remaining_accounts に入れます。 CollectRemainingRewards は別のものです:これはリワードの ファンダー が、ストリームの end_time 後に、どのポジションにも割り当てられなかったトークンをスイープできるようにするものです。

状態変更マトリックス

次のステップ

ソース: