Rust CPI

Raydium-Programme von einem anderen Solana-Programm aus über CPI aufrufen: Konstruktion von Kontolisten, Signer-Seeds, verbleibende Konten und Fehlerbehandlung für CPMM, CLMM und LaunchLab. AMM v4 (ohne Anchor-Crate) und Farm v6 werden in eigenen Abschnitten behandelt.

Diese Seite wurde mit KI automatisch übersetzt. Maßgeblich ist stets die englische Version.

Englische Version ansehen →

CPI („Cross-Program Invocation”) ist der Mechanismus, über den ein Solana-Programm ein anderes aufruft. Die meisten Raydium-Programme werden mit Anchor-CPI-Wrapper-Crates ausgeliefert, die die Aufrufstelle wie einen typisierten Funktionsaufruf aussehen lassen – mit Kontostrukturen, die validierte Feldnamen und cpi::<ix>()-Helfer haben. Diese Seite dokumentiert das allgemeine Muster einmal, dann die programmspezifischen Unterschiede. Für ausführbare TypeScript-Beispiele siehe die code-demos-Seite jedes Produktkapitels.

​

Welches Muster gilt für welches Programm

Programm	Anchor-basiert	Crate	Wo
CPMM	Ja	raydium-cp-swap (öffentliches Repo; Rust use-Pfad ist raydium_cp_swap)	Das allgemeine Muster, das durchgearbeitete Beispiel
CLMM	Ja	raydium-clmm (öffentliches Repo; Rust use-Pfad ist raydium_clmm)	Anwendung des Musters: CLMM
LaunchLab	Ja	kein bestätigter Crate-Name; Programmquelle ist geschlossen, aber die On-Chain-IDL-Metadaten-ID ist raydium_launchpad, ein technischer Name statt des Produktnamens (siehe Hinweis in Anwendung des Musters: LaunchLab)	Anwendung des Musters: LaunchLab
Farm v6	Unbestätigt; keine öffentliche IDL oder Quelle gefunden (siehe Warnung in Farm v6)	n/a	Farm v6
AMM v4	Nein, älter als Anchor ohne CPI-Crate	keine	AMM v4

Wenn Sie CPMM, CLMM oder LaunchLab integrieren, lesen Sie zunächst das allgemeine Muster, dann springen Sie zum Abschnitt Ihres Programms für die Kontoliste und eventuelle Unterschiede. Farm v6 und AMM v4 unterscheiden sich genug, um ihre Abschnitte eigenständig zu lesen.

​

Cargo-Abhängigkeiten

# Beide öffentlichen Raydium-CPI-Crates fixieren Anchor =1.0.2 auf `master`,
# daher kann ein Programm von beiden abhängen — siehe die Tabelle unten.
[dependencies]
anchor-lang     = "=1.0.2"
anchor-spl      = "=1.0.2"
raydium-cp-swap = { git = "https://github.com/raydium-io/raydium-cp-swap", branch = "master", features = ["cpi"] }
raydium-clmm    = { git = "https://github.com/raydium-io/raydium-clmm",    branch = "master", features = ["cpi"] }
# HINWEIS: Wenn Sie einen älteren `rev` von vor dem Anchor-1.0-Upgrade fixieren (CPMM 2026-09-09,
# CLMM 2026-09-30), fixiert dieser rev anchor-lang 0.32.1; verwenden Sie =0.32.1 und die 0.3x
# CpiContext-API — und dann nur eines der beiden Crates gleichzeitig.
# LaunchLab: Programmquelle ist nicht öffentlich verfügbar (siehe reference/program-addresses).
# Es gibt keine Git-Abhängigkeit, auf die verwiesen werden kann. Generieren Sie stattdessen
# CPI-Bindings aus der veröffentlichten IDL. Siehe „Anwendung des Musters: LaunchLab" unten.
# AMM v4 hat kein veröffentlichtes Anchor-CPI-Crate; siehe seinen eigenen Abschnitt.

Der Abhängigkeitsschlüssel muss exakt dem [package] name des Ziel-Repos entsprechen, Bindestriche eingeschlossen. Cargo behandelt raydium_cp_swap nicht als gleichwertig mit raydium-cp-swap beim Auflösen einer Git-Abhängigkeit.

branch = "master" verfolgt die neueste veröffentlichte Quelle; fixieren Sie einen spezifischen rev = "<commit>", wenn Sie einen reproduzierbaren Build benötigen. Dies wird empfohlen, sobald Sie über die Prototyping-Phase hinaus sind, da eine Upstream-Kontostruktur-Änderung auf master Ihren Build ohne Warnung bricht.

Das cpi-Feature-Flag lässt die Crates nur zur CPI-Oberfläche (Kontostrukturen + Invoker) kompilieren, statt zum vollständigen Programm, sodass Ihre Binärdatei klein bleibt.

anchor-lang / anchor-spl müssen dem entsprechen, was das Ziel-Crate fixiert:

Crate	Fixiert anchor-lang / anchor-spl
raydium-cp-swap (master)	=1.0.2, vom 2026-09-09-Upgrade
raydium-clmm (master)	=1.0.2, vom 2026-09-30-Upgrade
Eines der Crates bei einem rev vor seinem Upgrade	0.32.1

Nehmen Sie beide Crates aus der gleichen Anchor-Linie. Beide master-Branches fixieren =1.0.2, daher kann ein Programm von einem einzigen Crate aus in CPMM und CLMM aufrufen. Das Mischen von Linien bricht den Build: zum Beispiel raydium-cp-swap auf master mit raydium-clmm fixiert auf einen rev von vor seinem Anchor-1.0-Upgrade. Cargo müsste zwei inkompatible Kopien von Anchors Traits in eine Binärdatei linken. Wenn Sie bei einem gemischten Paar stecken, teilen Sie das Programm in zwei auf, oder verzichten Sie auf das typisierte CPI-Crate für eine Seite und kodieren Sie diese Anweisung manuell (das für AMM v4 gezeigte Muster funktioniert für jedes Programm).

Anchor 1.0 hat zwei Dinge geändert, die jede CPI-Aufrufstelle berührt. Wenn Sie eine funktionierende Integration von 0.3x verschieben:

• CpiContext::new nimmt einen Pubkey, nicht einen AccountInfo. CpiContext::new(ctx.accounts.cpmm_program.to_account_info(), accts) wird zu CpiContext::new(*ctx.accounts.cpmm_program.key, accts). Gleiches für new_with_signer. Das Strukturfeld ist jetzt program_id: Pubkey.
• Context hat eine Lebensdauer, nicht vier. Context<'_, '_, 'info, 'info, MyProxySwap<'info>> wird zu Context<'info, MyProxySwap<'info>>.

Auf der Client-Seite gibt anchor-client’s RequestBuilder::instructions() jetzt Vec<Instruction> statt Result<Vec<Instruction>> zurück (lassen Sie das ? weg), und CommitmentConfig wurde aus solana-sdk verschoben — nehmen Sie es stattdessen von anchor_client. spl-associated-token-account 8.0 exportiert seine Helfer aus dem neuen spl-associated-token-account-interface-Crate neu. get_associated_token_address und ID sind immer noch an der Crate-Wurzel (spl_associated_token_account::{get_associated_token_address, ID}) erreichbar, aber die Adress-Helfer sind dort veraltet — bevorzugen Sie die direkte Abhängigkeit von spl-associated-token-account-interface und importieren Sie spl_associated_token_account_interface::address::get_associated_token_address und spl_associated_token_account_interface::program::ID. Beachten Sie, dass ::address und ::program Module des Interface-Crates sind; spl_associated_token_account::address::… wird nicht aufgelöst.

Für funktionierende CPI-Beispiele, die die Kontostrukturen end-to-end verdrahten, siehe raydium-io/raydium-cpi-example (behandelt AMM v4, CPMM und CLMM). Sein neuester Branch ist anchor-0.31.0 — es gibt noch keinen Anchor-1.x-Branch, daher behandeln Sie dieses Repo als Referenz für Kontostruktur-Verdrahtung, nicht für die Versions-Pins, die diese Seite vorschreibt.

​

Das allgemeine Anchor-CPI-Muster

Dieser Abschnitt führt Sie CPMM von Anfang bis Ende durch als praktisches Beispiel: Accounts-Struct, CpiContext, cpi::<ix>(). CLMM folgt der identischen Struktur, mit einer anderen Kontoliste und einer Anforderung für verbleibende Konten. LaunchLab folgt der gleichen Mechanik, aber seine Kontoliste enthält mehrere Konten ohne CPMM/CLMM-Äquivalent (global_config, platform_config, event_authority, program), daher behandeln Sie es als das gleiche Muster, nicht die gleiche Struktur. Lesen Sie stattdessen den jeweiligen Abschnitt jedes Programms, anstatt anzunehmen, dass die Kontoliste aus dieser Anleitung direkt übertragbar ist.

​

Konstruktion der Kontoliste

Jeder Raydium-CPI erfordert einen Accounts-Struct im aufrufenden Programm. Seine Felder sind alle Konten, die Ihre Anweisung benötigt, mit Validatoren auf Feldebene; ihre Deklarationsreihenfolge muss nicht mit Raydiums eigener Anweisungskontoreihenfolge übereinstimmen, da Ihr eigener IDL-generierter Client sie nach Name adressiert, nicht nach Position:

use anchor_lang::prelude::*;
use anchor_spl::token::{Token, TokenAccount, Mint};

#[derive(Accounts)]
pub struct MyProxySwap<'info> {
    #[account(mut)]
    pub user: Signer<'info>,

    /// CHECK: validated by CPMM
    #[account(mut)]
    pub pool_state: UncheckedAccount<'info>,

    /// CHECK: ditto
    pub amm_config: UncheckedAccount<'info>,

    /// CHECK: ditto
    pub pool_authority: UncheckedAccount<'info>,

    #[account(mut)]
    pub input_vault: Account<'info, TokenAccount>,
    #[account(mut)]
    pub output_vault: Account<'info, TokenAccount>,

    pub input_mint: Account<'info, Mint>,
    pub output_mint: Account<'info, Mint>,

    #[account(mut)]
    pub user_input_ata:  Account<'info, TokenAccount>,
    #[account(mut)]
    pub user_output_ata: Account<'info, TokenAccount>,

    /// Typed as `Program<RaydiumCpSwap>` rather than `UncheckedAccount`: this account
    /// is the program being invoked, not Raydium-owned data, so Anchor's `Program<T>`
    /// wrapper checks its address automatically instead of leaving that check to the
    /// callee.
    pub cpmm_program: Program<'info, raydium_cp_swap::program::RaydiumCpSwap>,
    pub token_program: Program<'info, Token>,
    /// CHECK: observation PDA
    #[account(mut)]
    pub observation_state: UncheckedAccount<'info>,
}

Die meisten Raydium-seitigen Konten sind UncheckedAccount, weil der Aufgerufene (Raydium) die Validierung übernimmt. Ihr aufruferendes Programm validiert nur streng Konten, die Sie besitzen, wie Benutzer-ATAs und Ihre eigenen PDAs. Der /// CHECK:-Dokumentationskommentar unterdrückt Anchors Warnung über fehlende Überprüfungen. Die eine Raydium-seitige Ausnahme ist cpmm_program selbst: Es ist das aufgerufene Programm und nicht ein Datenkonto, das Raydium intern validiert, daher wird es als Program<T> typisiert und erhält Anchors automatische Adressprüfung statt einer manuellen /// CHECK:. Diese überwiegend UncheckedAccount-Struktur, bei der Raydium seine eigenen Konten validiert, ist die gleiche für CLMM und LaunchLab. Dieses Beispiel geht davon aus, dass beide Mints klassische SPL Token sind; wenn eine Seite ein Token-2022-Mint sein kann, fügen Sie ein token_program_2022: Program<'info, anchor_spl::token_2022::Token2022>-Feld hinzu und übergeben Sie es im CPI-Aufruf unten als input_token_program/output_token_program dieser Seite statt token_program.

​

Aufbau des CPI-Aufrufs

Anchor generiert einen Helper pro Anweisung zusammen mit einem CPI-Accounts-Struct (cpi::accounts::Swap, unten als CpmmSwap aliasiert). Im Gegensatz zu Ihrem eigenen MyProxySwap-Struct oben sind die Feldnamen und die Reihenfolge dieses Structs durch raydium-cp-swaps eigenes IDL festgelegt und müssen genau übereinstimmen:

use raydium_cp_swap::cpi::{self, accounts::Swap as CpmmSwap};

pub fn my_proxy_swap(
    ctx: Context<MyProxySwap>,
    amount_in: u64,
    minimum_amount_out: u64,
) -> Result<()> {
    let cpi_accounts = CpmmSwap {
        // `payer` is YOUR signer — it must own `input_token_account`.
        payer:                ctx.accounts.user.to_account_info(),
        // `authority` is CPMM's OWN vault PDA at seeds [b"vault_and_lp_mint_auth_seed"],
        // which CPMM signs with itself. Passing your signer here fails the
        // seeds constraint (`ConstraintSeeds`) before any transfer runs.
        authority:            ctx.accounts.pool_authority.to_account_info(),
        amm_config:           ctx.accounts.amm_config.to_account_info(),
        pool_state:           ctx.accounts.pool_state.to_account_info(),
        input_token_account:  ctx.accounts.user_input_ata.to_account_info(),
        output_token_account: ctx.accounts.user_output_ata.to_account_info(),
        input_vault:          ctx.accounts.input_vault.to_account_info(),
        output_vault:         ctx.accounts.output_vault.to_account_info(),
        input_token_program:  ctx.accounts.token_program.to_account_info(),
        output_token_program: ctx.accounts.token_program.to_account_info(),
        input_token_mint:     ctx.accounts.input_mint.to_account_info(),
        output_token_mint:    ctx.accounts.output_mint.to_account_info(),
        observation_state:    ctx.accounts.observation_state.to_account_info(),
    };
    // Anchor 1.0: the first argument is the program's Pubkey, not its AccountInfo.
    let cpi_ctx = CpiContext::new(
        *ctx.accounts.cpmm_program.key,
        cpi_accounts,
    );

    cpi::swap_base_input(cpi_ctx, amount_in, minimum_amount_out)?;
    Ok(())
}

cpi::swap_base_input wird aus dem IDL generiert; seine Argumentliste spiegelt die Argumentliste der Anchor-Anweisung wider. Jedes bestätigte Anchor-basierte Raydium-Programm (CPMM, CLMM, LaunchLab) generiert seine cpi::<ix>()-Helper auf die gleiche Weise, wobei der Funktionsname dem Anweisungsnamen in Snake-Case entspricht. Ob dies auf Farm v6 zutrifft, ist unbestätigt; siehe dessen Abschnitt.

​

Signer-Seeds (PDA-signierter CPI)

Wenn Ihr Programm den CPI im Namen einer PDA signiert (häufig bei Vaults, Escrows usw.), verwenden Sie CpiContext::new_with_signer:

let bump         = ctx.accounts.my_authority_bump;
let signer_seeds: &[&[&[u8]]] = &[&[b"my_authority", &[bump]]];

let cpi_ctx = CpiContext::new_with_signer(
    *ctx.accounts.cpmm_program.key,
    cpi_accounts,
    signer_seeds,
);

cpi::swap_base_input(cpi_ctx, amount_in, minimum_amount_out)?;

Die Signer-Seeds müssen mit der Ableitung der PDA übereinstimmen. Für jedes Konto, das als authority (oder ähnliche Signer-Rolle) übergeben wird, prüft die Solana-Runtime, dass die PDA über diese Seeds signiert.

​

Verbleibende Konten

Einige Raydium-Anweisungen nehmen verbleibende Konten an, eine Liste variabler Länge, die nach den festen Konten angehängt wird. Anchors CPI-Helper führen keine Typprüfung für verbleibende Konten durch; übergeben Sie sie über .with_remaining_accounts(...):

let cpi_ctx = CpiContext::new(program_id, accounts)
    .with_remaining_accounts(ctx.remaining_accounts.to_vec());

Die Reihenfolge ist immer wichtig, da das empfangende Programm die verbleibenden Konten in der Reihenfolge durchläuft, in der Sie sie übergeben. Zwei bestätigte Ordnungen:

• CLMM SwapV2: Tick-Arrays, in Richtungsreihenfolge.
• Farm v6: (reward_vault, user_reward_ata)-Paare, aber nur ab dem zweiten Reward-Stream an; siehe Farm v6 für das, was die Dekodierung einer echten Transaktion zeigt.

​

Anwendung des Musters: CLMM

SwapV2 folgt dem allgemeinen Muster oben mit einer anderen Kontoliste und einer Anforderung für verbleibende Konten für Tick-Arrays. Das Modul #[program] der Crate heißt raydium_clmm, was auch sein Rust-use-Pfad ist.

Der CPI-Accounts-Struct heißt SwapSingleV2, nicht SwapV2. SwapV2 ist der On-Chain-Anweisungsname.

use raydium_clmm::cpi::{self, accounts::SwapSingleV2 as ClmmSwap};

#[derive(Accounts)]
pub struct MyProxyClmmSwap<'info> {
    #[account(mut)]
    pub payer: Signer<'info>,

    /// CHECK: validated by CLMM
    pub amm_config: UncheckedAccount<'info>,
    /// CHECK: ditto
    #[account(mut)]
    pub pool_state: UncheckedAccount<'info>,

    #[account(mut)]
    pub input_token_account: Account<'info, TokenAccount>,
    #[account(mut)]
    pub output_token_account: Account<'info, TokenAccount>,
    #[account(mut)]
    pub input_vault: Account<'info, TokenAccount>,
    #[account(mut)]
    pub output_vault: Account<'info, TokenAccount>,

    /// CHECK: observation PDA
    #[account(mut)]
    pub observation_state: UncheckedAccount<'info>,

    pub token_program: Program<'info, Token>,
    pub token_program_2022: Program<'info, anchor_spl::token_2022::Token2022>,
    /// CHECK: SPL memo program, required for some Token-2022 paths
    pub memo_program: UncheckedAccount<'info>,

    pub input_vault_mint: Account<'info, Mint>,
    pub output_vault_mint: Account<'info, Mint>,

    /// Typed as `Program<T>` rather than `UncheckedAccount`, same reason as CPMM's
    /// `cpmm_program` in the general pattern above: it's the invoked program, and
    /// `Program<T>` checks its address automatically.
    pub clmm_program: Program<'info, raydium_clmm::program::RaydiumClmm>,
    // remaining_accounts: tick_array_bitmap_extension (if the walk needs it), then
    // as many tick_array accounts as the swap's expected price range spans.
}

Berechnen Sie die Tick-Array-Liste auf die gleiche Weise wie das SDK, über ein Quote gegen den aktuellen Pool-Status, anstatt eine feste Anzahl zu erraten; ein Swap, der die übergebenen Arrays überläuft, wird mit TickArrayNotFound zurückgewiesen (siehe products/clmm/instructions für die vollständige Kontotabelle und Fehlerliste). Übergeben Sie sie in der Richtung des Preis-Walks: erstes Array in Swap-Richtung zuerst.

​

Das Muster anwenden: LaunchLab

LaunchLab basiert auf Anchor und veröffentlicht ein IDL: raydium_launchpad/raydium_launchpad.json im öffentlichen Repository raydium-idl. Der interne Metadaten-Identifikator dieses IDL ist raydium_launchpad, ein technischer Name für das zugrunde liegende Programm, nicht ein alternativer Name für das Produkt. Anders als bei CPMM und CLMM ist jedoch der Quellcode des Programms selbst nicht öffentlich verfügbar (siehe reference/program-addresses). Es gibt keine git = "..." Abhängigkeit für Cargo und keinen Quellcode, um zu bestätigen, welcher Rust use-Pfad einer echten Crate entsprechen würde.

Generieren Sie Bindings aus dem veröffentlichten IDL mit Anchors declare_program! Makro. Speichern Sie die IDL-JSON als idls/raydium_launchpad.json in Ihrer Crate (Cargo sucht nach einem idls/ Verzeichnis relativ zu CARGO_MANIFEST_DIR), dann generiert declare_program!(raydium_launchpad); die Structs raydium_launchpad::cpi::accounts::<Ix> und Funktionen cpi::<ix>() direkt aus dem IDL, ohne Programmquellcode erforderlich. Der generierte Name der Accounts-Struktur ist immer der Instruktionsname in PascalCase (buy_exact_in → BuyExactIn), und die Feldnamen entsprechen exakt den Kontonamen des IDL, derselben Kontoliste, die bereits in MyProxyBuy unten verwendet wird.

Die CPI-Form folgt dem allgemeinen Muster. Die Kontoliste und Argumente unten stammen aus der On-Chain-IDL-Instruktion buy_exact_in, nicht aus products/launchlab/instructions.mdx:

use anchor_lang::prelude::*;
use anchor_spl::token::{Token, TokenAccount, Mint};
use raydium_launchpad::cpi::{self, accounts::BuyExactIn};

#[derive(Accounts)]
pub struct MyProxyBuy<'info> {
    #[account(mut)]
    pub payer: Signer<'info>,

    /// CHECK: PDA, seeds = [b"vault_auth_seed"], validated by the program
    pub authority: UncheckedAccount<'info>,

    /// CHECK: validated by the program
    pub global_config: UncheckedAccount<'info>,
    /// CHECK: validated by the program
    pub platform_config: UncheckedAccount<'info>,

    /// CHECK: validated by the program
    #[account(mut)]
    pub pool_state: UncheckedAccount<'info>,

    #[account(mut)]
    pub user_base_token: Account<'info, TokenAccount>,
    #[account(mut)]
    pub user_quote_token: Account<'info, TokenAccount>,
    #[account(mut)]
    pub base_vault: Account<'info, TokenAccount>,
    #[account(mut)]
    pub quote_vault: Account<'info, TokenAccount>,

    pub base_token_mint: Account<'info, Mint>,
    pub quote_token_mint: Account<'info, Mint>,

    /// CHECK: base mint's token program (SPL Token or Token-2022, depending on the mint)
    pub base_token_program: UncheckedAccount<'info>,
    /// Typed as `Program<Token>` rather than `UncheckedAccount`: the IDL fixes this to
    /// classic SPL Token specifically (unlike base_token_program above), so Anchor's
    /// built-in address check on `Program<Token>` is sufficient on its own.
    pub quote_token_program: Program<'info, Token>,

    /// CHECK: PDA, seeds = [b"__event_authority"], required by the program's emit_cpi! pattern
    pub event_authority: UncheckedAccount<'info>,
    /// CHECK: the program's own account, required alongside event_authority
    pub program: UncheckedAccount<'info>,
}

pub fn my_proxy_buy(
    ctx: Context<MyProxyBuy>,
    amount_in: u64,
    minimum_amount_out: u64,
    share_fee_rate: u64,
) -> Result<()> {
    let cpi_accounts = BuyExactIn {
        payer:               ctx.accounts.payer.to_account_info(),
        authority:           ctx.accounts.authority.to_account_info(),
        global_config:       ctx.accounts.global_config.to_account_info(),
        platform_config:     ctx.accounts.platform_config.to_account_info(),
        pool_state:          ctx.accounts.pool_state.to_account_info(),
        user_base_token:     ctx.accounts.user_base_token.to_account_info(),
        user_quote_token:    ctx.accounts.user_quote_token.to_account_info(),
        base_vault:          ctx.accounts.base_vault.to_account_info(),
        quote_vault:         ctx.accounts.quote_vault.to_account_info(),
        base_token_mint:     ctx.accounts.base_token_mint.to_account_info(),
        quote_token_mint:    ctx.accounts.quote_token_mint.to_account_info(),
        base_token_program:  ctx.accounts.base_token_program.to_account_info(),
        quote_token_program: ctx.accounts.quote_token_program.to_account_info(),
        event_authority:     ctx.accounts.event_authority.to_account_info(),
        program:             ctx.accounts.program.to_account_info(),
    };
    // `program` doubles as the CPI target here: LaunchLab's own account is both one of
    // its instruction's required accounts (for its emit_cpi! pattern) and the program
    // CpiContext::new invokes.
    let cpi_ctx = CpiContext::new(
        *ctx.accounts.program.key,
        cpi_accounts,
    );

    cpi::buy_exact_in(cpi_ctx, amount_in, minimum_amount_out, share_fee_rate)?;
    Ok(())
}

Nach der Graduierung ist das Zielprogramm CPMM oder AMM v4, abhängig von pool_state.migrate_type, das laut products/launchlab/accounts.mdx zur Zeit von Initialize gesetzt wird. Ihre CPI-Kontoliste muss für beide vorbereitet sein, oder Sie müssen migrate_type zuerst aus PoolState auslesen und verzweigen.

​

Fehlerbehandlung

Jedes Anchor-basierte Raydium-Programm gibt seine eigene Error-Enum zurück; Anchor umhüllt sie, sodass Ihr aufruferendes Programm sie als Err(ProgramError::Custom(code)) sieht. Um spezifische Fehler zu behandeln:

use raydium_cp_swap::error::ErrorCode as CpmmErr;

match cpi::swap_base_input(cpi_ctx, amount_in, minimum_amount_out) {
    Ok(_) => Ok(()),
    Err(e) => {
        msg!("CPMM swap failed: {:?}", e);
        // Re-raise, or convert to your own error type.
        Err(e)
    }
}

Ersetzen Sie den relevanten Error-Typ für das Programm, das Sie aufrufen (raydium_clmm::error::ErrorCode für CLMM usw.). Fehlercodes sind stabil gemäß der IDL-Richtlinie (sdk-api/anchor-idl), sodass Sie gegen spezifische Codes testen können, indem Sie gegen den numerischen Wert vergleichen. Vollständige Fehlertabellen: CPMM, CLMM, AMM v4, Farm v6 und LaunchLab.

​

Compute-Budget in zusammengesetzten CPIs

Jeder CPI-Frame hat Overhead, und der eigene CU-Verbrauch des aufgerufenen Programms addiert sich zu Ihrem, daher benötigt eine Transaktion, die von innerhalb Ihres Programms in Raydium aufruft, ein explizites Compute-Budget, anstatt sich auf das Standard-Limit von 200k CU zu verlassen.

Gemessen, nicht geschätzt. Ein CPMM swap_base_input im Mainnet verbraucht ~23.000 CU im CPMM-Programm selbst — gemessen am 2026-09-09 über acht Live-Swaps in einem hochvolumigen Pool (22.721–23.052), gelesen aus der Log-Zeile Program CPMMoo8… consumed N of M compute units. Zum Vergleich: AMM v4 Swap ~26.000; CLMM swap ~41.000; CLMM swap_v2 ~48.000 (43.838–52.887), steigt mit jedem Tick-Crossing.

Eine frühere Version dieser Seite meldete ~47.700 CU für einen Proxy-Swap CPI. Diese Zahl war die ganze Transaktion (computeUnitsConsumed), die das eigene Programm des Aufrufers, den CPI-Frame und jedes ATA-Setup umfasst — nicht die Kosten des aufgerufenen Programms. Beide sind nützlich, aber es sind nicht dieselben Zahlen, daher vergleichen Sie Gleiches mit Gleichem. Messen Sie Ihre eigene Transaktion, anstatt nach einer Zahl aus der Dokumentation zu budgetieren, da das Standard-Limit von 200k CU stillschweigend erschöpft wird und die Pro-Instruktions-Kosten sich verschieben, wenn Programme aktualisiert werden.

CLMM und LaunchLab CPIs kosten mehr (CLMM durchläuft insbesondere zusätzliche Tick-Arrays über remaining_accounts, was CU pro Array hinzufügt), aber nur die obige CPMM-Zahl ist ein gemessener Wert. Setzen Sie immer ein explizites ComputeBudgetProgram::set_compute_unit_limit(...) Instruktion, die auf Ihrer eigenen Messung basiert, nicht auf einer Zahl, die aus der Dokumentation kopiert wurde, da das Standard-Limit von 200k CU stillschweigend erschöpft wird und sich die Pro-Instruktions-Kosten verschieben, wenn Programme aktualisiert werden.

​

AMM v4: manuelle Instruction-Konstruktion

AMM v4 stammt aus der Zeit vor Anchor und hat keine CPI-Crate, was es zum einzigen Programm in dieser Dokumentation macht, das nicht dem allgemeinen Muster oben folgt. Bauen Sie die Instruction von Hand:

use anchor_lang::prelude::*;
use anchor_lang::solana_program::program::invoke_signed;
use anchor_lang::solana_program::instruction::{Instruction, AccountMeta};

const AMM_V4_PROGRAM_ID: Pubkey = pubkey!("675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8");

// SwapBaseIn discriminator is 9.
let mut data = vec![9u8];
data.extend_from_slice(&amount_in.to_le_bytes());
data.extend_from_slice(&minimum_amount_out.to_le_bytes());

let ix = Instruction {
    program_id: AMM_V4_PROGRAM_ID,
    accounts: vec![
        AccountMeta::new_readonly(token_program_id, false),
        AccountMeta::new(amm_id, false),
        AccountMeta::new_readonly(amm_authority, false),
        // ... remaining accounts per products/amm-v4/instructions ...
    ],
    data,
};
invoke_signed(&ix, &account_infos, signer_seeds)?;

Siehe products/amm-v4/code-demos für die vollständige Kontoliste.

​

Farm v6

Verwenden Sie das TS SDK, wenn das für Ihre Integration eine Option ist. raydium.farm.deposit(...) (siehe products/farm-staking/code-demos) wird durch echte Demos ausgeübt und hängt nicht davon ab, ob eine Rust Anchor-Crate für dieses Programm existiert.

Farm v6 bietet keinen Anchor CPI-Pfad. Es gibt keine raydium_farm_v6 Crate auf crates.io, kein öffentliches Quellcode-Repository und kein On-Chain-IDL — das Programm hat weder ein Legacy-anchor:idl Konto noch einen Eintrag im Program Metadata-Programm (siehe sdk-api/anchor-idl). Behandeln Sie es als ein Nicht-Anchor-Programm und bauen Sie seine Instruktionen von Hand, wie unten.

Wenn Sie trotzdem Rust CPI benötigen, zum Beispiel um von einem anderen On-Chain-Programm zu komponieren, bauen Sie die Instruction von Hand, auf die gleiche Weise wie AMM v4: leiten Sie die echte Kontoliste und Instruktions-Diskriminatoren unabhängig ab, zum Beispiel durch Dekodieren der TypeScript-Layouts des SDK (raydium-sdk-V2’s Farm-Modul), Dekodieren echter Transaktionen direkt (siehe unten) oder Dumpen und Disassemblieren des bereitgestellten Programms.

Für die Instruktionsform ohne Argumente, die mit einem Harvest- oder Claim-Aufruf konsistent ist, ist die echte Kontenreihenfolge ein festes Präfix (token_program, das State-Konto der Farm, eine Vault-Authority PDA, die erste Reward-Vault dieser PDA, eine zweite PDA, der Aufrufer und die ATA des Aufrufers für diesen ersten Reward-Mint), gefolgt von (reward_vault_i, user_reward_ata_i) Paaren in remaining_accounts für jeden Reward-Stream nach dem ersten. Die Paarungskonvention ist real, aber sie beginnt erst beim zweiten Reward-Stream: die Vault und ATA des ersten Streams sind feste Konten, nicht nebeneinander, und nicht Teil von remaining_accounts überhaupt.

​

Testen eines CPI-Flows

Für die lokale Entwicklung müssen die Raydium-Programme in Ihrem Test-Validator verfügbar sein. Es gibt drei Optionen:

1. anchor test mit Program Clone. Zieht den bereitgestellten Mainnet-Bytecode in Ihren lokalen Validator; siehe Programme in einen lokalen Validator klonen unten für die Anchor.toml-Konfiguration und zwei Dinge, die speziell bei Pool-Erstellungstests zu Problemen führen.
2. Devnet. Raydium stellt die meisten Programme auf Devnet bereit, aber unter unterschiedlichen Program IDs als auf Mainnet für jedes Programm (CPMM, CLMM, AMM v4, Stable AMM und LaunchLab haben jeweils eine eigene Devnet-Adresse; siehe die Devnet-Tabelle in reference/program-addresses). Farm v3/v5/v6 werden nicht zuverlässig auf Devnet veröffentlicht; die Live-API (https://api-v3-devnet.raydium.io/main/info) zeigt das aktuelle Bild. Wenn Sie die gebündelten DEVNET_PROGRAM_ID-Konstanten von raydium_clmm verwenden (oder das Äquivalent für andere Crates), gehen Sie nicht davon aus, dass eine Mainnet-ID auch auf Devnet funktioniert. Führen Sie anchor test --provider.cluster devnet aus, um Live-Code zu testen, sobald Sie die richtigen Adressen haben.
3. Lokale Bereitstellung. Klonen Sie die Raydium-Repositories (CPMM, CLMM; LaunchLabs Quellcode ist für diese Option nicht verfügbar) und führen Sie anchor deploy auf einem lokalen Validator aus. Dies erhöht den Test-Zyklus-Overhead, ermöglicht es Ihnen aber, den aufgerufenen Code zum Debuggen zu ändern.

Führen Sie anchor test aus, oder führen Sie zuerst anchor build und dann anchor test --skip-build aus, wenn Sie die Test-Datei iterieren, ohne das Programm zu ändern.

​

Programme in einen lokalen Validator klonen

[test]
# Der Standard (5s) reicht nicht aus, wenn Sie mehrere Konten klonen, da jeder
# während des Validator-Starts ein sequenzieller Mainnet-RPC-Roundtrip ist.
startup_wait = 60000

[test.validator]
url = "https://api.mainnet-beta.solana.com"

[[test.validator.clone]]
address = "CAMMCzo5YL8w4VFF8KVHrK22GGUsp5VTaW7grrKgrWqK"  # CLMM

[[test.validator.clone]]
address = "CPMMoo8L3F4NbTegBCKVNunggL7H1ZpdTHKxQB5qKP1C"  # CPMM

[[test.validator.clone]]
address = "LanMV9sAd7wArD4vJFi2qDdfnVhFxYSUg6eADduJ3uj"   # LaunchLab

[[test.validator.clone]]
address = "FarmqiPv5eAj3j1GMdMCMUGXqPUvmquZtMy86QH6rzhG"  # Farm v6

Dies funktioniert unabhängig von der Program ID, unabhängig davon, ob der Quellcode des Programms öffentlich ist oder nicht. LaunchLab wird daher auf die gleiche Weise geklont wie CPMM und CLMM, obwohl sein Quellcode nicht verfügbar ist. reference/program-addresses ist die maßgebliche Quelle für jede Adresse hier.

Das Klonen des Programms reicht nicht aus, wenn Ihr Test auch einen Pool erstellt (anstatt gegen einen bereits existierenden zu tauschen). CPMMs initialize-Anweisung validiert seine amm_config- und create_pool_fee-Konten gegen echte On-Chain-Daten, daher müssen Sie diese auch klonen, sonst schlägt initialize direkt fehl. Speziell für CPMM: Klonen Sie die Gebühren-Tier-AmmConfig, die Sie möchten (rufen Sie ihre Adresse von GET https://api-v3.raydium.io/main/cpmm-config ab, Index 0 ist die 0,25%-Tier) und das Gebühren-Empfänger-Token-Konto, das nach exakter Adresse validiert wird, nicht spontan erstellt, daher muss es bereits existieren.

Ein Pool, den Ihr Test gerade erstellt hat, ist nicht sofort tauschbar. CPMMs initialize überschreibt stillschweigend eine angeforderte open_time, die nicht streng in der Zukunft liegt (if open_time <= block_timestamp { open_time = block_timestamp + 1 }), daher hinterlässt selbst startTime: 0 („sofort öffnen”, gemäß SDK) eine echte Lücke von ≥1 Sekunde, bevor der Pool Swaps akzeptiert. Ein Test, der einen Pool erstellt und sofort dagegen tauscht, trifft auf NotApproved. Ein kurzes await (1–2s) zwischen Pool-Erstellung und dem ersten Swap reicht aus. Dies ist spezifisch für Tests; ein Mensch, der zwei separate manuelle Befehle ausführt, würde dies normalerweise nicht bemerken, da Tippen und Prozessstart bereits mehr als eine Sekunde verbrauchen.

​

Hinweise

• products/cpmm/code-demos, products/clmm/code-demos, products/amm-v4/code-demos, products/farm-staking/code-demos, products/launchlab/code-demos: produktspezifische CPI- und TypeScript-Beispiele.
• sdk-api/anchor-idl: IDL-Abruf und Client-Regeneration, einschließlich des IDL-Codegen-Pfads für LaunchLab.
• integration-guides/cpi-integration: übergeordnete Integrationsmuster wie Escrows, Vaults und Aggregator-Komposition.

Quellen:

• raydium-cp-swap
• raydium-clmm
• raydium-idl: LaunchLab IDL (der Programmquellcode selbst ist geschlossen)
• Anchor CPI docs