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 →
Her Raydium programının en az bir ayrıcalıklı rolü vardır — programı yükseltebilen, yeni konfigürasyonlar oluşturabilen veya protokol ücretlerini çekebilen bir anahtar. Bu rollerin yapabileceklerini en aza indirmek (ve bunları gecikmeli multisigların arkasına koymak) tehlikeye atılmış bir yöneticiye karşı birincil savunmadır. Bu sayfa rolleri ve bunların pratikte nasıl güvenli hale getirildiğini kataloglar.

Programa göre roller

AMM v4

CPMM

Yaratıcı ücreti toplama ayrıcalıklı bir rol tanıtmaz. CollectCreatorFeePermissionless herhangi bir ödeyiciyi kabul eder, alıcı sahibini PoolState.pool_creator ile sınırlandırır ve her iki hedefi de o yaratıcının kanonik ATA’larına sınırlandırır. Bir çağrıcı eksik ATA’ları finanse edebilir ve taramasını tetikleyebilir ancak ücretleri yeniden yönlendiremez.

CLMM

Bir çift için seed_index türetilmiş adresinde ek pool’lar oluşturmak (CreateCustomizablePoolV2) hiçbir rol gerektirmez. 2026-10-22 yükseltmesinden önce özel bir permission_pda_admin anahtarı tarafından verilen bir Permission PDA’sı gerektiriyordu; bu rol, Permission hesabı ve onun iki yönetici talimatı kaldırıldı. limit_order_admin kasıtlı olarak dar bir operasyonel roldür. Zincir dışı bir keeper’ın doldurulmuş emirleri taraması için vardır ve emrin sahibinin çevrimiçi olması gerekmez. Keeper anahtarı sıcaktır (keeper VM’de yaşar) ve yukarıdaki multisig’lerden bağımsız olarak döndürülür. Somut olarak, keeper yetkilisi şu şekilde sınırlandırılır:
  • SettleLimitOrder — doldurulmuş bir emrin çıktısını sahibinin ATA’sına emrin limit fiyatında itin.
  • CloseLimitOrder — tamamen kapatılmış bir emrin hesabını kira geri almak için kapat (kira emir sahibine gider).
OpenLimitOrder, IncreaseLimitOrder, DecreaseLimitOrder çağıramaz, herhangi bir pool alanını değiştiremez veya başka herhangi bir talimat için imza atamaz — bu kontroller zincir üzerinde talimatın Accounts yapısındaki seed ve has_one kısıtlamaları tarafından uygulanır. Tehlikeye atılmış bir keeper en kötü ihtimalle kullanılamaz (emirler sahibi bunları kendileri kapatana kadar park edilir) veya meşru doldurulabilir emirleri sıra dışında kapatabilir; kullanıcı fonlarını sahibinin zaten yetkilendirdiği yerden başka bir yere taşıyamaz.

Farm v6

Bireysel farm’ların protokol yöneticisi yoktur — her farm’ın oluşturucusu sadece kendi farm’ını kontrol eder ve oluşturucunun yetkileri sınırlıdır (kullanıcı stake’lerini ele geçiremez, staking mint’ini değiştiremez).

LaunchLab

Platform yöneticisi izin listesi kendi kendini kısıtlar: o platform altında launch’ların kullanabileceği GlobalConfig hesaplarını sınırlandırır. Diğer platform’lar veya mevcut launch fonları üzerinde yetki vermez. Kanonik devredilmiş yetki adresleri reference/program-addresses içinde yaşar.

Program yükseltme yetkilisi

Raydium’un programları standart Solana BPF Loader v3 yükseltme mekanizmasını kullanır. Tüm programlar için yükseltme yetkilisi 3/4 Squads multisig’idir. Neden 3/4: tek bir tehlikeye atılmanın yetersiz olması için yeterli imzacı; meşru bir yükseltmeyi koordine etmenin uygulanabilir olması için yeterince az. Dört yetki bağımsız, hava geçirmez soğuk cihaz imzacılarıdır ve çekirdek takım üyeleri tarafından tutulur. Sıralı imzalama aynı işlemde paralel onayları engeller; işlemler sabit bir son kullanma penceresine sahiptir. Multisig işlemleri Solana’nın STRIDE Programı (Asymmetric Research) ile ortaklık halinde periyodik olarak gözden geçirilir.

Yükseltme yetkilisini kaldırma

Raydium hiçbir programın yükseltme yetkilisini null olarak ayarlamadı. Protokol programların yükseltlenebilir olması gerektiği ilkesi altında çalışır (hataları yamalamak, Token-2022 gibi uzantılar eklemek, entegrasyon kaymasını düzeltmek). Ödünleşme: kullanıcılar 3/4 multisig’in sadece iyi incelenmiş yükseltmeleri dağıtacağına güvenir. Hiçbir Raydium programı şu anda değişmez bir alternatif olarak kabul edilecek kadar dondurulmuş veya yavaş hareket etmez — tarihsel olarak en statik olan AMM v4, kendisi 2026-07-22’de yeniden dağıtıldı. Her program için son dağıtılan slot herkese açıktır; herhangi birinin hareketsiz olduğunu varsaymadan önce okuyun: (Her programın ProgramData hesabından; solana program show <PROGRAM_ID> aynı slot’u bildirir.)

AmmConfig yetkilisi

Her yeni AmmConfig oluşturması izinlidir — 3/5 treasury multisig’i yeni ücret seviyeleri ve tick aralıklarını yetkilendirir. Mevcut pool’lar AmmConfig’lerini PDA’ya göre referans alır; pool’un ücret seviyesi AmmConfig’in söylediği şeydir. Yöneticiler mevcut bir AmmConfig’i değiştirebilir mi? Evet, teknik olarak. updateAmmConfig yönetici tarafından çağrılabilir. Pratikte, dağıtılan AmmConfig’lere yapılan değişiklikler kaçınılır çünkü bu config’i kullanan tüm pool’ların ekonomisini sessizce değiştirir. Protokol politikası herhangi bir değişiklik için yeni bir AmmConfig oluşturmak ve geçiş yapmaktır. Yöneticiler config aracılığıyla protokol ücretlerini çalabilir mi? Hayır — AmmConfig ücret parametrelerini içerir ancak protokol ücreti alıcısını değil; bu pool başına ayrı bir değişmez adrestir.

Protokol ücreti talebinde bulunma

Swap ücretlerinin bir kısmı (tipik olarak 25 bps swap ücretinin 3–12 bps’si, config’e bağlı olarak) bir protokol ücreti vault’unda birikir. Multisig bu birikmiş ücretleri çekebilir. Kullanıcılar bundan dolayı LP bakiyelerinin değiştiğini asla görmezler — bu protokolün önceden ayrılan payıdır, LP parası değildir.

Farm oluşturucu yetkilisi

Farm’lar v6 oluşturucuya şu yetkiyi verir:
  • Ödül vault’unu finanse et (daha fazla token ekle).
  • Zamanlamayı uzat (bitiş zamanını ileri itmek).
  • Bitiş zamanından sonra withdrawReward çağrısı yaparak kullanılmayan vault bakiyesini geri al.
Farm oluşturucuları yapamaz:
  • Stake edilmiş kullanıcı LP’sini çek.
  • Staking mint’ini değiştir.
  • Emisyon oranlarını geriye dönük olarak değiştir (sadece setRewards aracılığıyla ileri dönük).
  • Kullanıcı hasat’larını dondur.
Kötü niyetli bir farm oluşturucu en kötü ihtimalle vault’u yetersiz finanse edebilir, böylece farm kuruya gider; kullanıcıların ana stake’i her zaman güvenlidir.

Squads multisig konfigürasyonu

Raydium farklı risk yüzeyleri için iki ayrı Squads multisig’i işletir. Her ikisi de Squads Protocol UI aracılığıyla zincir üzerinde incelenebilir. Yükseltme multisig’inin operasyonel özellikleri:
  • Herhangi bir işlemde 24 saatlik timelock. Bugün onaylanan bir yükseltme en erken 24 saat sonra yürütülür ve kullanıcılara yanıt verme zamanı verir.
  • Hava geçirmez soğuk cihaz imzalama. Soğuk cihazların ağ kartları fiziksel olarak çıkarılmıştır; sadece bir donanım cüzdanına bağlanırlar ve işlem verilerini ayrı bir sıcak cihazdan QR kodu aracılığıyla okurlar.
  • Sıralı imzalama. Sadece bir soğuk cihaz bir işlemi oluşturup imzaladıktan sonra sonraki soğuk cihaz imzalama işlemine başlayabilir — aynı işlemde çakışan veya paralel imzaları engeller.
  • İşlem son kullanma tarihi. Her işlem sabit bir son kullanma penceresine sahiptir, bu nedenle eski işlemler otomatik olarak geçersiz hale gelir.
  • TOTP + fiziksel anahtar uygulaması işlem başlatma ve zincir üzerinde yayın için kullanılan sıcak cihazlarda.
  • Genel işlem kuyruğu. Herkes Squads UI’de bekleyen yükseltmeleri izleyebilir.
Treasury multisig’inin timelock’u yoktur — kapsamı daha dar ve rutin işlemler (AmmConfig’ler oluşturma, ücretleri tarama) aynı gün içinde yapılması gerekir. Treasury multisig ayrıca yukarıdaki programa göre tablolarda listelenen sınırlı program yöneticisi yetkilisini tutar; bu geçici bir düzenlemedir ve projenin güvenlik ortakları ile periyodik olarak gözden geçirilir.

Zincir üzerinde yetkiyi doğrulama

Bir programın mevcut yükseltme yetkisini doğrulamanın en basit yolu:
Çıktı şunları içerir:
Authority beklenen Squads multisig adresi değilse, bir sorun vardır. Raydium, beklenen yetki adreslerini reference/program-addresses sayfasında yayınlar. AmmConfig / pool yönetici rolleri için zincir üzerindeki hesabı getirin ve çözün:
AmmConfig bir admin alanına sahip değildir — program yöneticisi programa derlenmiş bir pubkey’dir (crate::admin::ID), ve yapılandırma başına operasyonel yetkililer protocolOwner / fundOwner olur. BPF yükseltme yetkisi ayrı, yükleyici düzeyinde bir konudur; solana program show ile okuyun.

Geçmiş yetki değişiklikleri

Kullanıcı tarafı hususlar

Bir kullanıcı/LP/entegratör olarak ne yapmalısınız?
  1. Büyük tahsislerden önce yükseltme yetkisini kontrol edin. Belgelenen multisig ile eşleştiğini doğrulayın.
  2. Multisig aktivitesini izleyin. Squads UI beklemede olan işlemleri gösterir; planlanan bir yükseltme size değişiklikle ayrılmak için 24 saat verir.
  3. Zaman-kilit-farkında geri alma stratejileri. Otomatik bileşik faiz çalıştırıyorsanız, geri alma yolunuzun değiştirilmekte olan bir talimatı gerektirmediğinden emin olun.
  4. Program değişmezliğini varsaymayın. Her Raydium programı yükseltilebilir; buna göre planlayın.

Entegratörler için tuzaklar

1. Yetki adreslerini önbelleğe alma

Yükseltme yetkisini veya yönetici multisig adresini kodunuza sabit kodlarsanız ve daha sonra döndürülürse, doğrulamanız başarısız olur. reference/program-addresses sayfasından çalışma zamanında getirin veya periyodik olarak yenileyin.

2. AmmConfigs’in sabit olduğunu varsaymak

Herhangi bir zamanda yeni bir AmmConfig oluşturulabilir. Toplayıcınız/yönlendiricininiz tam yapılandırma listesini periyodik olarak yeniden getirmelidir (saatlik iyidir).

3. Farm-yaratıcı rahatsızlık vektörleri

Düşük itibar sahibi bir farm’a yatırım yapıyorsanız, yaratıcı farm’ı erken sonlandırabilir ve ödül kasasını geri talep edebilir (hiçbir kullanıcı henüz stake etmemişse). Kullanıcılar stake ettikten sonra, orantılı haklar program tarafından uygulanır; geri talep yalnızca mantıklı sondan sonra kalan kısmı alır.

İşaretçiler

Kaynaklar: