Paylaşılan altyapı

​

Burada “paylaşılan” ne anlama gelir

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

​

1. Yetki PDA’ları

• CPMM ve CLMM için yetki PDA’sı genel bir hesaptır — o türün her havuzu bunu kullanır. CPMM’ye CPI yapıyorsanız buna havuz başına değil bir kez ihtiyacınız vardır.
• Havuz başına / çiftlik başına yetkililer için PDA’yı havuz/çiftlik kimliğinden türetirsiniz. SDK bunu getPoolKeys / getFarmKeys içinde yapar; doğrudan entegre oluyorsanız findProgramAddressSync ile türetirsiniz.
• Kasa sahipliği değiştirilemez. Bir token hesabı yetki PDA’sı sahibi olarak oluşturulduktan sonra, yalnızca o PDA — program tarafından çağrılan — dışarı aktarabilir. Yönetici geçersiz kılması yoktur.

​

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

// 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 katmanda yeni havuz oluşturmayı engelle
    pub index: u16,                       // katman indeksi
    pub trade_fee_rate: u64,              // işlemin ücretlere giden kısmı
    pub protocol_fee_rate: u64,           // işlem ücretinin protokole giden kısmı
    pub fund_fee_rate: u64,               // işlem ücretinin fona giden kısmı
    pub create_pool_fee: u64,             // havuz başına bir kerelik oluşturma ücreti
    pub protocol_owner: Pubkey,           // CollectProtocolFee için imzalayıcı
    pub fund_owner: Pubkey,               // CollectFundFee için imzalayıcı
    pub padding: [u64; 16],
}

• Ücret katmanları globaldir. Bir havuz “bu 0,25% havuzudur” dediğinde, oluşturma sırasında trade_fee_rate’i 0,25% olan AmmConfig’e bağlandığı anlamına gelir. Havuz başına oran geçersiz kılması yoktur.
• Bir yapılandırma değiştirilebilir ancak havuzlar takip etmez. Yapılandırma yetkilisi bir AmmConfig’i düzenlediyse, o yapılandırmaya bağlı her mevcut havuz yeni oranı hemen alır. Bu bir hata değil, bir özelliktir; protokol düzeyinde ekonomik değişikliklerin havuz başına göçler olmadan nasıl yayıldığıdır.
• disable_create_pool kullanımdan kaldırma kaldıracıdır. Bir ücret katmanı sonlandırıldığında, protokol multisig bu bayrağı ayarlar — mevcut havuzlar çalışmaya devam eder ancak yeni havuzlar katmanı seçemez.
• protocol_owner / fund_owner ücret-toplama çağrıları için imzalayıcılardır. Bunları bir multisig’e ayarlamak ücret çekişini kapıya koymaktır. Bunlar ücretler için hedef adresler DEĞİLdir; bu aynı hesaptaki protocol_fee_destination / fund_fee_destination adresleridır.

​

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

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

1. İşlem ücreti havuza tahakkuk eder. Ücret swap’ın giriş tarafından çıkarılır ve ücret sonrası miktar sabit-ürün matematiğinin gördüğü şeydir. Bu “LP ücret kazanır” anlamına gelir — k yükselir ve dolayısıyla zımni LP token başına değer de yükselir.
2. Protokol/fon/yaratıcı kısımları bu LP tarafı tahakkuktan havuz başına sayaç hesaplarına düşülür. Bunlar havuz durumunda (protocol_fees_token{0,1}, fund_fees_token{0,1}, vb.) oturur ve birisi ilgili toplama talimatını çağırana kadar. Bunlar havuzun kasalarından o zamana kadar çıkmaz; swap’ın perspektifinden hala “havuzda”dırlar.
3. Toplama bunları dışarı çıkarır. Protokol ve fon yolları AmmConfig’den ilgili protocol_owner / fund_owner imzalayıcısını gerektirir. CPMM yaratıcı ücretleri yaratıcı tarafından imzalanan CollectCreatorFee yolunu veya herhangi bir ödeyicinin tetikleyebileceği ancak hedefleri yaratıcının kanonik ATA’larına sabitleyen CollectCreatorFeePermissionless’i kullanır.

• Bölünme yüzdeleri işlem ücretinin dışındadır, işlemin dışında değil. 0,25% işlem ücreti ve 12% protokol payı ile protokol 0,25% × 12% = 0,03% işlemin — işlemin 12%‘si değil.
• Yaratıcı ücretleri yalnızca LaunchLab-mezun havuzlarında mevcuttur. Standart CPMM/CLMM havuzları 3 yönlü bölünmeye (LP / protokol / fon) sahiptir. LaunchLab, Initialize’da yapılandırılan ve değişmez olan tokeni başlatana yönlendirilen dördüncü bir yuva ekler.
• AMM v4 yalnızca iki yönlü bölünür, havuz başına sabit kodlanmış: LP ve protokol. Fon yuvası yok, yaratıcı yuvası yok.
• Fon vs protokol — her ikisi de protokol-hazinesi hedefleridir, ancak farklı imzalayıcılara ve farklı amaçlanan kullanımlara sahiptirler. protokol tarihsel olarak operasyonları finanse eder; fon daha uzun vadeli hazinedir. İkisi arasındaki bölünme kendisi ayarlanabilirdir.

​

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

// CPMM ObservationState (kısaltılmış)
pub struct ObservationState {
    pub initialized: bool,
    pub observation_index: u16,            // üzerine yazılacak 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,  // başlangıçtan bu yana (fiyat × dt) toplamı
    pub cumulative_token_1_price_x32: u128,
}

• Her swap update_observation çağırır. Program mevcut fiyatı okur, önceki gözlemden bu yana geçen saniyelerle çarpar ve bunu kümülatif sayaca ekler. Yeni giriş en eski yuvayı üzerine yazar (halka-arabelleği stili).
• Bir pencere üzerinde TWAP = (cumul[end] − cumul[start]) / (timestamp[end] − timestamp[start]). Tüketiciler istenen pencereyi parantez içine alan iki gözlem seçer ve böler.
• Raydium kendisi fiyatlandırma için TWAP kullanmaz. AMM matematik spot rezervleri doğrudan okur. Gözlemler bir dışsallıktır — Raydium bunları 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 log geçmişinden zincir dışında bir tane hesaplamak zorundadır.

​

5. REST API + SDK + IDL

• REST API — https://api-v3.raydium.io. Tüm zincir üstü durumun çoğunlukla okunan indekslenmiş görünümü artı bir alıntı motoru. Bir ana bilgisayar, bir şema.
• TypeScript SDK — NPM’de @raydium-io/raydium-sdk-v2. Her program için işlemleri oluşturur ve imzalar. Alıntılar/meta veriler için API ile konuşur, imza öncesi durum yenilemesi için Solana RPC ile konuşur.
• IDL kayıt defteri — Her yayınlanan program için Anchor IDL’leri raydium-idl deposunda 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.

​

6. İndeksleyiciler ve fiyat beslemeleri

• İndeksleyici “program arası durumu bilen” tek şeydir. Bir CPMM havuzunu CLMM muadili ile eşleştirmek, 24s-hacim numarasını program sürümleri arasında hesaplamak, bir LP mint ile 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.

​

Paylaşılmayan şey

• Programlar birbirini çağırmaz. Bir CPMM swap asla CLMM veya AMM v4’e CPI yapmaz. Birden fazla AMM’yi oluşturan tek program AMM Yönlendirme programıdır — ve o da kendisi incedir, sadece her AMM’ye sırayla CPI’lar yayınlar.
• Programlar arasında paylaşılan yükseltme yetkilisi yoktur. Her zincir üstü programın kendi program-yükseltme anahtarı vardır (3/4 multisig artı 24s zaman kilidi). Bunlar bağlantılı değildir.
• Çiftlikler ve AMM’ler arasında paylaşılan durum yoktur. Bir çiftlik bahis yaptığı LP’nin CPMM havuzundan, CLMM-konum-NFT-mint’inden veya ilgisiz SPL token’ından olup olmadığını bilmez. Çiftlik programı bahis mint’ini opak olarak ele alır.
• Oracle bağımlılığı yoktur. Fiyatlandırma zincir üstü rezervlerdir. Pyth/Switchboard geri dönüşü yoktur; AMM temizlemeden önce bir oracle’ı kontrol etmez.

​

İşaretçiler

• protocol-overview/architecture — bu parçaların nasıl oluşturulduğunu gösteren kanonik diyagram.
• protocol-overview/versions-and-migration — kurallar program sürümleri arasında nasıl gelişti.
• security/admin-and-multisig — AmmConfigs’in arkasındaki anahtarları kimin kontrol ettiği.
• reference/fee-comparison — ürün başına ücret-oranı matrisi.
• reference/program-addresses — kanonik program kimlikleri.

• Raydium SDK v2 — PDA tohumları, hesap düzenleri ve IDL tanımları için gerçeğin kaynağı.
• Raydium IDL kayıt defteri — Anchor IDL’leri.
• Yukarıda satır içinde alıntılanan ürüne özgü hesaplar sayfaları.