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 (“çapraz program çağırması”), 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ı crate’leriyle birlikte gelir; doğrulanmış alan adlarına sahip hesap yapıları ve cpi::<ix>() yardımcıları vardır. 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 hesap listesi ve farklılıklar için programınızın bölümüne atlayın. Farm v6 ve AMM v4 yeterince farklıdır ve bölümlerini bağımsız olarak okumayı gerektirir.

Cargo bağımlılıkları

Bağımlılık anahtarı hedef repo’nun [package] name ile tam olarak eşleşmelidir, tireleri de dahil olmak üzere. 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 üzerinde bir yukarı akış hesap düzeni değişikliği hiçbir uyarı olmadan derlemenizi bozacaktır. cpi özellik bayrağı, crate’lerin tam program yerine yalnızca CPI yüzeyine (hesap yapıları + çağırıcılar) derlenmesini sağlar, böylece ikili dosyanız küçük kalır. anchor-lang / anchor-spl hedef crate’in sabitlediği şeyle eşleşmelidir:
Her iki crate’i de aynı Anchor satırından alın. Her iki yükseltme dalı =1.0.2’yi sabitlediğinden, bir program tek bir crate’ten CPMM ve CLMM’ye CPI yapabilir. Satırları karıştırmak derlemeyi bozar: örneğin, raydium-cp-swap chore/upgrade-anchor üzerinde raydium-clmm master üzerinde. Cargo, bir ikili dosyaya Anchor’ın uyumsuz iki kopyasını bağlamak zorunda kalırdı. Karışık bir çiftte sıkışıp kaldıysanız, programı ikiye bölün veya yazılı CPI crate’ini bir taraf için bırakın ve bu talimatı elle kodlayın (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, çünkü dallar sonunda master’a taşınacaktır.
Anchor 1.0, her CPI çağrı sitesinin dokunduğu iki şeyi değiştirdi. Çalışan bir entegrasyonu 0.3x’ten 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’dir.
  • 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 crate’inden yeniden dışa aktarır. get_associated_token_address ve ID hala crate kökünde ulaşılabilir (spl_associated_token_account::{get_associated_token_address, ID}), ancak adres yardımcıları orada kullanımdan kaldırılmıştır — bunun yerine spl-associated-token-account-interface’e doğrudan bağlı olmayı ve spl_associated_token_account_interface::address::get_associated_token_address ve spl_associated_token_account_interface::program::ID’yi içe aktarmayı tercih edin. ::address ve ::program’ın arayüz crate’inin modülleri olduğunu unutmayın; 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’a bakınız (AMM v4, CPMM ve CLMM’yi kapsar). En yeni dalı anchor-0.31.0’dir — henüz Anchor 1.x dalı yoktur, bu nedenle bu repo’yu 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 olup, alan düzeyinde doğrulayıcılar vardır; 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ı konuma göre değil, ada göre adresler:
Raydium tarafı hesaplarının çoğu UncheckedAccount’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’ın kendisidir: çağrılan program yerine çağrılan program olup, 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 mint’in de klasik SPL Token olduğunu varsayar; her iki taraf da Token-2022 mint 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çin.

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

Anchor her talimat için bir yardımcı oluşturur, bir CPI hesapları yapısı (cpi::accounts::Swap, aşağıda CpmmSwap olarak takma ad) ile birlikte. 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 sabitleniş ve tam olarak eşleşmek zorundadır:
cpi::swap_base_input IDL’den oluşturulur; argüman listesi Anchor talimatının argüman listesini yansıtır. Onaylanmış her Anchor tabanlı Raydium programı (CPMM, CLMM, LaunchLab) cpi::<ix>() yardımcılarını aynı şekilde oluşturur, işlev adı snake_case’deki talimat adıyla eşleşir. Bunun Farm v6’ya kadar uzanıp uzanmadığı onaylanmamıştır; bölümüne bakınız.

İmzalayan tohumlar (PDA imzalı CPI)

Programınız bir PDA adına CPI’yi imzaladığında (vault’lar, 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 alır, sabit hesaplardan sonra eklenen değişken uzunlukta bir liste. Anchor’ın CPI yardımcıları kalan hesapları tür kontrol etmez; bunları .with_remaining_accounts(...) aracılığıyla geçin:
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 Farm v6’da ne gösterdiğini görmek için.

Deseni uygulama: CLMM

SwapV2 yukarıdaki genel deseni izler, farklı bir hesap listesi ve tick dizileri için kalan hesaplar gereksinimi ile. Crate’in #[program] modülü raydium_clmm olarak adlandırılmıştır, bu da 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, geçerli havuz durumuna karşı bir alıntı aracılığıyla hesaplayın; dizileri aşan bir swap TickArrayNotFound ile geri döner (products/clmm/instructions’a tam hesap tablosu ve hata listesi için bakınız). Bunları fiyat yürüyüşü yönünde geçin: 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 repo’sunda. Bu IDL’nin iç meta veri tanımlayıcısı raydium_launchpad’tır, ürün adı değil, temel programın teknik adıdır. CPMM ve CLMM’den farklı olarak, programın kendi kaynağı genel olarak kullanılamaz (reference/program-addresses’e bakınız). Cargo’ya işaret edecek git = "..." bağımlılığı yoktur ve gerçek bir crate’in Rust use yolunun ne olacağını doğrulamak için kaynak yoktur. Yayınlanan IDL’den Anchor’ın declare_program! makrosu kullanarak bağlamalar oluşturun. IDL JSON’unu crate’inize idls/raydium_launchpad.json olarak kaydedin (Cargo CARGO_MANIFEST_DIR’e göre bir idls/ dizini arar), sonra declare_program!(raydium_launchpad); raydium_launchpad::cpi::accounts::<Ix> yapılarını ve cpi::<ix>() işlevlerini doğrudan IDL’den oluşturur, program kaynağı gerekli değildir. Oluşturulan hesapları yapısı adı her zaman PascalCase’deki 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 hesapları listeniz her ikisi için hazırlanmalı veya önce PoolState’den migrate_type’ı okumalı ve dallanmalısınız.

Hata yayılması

Her Anchor tabanlı Raydium programı kendi hata enum’ını döndürür; Anchor bunları sarmaladığından, ç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ın kendi CU tüketimi sizinkinin üzerine 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ında 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ükseliyor.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ın kendi programını, CPI çerçevesini ve herhangi bir ATA kurulumunu içerir — çağrılanın maliyeti değil. Her ikisi de yararlıdır, ancak aynı sayı değildir, bu nedenle benzer şeyleri karşılaştırın. Belgelendirmeden kopyalanan bir sayı yerine kendi işleminizi ölçün.
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 kendi ölçümünüzden boyutlandırılmış açık bir ComputeBudgetProgram::set_compute_unit_limit(...) talimatı ayarlayın, belgelendirmeden kopyalanan bir sayı değil, çünkü varsayılan 200k CU sınırı sessizce tükenecek ve program yükseltmeleri sırasında talimat başına maliyetler değişecektir.

AMM v4: manuel Talimat oluşturma

AMM v4 Anchor’dan öncedir ve CPI crate’i yoktur, bu nedenle bu belgedeki tek program genel deseni izlemez. Instruction’ı elle oluşturun:
Tam hesap listesi için products/amm-v4/code-demos’a 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’a bakınız) gerçek demolar tarafından uygulanır ve bir Rust Anchor crate’inin bu program için var olup olmadığına bağlı değildir.
Farm v6 Anchor CPI yolu sunmaz. crates.io’da raydium_farm_v6 crate’i yoktur, genel kaynak deposu yoktur ve zincir üstü IDL yoktur — program ne eski bir anchor:idl hesabına ne de Program Meta veri programına bir girişe sahiptir (sdk-api/anchor-idl’a 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 yapıyorsanız, 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 disassemble ederek. 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, farm’ın durum hesabı, bir vault yetkilisi PDA’sı, bu PDA’nın ilk ödül vault’u, ikinci bir PDA, çağıran ve çağıranın bu ilk ödül mint’i için ATA’sı), ardından remaining_accounts’ta ilk akıştan sonra her ödül akışı için (reward_vault_i, user_reward_ata_i) çiftleri. Eşleştirme kuralı gerçektir, ancak yalnızca ikinci ödül akışında başlar: ilk akışın vault’u ve ATA’sı sabit hesaplar, birbirine bitişik değil ve remaining_accounts’ın parçası değildir.

CPI akışını test etme

Yerel dev, Raydium programlarının test doğrulayıcınızda kullanılabilir olmasını gerektirir. Üç seçenek:
  1. Program klonu ile anchor test. Dağıtılan mainnet bayt kodunu yerel doğrulayıcınıza çeker; Anchor.toml yapılandırması için Yerel doğrulayıcıya programları klonlama’ya bakınız ve havuz oluşturma testlerini özellikle sıkıntıya sokan iki şey.
  2. Devnet. Raydium çoğu programı devnet’e dağıtır, ancak her program için mainnet’ten farklı program ID’leri (CPMM, CLMM, AMM v4, Stable AMM ve LaunchLab’ın her birinin farklı bir devnet adresi vardır; reference/program-addresses’deki 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) geçerli resmi vardır. raydium_clmm’nin paketlenmiş DEVNET_PROGRAM_ID sabitlerini (veya diğer crate’ler için eşdeğeri) kullanırsanız, mainnet ID’sinin devnet’te de çalışacağını varsaymayın. Doğru adresleriniz olduğunda anchor test --provider.cluster devnet ile canlı koda çalıştırın.
  3. Yerel dağıtım. Raydium repo’larını klonlayın (CPMM, CLMM; LaunchLab’ın kaynağı bu seçenek için kullanılamaz) 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 anchor build yapın ve programı değiştirmeden test dosyasında yineleme yapıyorsanız anchor test --skip-build yapın.

Yerel doğrulayıcıya programları klonlama

Bu, programın kaynağının genel olup olmadığına bakılmaksızın program ID’si tarafından çalışır, bu nedenle LaunchLab kaynağı kullanılamasa 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 klonlamalı veya initialize tamamen başarısız olur. CPMM özellikle: istediğiniz ücret katmanı AmmConfig’ını 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ını, tam adrese göre doğrulanmış, anında oluşturulmayan, bu nedenle zaten var olması gerekir.
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’ya göre) havuz swap’ları kabul etmeden önce gerçek ≥1 saniyelik bir boşluk bırakır. Bir havuz oluşturan ve sıfır gecikmeli karşı swap yapan bir test NotApproved’a çarpacaktır. Havuz oluşturma ve ilk swap arasında kısa bir await (1–2s) yeterlidir. Bu test’e ö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: