Langsung ke konten utama

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.

Halaman ini diterjemahkan secara otomatis oleh AI. Versi bahasa Inggris adalah acuan resmi.Lihat versi bahasa Inggris →
Audit menangkap beberapa kelas bug (pola serangan yang dikenal, kesalahan kontrol akses, integer overflow) dan melewatkan yang lain (cacat desain ekonomi, manipulasi game-theoretic, bug integrasi dengan program lain). Program Raydium telah melalui beberapa putaran audit masing-masing; halaman ini menampilkannya dan membahas apa yang setiap audit benar-benar verifikasikan.

​
Tabel audit per-program

ProgramAuditorTanggalLaporan
Order-book AMMKudelski SecurityQ2 2021Lihat
Concentrated liquidity (CLMM)OtterSecQ3 2022Lihat
Updated order-book AMMOtterSecQ3 2022Lihat
StakingOtterSecQ3 2022Lihat
Order-book AMM & OpenBook migrationMadShieldQ2 2023Lihat
Constant-product AMM (CPMM)MadShieldQ1 2024Lihat
Burn & Earn (liquidity locker)HalbornQ4 2024Lihat
LaunchLabHalbornQ2 2025Lihat
CPMM (update)Sec3Q3 2025Lihat
CLMM update — Limit Order, Dynamic Fee, Single Asset FeeSec3Q2 2026Lihat
Tim dari Neodyme juga telah melakukan review ekstensif melalui perjanjian bug-bounty. Semua laporan audit untuk program Raydium dicerminkan di github.com/raydium-io/raydium-docs/audit/. Setiap auditor juga menerbitkan di situs mereka sendiri.

​
Apa yang audit lakukan

Audit Raydium khas (~3–6 minggu, 2 auditor) mencakup:
  • Kontrol akses — apakah setiap operasi terprivileges dengan benar ditutup akses?
  • Aritmetika — overflow, underflow, arah pembulatan, presisi fixed-point.
  • Validasi akun — apakah setiap akun memiliki pemilik, mint, dan otoritas yang benar?
  • Pola mirip reentrancy — apakah state diperbarui sebelum atau sesudah CPI?
  • Derivasi PDA — apakah seed konsisten di semua lokasi?
  • Kode kesalahan dan pesan — apakah kondisi kesalahan revert dengan bersih?
  • Kualitas kode — Rust idiomatik, kode mati, cabang yang tidak dapat dijangkau.

​
Apa yang audit tidak lakukan

  • Game theory ekonomi — misalnya “jika saya dapat membuat 1000 pool secara gratis, dapatkah saya grief router?”
  • MEV / pengurutan — sandwich attacks, front-running melalui kolusi validator.
  • Infrastruktur off-chain — keandalan RPC, kebenaran indexer, frontend.
  • Integrasi dengan program lain — bug yang hanya terbentuk ketika dikomposisi dengan lending, options, atau kontrak aggregator tertentu.
  • Perilaku muncul seiring waktu — apa yang terjadi setelah 10 juta posisi? Audit melihat kasus uji dalam skala kecil.
Inilah sebabnya audit ≠ jaminan keamanan. Raydium melengkapi audit dengan bug bounties, monitoring, dan defensive engineering.

​
Status resolusi temuan

Setiap audit menghasilkan daftar temuan (critical / high / medium / low / informational), dengan hitungan severity dan status per-temuan (Fixed / Acknowledged / Won’t fix). Rincian per-temuan tidak diduplikasi di sini — baca setiap laporan langsung melalui tabel di atas.

​
Re-audit setelah perubahan signifikan

Ketika program mengirimkan upgrade signifikan (instruksi baru, bidang akun baru, dukungan ekstensi baru), Raydium melakukan re-audit. Review Sec3 Q3 2025 dari CPMM dan review Sec3 Q2 2026 dari CLMM (Limit Order, Dynamic Fee, Single Asset Fee) yang tercantum di tabel di atas adalah re-audit jenis ini. Cakupan re-audit lebih sempit (hanya diff), tetapi itu adalah re-audit asli — bukan hanya code review. Laporan untuk re-audit ditambahkan ke laporan audit utama.

​
Verifikasi on-chain

Hash program yang digunakan harus cocok dengan hash kode yang diaudit. Siapa pun dapat memverifikasi: 
# Tarik bytecode program yang digunakan.
solana program dump <PROGRAM_ID> program.so

# Bangun repo pada commit yang diaudit.
git clone https://github.com/raydium-io/raydium-cp-swap
cd raydium-cp-swap
git checkout <audited_commit_hash>
anchor build --verifiable

# Bandingkan.
sha256sum program.so target/deploy/raydium_cp_swap.so
Build verifiable Anchor menghasilkan bytecode deterministik; hash harus cocok persis. Jika tidak, program yang digunakan bukan program yang diaudit — eskalasi. Raydium menerbitkan hash yang diharapkan per deploy di bagian rilis repo.

​
Cara membaca laporan audit

Panduan singkat untuk non-auditor:
  1. Lewati ke ringkasan temuan — tabel hitungan severity. Jika hitungan “Critical” adalah >0 dan Anda melihat status “Open”, gali lebih dalam.
  2. Baca deskripsi dan status setiap temuan. “Fixed in commit XYZ” berarti resolved; “Acknowledged” berarti tim menerima risiko; “Partially fixed” layak diperiksa lebih dekat.
  3. Pindai bagian cakupan. Jika audit tidak mencakup instruksi atau akun yang Anda pedulikan, ketiadaan temuan di sana bukan bukti keamanan.
  4. Baca sekilas bagian rekomendasi auditor. Sering lebih berguna daripada temuan — mengungkap catatan “kami tidak dapat secara formal membuktikan ini tetapi kami tidak nyaman.”

​
Integrasi bug-bounty

Audit berjalan pre-deploy; bug bounties berjalan terus-menerus post-deploy. Program bounty Raydium (security/disclosure) mencakup semua yang audit lakukan plus:
  • Serangan ekonomi yang tidak audit lakukan.
  • Bug yang ditemukan dalam integrasi baru.
  • Bug implementasi dalam SDK dan komponen off-chain.
Temuan whitehat dalam program bounty biasanya dibayar lebih cepat daripada menunggu siklus audit berikutnya; insentif selaras untuk mengungkap dengan cepat. Program aktif dihosting di Immunefi: immunefi.com/bug-bounty/raydium/information.

​
Insiden historis

Program Raydium telah mengalami dua insiden dunia nyata yang penting:

​
Eksploitasi otoritas pool (Desember 2022)

Apa: Kunci pribadi otoritas pool AMM v4 dikompromikan, memungkinkan penyerang untuk menguras beberapa pool. Cakupan: Manajemen kunci operasional, bukan bug program. Audit tidak menandai kode karena kode benar; proses manajemen kunci adalah kegagalannya. Perbaikan: Migrasi Multisig (semua peran otoritas dipindahkan ke Squads multisig); kontrol operasional tambahan. Pelajaran: Audit tidak mencakup manajemen kunci. Lihat security/admin-and-multisig.

​
Pembekuan integrasi OpenBook (Januari 2023)

Apa: Pembaruan program OpenBook mengubah semantik akun; MonitorStep crank AMM v4 tidak dapat menyelesaikan PnL sampai patch AMM v4 dikirimkan. Cakupan: Bug integrasi — tidak ada program yang salah secara terisolasi. Perbaikan: Patch AMM v4 dan deploy terkoordinasi. Pelajaran: Audit dari program A tidak menangkap bug dalam integrasi program A dengan program B. Alat yang tepat adalah integration testing + staged rollouts.

​
Penunjuk

Sumber: