このページは AI による自動翻訳です。すべての内容は英語版を正とします。英語版を表示 →
IDL とは
Solana 上の Anchor プログラムは、命令、アカウントレイアウト、エラー列挙型、構造体スキーマを記述する IDL(Interface Definition Language)ファイルを公開します。IDL はクライアントコード生成の信頼できる情報源です。TS SDK、Rust CPI クレート、サードパーティ製クライアントはすべて IDL から生成されるか、それに対して手書きされます。 Raydium は CPMM、CLMM、LaunchLab の IDL を公開しています。AMM v4、Stable AMM、Farm(v3 / v5 / v6)は Anchor より前のものであるか、Anchor で配布されていません。これらのアカウント構造は SDK で手動で保守されています。IDL の場所
IDL は専用リポジトリに保存されています:
IDL ファイルはリポジトリの git 履歴でバージョン管理されています。バイト単位での再現性が必要な場合は、特定のコミットにピンしてください。
一部の IDL はメインネットから直接取得することもできます:
3 つのレガシー IDL アカウントはすべて、IDL 権限
2XVnob28A5Qnpcy95UVeHWNT6G8Poy3tpA3AFyAMoZDt によって書き込み可能です。これはプログラムの BPF アップグレード権限とは別です。したがって、IDL は再デプロイなしで更新でき、再デプロイより遅れることもあります。オンチェーン IDL を便利なものとして扱い、デプロイされたバイトコードの形状の証明として扱わないでください。
TypeScript クライアントの再生成
Anchor のコード生成は IDL から型付きクライアントを生成します:raydium.cpmm.swap(...) ヘルパーを使用します。これは Anchor メソッドとすべてのブックキーピング(ATA 作成、転送手数料調整、計算予算、Token-2022 プログラムルーティング)をラップします。SDK の下のレイヤーが必要な場合にのみ再生成してください。
Rust クライアント(CPI クレート)の再生成
Raydium は IDL を持つプログラムの Anchor クレートを公開しています:raydium_cp_swap と raydium_clmm で参照してください。raydium_amm_v3 という名前のクレートはどのスペルでも存在しません。ブランチが異なることに注意してください。raydium-cp-swap の master はまだ anchor-lang 0.32.1 をピンしているため、Anchor-1.0 統合には chore/upgrade-anchor が必要です。CLMM はどちらの方法でも 0.32.1 にあるため、2 つはクレートを共有できません。
cpi フィーチャーは cpi::accounts::<Ix> アカウント構造体と cpi::<ix>() インボーカーを公開します。すぐに使用できる CPI ラッパーです。使用パターンについては sdk-api/rust-cpi を参照してください。
新しいバインディングを生成する場合:
Python クライアントの再生成
公式の Raydium Python SDK はありません。サードパーティ製ジェネレータには以下が含まれます:anchorpy— Anchor の TypeScript クライアントの Python ポート。IDL から型付きメソッドビルダーを生成します。solders— 低レベルの Solana プリミティブ(トランザクション、キーペア、パブキー)の Rust バインディング。anchorpyの下で使用されます。
sdk-api/python-integration を参照してください。
IDL 変更ポリシー
Raydium は IDL の安定性について以下のルールに従います:- 命令ディスクリミネータは変わりません。 新しい命令を追加すると列挙型の末尾が拡張されます。既存のディスクリミネータは安定したままです。
- アカウントサイズは安定しており、新しいフィールドは予約済みパディングから取得されます。 すべての Raydium 状態構造体は作成時にサイズ設定された末尾パディング領域を持ち、新しいフィールドは追加されるのではなくそのパディングから取得されます。したがって、アカウントのバイト長とすべての既存フィールドのオフセットは固定されたままです。その結果、以前パディングとして読み取ったバイトが意味を持つようになり、フィールドはパディングに戻すことができます(2026-08-31 リリースで
PlatformConfig.curve_paramsが行ったように)。アップグレード後に構造体定義を再度読み取ってください。パディングがゼロのままであると仮定しないでください。 - エラー列挙型コードは追加のみです。 既存のエラーコードは常に同じことを意味します。
- 破壊的な変更は新しいプログラムで提供されます。 再設計が必要な場合、チームは新しいプログラム ID をデプロイします(例:AMM v4 をアップグレードするのではなく、新しいプログラムとしての CPMM)。古いプールは古いプログラムで実行され続けます。新しいプールは新しいプログラムに移動します。
IDL が変更されたときの対応
- SDK を更新します。
npm update @raydium-io/raydium-sdk-v2。 - クライアントコードを再生成します(Anchor コード生成を直接使用する場合)。
- アカウントレイアウトを比較します。 新しいレイアウトの末尾フィールドは、コードが見ていない唯一のものです。それらが必要かどうかを確認してください。
- 古い命令ディスクリミネータが無効であると仮定しないでください。 ルール 1 に従い、それらはまだ機能します。
- メインネットにロールアウトする前に、devnet に対して統合テストを再実行します。
IDL トラブルシューティング
「Invalid discriminator」エラー
通常、IDL のバージョン N に対して構築されたクライアントが、プログラムのデプロイ前バージョンにのみ存在した命令を呼び出そうとしていることを意味します。ライブプログラムから IDL を再度取得してください:アカウントデコード失敗
program.account.<Name>.fetch(pubkey) が「Invalid account discriminator」でスローされる場合、アカウントは以前のプログラムバージョンで作成され、Anchor はその 8 バイトディスクリミネータを拒否しています。修正は、SDK からの生のレイアウトパーサー(PoolInfoLayout.decode(accountData))を使用することです。これは Anchor ディスクリミネータを強制しません。
生成されたクライアントに命令がない
Anchor の TS コード生成は、IDL エントリに有効な識別子として解析されるname を持つ命令に対してのみメソッドを生成します。Raydium の命令はすべてこれを満たしていますが、不一致が見られる場合は、IDL ファイルが現在の SDK リリースからのものであるかどうかを確認してください。
ポインタ
sdk-api/rust-cpi— Rust CPI クレートの使用。sdk-api/python-integration—anchorpy経由の Python。sdk-api/typescript-sdk— より高レベルの TS クライアント。

