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 →
AMM là mục tiêu hấp dẫn cho mã độc ý: quỹ của LP nằm trong các pool hoàn toàn công khai; mỗi swap thay đổi giá một cách xác định. Trang này liệt kê các lớp tấn công được chứng minh chống lại AMM ở bất kỳ đâu, cách chúng áp dụng cho Raydium cụ thể, và những gì Raydium (cùng các tích hợp) làm để phòng vệ.
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 chiều (đẩy giá lên), để 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.Phơi nhiễm
- Phơi nhiễm nhiều nhất: pool CPMM có TVL thấp và pool AMM v4 — ngay cả những giao dịch nhỏ cũng làm giá thay đổi đáng kể.
- Phơi nhiễm ít hơn: pool CLMM sâu — những giao dịch trong tick không làm giá thay đổi.
- Không phơi nhiễm: harvest farm, LP deposit (tỷ lệ được thực thi, không nhạy cảm giá theo cách tương tự).
Phòng vệ
- Jito bundle (
integration-guides/routing-and-mev) ẩn tx khỏi mempool công khai. - Slippage chặt chẽ — minimum-out gần hơn với giá trị kỳ vọng 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 USD thành 10× 10k USD; mỗi cái làm giá thay đổi ít hơn.
Thái độ 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 ở mức chương trình. Bảo vệ xảy ra ở lớp gửi (Jito, bảo vệ tích hợp của ví). UI mặc định slippage thành 0.5%, điều này hợp lý cho hầu hết các pool.2. Thao túng giá
Tấn công
Một trader 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ố tác động hạ nguồn phụ thuộc vào giá (thanh lý, vay dẫn xuất từ oracle, thanh toán phái sinh), sau đó trả giá về bình thường.Phơi nhiễm
- Các hoạt động Raydium gốc: không phơi nhiễm. Swap vào và ra chỉ phải chịu phí vòng đi; trader mất tiền.
- Các chương trình tích hợp: phơi nhiễm nếu chúng đọc giá pool Raydium một cách ngây thơ.
Phòng vệ
- 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 thao túng được mà không 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ỉ hoạt động khi chúng thống nhất trong 1%, thao túng flash-loan của bất kỳ nguồn nào không đủ.
Thái độ của Raydium
CLMM cung cấp hỗ trợ TWAP ObservationState; các tích hợp bỏ qua nó và sử dụng spot price tự chịu. 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 6-decimal mint → 1 đơn vị LP phát hành). Sau đó attacker “donate” 1,000,000 token trực tiếp vào vault pool qua SPL Token transfer. Bây giờ 1 đơn vị LP đại diện cho 500,000 mỗi mint. Bất kỳ LP tiếp theo deposit ít hơn sẽ được làm tròn thành 0 đơn vị LP và mất deposit.Phơi nhiễm
- CPMM / AMM v4: có khả năng phơi nhiễm trên pool mới tạo, có tính thanh khoản thấp.
- CLMM: không phơi nhiễm (không có LP mint chung; mỗi position là NFT riêng của nó với giá trị thanh khoản tường minh).
Phòng vệ
initialize instruction 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 LP đầu tiên nhận sqrt(x × y) - MINIMUM_LIQUIDITY, với MINIMUM_LIQUIDITY (1000 đơn vị) bị đốt thành null. Tấn công donation yêu cầu attacker 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 rất nhỏ và hướng dẫn người dùng đến các lượng hợp lý.
Thái độ của Raydium
KhóaMINIMUM_LIQUIDITY đã được triển khai 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ị mỗi mint để làm cho tấn công donation không kinh tế dù sao.
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. Attacker 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ả transfer (thực chất soft-rug — người dùng không thể rút). Attacker làm cho pool có thể giao dịch chỉ một chiều, mua LP rẻ, mở khóa hook, thắng.Phơi nhiễm
Pool bao gồm một mint transfer-hook.Phòng vệ
- Mức chương trình: Các chương trình Raydium gọi hook trong swap; nếu hook chặn, swap hoàn lại. Điều này không ngăn chặn tấn công về mặt cơ học.
- Mức UI: Raydium đánh dấu pool với transfer-hook mint.
- Mức tích hợp: các aggregator nên bỏ qua transfer-hook mint theo mặc định và chỉ cho phép danh sách xác minh hook.
Thái độ của Raydium
Raydium không cấm pool transfer-hook (hook hợp pháp tồn tại), nhưng gắn thẻ rõ ràng. Các aggregator lọc theotags.includes("TRANSFER_HOOK") có thể loại trừ nếu muốn.
5. Composability / CPI exploits
Tấn công
Một chương trình tạo Raydium qua CPI và giới thiệu một bug: ví dụ, nó truyền saiobservation_state, sai tick array cho CLMM swap, hoặc double-spend một account. Attacker xác định tạo vị trí bug và khai thác.
Phơi nhiễm
- Tích hợp buggy — thường là nguồn của bug.
- Raydium — chỉ nếu bug kích hoạt hành vi không dự kiến trong chính 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 qua CPI — các bộ xác thực tài khoản của Raydium bắt các tài khoản không đúng hình dạng và hoàn lại. Các exploit trong hệ sinh thái rộng hơn đã xảy ra qua bug chương trình tùy chỉnh tạo với AMM nhưng không bắt nguồn từ AMM.Phòng vệ
- Các chương trình gọi nên sử dụng helper CPI Anchor (không phải hand-built instruction) nếu có thể — type-safety bắt hầu hết misuse.
- Các integration test chống lại mainnet-forked state phủ các trường hợp composition.
6. Thỏa hiệp Admin / Key
Tấn công
Một admin key (upgrade authority, AmmConfig admin, protocol fee claim) bị thỏa hiệp. Attacker triển khai upgrade độc hại để xả pool, hoặc sửa AmmConfig để định tuyến phí tới ví attacker, hoặc xả protocol fee.Phơi nhiễm
Tất cả vai trò được ghi trongsecurity/admin-and-multisig.
Phòng vệ
- 3/4 multisig trên upgrade authority yêu cầu thỏa hiệp 4 signer độc lập.
- 24-hour timelock trên upgrade cho người dùng thời gian để unwind trước khi upgrade độc hại kích hoạt.
- Theo dõi hoạt động — cảnh báo bất kỳ hoạt động multisig nào qua hàng đợi công khai của Squads.
Sự cố lịch sử
Admin key của pool AMM v4 bị thỏa hiệp vào tháng 12 năm 2022 (pre-multisig). Fix: chuyển tất cả authority sang Squads multisig. Sau fix, 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 attacker tinh vi khai thác rounding hoặc fee-accounting edge case 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 fee-growth làm tròn chống lại người dùng, tích lũy bụi.
- Tick crossing ghi có/debit sai delta fee_growth.
- Integer overflow trong sản phẩm
sqrtPrice * liquidity.
Phơi nhiễm
Toán học tùy chỉnh phức tạp. Audit và fuzzing là phòng vệ chính.Thái độ của Raydium
CLMM đã có hai audit độc lập (OtterSec + MadShield) cộng với fuzzing dựa trên tính chất liên tục. Không tìm thấy bug ảnh hưởng tới production. Số họcsqrt_price_x64 Q64.64 sử dụng toán học 128-bit bão hòa với unit test bao phủ các tick biên.
8. Nhầm lẫn Position-NFT
Tấn công
Một người dùng bị lừa ký transaction chuyển CLMM position NFT của họ cho attacker. Attacker hiện sở hữu liquidity của position.Phơi nhiễm
Bất kỳ position NFT holder nào.Phòng vệ
- Wallet UI nên nhận diện Raydium position NFT 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ý transaction chuyển NFT.
Thái độ của Raydium
Position NFT triển khai tiêu chuẩn metadata của Metaplex; ứng dụng ví hiểu CLMM position hiển thị chúng là liquidity position thay vì NFT có thể giao dịch. Hầu hết wallet Solana lớn hiển thị chúng đặc biệt từ năm 2026.9. Thao túng dòng phần thưởng Farm
Tấn công
Một farm creator tài trợ vault phần thưởng, thu hút staker, sau đó gọirestartRewards với các tham số làm cho tính toán pending-reward kỳ lạ, ăn cắp giá trị harvest.
Phơi nhiễm
Farm với farm creator độc hại. Farm v6 ràng buộc sức mạnh creator chặt chẽ; tấn công này không hoạt động.Phòng vệ
Admin instruction 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 pre-change bị corruption retroactively.
Thái độ của Raydium
Audit farm của OtterSec cụ thể kiểm tra các tình huống restart-reward; không tìm thấy exploit.10. Phân kỳ Simulation-vs-Execution
Tấn công
Một attacker xây dựng transaction mô phỏng thành công nhưng hoàn lại khi thực thi (hoặc ngược lại). Dùng để làm phiền ví dựa vào mô phỏng để hiển thị.Phơi nhiễm
Ví hiển thị “bạn sẽ nhận được X” dựa trên mô phỏng.Phòng vệ
- Sử dụng
simulateTransactionvới cùng blockhash như submission thực. - Hiển thị output dự kiến là ”≈” (xấp xỉ) không phải chính xác.
- Re-simulate ngay trước submission.
Thái độ của Raydium
Mô phỏng CLMM xác định được cho pool state hiện tại; phân kỳ chỉ xảy ra nếu state thay đổi giữa mô phỏng và thực thi (trường hợp bình thường, xử lý via slippage bound).Bảng tóm tắt
| Vector | Cụ thể Raydium | Phòng vệ tại | Rủi ro còn lại cho người dùng |
|---|---|---|---|
| Sandwich / MEV | Có | Submission layer (Jito, slippage) | Thấp nếu dùng Jito |
| Thao túng giá | Chỉ composability | Sử dụng TWAP | Thấp nếu TWAP được tiêu thụ |
| Tấn công donation | CPMM | MINIMUM_LIQUIDITY | Thấp |
| Lạm dụng transfer-hook | Pool Token-2022 | UI flags | Trung bình cho hook không xác minh |
| CPI exploit | Bug của tích hợp | Raydium validator hoàn lại | Thấp (bug ở trong tích hợp) |
| Thỏa hiệp admin | Tất cả chương trình | Multisig + timelock | Thấp (24h để phản ứng) |
| Toán tick CLMM | CLMM | Audit + fuzzing | Thấp |
| Nhầm lẫn Position NFT | CLMM | Wallet UX | Thấp với ví hiện đại |
| Thao túng farm | Farm v6 | Sức mạnh creator bị ràng buộc | Thấp |
| Phân kỳ mô phỏng | Bất kỳ | Wallet UX | Thấp |
Những gì người dùng có thể làm
- Mặc định slippage chặt chẽ; tăng chỉ khi cần.
- Sử dụng Jito-enabled wallet / swap flow.
- Xác minh mint extension trước LP.
- Giám sát Squads multisig cho pending upgrade.
- Đa dạng hóa trên các pool; đừng tập trung tất cả LP của bạn trong một pool launch mới.
Những gì tích hợp có thể làm
- Sử dụng CLMM ObservationState TWAP cho giá dẫn xuất.
- Xác thực ràng buộc tài khoản khi tạo qua CPI.
- Lọc pool theo
tagsfield (bỏ quascam,honeypot, transfer-hook không xác minh). - Đặt slippage bound hợp lý; đừng chấp nhận 0 slippage từ user input.
- Sử dụng
simulateTransactioncẩn thận — ghi chép nó là một ước tính.
Con trỏ
security/oracle-and-token-risks— Rủi ro Token-2022 chi tiết.security/admin-and-multisig— cấu trúc authority.security/disclosure— chương trình bug-bounty.integration-guides/routing-and-mev— Giảm thiểu MEV.
- 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.


