共有インフラストラクチャ

​

ここでの「共有」の意味

• 規約の共有。 すべてのプログラムは同じ PDA 導出パターン、同じ手数料分割の形状、同じオブザベーション アカウントの考え方を使用します。ただし、各プログラムは独自のシードを使用して独自に実装します。
• アカウントの共有。 少数のアカウントは、多くのプール全体で文字通り同じレコードです（CPMM のグローバル オーソリティ PDA、AmmConfig アカウント）。
• オフチェーン共有。 1 つの REST API と 1 つの TypeScript SDK が 4 つのプログラムすべてをサポートします。インテグレーターは、最終的にどのプログラムを呼び出すかに関わらず、1 つの HTTP ホストと 1 つの NPM パッケージと対話します。

​

1. オーソリティ PDA

• CPMM と CLMM の場合、オーソリティ PDA はグローバル アカウントです。そのタイプのすべてのプールがそれを使用します。CPMM に CPI している場合、プール単位ではなく 1 回必要です。
• プール単位/ファーム単位のオーソリティの場合、プール/ファーム ID から PDA を導出します。SDK はこれを getPoolKeys / getFarmKeys で行います。直接統合している場合は、findProgramAddressSync で導出します。
• ボール所有権は変更できません。 トークン アカウントがオーソリティ PDA を所有者として作成されると、そのプログラムによって呼び出されたその PDA のみが転送できます。管理者オーバーライドはありません。

​

2. 管理者とコンフィグ アカウント

// CPMM AmmConfig（簡略版 — CLMM バージョンは構造的に似ています）
pub struct AmmConfig {
    pub bump: u8,
    pub disable_create_pool: bool,        // このティアでの新しいプール作成をゲート
    pub index: u16,                       // ティア インデックス
    pub trade_fee_rate: u64,              // トレードの手数料に行く部分
    pub protocol_fee_rate: u64,           // トレード手数料のプロトコルへの部分
    pub fund_fee_rate: u64,               // トレード手数料のファンドへの部分
    pub create_pool_fee: u64,             // プール作成ごとの 1 回限りの手数料
    pub protocol_owner: Pubkey,           // CollectProtocolFee の署名者
    pub fund_owner: Pubkey,               // CollectFundFee の署名者
    pub padding: [u64; 16],
}

• 手数料ティアはグローバルです。 プールが「これは 0.25% プールです」と言う場合、作成時に trade_fee_rate が 0.25% だった AmmConfig にバインドされていることを意味します。プール単位のレート オーバーライドはありません。
• コンフィグは変更できますが、プールは追従しません。 コンフィグ オーソリティが AmmConfig を編集すると、そのコンフィグにバインドされたすべての既存プールは新しいレートを即座に取得します。これはバグではなく機能です。プロトコル レベルの経済的変化がプール単位のマイグレーションなしに伝播する方法です。
• disable_create_pool は廃止レバーです。 手数料ティアが廃止されると、プロトコル マルチシグはこのフラグを設定します。既存のプールは機能し続けますが、新しいプールはティアを選択できません。
• protocol_owner / fund_owner は手数料収集呼び出しの署名者です。それらをマルチシグに設定することが手数料引き出しをゲートする方法です。それらは手数料自体の宛先アドレスではありません。それは同じアカウント上の protocol_fee_destination / fund_fee_destination です。

​

3. プロトコル / ファンド / クリエイター手数料の分割

                         total swap fee
                              │
              ┌───────────────┼───────────────┬──────────────┐
              ▼               ▼               ▼              ▼
        LP pool side     Protocol         Fund         Creator
        (raises k)       treasury         multisig     (LaunchLab pools)

1. トレード手数料はプールに蓄積します。 手数料はスワップの入力側から削除され、手数料後の金額が定数積数学が見るものです。これが「LP が手数料を獲得する」という意味です。k が上昇し、暗黙の LP トークン単位の値も上昇します。
2. プロトコル/ファンド/クリエイター部分は、その LP 側の蓄積からプール単位のカウンター アカウントに差し引かれます。 それらはプール状態（protocol_fees_token{0,1}、fund_fees_token{0,1} など）に座り、対応する収集命令が呼び出されるまでそこに留まります。それまでプールのボールトから出ません。スワップの観点からは、それらはまだ「プール内」です。
3. 収集がそれらを移動させます。 プロトコルとファンド パスには、AmmConfig からそれぞれの protocol_owner / fund_owner 署名者が必要です。CPMM クリエイター手数料は、クリエイター署名の CollectCreatorFee パスまたは CollectCreatorFeePermissionless を使用します。後者は任意のペイヤーがトリガーできますが、宛先をクリエイターの正規 ATA に固定します。

• 分割パーセンテージはトレード手数料からのもので、トレードからではありません。 0.25% のトレード手数料と 12% のプロトコル シェアは、プロトコルが 0.25% × 12% = 0.03% のトレードを取得することを意味します。トレードの 12% ではなく。
• クリエイター手数料は LaunchLab 卒業プールにのみ存在します。 標準 CPMM/CLMM プールは 3 方向分割（LP / プロトコル / ファンド）を持ちます。LaunchLab は 4 番目のスロットを追加し、トークンを起動した人にルーティングされ、Initialize で構成され、不変です。
• AMM v4 は 2 方向のみで分割します。プール単位でハードコードされています。ファンド スロットなし、クリエイター スロットなし。
• ファンド対プロトコル — 両方ともプロトコル トレジャリー宛先ですが、異なる署名者と異なる意図された用途があります。protocol は歴史的に運用に資金を提供します。fund はより長期的なトレジャリーです。2 つの間の分割自体が調整可能です。

​

4. オブザベーション アカウント（TWAP リング バッファ）

// CPMM ObservationState（簡略版）
pub struct ObservationState {
    pub initialized: bool,
    pub observation_index: u16,            // 次に上書きするスロット
    pub pool_id: Pubkey,
    pub observations: [Observation; OBSERVATION_NUM],
    pub padding: [u64; 4],
}

pub struct Observation {
    pub block_timestamp: u64,
    pub cumulative_token_0_price_x32: u128,  // 初期化以来の (price × dt) の合計
    pub cumulative_token_1_price_x32: u128,
}

• すべてのスワップが update_observation を呼び出します。 プログラムは現在の価格を読み取り、前のオブザベーション以来の経過秒数を乗算し、累積カウンターに追加します。新しいエントリは最も古いスロットを上書きします（リング バッファ スタイル）。
• ウィンドウ上の TWAP = (cumul[end] − cumul[start]) / (timestamp[end] − timestamp[start])。コンシューマーは目的のウィンドウをブラケットする 2 つのオブザベーションを選択し、除算します。
• Raydium 自体は価格設定に TWAP を使用しません。 AMM 数学は現物リザーブを直接読み取ります。オブザベーションは外部性です。Raydium は他のコントラクトが読み取れるようにそれらを書き込むコストを支払います。
• AMM v4 にはオブザベーション アカウントがありません。 ObservationState 設計より古いです。v4 TWAP を望むインテグレーターは、ログ履歴からオフチェーンで計算する必要があります。

​

5. REST API + SDK + IDL

• REST API — https://api-v3.raydium.io。すべてのオンチェーン状態のほぼ読み取り専用インデックス ビューと見積もりエンジン。1 つのホスト、1 つのスキーマ。
• TypeScript SDK — NPM の @raydium-io/raydium-sdk-v2。すべてのプログラムのトランザクションを構築および署名します。見積もり/メタデータについては API と通信し、署名前の状態更新については Solana RPC と通信します。
• IDL レジストリ — すべての公開プログラムの Anchor IDL は raydium-idl リポジトリに存在します（プログラムごとに 1 つの JSON：CPMM、CLMM、LaunchLab）。TypeScript SDK はこれらの IDL を内部で使用します。ダウンストリーム Rust / Python クライアントは同じファイルから再生成します。

​

6. インデクサーと価格フィード

• インデクサーは「クロスプログラム状態を知っている」唯一のものです。 CPMM プールを CLMM カウンターパートにマッピングする、プログラム バージョン全体で 24 時間ボリューム数を計算する、LP ミントに関連するファームを取得する — すべてがインデクサー作業です。プログラム自体はそれを行いません。
• インデクサー ダウンタイムは API ダウンタイムです。 API が古いまたは空のデータを返す場合、インデクサーが疑わしいです。オンチェーン状態は影響を受けません。独自の RPC と SDK を持つインテグレーターはトランザクションを続行できます。

​

共有されていないもの

• プログラムは互いに呼び出しません。 CPMM スワップが CLMM または AMM v4 に CPI することはありません。複数の AMM を構成する唯一のプログラムは AMM ルーティング プログラムです。そしてそれ自体は薄く、各 AMM に順番に CPI を発行するだけです。
• プログラム全体で共有アップグレード オーソリティはありません。 各オンチェーン プログラムには独自のプログラム アップグレード キーがあります（3/4 マルチシグと 24 時間タイムロック）。それらはリンクされていません。
• ファームと AMM 間で共有状態はありません。 ファームは、ステーキングするどの LP が CPMM プール、CLMM ポジション NFT ミント、または無関係な SPL トークンからのものかを知りません。ファーム プログラムはステーキング ミントを不透明として扱います。
• オラクル依存性はありません。 価格設定はオンチェーン リザーブです。Pyth/Switchboard フォールバックはありません。AMM はクリアする前にオラクルをチェックしません。

​

ポインター

• protocol-overview/architecture — これらのピースがどのように構成されるかを示す正規図。
• protocol-overview/versions-and-migration — 規約がプログラム バージョン全体でどのように進化したか。
• security/admin-and-multisig — AmmConfigs の背後にあるキーを制御する人。
• reference/fee-comparison — プロダクトごとの手数料レート マトリックス。
• reference/program-addresses — 正規プログラム ID。

• Raydium SDK v2 — PDA シード、アカウント レイアウト、IDL 定義の信頼できる情報源。
• Raydium IDL レジストリ — Anchor IDL。
• 上記でインラインで引用されたプロダクト別アカウント ページ。