Skip to main content
このページは AI による自動翻訳です。すべての内容は英語版を正とします。英語版を表示 →

2 つの独立したフィー、4 つの宛先

CPMM はすべてのスワップに対して2 つの独立した料率のフィーを課金します:
  1. トレードフィー — AmmConfig.trade_fee_rate で課金され、3 つの宛先に分割されます:
    • LP シェア — ヴォルト内に留まり、k を増加させます。LP トークンをバーンすることで暗黙的に請求されます。
    • プロトコルシェア — PoolState.protocol_fees_token* に累積され、protocol_owner が CollectProtocolFee 経由で回収します。
    • ファンドシェア — PoolState.fund_fees_token* に累積され、fund_owner が CollectFundFee 経由で回収します。
  2. クリエイターフィー(オプション、プール単位) — AmmConfig.creator_fee_rate で課金され、トレードフィーとは独立して PoolState.creator_fees_token* に累積されます。クリエイターは CollectCreatorFee 経由で回収するか、任意のペイヤーが宛先制約付きの CollectCreatorFeePermissionless パスをトリガーできます。プールが enable_creator_fee = true で作成された場合のみアクティブです。2026-09-19 アップグレード以降、累積されたクリエイターフィーはコレクション時に再度分割されます:設定可能なシェアがプールのプロトコルバケットに移動され、残りのみがクリエイターに到達します — クリエイターフィーのプロトコルシェアを参照してください。
クリエイターフィーはトレードフィーのスライスではありません。2 つの料率はスワップ入力時にフィーが取られるときに加算されますが、各々は独自のバケットのままです — スワップで取られるプロトコルおよびファンドシェアは常に 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 つの異なる税を支払います:
  1. amount_in に対する入力ミントの転送フィー(ミントのフィー権限へ)。
  2. 残りに対するプールの trade_fee(上記のように分割)。
  3. amount_out に対する出力ミントの転送フィー(ミントのフィー権限へ)。
SDK のクォーターはすべての 3 つを考慮するため、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 で初期化されたプールは側を切り替えることができません。
クリエイターフィーは Raydium の「Burn & Earn」パターンの背後にあるメカニズムです:LP トークンは LP Lock プログラムの下でロックされるため、クリエイターはリクイディティを引き出すことができませんが、累積されたクリエイターフィーは無期限に回収できます。

クリエイターフィーのプロトコルシェア

2026-09-19 アップグレード以降、プロトコルはクリエイターフィーの設定可能なシェアを保持できます。スワップについては何も変わりません:クリエイターフィーは依然として creator_fee_rate で課金され、完全に creator_fees_token{0,1} に累積されます。分割は一度、コレクション時に、CollectCreatorFee および CollectCreatorFeePermissionless 内で発生します。

料率の出所

優先順位順に 2 つのソース:
  1. CreatorFeeShare PDA — シード ["creator_fee_share", creator, amm_config]。このアカウントが存在し、CPMM によって所有されている場合、その share_rate が優先されます。プロトコルがティア自体に触れることなく、特定のフィーティアで クリエイター単位の料率をネゴシエートできます。
  2. 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} はゼロにされます(以前と同じ)。
依存する価値のある 3 つのプロパティ:
  • 丸めはクリエイターに有利です。 プロトコルシェアはフロアするため、ダストはクリエイターに留まります — protocol_fee および fund_fee と同じ方向で、これらも既に累積されたフィーからシェアを切り出します。
  • 値は保存されます。 creator_amount + shared_amount == creator_fee はすべての料率とすべてのフィー(u64::MAX を含む)に対して成立します。
  • share_rate = 0 はノーオペです。 デフォルトコンフィグ値と CreatorFeeShare PDA の不在の両方は、クリエイターフィー全体をクリエイターに残します。これはアップグレード前の動作です。

インテグレーターにとって何を意味するか

  • 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 — プールトレードフィーとミント転送フィーを正しく組み合わせる方法。
ソース: