Kunci admin dan multisig

Halaman ini diterjemahkan secara otomatis oleh AI. Versi bahasa Inggris adalah acuan resmi.Lihat versi bahasa Inggris →

Setiap program Raydium memiliki setidaknya satu peran istimewa — kunci yang dapat meningkatkan program, membuat konfigurasi baru, atau menarik biaya protokol. Meminimalkan apa yang dapat dilakukan peran-peran ini (dan membatasi mereka di belakang multisig dengan penundaan) adalah pertahanan utama terhadap admin yang dikompromikan. Halaman ini mencatat peran-peran dan bagaimana mereka diamankan dalam praktik.

Peran menurut program

AMM v4

Peran	Alamat Otoritas	Apa yang dapat dilakukan
Upgrade program	Squads multisig (3/4)	Terapkan bytecode program baru
Admin pool	Treasury multisig (3/5)	Alihkan status pool, perbarui biaya di pool yang ada

CPMM

Peran	Alamat Otoritas	Apa yang dapat dilakukan
Upgrade program	Squads multisig (3/4)	Terapkan bytecode program baru
Admin AmmConfig	Treasury multisig (3/5)	Buat AmmConfigs baru (tingkat biaya); alihkan yang ada
Penerima biaya create pool	Treasury multisig (3/5)	Terima biaya create-pool sekali jalan
Pembuat Permission-PDA	Program `admin` atau pemilik create-permission-PDA khusus (nilai berbeda di mainnet vs devnet)	Panggil `CreatePermissionPda` untuk memberikan akses otoritas ke `InitializeWithPermission`. Pemilik khusus tidak dapat memanggil `ClosePermissionPda`; pencabutan tetap hanya admin.

Pengumpulan biaya kreator tidak memperkenalkan peran istimewa. CollectCreatorFeePermissionless menerima pembayar apa pun, membatasi pemilik penerima ke PoolState.pool_creator, dan membatasi kedua tujuan ke ATA kanonik kreator tersebut. Pemanggil dapat mendanai ATA yang hilang dan memicu penyapuan tetapi tidak dapat mengalihkan biaya.

CLMM

Peran	Alamat Otoritas	Apa yang dapat dilakukan
Upgrade program	Squads multisig (3/4)	Terapkan bytecode program baru
Admin AmmConfig	Treasury multisig (3/5)	Buat/ubah AmmConfigs
Admin DynamicFeeConfig	Treasury multisig (3/5)	`CreateDynamicFeeConfig` / `UpdateDynamicFeeConfig` — kalibrasi tingkat biaya dinamis yang dapat dipilih oleh panggilan `CreateCustomizablePool`
`permission_pda_admin`	Program `admin` atau kunci `permission_pda_admin` khusus (nilai berbeda di mainnet vs devnet)	`CreatePermissionPda` / `ClosePermissionPda` — berikan atau cabut hak otoritas untuk memanggil `CreatePermissionedPool`. Pemberian adalah keberadaan PDA `["permission", authority]` saja; itu tidak memberikan kekuatan mutasi pool apa pun.
`limit_order_admin` (program-wide)	Dompet operasional panas off-chain, bukan multisig	Selesaikan dan tutup pesanan batas atas nama pemiliknya. Kunci keeper adalah konstanta program-wide tunggal (nilai berbeda di mainnet vs devnet), diperiksa melalui `signer == limit_order.owner \|\| signer == limit_order_admin::ID` pada `SettleLimitOrder` / `CloseLimitOrder`. Output selalu mendarat di ATA pemilik asli; keeper tidak dapat mengalihkan dana, memodifikasi pesanan, atau membuka yang baru.

Memegang PDA Permission memungkinkan otoritasnya memanggil CreatePermissionedPool — membuat pool tambahan untuk pasangan yang sudah memiliki satu kanonik, masing-masing di alamat yang diturunkan dari seed_index yang berbeda. Izin dibatasi hanya untuk pembuatan pool: tidak dapat memindahkan dana, mengubah biaya, atau menyentuh pool yang ada. Mencabutnya (ClosePermissionPda) menghentikan otoritas dari pembuatan pool lebih lanjut tetapi meninggalkan pool yang sudah dibuat tidak tersentuh. limit_order_admin adalah peran operasional yang sengaja sempit. Itu ada sehingga keeper off-chain dapat menyapu pesanan yang terisi tanpa pemilik pesanan harus online. Kunci keeper panas (hidup di VM keeper) dan dirotasi secara independen dari multisig di atas. Secara konkret, otoritas keeper dibatasi untuk:

SettleLimitOrder — dorong output terisi dari pesanan ke ATA pemilik pada harga batas pesanan.
CloseLimitOrder — tutup akun pesanan yang sepenuhnya diselesaikan untuk mengklaim sewa (sewa pergi ke pemilik pesanan).

Itu tidak dapat memanggil OpenLimitOrder, IncreaseLimitOrder, DecreaseLimitOrder, mengubah bidang pool apa pun, atau menandatangani instruksi lain apa pun — pemeriksaan tersebut ditegakkan on-chain oleh seed dan batasan has_one dalam struct Accounts instruksi. Keeper yang dikompromikan paling buruk dapat tidak tersedia (pesanan tetap diparkir sampai pemilik menyelesaikannya sendiri) atau menyelesaikan/menutup pesanan yang dapat diisi secara sah di luar urutan; itu tidak dapat memindahkan dana pengguna ke mana pun selain tempat pemilik sudah mengotorisasinya.

Farm v6

Peran	Alamat Otoritas	Apa yang dapat dilakukan
Upgrade program	Squads multisig (3/4)	Terapkan bytecode program baru
Pembuat farm (per farm)	Dompet pembuat farm	Dana vault reward, perpanjang jadwal, klaim kembali reward yang tidak digunakan

Farm individual tidak memiliki admin protokol — setiap pembuat farm hanya mengontrol farm mereka, dan kekuatan pembuat dibatasi (tidak dapat merampas stake pengguna, tidak dapat mengubah mint staking).

LaunchLab

Peran	Alamat Otoritas	Apa yang dapat dilakukan
Upgrade program	Squads multisig (3/4)	Terapkan bytecode program baru
Admin program	Admin Raydium bersama	Buat dan perbarui akun `GlobalConfig`; operasikan jalur admin-only lainnya
Pembuat config yang didelegasikan	Otoritas spesifik cluster khusus	Buat `GlobalConfig` baru; tidak dapat memperbarui config yang ada
Admin platform	Otoritas seed PDA untuk satu `PlatformConfig`	Perbarui pengaturan platform dan buat atau tutup akun `PlatformAllowConfig` platform tersebut
Pembuat launch (per launch)	Dompet pembuat launch	Klaim biaya pembuat kurva ikatan; menerima hak biaya pembuat CPMM hanya ketika platform tidak mengganti `platform_cp_creator`

Daftar izin admin platform membatasi diri sendiri: itu membatasi akun GlobalConfig mana yang dapat digunakan launch di bawah platform tersebut. Itu tidak memberikan otoritas atas platform lain atau dana launch yang ada. Alamat otoritas delegasi kanonik hidup di reference/program-addresses.

Otoritas upgrade program

Program Raydium menggunakan mekanisme upgrade BPF Loader v3 standar Solana. Otoritas upgrade untuk semua program adalah multisig Squads 3/4. Mengapa 3/4: cukup penandatangan sehingga kompromi tunggal tidak cukup; cukup sedikit sehingga mengoordinasikan upgrade yang sah dapat dilakukan. Empat otoritas adalah penandatangan perangkat dingin yang terpisah dan terisolasi udara yang dipegang oleh anggota tim inti. Penandatanganan berurutan mencegah persetujuan paralel pada transaksi yang sama; transaksi membawa jendela kedaluwarsa tetap. Operasi multisig ditinjau secara berkala dalam kemitraan dengan Program STRIDE Solana (Asymmetric Research).

Menghapus otoritas upgrade

Raydium belum menetapkan otoritas upgrade program apa pun ke null. Protokol beroperasi di bawah prinsip bahwa program perlu dapat ditingkatkan (untuk menambal bug, menambahkan ekstensi seperti Token-2022, memperbaiki drift integrasi). Trade-off: pengguna mempercayai bahwa multisig 3/4 hanya akan menerapkan upgrade yang ditinjau dengan baik. Bagi pengguna yang menginginkan alternatif yang tidak dapat diubah, program AMM v4 yang lebih lama telah stabil sejak audit terakhirnya; nol upgrade dalam 18 bulan. Jalur kode tersebut secara efektif beku meskipun otoritas masih ada.

Otoritas AmmConfig

Setiap pembuatan AmmConfig baru memiliki izin — multisig treasury 3/5 mengotorisasi tingkat biaya dan spasi tick baru. Pool yang ada mereferensikan AmmConfig mereka dengan PDA; tingkat biaya pool adalah apa pun yang dikatakan AmmConfig. Bisakah admin mengubah AmmConfig yang ada? Ya, secara teknis. updateAmmConfig dapat dipanggil oleh admin. Dalam praktik, modifikasi pada AmmConfigs yang diterapkan dihindari karena mengubah ekonomi semua pool yang menggunakan config tersebut secara diam-diam. Kebijakan protokol adalah membuat AmmConfig baru untuk perubahan apa pun dan bermigrasi. Bisakah admin mencuri biaya protokol melalui config? Tidak — AmmConfig berisi parameter biaya tetapi bukan penerima biaya protokol; itu adalah alamat yang terpisah dan tidak dapat diubah per pool.

Klaim biaya protokol

Sebagian dari biaya swap (biasanya 3–12 bps dari 25 bps biaya swap, tergantung config) terakumulasi ke vault biaya protokol. Multisig dapat menarik biaya yang terakumulasi ini. Pengguna tidak pernah melihat saldo LP mereka berubah dari ini — itu adalah bagian yang dialokasikan sebelumnya protokol, bukan uang LP.

Otoritas pembuat farm

Farm v6 memberikan pembuat kekuatan untuk:

Dana vault reward (tambahkan lebih banyak token).
Perpanjang jadwal (dorong waktu akhir lebih lambat).
Panggil withdrawReward setelah waktu akhir untuk mengklaim saldo vault yang tidak digunakan.

Pembuat farm tidak dapat:

Tarik LP stake pengguna.
Ubah mint staking.
Ubah tingkat emisi secara retroaktif (hanya forward-looking melalui setRewards).
Bekukan harvest pengguna.

Pembuat farm yang berbahaya paling buruk dapat kurang mendanai vault sehingga farm kehabisan; stake pokok pengguna selalu aman.

Konfigurasi multisig Squads

Raydium mengoperasikan dua multisig Squads terpisah untuk permukaan risiko yang berbeda. Keduanya dapat diperiksa on-chain melalui UI Squads Protocol.

Multisig	Threshold	Timelock	Cakupan
Upgrade program	3/4	24 jam	Satu-satunya otoritas untuk menerapkan bytecode program baru untuk AMM v4, CPMM, CLMM, LaunchLab, Lock, AMM Routing, Stable Swap, dan program Farm/Staking warisan. 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 AmmConfigs, menyapu biaya protokol, mengonfigurasi parameter pool) untuk saat ini. Lihat di `v3.squads.so/dashboard/RVha…dHdtYz09`.

Properti operasional multisig upgrade:

Timelock 24 jam pada transaksi apa pun. Upgrade yang disetujui hari ini tidak dieksekusi lebih awal dari 24 jam kemudian, memberi pengguna waktu untuk merespons.
Penandatanganan perangkat dingin yang terisolasi udara. Perangkat dingin memiliki kartu jaringan yang dihapus secara fisik; mereka terhubung hanya ke dompet perangkat keras dan membaca data transaksi melalui kode QR dari perangkat panas terpisah.
Penandatanganan berurutan. Hanya setelah satu perangkat dingin menghasilkan dan menandatangani transaksi dapat perangkat dingin berikutnya memulai proses penandatanganannya — mencegah tanda tangan yang bertentangan atau paralel pada transaksi yang sama.
Kedaluwarsa transaksi. Setiap transaksi membawa jendela kedaluwarsa tetap, sehingga transaksi basi secara otomatis tidak valid.
Penegakan TOTP + kunci fisik pada perangkat panas yang digunakan untuk inisiasi transaksi dan siaran on-chain.
Antrian transaksi publik. Siapa pun dapat memantau upgrade yang tertunda di UI Squads.

Multisig treasury tidak memiliki timelock — cakupannya lebih sempit dan ops rutin (membuat AmmConfigs, menyapu biaya) perlu mendarat hari yang sama. Multisig treasury juga memegang otoritas admin program terbatas yang tercantum dalam tabel per-program di atas; ini adalah pengaturan sementara dan ditinjau secara berkala dengan 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:          CPMMoo8L3F4NbTegBCKVNunggL7H1ZpdTHKxQB5qKP1C
Owner:               BPFLoaderUpgradeab1e11111111111111111111111
ProgramData Address: <ProgramDataPDA>
Authority:           <EXPECTED_MULTISIG_ADDRESS>
Last Deployed In Slot: <slot>
Data Length: <n> bytes

Jika Authority bukan alamat multisig Squads yang diharapkan, ada yang salah. Raydium menerbitkan alamat otoritas yang diharapkan di reference/program-addresses. Untuk peran admin AmmConfig / pool, ambil akun on-chain dan dekode:

const config = await raydium.cpmm.getAmmConfig(configPda);
console.log("AmmConfig admin:", config.admin.toBase58());
// Diharapkan: multisig treasury 3/5.

Perubahan otoritas historis

Tanggal	Program	Perubahan
2022-12	AMM v4	Otoritas upgrade bermigrasi dari single-sig ke multisig 3/4 setelah insiden
2023-02	Semua program	Semua peran operasional disatukan di bawah multisig treasury 3/5
2023-11	CLMM	Menambahkan multisig kedua untuk operasi reward-only untuk mengurangi eksposur
2024-05	CPMM	Deploy awal dengan otoritas multisig dari hari pertama

Pertimbangan sisi pengguna

Apa yang harus Anda lakukan sebagai pengguna/LP/integrator?

Periksa otoritas upgrade sebelum alokasi besar. Konfirmasi itu cocok dengan multisig yang didokumentasikan.
Pantau aktivitas multisig. UI Squads menunjukkan transaksi yang tertunda; upgrade yang dijadwalkan memberi Anda 24 jam untuk membuka jika Anda tidak setuju dengan perubahan.
Strategi penebusan yang menyadari time-lock. Jika Anda menjalankan auto-compounder, pastikan jalur unwind Anda tidak memerlukan instruksi yang sedang diubah.
Jangan asumsikan ketidakubahan program. Setiap program Raydium dapat ditingkatkan; rencanakan untuk itu.

Jebakan untuk integrator

1. Caching alamat otoritas

Jika Anda hardcode otoritas upgrade atau alamat multisig admin dalam kode Anda dan kemudian dirotasi, verifikasi Anda gagal. Ambil dari reference/program-addresses saat runtime atau segarkan secara berkala.

2. Mengasumsikan AmmConfigs stabil

AmmConfig baru dapat dibuat kapan saja. Aggregator/router Anda harus mengambil ulang daftar config lengkap secara berkala (per jam tidak apa-apa).

3. Vektor kesedihan pembuat farm

Jika Anda menyetor ke farm dengan reputasi rendah, pembuat dapat mengakhiri farm lebih awal dan mengklaim kembali vault reward (dengan asumsi tidak ada pengguna yang telah stake). Setelah pengguna stake, hak pro-rata ditegakkan oleh program; klaim kembali hanya mendapat sisa setelah akhir rasional.

Penunjuk

reference/program-addresses — alamat otoritas kanonik.
security/attack-vectors — bagaimana kompromi admin memanifestasikan diri.
ray/treasury — alamat treasury dan pengumpulan biaya.
security/disclosure — melaporkan masalah admin yang dicurigai.

Sumber:

Squads Protocol — UI multisig.
Dokumen Solana BPF Loader — mekanisme upgrade.

Security & risk

RAY token & Protocol revenues

Kunci admin dan multisig

Peran menurut program

AMM v4

CPMM

CLMM

Farm v6

LaunchLab

Otoritas upgrade program

Menghapus otoritas upgrade

Otoritas AmmConfig

Klaim biaya protokol

Otoritas pembuat farm

Konfigurasi multisig Squads

Memverifikasi otoritas on-chain

Perubahan otoritas historis

Pertimbangan sisi pengguna

Jebakan untuk integrator

1. Caching alamat otoritas

2. Mengasumsikan AmmConfigs stabil

3. Vektor kesedihan pembuat farm

Penunjuk

​Peran menurut program

​AMM v4

​CPMM

​CLMM

​Farm v6

​LaunchLab

​Otoritas upgrade program

​Menghapus otoritas upgrade

​Otoritas AmmConfig

​Klaim biaya protokol

​Otoritas pembuat farm

​Konfigurasi multisig Squads

​Memverifikasi otoritas on-chain

​Perubahan otoritas historis

​Pertimbangan sisi pengguna

​Jebakan untuk integrator

​1. Caching alamat otoritas

​2. Mengasumsikan AmmConfigs stabil

​3. Vektor kesedihan pembuat farm

​Penunjuk

Peran menurut program

AMM v4

CPMM

CLMM

Farm v6

LaunchLab

Otoritas upgrade program

Menghapus otoritas upgrade

Otoritas AmmConfig

Klaim biaya protokol

Otoritas pembuat farm

Konfigurasi multisig Squads

Memverifikasi otoritas on-chain

Perubahan otoritas historis

Pertimbangan sisi pengguna

Jebakan untuk integrator

1. Caching alamat otoritas

2. Mengasumsikan AmmConfigs stabil

3. Vektor kesedihan pembuat farm

Penunjuk