このページは AI による自動翻訳です。すべての内容は英語版を正とします。英語版を表示 →
2 つの独立したフィー、4 つの宛先
CPMM はすべてのスワップに対して2 つの独立した料率のフィーを課金します:- トレードフィー —
AmmConfig.trade_fee_rateで課金され、3 つの宛先に分割されます:- LP シェア — ヴォルト内に留まり、
kを増加させます。LP トークンをバーンすることで暗黙的に請求されます。 - プロトコルシェア —
PoolState.protocol_fees_token*に累積され、protocol_ownerがCollectProtocolFee経由で回収します。 - ファンドシェア —
PoolState.fund_fees_token*に累積され、fund_ownerがCollectFundFee経由で回収します。
- LP シェア — ヴォルト内に留まり、
- クリエイターフィー(オプション、プール単位) —
AmmConfig.creator_fee_rateで課金され、トレードフィーとは独立してPoolState.creator_fees_token*に累積されます。クリエイターはCollectCreatorFee経由で回収するか、任意のペイヤーが宛先制約付きのCollectCreatorFeePermissionlessパスをトリガーできます。プールがenable_creator_fee = trueで作成された場合のみアクティブです。2026-09-19 アップグレード以降、累積されたクリエイターフィーはコレクション時に再度分割されます:設定可能なシェアがプールのプロトコルバケットに移動され、残りのみがクリエイターに到達します — クリエイターフィーのプロトコルシェアを参照してください。
trade_fee からのみ派生し、creator_fee からは決して派生しません。creator_fee_rate = 1000(0.10%)と trade_fee_rate = 2500(0.25%)のプールは、クリエイターフィーオンインプットスワップで入力の合計 0.35% を課金し、そのうちクリエイターバケットが 0.10% を取得し、トレードフィーバケットが 0.25% を取得します。
クリエイターフィーのプロトコルシェアは逆方向に機能し、上記と混同しやすいです:それはクリエイターバケットから切り出され、トレードフィーからではなく、スワップ時ではなく、CollectCreatorFee または CollectCreatorFeePermissionless が累積残高を決済するときに適用されます。スワップ計算はそれによって変わりません。
トレードフィー料率(trade_fee_rate、protocol_fee_rate、fund_fee_rate)、creator_fee_rate、およびデフォルト creator_fee_share_rate はすべて AmmConfig に存在します。プール単位の enable_creator_fee フラグと creator_fee_on モード(トレードのどちら側からクリエイターフィーが取られるか)は PoolState に存在します。クリエイター単位のシェア料率オーバーライドは独自の CreatorFeeShare PDA に存在します。products/cpmm/accountsを参照してください。
料率と単位
すべての料率はu64 で、1 / FEE_RATE_DENOMINATOR の単位で表示されます。ここで FEE_RATE_DENOMINATOR = 1_000_000 です。
trade_fee_rateはスワップボリュームの分数です。2500⇒ 関連する側(入力または出力、creator_fee_onに応じて — 下の「フィーが取られるトレードのどちら側」を参照)の 0.25%。creator_fee_rateはスワップボリュームの分数で、トレードフィーとは別に取られます。1000⇒ 関連する側の 0.10%。protocol_fee_rateおよびfund_fee_rateはボリュームではなくトレードフィーの分数です。120_000⇒ トレードフィーの 12%。creator_fee_share_rateはボリュームではなく、トレードフィーでもなく、累積されたクリエイターフィーの分数です。200_000⇒ コレクション時にcreator_fees_token*に存在するものの 20%。0(デフォルト)はクリエイターフィー全体をクリエイターに残します。
AmmConfig[index=0](「標準」0.25% プール)のデフォルトパラメータ(参考用):
したがって、
AmmConfig[0] に対する $1,000 スワップで enable_creator_fee = false の場合:合計 $2.50 のトレードフィー、そのうち $2.10 は LP に留まり、$0.30 はプロトコルに、$0.10 はファンドに行きます。クリエイターフィーが無効になっているため、クリエイターバケットは 0 です。
同じプールが enable_creator_fee = true で creator_fee_rate = 1000(0.10%)の場合、ユーザーはクリエイターバケットに追加で $1.00 を支払います — creator_fee_on で設定されたトレードの同じ側から取られます — 合計フィーは $3.50 になります。トレードフィーバケットとそのプロトコル/ファンド分割は変わりません。
現在のメインネット値を GET https://api-v3.raydium.io/main/cpmm-config で確認してください — 料率は管理者が変更可能であり、ハードコードするのではなく新しく読み込む必要があります。
コード内の分割
- 入力の合計フィーは切り上げられるため、プールは決して過少請求しません。
trade_feeのサブ分割(プロトコル、ファンド)は切り下げられるため、その合計がtrade_feeを超えることはありません。残りは LP シェアです。lp_share = trade_fee − protocol_fee − fund_fee(creator_fee は独自のバケットであるため、ここでは差し引かれません)。- クリエイターフィーは
PoolState.creator_fee_onに応じて入力または出力から取られます(次のセクション「フィーが取られるトレードのどちら側」を参照)。料率はどちらの場合でも変わりません。
フィーが取られるトレードのどちら側
CPMM には、プール単位のcreator_fee_on 設定(BothToken / OnlyToken0 / OnlyToken1)があり、クリエイターフィーが特定のスワップの入力側または出力側から取られるかどうかを決定します。ランタイムヘルパー is_creator_fee_on_input(direction) はそれをスワップごとのブール値に折りたたみます:
クリエイターフィーが入力側にある場合、トレードフィーとクリエイターフィーの両方が
amount_in からカーブが実行される前に差し引かれます。クォート計算:入力から合計 trade_rate + creator_rate を取ります。
クリエイターフィーが出力側にある場合、トレードフィーのみが amount_in から差し引かれます。カーブはフィーなしの出力を生成し、その後クリエイターフィーがその出力から差し引かれます。クォート計算:入力から trade_rate を取ります。出力から creator_rate を取ります。
トレードフィー自体は常に入力側から取られます(標準的な Uniswap-V2 パターン)。クリエイターフィーのみが出力に着地できます。
「累積」フィーがカーブとどのように相互作用するか
重要な微妙な点:プロトコル、ファンド、およびクリエイターフィーは、それぞれのCollect* 命令が呼び出されるまで、物理的にヴォルト内に留まります。しかし、それらはカーブのヴォルト残高の見方から除外されます。
1 つのスワップ後の具体的な図:
k' ≥ k を強制するときに curve_x(および類似の curve_y)を使用します。これは、非 LP フィーが LP シェアを膨らませることなく、それらの宛先に到達する方法です。
設計する際に考慮すべき結果:
- 生のバランスからのクォートは間違っています。
getTokenAccountBalanceからクォーターを構築する場合、プールが尊重する価格を一貫して過大評価します。常に累積フィーを差し引くか、SwapBaseInput/ API 経由でシミュレートしてください。 CollectProtocolFeeは価格を動かしません。 ヴォルトからトークンを移動し、protocol_fees_token*カウンターをゼロにするため、curve_xとcurve_yは変わりません。- LP フィーはカウンターに累積されません。 それらはヴォルト残高に暗黙的です。累積 LP フィーに対する LP の権利は、LP トークンをバーンすることで行使されます(つまり、
Withdraw経由)—CollectLpFeeはありません。
Token-2022 転送フィーとの相互作用
Token-2022 転送フィーは CPMM ではなくミントによって適用されます。それらはすべてのトークン転送 — スワップ、デポジット、引き出し、およびCollect* スイープに作用します。CPMM のトレードフィー計算は、実際にヴォルトに着地した金額、つまり入力ミントの転送フィー(存在する場合)を差し引いたものに対して計算されます。
したがって、最悪の場合、ユーザーは入力正確スワップで 3 つの異なる税を支払います:
amount_inに対する入力ミントの転送フィー(ミントのフィー権限へ)。- 残りに対するプールの
trade_fee(上記のように分割)。 amount_outに対する出力ミントの転送フィー(ミントのフィー権限へ)。
minimum_amount_out はユーザーが実際に受け取るものの単位です。独自のクォーターを作成している場合は、その動作をミラーリングするか、スリッページチェックが体系的に寛容になりすぎます。
詳細な導出については、algorithms/token-2022-transfer-feesを参照してください。
クリエイターフィー
クリエイターフィーはオプションでプール単位です。料率はAmmConfig.creator_fee_rate に存在します。有効フラグと側(creator_fee_on)は PoolState に存在します:
- プール作成時に有効化。
Initializeはデフォルトでenable_creator_fee = falseを設定します。InitializeWithPermission経由で作成されたプール(LaunchLab 卒業およびその他のゲートされたパスで使用)はenable_creator_fee = trueを渡し、creator_fee_onを選択できます。 - 料率はフィーティアと共有。 料率自体は
AmmConfig.creator_fee_rateで、そのコンフィグにバインドされたすべてのプール全体で同じ値です。その後、各プールはそれを課金するかどうか(enable_creator_fee)と、スワップのどちら側から課金するか(creator_fee_on)を決定します。enable_creator_fee = falseの場合、プールの有効クリエイターフィー料率は、コンフィグ値に関係なくゼロです(ソースのPoolState::adjust_creator_fee_rateを参照)。 - トレードフィーから独立。 クリエイターフィーは LP / プロトコル / ファンドシェアを削減することはありません — それは独自の料率で、別に適用され、独自のカウンターに累積されます。
CollectCreatorFeeまたはCollectCreatorFeePermissionless経由で回収。 元のパスにはPoolState.pool_creatorの署名が必要です。パーミッションレスパスでは、任意のペイヤーがコレクションをトリガーできますが、両方の宛先をクリエイターの正規 ATA に固定します。両方のパスは、プロトコルのシェアを最初に決済します — 次のセクションを参照してください。- 作成後に再度有効化またはリルートできません。
enable_creator_fee = falseで初期化されたプールはクリエイターフィーを課金することはありません。特定のcreator_fee_onで初期化されたプールは側を切り替えることができません。
クリエイターフィーのプロトコルシェア
2026-09-19 アップグレード以降、プロトコルはクリエイターフィーの設定可能なシェアを保持できます。スワップについては何も変わりません:クリエイターフィーは依然としてcreator_fee_rate で課金され、完全に creator_fees_token{0,1} に累積されます。分割は一度、コレクション時に、CollectCreatorFee および CollectCreatorFeePermissionless 内で発生します。
料率の出所
優先順位順に 2 つのソース:CreatorFeeSharePDA — シード["creator_fee_share", creator, amm_config]。このアカウントが存在し、CPMM によって所有されている場合、そのshare_rateが優先されます。プロトコルがティア自体に触れることなく、特定のフィーティアで クリエイター単位の料率をネゴシエートできます。AmmConfig.creator_fee_share_rate— そのフィーティアのすべてのクリエイターのデフォルト。PDA が存在しない場合に使用されます。
FEE_RATE_DENOMINATOR = 1_000_000 上の u64 で、両方とも分母でキャップされます。コレクション命令は、作成されたことがない場合でも、常に creator_fee_share アカウントを取得します — プログラムはそれが空かどうかをチェックし、フォールバックします。間違ったアドレスを渡すと、フォールバックではなく PDA 制約が失敗します。
分割が何をするか
creator_fees_token_0 および creator_fees_token_1 に独立して適用され、その後:
creator_amount_{0,1}はヴォルトからクリエイターのトークンアカウントに転送されます。shared_amount_{0,1}は**protocol_fees_token_{0,1}に追加**され、プロトコル所有者がCollectProtocolFeeで回収するまでヴォルト内に留まります。別の命令や別のカウンターはありません。creator_fees_token_{0,1}はゼロにされます(以前と同じ)。
- 丸めはクリエイターに有利です。 プロトコルシェアはフロアするため、ダストはクリエイターに留まります —
protocol_feeおよびfund_feeと同じ方向で、これらも既に累積されたフィーからシェアを切り出します。 - 値は保存されます。
creator_amount + shared_amount == creator_feeはすべての料率とすべてのフィー(u64::MAXを含む)に対して成立します。 share_rate = 0はノーオペです。 デフォルトコンフィグ値とCreatorFeeSharePDA の不在の両方は、クリエイターフィー全体をクリエイターに残します。これはアップグレード前の動作です。
インテグレーターにとって何を意味するか
- LP とクォートは影響を受けません。 共有金額は、両方とも既にヴォルトのカーブビューから除外されている 2 つのカウンター間で移動するため(
vault_amount_without_fee)、コレクション全体でcurve_xとcurve_yは移動しません。kは変わりません。 creator_fees_token*を読むクリエイターフィー推定器は、現在、支払いを過大評価します。 その(creator, amm_config)ペアに実際に適用される料率を使用して(1 − share_rate / 1_000_000)で乗算します。コンフィグデフォルトではなく。protocol_fees_token*はスワップ外で増加します。 スワップボリュームに対するプロトコル累積を調整するモニターは、各クリエイターフィーコレクション時にジャンプを見ます。プロトコル累積はtrade_fee × protocol_fee_rateだけではなくなりました。- 料率は累積とコレクション間で変更できます。 コレクション時に読み込まれるため、1 つの料率の下で累積されたフィーは、誰かが
Collect*を呼び出すときに有効な料率で決済されます。
CreatorFeeShare アカウントは、管理者または専用クリエイターフィーシェア権限によって CreateCreatorFeeShare / CloseCreatorFeeShare 経由で作成および閉鎖されます。閉鎖するとペアは AmmConfig.creator_fee_share_rate に戻ります。アカウントレイアウトは products/cpmm/accounts、アドレスは reference/program-addresses にあります。
コレクション運用フロー
プロトコルおよびファンド所有者はメインネット上の Raydium マルチシグです。
security/admin-and-multisigを参照してください。元のクリエイターのみのパスでは、クリエイター署名者は PoolState に記録されたアカウントです。パーミッションレスパスでは、呼び出し元は欠落しているクリエイター ATA のいずれかを作成するために支払います。プログラムは creator を pool_state.pool_creator に制約し、各宛先をそのクリエイターと対応するヴォルトミントおよびトークンプログラムから派生させるため、呼び出し元はファンドをリダイレクトできません。
フィーティアの変更
フィー料率は、管理者がUpdateAmmConfig 経由で変更できます(products/cpmm/instructionsを参照)。変更は、そのコンフィグにバインドされたすべてのプールの次のスワップで有効になります — マイグレーションはありません。プールは各スワップでコンフィグを読み込むためです。
管理者ができないこと:
- プールを 1 つの
AmmConfigから別のAmmConfigに移動する。 - 既に累積されたフィーに遡及的に価格を付け直す。
protocol_owner/fund_owner署名者なしでフィーを回収する。
実行中のプールからフィーを読む
キャッシュされたコンフィグからではなく、オンチェーンでシェア料率を解決してください。
creator_fee_share_rate は新しく追加された AmmConfig フィールドであるため、REST コンフィグペイロードがそれを運ぶと仮定するのではなく、アカウントから読み込み、CreatorFeeShare PDA が ["creator_fee_share", creator, ammConfig] に存在するかどうかをクリエイターに支払いを見積もる前にチェックしてください。不在の PDA は一般的なケースで、コンフィグデフォルトが適用されることを意味します。CLMM および AMM v4 との比較
reference/fee-comparisonを参照して、並列マトリックスを確認してください。概要:
- AMM v4 は固定 0.25% のトレードフィーを使用し、異なる LP/プロトコル分割とファンドフィーなし。
- CLMM フィーはティック間隔ティアごと、ポジションごと(プールごとではなく)で、
DecreaseLiquidityまたはCollectFees経由で請求されます。
次に進むべき場所
products/cpmm/math— トレードフィー控除がカーブにどのようにプラグインされるか。products/cpmm/instructions—Collect*命令アカウントリスト。両方のクリエイターパスが現在必要とするcreator_fee_shareアカウントを含む。algorithms/token-2022-transfer-fees— プールトレードフィーとミント転送フィーを正しく組み合わせる方法。

