Skip to main content
Bu sayfa yapay zekâ tarafından otomatik olarak çevrilmiştir. İngilizce sürüm esas alınır.İngilizce sürümü görüntüle →
CPI (“cross-program invocation”), bir Solana programının başka bir programı çağırması mekanizmasıdır. Raydium’un çoğu programı, çağrı sitesini yazılı bir işlev çağrısı gibi görünen Anchor CPI sarmalayıcı sandıkları ile birlikte gelir; doğrulanmış alan adlarına sahip hesap yapıları ve cpi::<ix>() yardımcıları. Bu sayfa genel deseni bir kez belgelemekte, ardından program başına farklılıkları açıklamaktadır. Çalıştırılabilir TypeScript için her ürün bölümünün code-demos sayfasına bakınız.

Hangi desen hangi programa uygulanır

CPMM, CLMM veya LaunchLab’ı entegre ediyorsanız, önce genel deseni okuyun, ardından programınızın bölümüne atlayın. Farm v6 ve AMM v4 kendi bölümlerini bağımsız olarak okumayı gerektiren kadar farklıdır.

Cargo bağımlılıkları

Bağımlılık anahtarı hedef deponun [package] name ile tam olarak eşleşmelidir, tireleri dahil. Cargo, bir git bağımlılığını çözerken raydium_cp_swap’ı raydium-cp-swap’a eşdeğer olarak görmez.
branch = "master" en son yayınlanan kaynağı izler; yeniden üretilebilir bir derleme gerekiyorsa belirli bir rev = "<commit>" ile sabitleyin. Prototiplemeyi geçtikten sonra bu önerilir, çünkü master üzerindeki bir yukarı akış hesap düzeni değişikliği hiçbir uyarı olmadan derlemenizi bozacaktır. cpi özellik bayrağı, sandıkların tam program yerine yalnızca CPI yüzeyine (hesap yapıları + çağırıcılar) derlemesini sağlar, böylece ikili dosyanız küçük kalır. anchor-lang / anchor-spl hedef sandığın sabitlediği şeyle eşleşmelidir ve 2026-09 itibariyle iki genel Raydium sandığı uyuşmamaktadır:
Şu anda bir programdan her iki sandığa da bağlı olamazsınız. Her biri Anchor’ı = ile sabitlediğinden, Cargo’nun bir ikili dosyaya Anchor’ın özelliklerinin iki uyumsuz kopyasını bağlaması gerekir ve derleme başarısız olur. Programınız hem CPMM hem de CLMM’ye CPI yapıyorsa, onu iki programa bölmeniz veya bunlardan birinin yazılı CPI sandığını bırakıp bu talimatı elle kodlamanız gerekir (AMM v4 için gösterilen desen herhangi bir program için çalışır). Başlamadan önce her iki Cargo.toml dosyasını yeniden kontrol edin — CLMM Anchor 1.x’e geçtiğinde bunun çözülmesi beklenmektedir.
Anchor 1.0 her CPI çağrı sitesinin dokunduğu iki şeyi değiştirdi. 0.3x’ten çalışan bir entegrasyonu taşıyorsanız:
  • CpiContext::new bir AccountInfo değil, bir Pubkey alır. CpiContext::new(ctx.accounts.cpmm_program.to_account_info(), accts) CpiContext::new(*ctx.accounts.cpmm_program.key, accts) olur. new_with_signer için aynı. Yapı alanı artık program_id: Pubkey.
  • Context dört değil, bir yaşam süresine sahiptir. Context<'_, '_, 'info, 'info, MyProxySwap<'info>> Context<'info, MyProxySwap<'info>> olur.
İstemci tarafında, anchor-client’ın RequestBuilder::instructions() artık Result<Vec<Instruction>> yerine Vec<Instruction> döndürür (? bırakın) ve CommitmentConfig solana-sdk’dan çıktı — bunun yerine anchor_client’dan alın. spl-associated-token-account 8.0 yardımcılarını yeni spl-associated-token-account-interface sandığından yeniden dışa aktarır. get_associated_token_address ve ID hala sandık kökünde erişilebilir (spl_associated_token_account::{get_associated_token_address, ID}), ancak adres yardımcıları orada kullanımdan kaldırılmıştır — bunun yerine doğrudan spl-associated-token-account-interface sandığına bağlı olmayı tercih edin ve spl_associated_token_account_interface::address::get_associated_token_address ve spl_associated_token_account_interface::program::ID içe aktarın. ::address ve ::program arayüz sandığının modülleridir; spl_associated_token_account::address::… çözülmez.
Hesap yapılarını uçtan uca bağlayan çalışan CPI örnekleri için raydium-io/raydium-cpi-example (AMM v4, CPMM ve CLMM’yi kapsar) bölümüne bakınız. En yeni dalı anchor-0.31.0 — henüz Anchor 1.x dalı yok, bu nedenle bu depoyu hesap yapısı bağlaması için referans olarak değerlendirin, bu sayfanın zorunlu kıldığı sürüm sabitlemeleri için değil.

Genel Anchor CPI deseni

Bu bölüm CPMM’yi uçtan uca çalışan örnek olarak açıklamaktadır: Accounts yapısı, CpiContext, cpi::<ix>(). CLMM aynı şekli izler, farklı bir hesap listesi ve kalan hesaplar gereksinimi ile. LaunchLab aynı mekanikleri izler ancak hesap listesi CPMM/CLMM’ye eşdeğer olmayan birkaç hesap taşır (global_config, platform_config, event_authority, program), bu nedenle bunu aynı desen olarak değerlendirin, aynı şekil değil. Her programın kendi bölümüne bakınız, bu kılavuzun hesap listesinin doğrudan aktarılacağını varsaymayın.

Hesap listesi oluşturma

Her Raydium CPI, çağıran programda bir Accounts yapısı gerektirir. Alanları, talimatınızın ihtiyaç duyduğu hesaplar, alan düzeyinde doğrulayıcılarla; bunların bildirim sırası Raydium’un kendi talimat hesap sırasıyla eşleşmek zorunda değildir, çünkü kendi IDL tarafından oluşturulan istemci bunları ad ile değil, konum ile ele alır:
Raydium tarafı hesaplarının çoğu UncheckedAccount olarak yazılmıştır çünkü çağrılan taraf (Raydium) doğrulamaya sahiptir. Çağıran programınız yalnızca sizin sahip olduğunuz hesapları kesin olarak doğrular, örneğin kullanıcı ATA’ları ve kendi PDA’larınız. /// CHECK: doc-yorumu Anchor’ın eksik kontroller hakkındaki uyarısını bastırır. Raydium tarafı istisnası cpmm_program kendisidir: çağrılan program yerine çağrılan program olduğundan, Raydium’un dahili olarak doğruladığı bir veri hesabı değildir, bu nedenle Program<T> olarak yazılmıştır ve manuel /// CHECK: yerine Anchor’ın otomatik adres kontrolünü alır. Bu çoğunlukla UncheckedAccount şekli, Raydium’un kendi hesaplarını doğruladığı, CLMM ve LaunchLab için aynıdır. Bu örnek her iki madeni paranın da klasik SPL Token olduğunu varsayar; her iki taraf da Token-2022 madeni parası olabilirse, bir token_program_2022: Program<'info, anchor_spl::token_2022::Token2022> alanı ekleyin ve aşağıdaki CPI çağrısında token_program yerine input_token_program/output_token_program olarak geçirin.

CPI çağrısını oluşturma

Anchor her talimat için bir yardımcı oluşturur, CPI hesapları yapısı ile birlikte (cpi::accounts::Swap, aşağıda CpmmSwap olarak takma ad). Yukarıdaki kendi MyProxySwap yapınızdan farklı olarak, bu yapının alan adları ve sırası raydium-cp-swap’ın kendi IDL’si tarafından sabittir ve tam olarak eşleşmesi gerekir:
cpi::swap_base_input IDL’den oluşturulur; argüman listesi Anchor talimatının argüman listesini yansıtır. Onaylanan her Anchor tabanlı Raydium programı (CPMM, CLMM, LaunchLab) cpi::<ix>() yardımcılarını aynı şekilde oluşturur, işlev adı snake_case’de talimat adıyla eşleşir. Bunun Farm v6’ya kadar uzanıp uzanmadığı onaylanmamıştır; kendi bölümüne bakınız.

İmzalayan tohumlar (PDA imzalı CPI)

Programınız bir PDA adına CPI’yi imzaladığında (kasalar, emanetler vb. için yaygın), CpiContext::new_with_signer kullanın:
İmzalayan tohumlar PDA’nın türetilmesiyle eşleşmelidir. authority (veya benzer imzalayan rol) olarak geçirilen herhangi bir hesap için, Solana çalışma zamanı PDA’nın bu tohumlar aracılığıyla imzaladığını kontrol eder.

Kalan hesaplar

Bazı Raydium talimatları kalan hesaplar, sabit hesaplardan sonra eklenen değişken uzunlukta bir liste alır. Anchor’ın CPI yardımcıları kalan hesapları tür kontrol etmez; bunları .with_remaining_accounts(...) aracılığıyla geçirin:
Sıra her zaman önemlidir, çünkü alıcı program kalan hesapları geçtiğiniz sırada yineler. İki onaylanmış sıralama:
  • CLMM SwapV2: tick dizileri, yönsel olarak sıralanmış.
  • Farm v6: (reward_vault, user_reward_ata) çiftleri, ancak yalnızca ikinci ödül akışından itibaren; gerçek bir işlemi çözmek için Farm v6 bölümüne bakınız.

Deseni uygulama: CLMM

SwapV2 yukarıdaki genel deseni farklı bir hesap listesi ve tick dizileri için kalan hesaplar gereksinimi ile izler. Sandığın #[program] modülü raydium_clmm olarak adlandırılmıştır, bu aynı zamanda Rust use yoludur.
CPI hesapları yapısı SwapV2 değil, SwapSingleV2 olarak adlandırılmıştır. SwapV2 zincir üstü talimat adıdır.
Tick dizisi listesini SDK’nın yaptığı gibi, sabit bir sayı tahmin etmek yerine mevcut havuz durumuna karşı bir alıntı aracılığıyla hesaplayın; dizileri aşan bir swap TickArrayNotFound ile geri döner (products/clmm/instructions tam hesap tablosu ve hata listesi için). Bunları fiyat yürüyüşü yönünde geçirin: ilk dizi swap yönünde ilk.

Deseni uygulama: LaunchLab

LaunchLab Anchor tabanlı ve IDL yayınlanmıştır: raydium_launchpad/raydium_launchpad.json genel raydium-idl deposunda. Bu IDL’nin iç meta veri tanımlayıcısı raydium_launchpad, ürün adı değil, temel program için teknik bir addır. CPMM ve CLMM’den farklı olarak, programın kendi kaynağı genel olarak mevcut değildir (reference/program-addresses bölümüne bakınız). Cargo’ya işaret edecek git = "..." bağımlılığı yok ve gerçek bir sandığın Rust use yolunun ne olacağını doğrulamak için kaynak yok. Yayınlanan IDL’den Anchor’ın declare_program! makrosu kullanarak bağlamalar oluşturun. IDL JSON’ını sandığınızda idls/raydium_launchpad.json olarak kaydedin (Cargo CARGO_MANIFEST_DIR’ye göre bir idls/ dizini arar), ardından declare_program!(raydium_launchpad); IDL’den doğrudan raydium_launchpad::cpi::accounts::<Ix> yapıları ve cpi::<ix>() işlevleri oluşturur, program kaynağı gerekli değildir. Oluşturulan hesapları yapısı adı her zaman PascalCase’de talimat adıdır (buy_exact_in → BuyExactIn), ve alan adları IDL’nin hesap adlarıyla tam olarak eşleşir, aşağıdaki MyProxyBuy’da zaten kullanılan aynı hesap listesi. CPI şekli genel deseni izler. Aşağıdaki hesap listesi ve argümanlar zincir üstü IDL’nin buy_exact_in talimatından gelir, products/launchlab/instructions.mdx’den değil:
Mezuniyet sonrası, hedef program pool_state.migrate_type’a bağlı olarak CPMM veya AMM v4’tür, products/launchlab/accounts.mdx Initialize zamanında ayarlandığını söyler. CPI hesap listeniz her ikisi için hazırlanmalı veya önce PoolState’den migrate_type’ı okumanız ve dallanmanız gerekir.

Hata yayılması

Her Anchor tabanlı Raydium programı kendi hata numaralandırmasını döndürür; Anchor bunları sarar, bu nedenle çağıran programınız bunları Err(ProgramError::Custom(code)) olarak görür. Belirli hataları işlemek için:
Çağırdığınız program için ilgili hata türünü değiştirin (raydium_clmm::error::ErrorCode CLMM için vb.). Hata kodu numaraları IDL politikasına göre kararlıdır (sdk-api/anchor-idl), bu nedenle sayısal değere karşı karşılaştırarak belirli kodlara karşı test edebilirsiniz. Tam hata tabloları: CPMM, CLMM, AMM v4, Farm v6 ve LaunchLab.

Bileşik CPI’lerde hesaplama bütçesi

Her CPI çerçevesinin ek yükü vardır ve çağrılan tarafın kendi CU tüketimi sizinkinin üstüne yığılır, bu nedenle programınızın içinden Raydium’a çağrı yapan bir işlem 200k CU varsayılanına güvenmek yerine açık bir hesaplama bütçesi gerektirir.
Tahmin değil, ölçülen. Mainnet’te bir CPMM swap_base_input ~23.000 CU CPMM programının kendisinde tüketir — 2026-09-09’da yüksek hacimli bir havuzda sekiz canlı swap arasında örneklenmiş (22.721–23.052), Program CPMMoo8… consumed N of M compute units günlük satırından okunmuştur. Karşılaştırma için: AMM v4 swap ~26.000; CLMM swap ~41.000; CLMM swap_v2 ~48.000 (43.838–52.887), her tick geçişi ile yükselen.Bu sayfanın önceki bir revizyonu bir proxy-swap CPI için ~47.700 CU bildirmiştir. Bu rakam tüm işlem (computeUnitsConsumed), çağıran programını, CPI çerçevesini ve herhangi bir ATA kurulumunu içerir — çağrılan tarafın maliyeti değil. Her ikisi de yararlıdır, ancak aynı sayı değildir, bu nedenle benzer şeyleri karşılaştırın. Kendi işleminizi ölçün, belgelendirmeden kopyalanan bir sayıya göre bütçe yapmayın, çünkü varsayılan 200k CU sınırı sessizce tükenecek ve program yükseltildiğinde talimat başına maliyetler değişir.
CLMM ve LaunchLab CPI’leri daha pahalıdır (CLMM özellikle remaining_accounts aracılığıyla ek tick dizileri yürür, dizi başına CU ekler), ancak yalnızca yukarıdaki CPMM rakamı ölçülen bir değerdir. Her zaman belgelendirmeden kopyalanan bir sayı yerine kendi ölçümünüzden boyutlandırılmış açık bir ComputeBudgetProgram::set_compute_unit_limit(...) talimatı ayarlayın, çünkü varsayılan 200k CU sınırı sessizce tükenecek ve program yükseltildiğinde talimat başına maliyetler değişir.

AMM v4: manuel Talimat oluşturma

AMM v4 Anchor’dan öncedir ve CPI sandığı yoktur, bu nedenle bu belgedeki tek program genel deseni izlemez. Instruction’ı elle oluşturun:
Tam hesap listesi için products/amm-v4/code-demos bölümüne bakınız.

Farm v6

Entegrasyonunuz için bir seçenek ise TS SDK’yı kullanın. raydium.farm.deposit(...) (products/farm-staking/code-demos bölümüne bakınız) gerçek demolar tarafından uygulanır ve bir Rust Anchor sandığının bu program için var olup olmadığına bağlı değildir.
Farm v6 Anchor CPI yolu sunmaz. crates.io’da raydium_farm_v6 sandığı yok, genel kaynak deposu yok ve zincir üstü IDL yok — program ne eski anchor:idl hesabına ne de Program Meta veri programına giriş (sdk-api/anchor-idl bölümüne bakınız). Bunu Anchor olmayan bir program olarak değerlendirin ve talimatlarını elle oluşturun, aşağıdaki gibi.
Yine de Rust CPI gerekiyorsa, örneğin başka bir zincir üstü programdan oluşturma, Instruction’ı elle oluşturun, AMM v4 ile aynı şekilde: gerçek hesap listesini ve talimat ayırıcılarını bağımsız olarak türetin, örneğin SDK’nın TypeScript düzenlerini çözerek (raydium-sdk-V2’nin farm modülü), gerçek işlemleri doğrudan çözerek (aşağıya bakınız) veya dağıtılan programı dökerek ve sökkerek. Sıfır argüman talimat şekli için bir hasat veya talep çağrısı ile tutarlı, gerçek hesap sırası sabit bir önek (token_program, çiftliğin durum hesabı, bir kasa yetkilisi PDA’sı, bu PDA’nın ilk ödül kasası, ikinci bir PDA, çağıran ve çağıran’ın bu ilk ödül madeni parasının ATA’sı), ardından remaining_accounts’da (reward_vault_i, user_reward_ata_i) çiftleri ilk sonrası her ödül akışı için. Eşleştirme kuralı gerçektir, ancak yalnızca ikinci ödül akışında başlar: ilk akışın kasası ve ATA’sı sabit hesaplar, birbirine bitişik değil ve remaining_accounts’ın parçası değildir.

CPI akışını test etme

Yerel geliştirme, Raydium programlarının test doğrulayıcınızda mevcut olmasını gerektirir. Üç seçenek:
  1. Program klonu ile anchor test. Dağıtılan mainnet bayt kodunu yerel doğrulayıcınıza çeker; aşağıdaki Programları yerel doğrulayıcıya klonlama bölümüne bakınız Anchor.toml yapılandırması ve havuz oluşturma testlerini özellikle engelleyen iki şey için.
  2. Devnet. Raydium çoğu programı devnet’e dağıtır, ancak mainnet’ten farklı program kimlikleri her program için (CPMM, CLMM, AMM v4, Stable AMM ve LaunchLab’ın her birinin farklı bir devnet adresi vardır; reference/program-addresses içindeki Devnet tablosuna bakınız). Farm v3/v5/v6 devnet’te güvenilir bir şekilde yayınlanmaz; canlı API (https://api-v3-devnet.raydium.io/main/info) mevcut resmi vardır. raydium_clmm’nin paketlenmiş DEVNET_PROGRAM_ID sabitlerini (veya diğer sandıklar için eşdeğeri) kullanırsanız, mainnet kimliğinin devnet’te de çalışacağını varsaymayın. Doğru adresleriniz olduğunda anchor test --provider.cluster devnet canlı koda vurmak için çalıştırın.
  3. Yerel dağıtım. Raydium depolarını klonlayın (CPMM, CLMM; LaunchLab’ın kaynağı bu seçenek için mevcut değildir) ve yerel doğrulayıcıya anchor deploy yapın. Test döngüsü ek yükü ekler ancak hata ayıklama için çağrılanı değiştirmenize izin verir.
anchor test ile çalıştırın veya program değiştirmeden test dosyasında yineleme yapıyorsanız önce anchor build ve ardından anchor test --skip-build yapın.

Programları yerel doğrulayıcıya klonlama

Bu, programın kaynağının genel olup olmadığına bakılmaksızın program kimliğine göre çalışır, bu nedenle LaunchLab kaynağı mevcut olmasa bile CPMM ve CLMM ile aynı şekilde klonlanır. reference/program-addresses buradaki her adres için gerçeğin kaynağıdır.
Programı klonlamak, testiniz ayrıca bir havuz oluşturuyorsa yeterli değildir (var olan bir havuza karşı swap yapmak yerine). CPMM’nin initialize talimatı amm_config ve create_pool_fee hesaplarını gerçek zincir üstü verilere karşı doğrular, bu nedenle bunları da klonlamanız gerekir veya initialize tamamen başarısız olur. CPMM özel olarak: istediğiniz ücret katmanı AmmConfig’ı klonlayın (adresini GET https://api-v3.raydium.io/main/cpmm-config’dan alın, dizin 0 %0,25 katmanıdır) ve ücret alıcı token hesabı, tam adrese göre doğrulanmıştır, anında oluşturulmaz, bu nedenle zaten var olmalıdır.
Testinizin yeni oluşturduğu bir havuz aynı anda değiştirilemez. CPMM’nin initialize sessizce istenen open_time’ı kesin olarak gelecekte olmayan bir şeyle geçersiz kılar (if open_time <= block_timestamp { open_time = block_timestamp + 1 }), bu nedenle startTime: 0 (“hemen aç,” SDK başına) bile havuz swapları kabul etmeden önce gerçek ≥1 saniye boşluğu bırakır. Bir havuz oluşturan ve sıfır gecikmeli karşı swap yapan bir test NotApproved ile çarpacaktır. Havuz oluşturma ve ilk swap arasında kısa bir await (1–2s) yeterlidir. Bu teste özgüdür; bir insan iki ayrı manuel komut çalıştırırken normalde fark etmez, çünkü yazma ve işlem başlatma zaten bir saniyeden fazla yer kaplar.

İşaretçiler

Kaynaklar: