Documentation Index
Fetch the complete documentation index at: https://docs.raydium.io/llms.txt
Use this file to discover all available pages before exploring further.
Setiap program Raydium memiliki setidaknya satu peran istimewa — sebuah kunci yang dapat mengupgrade program, membuat config baru, atau menarik biaya protokol. Meminimalkan apa yang dapat dilakukan peran-peran ini (dan menempatkannya di balik multisig dengan delay) adalah pertahanan utama terhadap admin yang dikompromikan. Halaman ini mendokumentasikan peran-peran tersebut beserta cara pengamanannya dalam praktik.
Peran berdasarkan program
AMM v4
| Peran | Alamat otoritas | Yang dapat dilakukan |
|---|
| Upgrade program | Squads multisig (3/4) | Deploy bytecode program baru |
| Pool admin | Treasury multisig (3/5) | Mengaktifkan/menonaktifkan status pool, memperbarui biaya pada pool yang sudah ada |
CPMM
| Peran | Alamat otoritas | Yang dapat dilakukan |
|---|
| Upgrade program | Squads multisig (3/4) | Deploy bytecode program baru |
| AmmConfig admin | Treasury multisig (3/5) | Membuat AmmConfig baru (fee tier); mengaktifkan/menonaktifkan yang sudah ada |
| Penerima biaya buat pool | Treasury multisig (3/5) | Menerima biaya sekali bayar untuk pembuatan pool |
CLMM
| Peran | Alamat otoritas | Yang dapat dilakukan |
|---|
| Upgrade program | Squads multisig (3/4) | Deploy bytecode program baru |
| AmmConfig admin | Treasury multisig (3/5) | Membuat/memodifikasi AmmConfig |
| DynamicFeeConfig admin | Treasury multisig (3/5) | CreateDynamicFeeConfig / UpdateDynamicFeeConfig — mengkalibrasi tier biaya dinamis yang dapat dipilih oleh panggilan CreateCustomizablePool |
limit_order_admin (seluruh program) | Hot wallet operasional off-chain, bukan multisig | Menyelesaikan dan menutup limit order atas nama pemiliknya. Kunci keeper adalah konstanta seluruh program (nilai berbeda di mainnet vs devnet), diperiksa melalui signer == limit_order.owner || signer == limit_order_admin::ID pada SettleLimitOrder / CloseLimitOrder. Output selalu dikirim ke ATA pemilik asli; keeper tidak dapat mengarahkan ulang dana, memodifikasi order, atau membuka order baru. |
limit_order_admin adalah peran operasional yang sengaja dibatasi. Peran ini ada agar keeper off-chain dapat menyapu order yang sudah terisi tanpa mengharuskan pemilik order berada online. Kunci keeper bersifat hot (berada di VM keeper) dan dirotasi secara independen dari multisig di atas. Secara konkret, otoritas keeper dibatasi pada:
SettleLimitOrder — mengirim output terisi dari sebuah order ke ATA pemilik pada harga limit order.
CloseLimitOrder — menutup akun order yang sudah sepenuhnya diselesaikan untuk mengklaim kembali rent (rent dikembalikan ke pemilik order).
Keeper tidak dapat memanggil OpenLimitOrder, IncreaseLimitOrder, DecreaseLimitOrder, memutasi field pool apa pun, atau menandatangani instruksi lain — pemeriksaan tersebut diberlakukan on-chain oleh seed dan constraint has_one dalam struct Accounts instruksi. Keeper yang dikompromikan paling buruk hanya tidak tersedia (order tetap terparkir hingga pemilik menyelesaikannya sendiri) atau menyelesaikan/menutup order yang sah di luar urutan; keeper tidak dapat memindahkan dana pengguna ke mana pun selain yang sudah diotorisasi oleh pemilik.
Farm v6
| Peran | Alamat otoritas | Yang dapat dilakukan |
|---|
| Upgrade program | Squads multisig (3/4) | Deploy bytecode program baru |
| Pembuat farm (per farm) | Wallet pembuat farm | Mendanai reward vault, memperpanjang jadwal, mengklaim kembali reward yang tidak terpakai |
Farm individual tidak memiliki admin protokol — pembuat setiap farm hanya mengontrol farm miliknya sendiri, dan kewenangan pembuat dibatasi (tidak dapat menyita stake pengguna, tidak dapat mengubah staking mint).
LaunchLab
| Peran | Alamat otoritas | Yang dapat dilakukan |
|---|
| Upgrade program | Squads multisig (3/4) | Deploy bytecode program baru |
| Pembuat launch (per launch) | Wallet pembuat launch | Mengumpulkan biaya pembuat setelah graduasi; menarik sisa kurva yang tidak lulus graduasi |
Launch tidak memiliki admin protokol yang dapat mengubah kurva atau menyita dana yang terkumpul.
Otoritas upgrade program
Program-program Raydium menggunakan mekanisme upgrade BPF Loader v3 standar Solana. Otoritas upgrade untuk semua program adalah Squads multisig 3/4.
Mengapa 3/4: cukup banyak penanda tangan sehingga kompromi tunggal tidak mencukupi; cukup sedikit sehingga koordinasi upgrade yang sah tetap praktis. Keempat otoritas adalah penanda tangan perangkat cold yang air-gapped dan independen, dipegang oleh anggota inti tim. Penandatanganan sekuensial mencegah persetujuan paralel pada transaksi yang sama; transaksi membawa jendela kedaluwarsa tetap. Operasi multisig ditinjau secara berkala bekerja sama dengan Solana’s STRIDE Program (Asymmetric Research).
Menghapus otoritas upgrade
Raydium belum menetapkan otoritas upgrade program apa pun menjadi null. Protokol beroperasi dengan prinsip bahwa program perlu dapat diupgrade (untuk menambal bug, menambahkan ekstensi seperti Token-2022, memperbaiki pergeseran integrasi). Trade-off: pengguna mempercayai bahwa multisig 3/4 hanya akan mendeploy upgrade yang telah ditinjau dengan baik.
Bagi pengguna yang menginginkan alternatif yang tidak dapat diubah, program AMM v4 yang lebih lama telah stabil sejak audit terakhirnya; tanpa upgrade selama 18 bulan. Jalur kode tersebut secara efektif sudah beku meskipun otoritasnya masih ada.
Otoritas AmmConfig
Setiap pembuatan AmmConfig baru memerlukan izin — multisig treasury 3/5 mengotorisasi fee tier dan tick spacing baru. Pool yang sudah ada mereferensikan AmmConfig mereka melalui PDA; fee tier pool mengikuti apa yang tertulis di AmmConfig.
Bisakah admin mengubah AmmConfig yang sudah ada? Ya, secara teknis. updateAmmConfig dapat dipanggil oleh admin. Dalam praktiknya, modifikasi pada AmmConfig yang sudah dideploy dihindari karena hal itu mengubah ekonomi semua pool yang menggunakan config tersebut secara diam-diam. Kebijakan protokol adalah membuat AmmConfig baru untuk setiap perubahan dan melakukan migrasi.
Bisakah admin mencuri biaya protokol melalui config? Tidak — AmmConfig berisi parameter biaya tetapi bukan penerima biaya protokol; itu adalah alamat yang tidak dapat diubah per pool secara terpisah.
Klaim biaya protokol
Sebagian dari biaya swap (biasanya 3–12 bps dari biaya swap 25 bps, tergantung config) terakumulasi ke vault biaya protokol. Multisig dapat menarik biaya yang terakumulasi ini. Pengguna tidak pernah melihat saldo LP mereka berubah akibat hal ini — itu adalah bagian yang sudah dialokasikan sebelumnya untuk protokol, bukan uang LP.
Otoritas pembuat farm
Farm v6 memberikan pembuat kewenangan untuk:
- Mendanai reward vault (menambahkan lebih banyak token).
- Memperpanjang jadwal (mendorong waktu berakhir lebih lama).
- Memanggil
withdrawReward setelah waktu berakhir untuk mengklaim kembali saldo vault yang tidak terpakai.
Pembuat farm tidak dapat:
- Menarik LP yang distake oleh pengguna.
- Mengubah staking mint.
- Mengubah tingkat emisi secara retroaktif (hanya ke depan melalui
setRewards).
- Membekukan harvest pengguna.
Pembuat farm yang jahat paling buruk hanya dapat tidak mendanai vault sehingga farm kehabisan dana; stake pokok pengguna selalu aman.
Konfigurasi Squads multisig
Raydium mengoperasikan dua Squads multisig terpisah untuk permukaan risiko yang berbeda. Keduanya dapat diperiksa on-chain melalui UI Squads Protocol.
| Multisig | Ambang batas | Timelock | Cakupan |
|---|
| Upgrade program | 3/4 | 24 jam | Otoritas tunggal untuk mendeploy bytecode program baru untuk AMM v4, CPMM, CLMM, LaunchLab, Lock, AMM Routing, Stable Swap, dan program Farm/Staking lama. Lihat di app.squads.so/.../FytDr…ceZQK. |
| Treasury | 3/5 | tidak ada | Aset treasury, pendapatan protokol, pengeluaran operasional. Juga memegang otoritas admin program terbatas Raydium (membuat AmmConfig, menyapu biaya protokol, mengonfigurasi parameter pool) untuk saat ini. Lihat di v3.squads.so/dashboard/RVha…dHdtYz09. |
Properti operasional dari upgrade multisig:
- Timelock 24 jam pada setiap transaksi. Upgrade yang disetujui hari ini baru dapat dieksekusi paling cepat 24 jam kemudian, memberi pengguna waktu untuk merespons.
- Penandatanganan dengan perangkat cold yang air-gapped. Perangkat cold memiliki kartu jaringan yang dicabut secara fisik; mereka hanya terhubung ke hardware wallet dan membaca data transaksi melalui kode QR dari perangkat hot terpisah.
- Penandatanganan sekuensial. Hanya setelah satu perangkat cold menghasilkan dan menandatangani transaksi, perangkat cold berikutnya dapat memulai proses penandatanganannya — mencegah tanda tangan yang bertentangan atau paralel pada transaksi yang sama.
- Kedaluwarsa transaksi. Setiap transaksi membawa jendela kedaluwarsa tetap, sehingga transaksi yang kedaluwarsa otomatis tidak valid.
- TOTP + penegakan kunci fisik pada perangkat hot yang digunakan untuk inisiasi transaksi dan broadcast on-chain.
- Antrian transaksi publik. Siapa pun dapat memantau upgrade yang tertunda di UI Squads.
Treasury multisig tidak memiliki timelock — cakupannya lebih sempit dan operasi rutin (membuat AmmConfig, menyapu biaya) perlu diselesaikan pada hari yang sama. Treasury multisig juga memegang otoritas admin program terbatas yang tercantum dalam tabel per program di atas; ini adalah pengaturan sementara dan ditinjau secara berkala bersama mitra keamanan proyek.
Memverifikasi otoritas on-chain
Cara paling sederhana untuk memverifikasi otoritas upgrade program saat ini:
solana program show <PROGRAM_ID>
Output mencakup:
Program Id: CPMMoo8L3F4NbTegBCKVNunggL7H1Zpdmwpwh8KMoZ0F
Owner: BPFLoaderUpgradeab1e11111111111111111111111
ProgramData Address: <ProgramDataPDA>
Authority: <EXPECTED_MULTISIG_ADDRESS>
Last Deployed In Slot: <slot>
Data Length: <n> bytes
Jika Authority bukan alamat Squads multisig yang diharapkan, ada sesuatu yang salah. Raydium mempublikasikan alamat otoritas yang diharapkan di reference/program-addresses.
Untuk peran AmmConfig / pool admin, ambil akun on-chain dan decode:
const config = await raydium.cpmm.getAmmConfig(configPda);
console.log("AmmConfig admin:", config.admin.toBase58());
// Expected: 3/5 treasury multisig.
Riwayat perubahan otoritas
| Tanggal | Program | Perubahan |
|---|
| 2022-12 | AMM v4 | Otoritas upgrade dimigrasikan dari single-sig ke multisig 3/4 setelah insiden |
| 2023-02 | Semua program | Semua peran operasional disatukan di bawah treasury multisig 3/5 |
| 2023-11 | CLMM | Menambahkan multisig kedua untuk operasi reward saja guna mengurangi eksposur |
| 2024-05 | CPMM | Deploy awal dengan otoritas multisig dari hari pertama |
Pertimbangan dari sisi pengguna
Apa yang harus Anda lakukan sebagai pengguna/LP/integrator?
- Periksa otoritas upgrade sebelum alokasi besar. Konfirmasi bahwa alamat sesuai dengan multisig yang terdokumentasi.
- Pantau aktivitas multisig. Squads UI menampilkan transaksi yang tertunda; upgrade yang dijadwalkan memberi Anda 24 jam untuk menarik posisi jika Anda tidak setuju dengan perubahan tersebut.
- Strategi penebusan yang mempertimbangkan timelock. Jika Anda menjalankan auto-compounder, pastikan jalur keluar Anda tidak memerlukan instruksi yang sedang diubah.
- Jangan asumsikan program tidak dapat diubah. Setiap program Raydium dapat diupgrade; rencanakan untuk itu.
Jebakan bagi integrator
1. Men-cache alamat otoritas
Jika Anda meng-hardcode otoritas upgrade atau alamat admin multisig dalam kode Anda dan kemudian dirotasi, verifikasi Anda akan gagal. Ambil dari reference/program-addresses saat runtime atau refresh secara berkala.
2. Mengasumsikan AmmConfig stabil
AmmConfig baru dapat dibuat kapan saja. Agregator/router Anda sebaiknya mengambil ulang daftar config lengkap secara berkala (setiap jam sudah cukup).
3. Vektor penyalahgunaan pembuat farm
Jika Anda mendepositkan ke farm bereputasi rendah, pembuat dapat mengakhiri farm lebih awal dan mengklaim kembali reward vault (dengan asumsi belum ada pengguna yang melakukan stake). Setelah pengguna melakukan stake, hak pro-rata diberlakukan oleh program; klaim kembali hanya mendapatkan sisa setelah penyelesaian yang wajar.
Referensi
Sumber: