Các vector tấn công

​

1. Tấn công sandwich / MEV

​

Tấn công

Một bot theo dõi mempool / gossip stream, phát hiện swap của người dùng, front-run bằng một lệnh mua cùng hướng (đẩy giá), cho phép tx của người dùng thực thi với giá tệ hơn, sau đó back-run bằng một lệnh bán ngược chiều. Bot kiếm lợi nhuận từ chênh lệch.

​

Điểm yếu

• Tiếp xúc nhiều nhất: các pool CPMM có TVL thấp và pool AMM v4 — ngay cả những giao dịch nhỏ cũng làm thay đổi giá đáng kể.
• Tiếp xúc ít hơn: các pool CLMM sâu — giao dịch trong tick không làm thay đổi giá.
• Không tiếp xúc: harvest farm, LP deposit (tỷ lệ được thực thi, không nhạy cảm với giá theo cách tương tự).

​

Phòng chống

• Jito bundles (integration-guides/routing-and-mev) ẩn tx khỏi mempool công khai.
• Slippage chặt — minimum-out gần hơn với giá dự kiến làm cho sandwich không có lợi nhuận. Dưới ~0,3%, hầu hết sandwich mất tiền.
• Kích thước giao dịch nhỏ hơn — chia một swap $100k thành 10× $10k; mỗi cái làm thay đổi giá ít hơn.

​

Lập trường của Raydium

Các chương trình cốt lõi của Raydium không thực thi bảo vệ chống MEV — chúng trung lập ở cấp chương trình. Bảo vệ xảy ra ở lớp submission (Jito, bảo vệ tích hợp của ví). UI mặc định slippage thành 0,5% là hợp lý cho hầu hết các pool.

​

2. Thao túng giá

​

Tấn công

Một nhà giao dịch lớn tạm thời di chuyển giá của pool (bằng flash loan hoặc tự tài trợ whale), kích hoạt một số hành động hạ lưu phụ thuộc vào giá (một liquidation, một khoản vay dẫn xuất từ oracle, một khoản thanh toán phái sinh), sau đó trả giá về bình thường.

​

Điểm yếu

• Hoạt động Raydium gốc: không tiếp xúc. Một swap spot vào và ra chỉ phải chịu phí round-trip; nhà giao dịch mất tiền.
• Chương trình tích hợp: tiếp xúc nếu chúng đọc giá pool Raydium một cách ngây thơ.

​

Phòng chống

• Sử dụng TWAP, không phải spot price, cho composability (xem security/oracle-and-token-risks).
• CLMM ObservationState cung cấp TWAP cửa sổ ngắn không thể bị thao túng mà không có cam kết vốn bền vững.
• Đồng thuận đa oracle: nếu chương trình của bạn đọc Raydium và Pyth và Jupiter và chỉ hành động khi chúng đồng ý trong 1%, thao túng flash-loan của bất kỳ nguồn nào không đủ.

​

Lập trường của Raydium

CLMM cung cấp hỗ trợ TWAP ObservationState; các integrator bỏ qua nó và sử dụng spot price tự chịu trách nhiệm. Frontend của Raydium sử dụng nhiều nguồn giá cho hiển thị USD.

​

3. Tấn công donation / inflation

​

Tấn công

LP đầu tiên trong một pool mới deposit một lượng nhỏ (ví dụ: 1 token mỗi mint 6-decimal → 1 đơn vị LP được phát hành). Sau đó, kẻ tấn công “donate” 1.000.000 token trực tiếp vào vault pool thông qua SPL Token transfer. Bây giờ 1 đơn vị LP đại diện cho 500.000 của mỗi mint. Bất kỳ LP tiếp theo nào deposit ít hơn số đó sẽ được làm tròn thành 0 đơn vị LP và mất deposit của họ.

​

Điểm yếu

• CPMM / AMM v4: có khả năng tiếp xúc trên các pool mới tạo, có tính thanh khoản thấp.
• CLMM: không tiếp xúc (không có mint LP được chia sẻ; mỗi vị trí là NFT riêng của nó với giá trị thanh khoản rõ ràng).

​

Phòng chống

Lệnh initialize của CPMM khóa một lượng LP tối thiểu vào pool (lấy cảm hứng từ mẫu MINIMUM_LIQUIDITY của Uniswap V2). Điều này có nghĩa là LP đầu tiên nhận được sqrt(x × y) - MINIMUM_LIQUIDITY, với MINIMUM_LIQUIDITY (1000 đơn vị) bị đốt thành null. Một tấn công donation yêu cầu kẻ tấn công donate >> deposit ban đầu, điều này trở nên không kinh tế. Ngoài ra, SDK của Raydium cảnh báo lớn khi deposit ban đầu nhỏ và hướng dẫn người dùng hướng tới các lượng hợp lý.

​

Lập trường của Raydium

Khóa MINIMUM_LIQUIDITY được cung cấp trong CPMM; AMM v4 có cơ chế tương tự. Người dùng tạo pool nên seed với ít nhất 10.000+ đơn vị của mỗi mint để làm cho tấn công donation không kinh tế trong mọi trường hợp.

​

4. Lạm dụng transfer-hook Token-2022

​

Tấn công

Hook transfer của một mint có thể nâng cấp. Kẻ tấn công triển khai một hook vô hại khi mint ra mắt, được liệt kê trên Raydium, tích lũy LP từ người dùng. Sau đó, nâng cấp hook để chặn tất cả các transfer (về cơ bản soft-rug — người dùng không thể rút). Kẻ tấn công làm cho pool chỉ có thể giao dịch theo một hướng, mua LP rẻ, mở khóa hook, thắng.

​

Điểm yếu

Các pool bao gồm một mint transfer-hook.

​

Phòng chống

• Cấp chương trình: Raydium gọi hook trong swap; nếu hook chặn, swap sẽ revert. Điều này không ngăn chặn tấn công về mặt cơ học.
• Cấp UI: Raydium đánh dấu các pool có mint transfer-hook.
• Cấp integrator: các aggregator nên bỏ qua mint transfer-hook theo mặc định và chỉ allow-list các hook được xác minh.

​

Lập trường của Raydium

Raydium không cấm các pool transfer-hook (các hook hợp pháp tồn tại), nhưng gắn thẻ chúng rõ ràng. Các aggregator lọc trên tags.includes("TRANSFER_HOOK") có thể loại trừ nếu muốn.

​

5. Lỗi composability / CPI

​

Tấn công

Một chương trình soạn Raydium thông qua CPI và giới thiệu một lỗi: ví dụ, nó chuyển observation_state sai, các tick array sai cho swap CLMM, hoặc double-spend một tài khoản. Kẻ tấn công xác định composability lỗi và khai thác.

​

Điểm yếu

• Integrator lỗi — thường là nguồn của lỗi.
• Raydium — chỉ nếu lỗi kích hoạt hành vi không dự định trong các chương trình Raydium.

​

Ví dụ lịch sử

Không có chương trình Raydium nào bị khai thác thông qua CPI — các trình xác thực tài khoản của Raydium bắt các tài khoản hình dạng sai và revert. Các khai thác trong hệ sinh thái rộng hơn đã xảy ra thông qua lỗi chương trình tùy chỉnh soạn với AMM nhưng không bắt nguồn từ AMM.

​

Phòng chống

• Các chương trình gọi nên sử dụng Anchor CPI helpers (không phải hướng dẫn xây dựng tay) khi có thể — type-safety bắt hầu hết sử dụng sai.
• Các bài kiểm tra tích hợp chống lại trạng thái mainnet-forked bao gồm các trường hợp composability.

​

6. Thỏa hiệp admin / key

​

Tấn công

Một khóa admin (upgrade authority, AmmConfig admin, protocol fee claim) bị thỏa hiệp. Kẻ tấn công triển khai một nâng cấp độc hại để thoát pool, hoặc sửa đổi AmmConfig để định tuyến phí đến ví kẻ tấn công, hoặc thoát phí giao thức.

​

Điểm yếu

Tất cả các vai trò được ghi lại trong security/admin-and-multisig.

​

Phòng chống

• Multisig 3/4 trên upgrade authority yêu cầu thỏa hiệp 4 người ký độc lập.
• Timelock 24 giờ trên nâng cấp cho người dùng thời gian để unwind trước khi nâng cấp độc hại kích hoạt.
• Giám sát hoạt động — cảnh báo về bất kỳ hoạt động multisig nào thông qua hàng đợi công khai của Squads.

​

Sự cố lịch sử

Khóa pool authority của AMM v4 bị thỏa hiệp vào tháng 12 năm 2022 (trước multisig). Sửa chữa: chuyển tất cả quyền hạn sang multisig Squads. Sau khi sửa chữa, không có sự cố.

​

7. Tấn công kinh tế trên toán học tick CLMM

​

Tấn công

Một kẻ tấn công tinh vi khai thác các trường hợp edge làm tròn hoặc kế toán phí trong toán học tick CLMM. Các ví dụ đã được tìm thấy trong các triển khai CLMM khác (không phải Raydium):

• Kế toán tăng trưởng phí làm tròn chống lại người dùng, tích lũy bụi.
• Tick crossing ghi/ghi nợ delta fee_growth sai.
• Integer overflow trong sản phẩm sqrtPrice * liquidity.

​

Điểm yếu

Toán học tùy chỉnh phức tạp. Audit và fuzzing là phòng chống chính.

​

Lập trường của Raydium

CLMM đã có hai audit độc lập (OtterSec + MadShield) cộng với fuzzing dựa trên thuộc tính liên tục. Không tìm thấy lỗi ảnh hưởng đến production cho đến nay. Số học sqrt_price_x64 Q64.64 sử dụng toán học 128-bit bão hòa với các bài kiểm tra đơn vị bao gồm các tick ranh giới.

​

8. Nhầm lẫn Position-NFT

​

Tấn công

Một người dùng bị lừa ký một giao dịch chuyển NFT vị trí CLMM của họ cho kẻ tấn công. Kẻ tấn công bây giờ sở hữu thanh khoản của vị trí.

​

Điểm yếu

Bất kỳ chủ sở hữu position NFT nào.

​

Phòng chống

• UI ví nên nhận ra NFT vị trí Raydium và hiển thị chúng riêng biệt (không phải NFT chung để “gửi”).
• Người dùng nên cảnh báo khi ký các giao dịch chuyển NFT.
• Một vị trí mới bị đóng băng chỉ khi nó sử dụng đường dẫn mở V2 và mint vault cơ bản của nó có freeze authority khớp với danh sách restricted-issuer của CLMM. Vị trí khớp đó không thể được chuyển hoặc có chủ sở hữu token-account thay đổi; tất cả các vị trí mới khác vẫn có thể chuyển được.

​

Lập trường của Raydium

NFT vị trí triển khai tiêu chuẩn metadata của Metaplex; các ứng dụng ví hiểu các vị trí CLMM hiển thị chúng dưới dạng vị trí thanh khoản chứ không phải NFT có thể giao dịch. Hầu hết các ví Solana chính hiển thị chúng đặc biệt kể từ năm 2026. Đóng băng restricted-issuer được nhắm mục tiêu và không bảo vệ các vị trí có thể chuyển thông thường.

​

9. Thao túng dòng phần thưởng farm

​

Tấn công

Người tạo farm tài trợ vault phần thưởng, thu hút staker, sau đó gọi restartRewards với các tham số làm cho tính toán pending-reward lỏng lẻo, đánh cắp giá trị harvest.

​

Điểm yếu

Farm với những người tạo độc hại. Farm v6 giới hạn chặt quyền hạn của người tạo; tấn công này không hoạt động.

​

Phòng chống

Các lệnh admin của Farm v6 (setRewards, restartRewards, addReward) bảo tồn quyền lợi pro-rata — reward_per_share được điều chỉnh tại thời điểm thay đổi, vì vậy không có accrual trước thay đổi bị hỏng retroactively.

​

Lập trường của Raydium

Audit farm của OtterSec cụ thể đã kiểm tra các kịch bản restart-rewards; không tìm thấy khai thác.

​

10. Phân kỳ simulation-vs-execution

​

Tấn công

Một kẻ tấn công xây dựng một giao dịch mô phỏng thành công nhưng revert khi thực thi (hoặc ngược lại). Được sử dụng để làm phiền ví dựa vào mô phỏng để hiển thị.

​

Điểm yếu

Ví hiển thị “bạn sẽ nhận được X” dựa trên mô phỏng.

​

Phòng chống

• Sử dụng simulateTransaction với cùng blockhash như submission thực.
• Hiển thị đầu ra dự kiến là ”≈” (xấp xỉ) không chính xác.
• Mô phỏng lại ngay trước submission.

​

Lập trường của Raydium

Mô phỏng CLMM là xác định với trạng thái pool hiện tại; phân kỳ chỉ xảy ra nếu trạng thái thay đổi giữa mô phỏng và thực thi (trường hợp bình thường, được xử lý thông qua slippage bounds).

​

Bảng tóm tắt

​

Những gì người dùng có thể làm

• Mặc định slippage chặt; chỉ tăng khi cần.
• Sử dụng ví / luồng swap được bật Jito.
• Xác minh mint extension trước LP.
• Giám sát multisig Squads để tìm các nâng cấp đang chờ xử lý.
• Đa dạng hóa trên các pool; không tập trung tất cả LP của bạn trong một pool ra mắt mới.

​

Những gì integrator có thể làm

• Sử dụng TWAP ObservationState cho định giá phái sinh.
• Xác thực ràng buộc tài khoản khi soạn thông qua CPI.
• Lọc pool theo trường tags (bỏ qua scam, honeypot, transfer-hook không được xác minh).
• Đặt slippage bounds hợp lý; không chấp nhận 0 slippage từ đầu vào người dùng.
• Sử dụng simulateTransaction cẩn thận — ghi lại đó là một ước tính.

​

Con trỏ

• security/oracle-and-token-risks — Rủi ro Token-2022 sâu.
• security/admin-and-multisig — cấu trúc quyền hạn.
• security/disclosure — chương trình bug-bounty.
• integration-guides/routing-and-mev — giảm thiểu MEV.

Nguồn:

• Rekt News — DeFi post-mortem thông báo cho danh sách này.
• Báo cáo audit được liên kết trong security/audits.