Paylaşılan altyapı

Her Raydium programının paylaştığı ilkeleri — yetki PDA’ları, AmmConfig hesapları, protokol/fon/yaratıcı ücret bölüşümü, gözlem hesapları ve genel REST API yüzeyi — bir kez tanımlanarak ürün başına bölümlerin başvurabileceği kaynaklar.

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 →

Raydium’un ürün programları bağımsız kod tabanlarıdır, ancak paylaşılan bir kural seti üzerinden tasarlanmıştır. Bu sayfa, bu kuralların kurallı başvuru kaynağıdır. Ürün başına bölümler, kuralların hesaplarında uygulanma biçimini açıklar; bu sayfa, kuralların kendilerini açıklar.

​

Burada “paylaşılan” ne anlama geliyor?

Kod tabanında üç tür paylaşım vardır:

• Kural paylaşımı. Her program aynı PDA-türetme deseni, aynı ücret-bölüşüm şeklini ve aynı gözlem-hesabı fikrini kullanır — ancak her biri bunu kendi programında kendi tohumlariyla uygular.
• Hesap paylaşımı. Birkaç hesap birçok pool arasında tam olarak aynı kayıttır (CPMM’deki global yetki PDA’sı, AmmConfig hesapları).
• Zincir dışı paylaşım. Bir REST API ve bir TypeScript SDK’sı dört programın tümünü yönetir. Entegratörler, hangi programa çağrı yapacaklarından bağımsız olarak, bir HTTP ana bilgisayarı ve bir NPM paketi ile etkileşime girerler.

Aşağıdaki beş ilkel, program sınırlarını aşan her şeyi kapsar.

​

1. Yetki PDA’ları

Her Raydium programının, token kasalarını sahibi olan tam olarak bir PDA’sı vardır. Kullanıcılar kasa yetki sahibi olarak direkt tutuş alamazlar — yetki PDA’sı, fonları çıkaran tek imzalayan ve yalnızca geçerli bir program talimatı bunu söylerken imzalar.

Desen ürünler genelinde aynıdır; tohumlar farklılık gösterir:

Program	Yetki PDA tohumları	Notlar
AMM v4	[poolId]	Pool başına yetki. v4’ün pool başına tasarımıyla aynı şekil.
CPMM	[b"vault_and_lp_mint_auth_seed"]	Tüm CPMM havuzları tarafından paylaşılan tek PDA. Pool-spesifik tohum yok.
CLMM	[b"pool_vault_and_lp_mint_auth_seed"]	Tüm CLMM havuzları arasında paylaşılan tek PDA.
Farm v3 / v5 / v6	[farmId]	Farm başına. PDA, o çiftlik için bahis + ödül kasalarına sahiptir.
LaunchLab	[b"vault_auth", launchId]	Launch başına. Mezuniyet öncesi temel + teklif kasalarına sahiptir.

Bunun birkaç sonucu vardır:

• CPMM ve CLMM için, yetki PDA’sı global bir hesaptır — o tür her havuz bunu kullanır. CPMM’ye CPI yapıyorsanız, bunu pool başına değil, bir kez gereklidir.
• Pool başına / farm başına yetki için, PDA’yı pool/farm ID’sinden türetirsiniz. SDK bunu getPoolKeys / getFarmKeys’te yapar; doğrudan entegre oluyorsanız, findProgramAddressSync ile türetirsiniz.
• Kasa sahipliği değiştirilemez. Bir token hesabı yetki PDA’sı olarak sahip olacak şekilde oluşturulduktan sonra, yalnızca bu PDA — program tarafından çağrılan — çıkış yapabilir. Yönetici geçersiz kılması yoktur.

Program başına kesin tohumlar ve ATA düzenleri için bkz. products/cpmm/accounts, products/clmm/accounts, products/amm-v4/accounts, products/farm-staking/accounts, products/launchlab/accounts.

​

2. Yönetici ve yapılandırma hesapları

CPMM ve CLMM, AmmConfig adlı bir yapılandırma-hesabı deseni paylaşır: bir u16 ile indekslenen küçük bir global hesap, tüm bir ücret seviyesi’ne uygulanan ücret oranlarını ve yönetici hedeflerini tutar. Havuzlar oluşturma sırasında bir yapılandırmaya bağlanır ve hiçbir zaman yeniden bağlanmaz.

// CPMM AmmConfig (kısaltılmış — CLMM sürümü yapısal olarak benzerdir)
pub struct AmmConfig {
    pub bump: u8,
    pub disable_create_pool: bool,        // bu seviyede yeni pool oluşturmayı kapat
    pub index: u16,                       // seviye indeksi
    pub trade_fee_rate: u64,              // ticarete giden ücretin kesri
    pub protocol_fee_rate: u64,           // ticaret ücretinin protokole giden kesri
    pub fund_fee_rate: u64,               // ticaret ücretinin fona giden kesri
    pub create_pool_fee: u64,             // bir kez pool başına oluşturma ücreti
    pub protocol_owner: Pubkey,           // CollectProtocolFee için imzalayan
    pub fund_owner: Pubkey,               // CollectFundFee için imzalayan
    pub padding: [u64; 16],
}

Yol kuralları:

• Ücret seviyeleri globaldir. Bir havuz “bu %0,25 havuzdur” dediğinde, oluşturma sırasında trade_fee_rate’i %0,25 olan AmmConfig’e bağlandığı anlamına gelir. Pool başına oran geçersiz kılması yoktur.
• Bir yapılandırma değişebilir ama havuzlar bunu takip etmez. Yapılandırma yetkilisi bir AmmConfig’i düzenlerse, o yapılandırmaya bağlı her mevcut havuz hemen yeni oranı alır. Bu bir hata değil, bir özelliktir; bu şekilde protokol düzeyindeki ekonomik değişiklikler pool başına göçler olmadan yayılır.
• disable_create_pool eskiye alma kaldıracıdır. Bir ücret seviyesi sona erdirildiğinde, protokol multisig bu bayrağı ayarlar — mevcut havuzlar çalışmaya devam eder ancak hiçbir yeni havuz seviyeyi seçemez.
• protocol_owner / fund_owner ücret toplama çağrıları için imzalayanlardır. Bunları bir multisig’e ayarlamak, ücret çekmesini kilitler. Ücreti kendileri için hedef adresler DEĞİLLERDİR; bu, aynı hesapta protocol_fee_destination / fund_fee_destination’dur.

AMM v4’ün AmmConfig’i yoktur — ücret parametreleri oluşturma sırasında pool başına, sabit kodlanmıştır. Farm ve LaunchLab’ın kendi eşdeğerleri vardır (FarmConfig, LaunchConfig) ilgili bölümlerinde ele alınmıştır.

Kim neyi değiştirebileceğinin tam tablosu security/admin-and-multisig’dedir. Mevcut kullanıcı karşılı ücret bölüşümleri ray/protocol-fees’dedir.

​

3. Protokol / fon / yaratıcı ücret bölüşümü

Her CPMM ve CLMM swap ücreti yolda dört hedefe kadar bölünür:

                         toplam swap ücreti
                              │
              ┌───────────────┼───────────────┬──────────────┐
              ▼               ▼               ▼              ▼
        LP pool tarafı     Protokol        Fon          Yaratıcı
        (k'yi yükseltir)   hazinesi      multisig     (LaunchLab havuzları)

Mekanik olarak:

1. Ticaret ücreti havuza tahakkuk eder. Ücret swap’ın giriş tarafından kaldırılır ve ücret sonrası miktar, sabit-çarpım matematiğinin gördüğü şeydir. Bu, “LP ücret kazanır” anlamına gelen şeydir — k artar ve dolayısıyla ima edilen LP-token başına değeri de artar.
2. Protokol/fon/yaratıcı kısımları o LP-tarafı tahakkuktan pool başına sayaç hesaplarına düşülür. Birisi CollectProtocolFee / CollectFundFee / CollectCreatorFee çağırana kadar havuz durumunda (protocol_fees_token{0,1}, fund_fees_token{0,1}, vb.) oturur. Swap perspektifinden, bunlar “hâla havuzda”.
3. Toplama onları çıkarır. İlgili imzalayan (AmmConfig’deki protocol_owner / fund_owner anahtarları veya LaunchLab havuzları için launch yaratıcısı) toplama talimatını çağırır ve program havuz kasasından bir hedef ATA’ya aktarır.

Birkaç önemli gözlem:

• Bölüşüm yüzdeleri ticaretten değil, ticaret ücretinden alınır. %0,25 ticaret ücreti ve %12 protokol payı, protokolün ticaretten %0,25 × %12 = %0,03%’ünü alması anlamına gelir — ticaretten %12’si değil.
• Yaratıcı ücretleri yalnızca LaunchLab-mezun havuzlarında mevcuttur. Standart CPMM/CLMM havuzları 3 yönlü bölüşüme sahiptir (LP / protokol / fon). LaunchLab, token’ı başlatan kişiye yönlendirilen dördüncü bir yuva ekler, Initialize’da yapılandırılır ve değişmezdir.
• AMM v4 yalnızca iki yolu böler, pool başına sabit kodlanmıştır: LP ve protokol. Fon yuvası yok, yaratıcı yuvası yok.
• Fon vs protokol — her ikisi de protokol-hazine hedefleridir, ancak farklı imzalayanlara ve farklı amaçlara sahiptir. protokol tarihsel olarak işlemleri finanse eder; fon daha uzun vadeli hazinedir. İkisi arasındaki bölüşüm kendi başına ayarlanabilirdir.

Spesifik oranlar reference/fee-comparison ve ray/protocol-fees’dedir.

​

4. Gözlem hesapları (TWAP halka arabelleği)

Hem CPMM hem de CLMM, pool başına gözlem hesabı tutar — diğer sözleşmelerin manipülasyona dirençli bir TWAP türetmek için kullanabileceği (timestamp, cumulative_price) örneklerinin sabit boyutlu halka arabelleği.

// CPMM ObservationState (kısaltılmış)
pub struct ObservationState {
    pub initialized: bool,
    pub observation_index: u16,            // üzerine yazacak sonraki yuva
    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,  // init'ten beri (fiyat × dt) toplamı
    pub cumulative_token_1_price_x32: u128,
}

Nasıl çalışır:

• Her swap update_observation çağırır. Program mevcut fiyatı okur, son gözlemden beri geçen saniye ile çarpar ve kümülatif sayaca ekler. Yeni giriş en eski yuvanın üzerine yazılır (halka-arabelleği stili).
• Bir pencere üzerinde TWAP = (cumul[end] − cumul[start]) / (timestamp[end] − timestamp[start]). Tüketiciler istenen pencereyi kapsayan iki gözlemi seçer ve bölerler.
• Raydium kendisi fiyatlandırma için TWAP’ı kullanmaz. AMM matematik spot rezervleri doğrudan okur. Gözlemler bir dışsallıktır — Raydium, onları yazmanın maliyetini öder, böylece diğer sözleşmeler okuyabilir.
• AMM v4’ün gözlem hesabı yoktur. ObservationState tasarımından daha eskidir; v4 TWAP’ı isteyen entegratörler, günlük geçmişten bir tane hesaplamalıdır.

Düzen ayrıntıları ve indeksleme matematiği products/cpmm/accounts ve products/clmm/accounts’tedir.

​

5. REST API + SDK + IDL

Zincir dışı yüzey, her ürün tarafından kullanılan tek bir triodur:

• REST API — https://api-v3.raydium.io. Tüm zincir üstü durumun ve bir fiyat motorunun yalnızca okunur indekslenmiş görünümü. Bir ana bilgisayar, bir şema.
• TypeScript SDK — NPM üzerinde @raydium-io/raydium-sdk-v2. Her program için işlemleri oluşturur ve imzalar. Teklifler/meta veriler için API’ye, ön-imza durumu yenilemeleri için bir Solana RPC’sine konuşur.
• IDL kayıt defteri — Her yayınlanan program için Anchor IDL’leri raydium-idl repo’sunda yaşar (program başına bir JSON: CPMM, CLMM, LaunchLab). TypeScript SDK bu IDL’leri dahili olarak tüketir; aşağı akış Rust / Python istemcileri aynı dosyalardan yeniden oluşturur.

Aralarındaki sınır keskindir:

Parça	Okur	Yazar	Eski toleransı
REST API	İndeksleyici (zincir günlüklerini ayrıştırır)	— (entegratörler için salt okunur)	Birkaç saniye
SDK	API + RPC	İşlemleri oluşturur; yayınlamaz	Yok — imza öncesi durumu yeniden getir
IDL	Program kaynağı	—	Program yükseltmesi başına sürümü

Yaygın bir hata, REST API çıktısını doğrudan bir işleme beslemektir. Yapmayın — ilgili pool/konum durumunu imzaladığınız yuvada bir Solana RPC’sinden yeniden getirin. SDK bunu birinci tarafa akışları için otomatik olarak yapar; SDK’yı atlarsanız bunu kendiniz yapmalısınız.

Tam başvuru sdk-api/’dedir, IDL yüzeyi spesifik olarak sdk-api/anchor-idl’dedir.

​

6. İndeksleyiciler ve fiyat beslemeleri

REST API, Raydium’un kendi indeksleyicisi tarafından beslenirse, Solana RPC’leri filosundan program günlüklerine abone olur ve denormalize kayıtları bir SQL depoya yazar. Entegratörler için iki sonuç:

• İndeksleyici, program dışı durumu “bilen” tek şeydir. Bir CPMM havuzunu CLMM karşılığına eşlemek, program sürümleri arasında 24s-hacim sayısı hesaplamak, bir LP mintine ilişkili bir çiftliği almak — bunların tümü indeksleyici işidir. Programların kendileri bunu yapmaz.
• İndeksleyici kapalı kalma süresi, API kapalı kalma süresidir. API eski veya boş veri döndürürse, indeksleyici şüphelidir. Zincir üstü durum etkilenmez; kendi RPC’si ve SDK’sı olan entegratörler işlem yapmaya devam edebilir.

Fiyat beslemeleri ayrı bir konudur. API, çoğu havuz yanıtında bir priceUsd alanı yayınlar; bu, indeksleyicinin havuz rezervleri görünümü ve alıntı yapılan referans fiyat (ortak pivot olarak USDC havuzları) anlık görüntüsünden zincir dışı olarak hesaplanır. UI için yeterlidir; zincir üstü oracle olarak kullanmak güvenli değildir. Bunun için gözlem TWAP’ını kullanın.

​

Paylaşılmayan nedir

Yeni okuyucular genellikle daha fazla paylaşım varsaydığı için açıkça listeleme değeri vardır:

• Programlar birbirini çağırmaz. CPMM swap, hiçbir zaman CLMM veya AMM v4’e CPI yapmaz. Birden fazla AMM’yi birleştiren tek program, AMM Yönlendirmesi programıdır — ve bu, kendisi de ince, her AMM’ye sırasıyla CPI’ları yayınlamaktır.
• Programlar arasında ortak yükseltme yetki yoktur. Her zincir üstü programın kendi program-yükseltme anahtarı vardır (3/4 multisig artı 24s zaman kilidi). Bağlantılı değildir.
• Çiftlikler ve AMM’ler arasında paylaşılan durum yoktur. Bir çiftlik, yükselttiği LP’nin CPMM havuzundan, CLMM-konum-NFT-mintinden veya ilgisiz SPL token’undan olduğunu bilmez. Çiftlik programı, bahis mintini opak olarak işler.
• Oracle bağımlılığı yoktur. Fiyatlandırma, zincir üstü rezervlerdir. Pyth/Switchboard geri planı yoktur; AMM temizlemeden önce oracle’ı kontrol etmez.

​

İşaretçiler

• protocol-overview/architecture — bu parçaların nasıl oluşturulduğunu gösteren kurallı diyagram.
• protocol-overview/versions-and-migration — kurallar program sürümleri arasında nasıl gelişti.
• security/admin-and-multisig — AmmConfig’lerin arkasındaki anahtarları kontrol eden kim.
• reference/fee-comparison — ürün başına ücret-oran matrisi.
• reference/program-addresses — kurallı program ID’leri.

Kaynaklar:

• Raydium SDK v2 — PDA tohumları, hesap düzenleri ve IDL tanımlarının gerçeği kaynağı.
• Raydium IDL kayıt defteri — Anchor IDL’leri.
• Yukarıda satırda alıntı yapılan ürün başına hesap sayfaları.