Chuyển đến nội dung chính

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.

Trang này được dịch tự động bằng AI. Phiên bản tiếng Anh là bản chính thức.Xem bản tiếng Anh →
Kiểm toán phát hiện được một số lớp lỗi (các mẫu tấn công đã biết, sai sót kiểm soát quyền truy cập, tràn số nguyên) nhưng bỏ sót những lỗi khác (các khiếm khuyết thiết kế kinh tế, thao tác lý thuyết trò chơi, lỗi tích hợp với các chương trình khác). Các chương trình Raydium đã trải qua nhiều vòng kiểm toán; trang này liệt kê chúng và thảo luận về những gì mỗi cuộc kiểm toán thực sự xác minh được.

​
Bảng kiểm toán theo chương trình

Chương trìnhHãng kiểm toánNgàyBáo cáo
Order-book AMMKudelski SecurityQ2 2021Xem
Concentrated liquidity (CLMM)OtterSecQ3 2022Xem
Order-book AMM cập nhậtOtterSecQ3 2022Xem
StakingOtterSecQ3 2022Xem
Order-book AMM & Migração OpenBookMadShieldQ2 2023Xem
Constant-product AMM (CPMM)MadShieldQ1 2024Xem
Burn & Earn (khoá thanh khoản)HalbornQ4 2024Xem
LaunchLabHalbornQ2 2025Xem
CPMM (cập nhật)Sec3Q3 2025Xem
CLMM cập nhật — Limit Order, Dynamic Fee, Single Asset FeeSec3Q2 2026Xem
Các thành viên của đội Neodyme cũng đã thực hiện các cuộc đánh giá mở rộng thông qua các thỏa thuận bug bounty. Tất cả báo cáo kiểm toán cho các chương trình Raydium được sao chép tại github.com/raydium-io/raydium-docs/audit/. Mỗi hãng kiểm toán cũng xuất bản trên trang web của họ.

​
Phạm vi kiểm toán

Một cuộc kiểm toán Raydium điển hình (3–6 tuần, 2 kiểm toán viên) bao gồm:
  • Kiểm soát quyền truy cập — mỗi hoạt động có đặc quyền có được bảo vệ đúng không?
  • Tính toán số học — tràn, cạn kiệt, hướng làm tròn, độ chính xác điểm cố định.
  • Xác thực tài khoản — mỗi tài khoản có chủ sở hữu, mint, chủ quyền đúng không?
  • Các mẫu giống như tái nhập — trạng thái cập nhật trước hay sau CPI?
  • Derivation PDA — các seed có nhất quán trên tất cả các trang không?
  • Mã lỗi và thông báo — các điều kiện lỗi có hoàn nguyên sạch không?
  • Chất lượng mã — Rust theo lề, mã chết, nhánh không thể tiếp cận.

​
Phạm vi kiểm toán không bao gồm

  • Lý thuyết trò chơi kinh tế — ví dụ “nếu tôi có thể tạo 1000 pools miễn phí, tôi có thể làm quấy rầy router không?”
  • MEV / đặt hàng — các cuộc tấn công sandwich, front-running thông qua thông đồng validator.
  • Cơ sở hạ tầng ngoài chuỗi — độ tin cậy RPC, tính chính xác của indexer, frontend.
  • Tích hợp với các chương trình khác — lỗi chỉ xuất hiện khi được sáng tác với các hợp đồng cho vay, tùy chọn hoặc aggregator cụ thể.
  • Hành vi nổi lên theo thời gian — điều gì xảy ra sau 10 triệu vị trí? Kiểm toán xem xét các trường hợp thử nghiệm quy mô nhỏ.
Đây là lý do tại sao kiểm toán ≠ đảm bảo an toàn. Raydium bổ sung kiểm toán bằng bug bounties, giám sát và kỹ thuật phòng chống.

​
Trạng thái giải quyết phát hiện

Mỗi cuộc kiểm toán tạo ra danh sách phát hiện (critical / high / medium / low / informational), với số lượng mức độ nghiêm trọng và trạng thái mỗi phát hiện (Fixed / Acknowledged / Won’t fix). Các chi tiết phát hiện riêng lẻ không được lặp lại tại đây — hãy đọc từng báo cáo trực tiếp thông qua bảng ở trên.

​
Kiểm toán lại sau các thay đổi đáng kể

Khi một chương trình triển khai một nâng cấp đáng kể (hướng dẫn mới, trường tài khoản mới, hỗ trợ tiện ích mở rộng mới), Raydium đặt hàng kiểm toán lại. Bài kiểm tra Sec3 Q3 2025 của CPMM và bài kiểm tra Sec3 Q2 2026 của CLMM (Limit Order, Dynamic Fee, Single Asset Fee) được liệt kê trong bảng trên đều là kiểm toán lại thuộc loại này. Phạm vi kiểm toán lại hẹp hơn (chỉ diff), nhưng nó thực sự là kiểm toán lại — không chỉ là bài đánh giá mã. Báo cáo cho kiểm toán lại được nối vào báo cáo kiểm toán chính.

​
Xác minh trên chuỗi

Hash chương trình được triển khai phải khớp với hash mã được kiểm toán. Bất cứ ai có thể xác minh: 
# Kéo bytecode chương trình được triển khai.
solana program dump <PROGRAM_ID> program.so

# Xây dựng repo tại commit được kiểm toán.
git clone https://github.com/raydium-io/raydium-cp-swap
cd raydium-cp-swap
git checkout <audited_commit_hash>
anchor build --verifiable

# So sánh.
sha256sum program.so target/deploy/raydium_cp_swap.so
Các bản dựng verifiable Anchor tạo ra bytecode xác định; các hash phải khớp chính xác. Nếu không, chương trình được triển khai không phải là chương trình được kiểm toán — hãy báo cáo. Raydium xuất bản các hash dự kiến mỗi lần triển khai trong phần phát hành repo.

​
Cách đọc báo cáo kiểm toán

Hướng dẫn ngắn cho những người không phải kiểm toán viên:
  1. Bỏ qua đến tóm tắt phát hiện — bảng số lượng mức độ nghiêm trọng. Nếu số “Critical” > 0 và bạn thấy trạng thái “Open”, hãy tìm hiểu sâu hơn.
  2. Đọc mô tả và trạng thái của mỗi phát hiện. “Fixed in commit XYZ” có nghĩa là đã giải quyết; “Acknowledged” có nghĩa là nhóm chấp nhận rủi ro; “Partially fixed” đáng để xem xét kỹ hơn.
  3. Quét phần phạm vi. Nếu kiểm toán không bao gồm hướng dẫn hoặc tài khoản bạn quan tâm, sự vắng mặt của phát hiện ở đó không phải là bằng chứng an toàn.
  4. Skim phần khuyến nghị của kiểm toán viên. Thường hữu ích hơn các phát hiện — bề mặt “chúng tôi không thể chứng minh chính thức điều này nhưng chúng tôi cảm thấy lo lắng” ghi chú.

​
Tích hợp bug bounty

Kiểm toán chạy trước triển khai; bug bounties chạy liên tục sau triển khai. Chương trình bounty của Raydium (security/disclosure) bao gồm mọi thứ kiểm toán làm cộng với:
  • Các cuộc tấn công kinh tế mà kiểm toán không bao gồm.
  • Lỗi tìm thấy trong các tích hợp mới.
  • Lỗi triển khai trong SDK và các thành phần ngoài chuỗi.
Một phát hiện whitehat trong chương trình bounty thường được trả lại nhanh hơn so với chờ đợi chu kỳ kiểm toán tiếp theo; các ưu đãi được căn chỉnh để công khai nhanh chóng. Chương trình hoạt động được lưu trữ trên Immunefi: immunefi.com/bug-bounty/raydium/information.

​
Các sự cố lịch sử

Các chương trình của Raydium đã có hai sự cố đáng chú ý trong thế giới thực:

​
Khai thác quyền nhân tố pool (tháng 12 năm 2022)

Cái gì: Khóa riêng tư của quyền nhân tố pool AMM v4 đã bị xâm phạm, cho phép kẻ tấn công rút mạnh một số pools. Phạm vi: Quản lý khóa hoạt động, không phải lỗi chương trình. Kiểm toán không đã cờ mã vì mã là chính xác; quy trình quản lý khóa là lỗi. Sửa chữa: Migração multisig (tất cả vai trò quyền được di chuyển sang Squads multisig); các biện pháp kiểm soát hoạt động bổ sung. Bài học: Kiểm toán không bao gồm quản lý khóa. Xem security/admin-and-multisig.

​
Đóng băng tích hợp OpenBook (tháng 1 năm 2023)

Cái gì: Một bản cập nhật chương trình OpenBook đã thay đổi ngữ nghĩa tài khoản; crank MonitorStep của AMM v4 không thể giải quyết PnL cho đến khi một bản vá AMM v4 được gửi đi. Phạm vi: Lỗi tích hợp — cả hai chương trình đều không sai trong bản thân. Sửa chữa: Bản vá AMM v4 và triển khai phối hợp. Bài học: Kiểm toán chương trình A không bắt được lỗi tích hợp của chương trình A với chương trình B. Công cụ phù hợp là kiểm tra tích hợp + triển khai theo giai đoạn.

​
Con trỏ

Nguồn: