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 →

Hai khái niệm riêng biệt

Price impactslippage thường bị nhầm lẫn trong các giao diện nhưng chúng đề cập đến những thứ khác nhau.
  • Price impact là một tính chất xác định của một giao dịch với trạng thái pool cụ thể. Với (Δin, reserves), price impact có thể tính toán được hoàn toàn trước khi giao dịch được gửi đi.
  • Slippage là hiệu số thực tế giữa giá mà bạn mong đợi tại thời điểm báo giá và giá mà bạn thực tế nhận tại thời điểm thực hiện. Nó là một hàm của độ trễ, các giao dịch đồng thời và thứ tự đưa vào block — không phải của toán học pool.
Một báo giá 1% đối với một pool vô tư có 0% slippage nếu nó được đưa vào block tiếp theo; 1% đó là price impact. Cùng một báo giá đó sẽ kém hơn 0,2% nếu một giao dịch khác nhấn vào pool trước — 0,2% bổ sung đó là slippage.

Định nghĩa hình thức

Price impact

p_before = pool.spot_price()
p_after  = pool.spot_price_if_trade(Δin) áp dụng
impact   = (p_before − p_after) / p_before       // có thể có dấu
Đối với CPMM: impact ≈ 2 · Δin / reserve_in cho những giao dịch nhỏ. Đối với CLMM: phụ thuộc vào số lượng tick mà giao dịch vượt qua; thường phẳng trong phạm vi tick hiện tại, nhảy tại mỗi lần vượt tick.

Slippage thực tế

quoted_out = amount_out được tính tại thời điểm báo giá
actual_out = amount_out được quan sát trên chuỗi
slippage   = (quoted_out − actual_out) / quoted_out
Slippage luôn không âm (hoặc bằng không), giả sử báo giá là trung thực. Một giá trị âm có nghĩa là bạn nhận được nhiều hơn so với báo giá — điều này có thể xảy ra nếu trạng thái pool di chuyển theo hướng có lợi cho bạn giữa báo giá và thực hiện.

Tính toán minAmountOutmaxAmountIn

Mỗi swap của Raydium có một ranh giới bảo vệ slippage:
  • SwapBaseInput(amount_in, min_amount_out) — nhập chính xác, giới hạn dưới đầu ra.
  • SwapBaseOutput(max_amount_in, amount_out) — đầu ra chính xác, giới hạn trên đầu vào.
SDK tính toán các giá trị này như sau:
const computed = raydium.<pool_type>.computeAmountOut({
  poolInfo,
  amountIn,
  mintIn,
  mintOut,
  slippage: 0.005,     // 0.5% tolerance
});

// computed.amountOut         — báo giá "mong đợi"
// computed.minAmountOut      — amountOut × (1 − slippage), được sử dụng làm ranh giới trên chuỗi
// computed.priceImpact       — xác định, chỉ dựa trên trạng thái pool
// computed.fee               — tổng phí được tính (tất cả các thành phần cộng lại)
Dung sai slippage là một bộ đệm xung quanh price impact, không phải là price impact chính nó. Dung sai 0,5% có nghĩa là “chấp nhận nhiều nhất là 0,5% tệ hơn báo giá của tôi” — độc lập với việc price impact là 0,01% (giao dịch nhỏ) hay 2% (giao dịch lớn). Đối với giao dịch có price impact 2% với dung sai 0,5%, minAmountOut2,5% dưới spot trước giao dịch — về cơ bản là tổng của impact và dung sai.

Dung sai slippage được khuyến nghị

Không có một con số nào là hoàn toàn chính xác; ranh giới phù hợp tùy thuộc vào:
  1. Sự ổn định của cặp. Các pool stablecoin-stablecoin có thể an toàn sử dụng 0,1%. Các pool cặp meme không ổn định thường cần 3–5% chỉ để đáng tin cậy hạ cánh.
  2. Kích thước giao dịch. Các giao dịch lớn hơn có price impact lớn hơn, vì vậy dung sai cần phải tỷ lệ với chúng để tránh hoàn nguyên. Mặc định auto-slippage của SDK xung quanh max(0,5%, 2 × price_impact) vì lý do này.
  3. Độ trễ đưa vào block. Các giao dịch nằm trong mempool trong nhiều block sẽ phải đối mặt với nhiều giao dịch đồng thời hơn. Các gói Jito và phí ưu tiên làm giảm điều này.
Quy tắc nhanh (mặc định giao diện Raydium):
Loại cặpDung sai mặc định
Stable-stable (USDC-USDT, USDC-USDS)0,1%
Stable-major (USDC-SOL, USDC-BTC)0,5%
Major-major (SOL-BTC, SOL-ETH)1%
Volatile (token meme, long-tail không thanh khoản)3–5%

Sự khác biệt giữa các loại AMM

CPMM

Price impact mượt mà và liên tục (dạng đóng 2 · Δin / reserve_in). Dung sai slippage tỷ lệ tuyến tính với kích thước giao dịch.

AMM v4

Cùng toán học đường cong với CPMM, nhưng “reserves hiệu quả” bao gồm các lệnh giới hạn được đăng bởi pool trên OpenBook. Thực tế điều này có nghĩa là:
  • Báo giá dựa trên số dư vault thô sẽ ước tính thấp hơn reserves và do đó ước tính thái quá impact.
  • SDK lấy AmmInfo và tổng vault + on_book.free + on_book.locked để có con số chính xác.
  • Trạng thái OpenBook cũ (crank bị chặn) có thể khiến impact được báo giá khác với hiện thực trên chuỗi. Các aggregator thường pre-crank (permissionless MonitorStep) trước một giao dịch AMM-v4 lớn.

CLMM

Price impact là từng mảnh. Trong phạm vi tick hiện tại, impact xấp xỉ tuyến tính trong Δin / L. Vượt qua một ranh giới tick có thể thay đổi L rời rạc, gây ra một bước nhảy đột ngột về giá biên. Một giao dịch vượt qua nhiều tick thưa thớt có thể có impact cao hơn nhiều so với quy tắc 2 · Δin / reserve. Báo giá CLMM của SDK lặp lại bước swap một cách xác định để trả về amountOut chính xác mong đợi, vì vậy minAmountOut = amountOut · (1 − slippage) là chính xác. Nhưng giá trị return priceImpact nên được diễn giải là “sự chênh lệch giữa spot trước giao dịch và spot sau giao dịch”, mà trên CLMM có thể lớn hơn nhiều so với slippage hiệu quả của swap cho người dùng chỉ quan tâm đến amount_out.

Đường cong LaunchLab

Tương tự như CPMM nhưng với đường cong không đối xứng (bậc hai hoặc virtual-reserves). Impact phát triển nhanh hơn đối với những người mua sau khi đường cong dốc hơn khi tiến gần đến tốt nghiệp. Giao diện pre-buyer nên cảnh báo khi một lệnh mua dự kiến sẽ đẩy đường cong hơn ~5% quote_reserve_target trong một giao dịch.

Cân nhắc MEV

Trên Solana, việc trích xuất MEV chống lại các swap chủ yếu có dạng sandwich attacks: một bot đặt giao dịch back-run được thực hiện sau của bạn, cộng với một front-run được thực hiện trước, cả hai ở cùng một slot. Giao dịch của bạn được điền với giá tệ hơn so với khi không có sandwich; back-run nắm bắt sự khác biệt. Các biện pháp giảm thiểu:
  1. Tight minAmountOut. Ranh giới slippage agressive khiến giao dịch nạn nhân hoàn nguyên nếu bị sandwich nặng, bảo vệ quỹ (nhưng lãng phí gas). Trên Solana đây là thực hành tiêu chuẩn — từ chối rẻ.
  2. Các gói Jito. Gửi qua Jito với một mẹo được gói lại loại trừ những người trung gian khỏi việc sắp xếp lại tx của bạn. Các gói hạ cánh dưới dạng các khối nguyên tử.
  3. Phí ưu tiên. Một phí ưu tiên cao làm tăng khả năng giao dịch của bạn được đặt trong block của leader hiện tại trước khi một sandwicher có thể phản ứng. Kém mạnh mẽ hơn gói, tiêu chuẩn hơn.
  4. RPC riêng tư. Gửi qua RPC riêng tư (hoặc qua endpoint trực tiếp của validator) giảm cửa sổ thời gian mà một sandwicher mempool có thể quan sát giao dịch của bạn.
SDK của Raydium không gói lại; các nhà tích hợp thường đặt Jito trên đầu. Xem integration-guides/routing-and-mev để biết các mẫu.

Slippage cho các tuyến đường đa bước

Khi một swap định tuyến qua nhiều pool (ví dụ USDC → SOL → RAY), dung sai slippage nên được áp dụng cho từng bước, không chỉ end-to-end:
// Sai: 0.5% áp dụng ở cuối chỉ, vì vậy bất kỳ bước trung gian nào trượt sẽ làm hỏng bước thứ hai.
const finalMin = finalAmount * (1 - 0.005);

// Tốt hơn: mỗi bước áp dụng ranh giới của riêng nó.
const hop1Min  = hop1Amount * (1 - 0.005);
const hop2Min  = hop2Amount * (1 - 0.005);
// End-to-end điều này chặt chẽ hơn (hợp chất), nhưng nguyên tử — nếu bất kỳ bước nào xấu đi, tx sẽ hoàn nguyên sớm.
Router của SDK áp dụng ranh giới per-hop tự động khi bạn gọi raydium.trade.swap. Đối với các router tùy chỉnh, lặp lại mẫu.

Báo cáo cho người dùng

Quy tắc nhanh cho một giao diện swap tốt:
  • Hiển thị cả hai price impact dự kiến và dung sai slippage riêng biệt.
  • Tô sáng khi price impact vượt quá ~2% — cảnh báo “high impact”.
  • Tô sáng khi price impact vượt quá dung sai — giao dịch gần như chắc chắn sẽ hoàn nguyên.
  • Đối với các cặp không ổn định, cung cấp chế độ “high slippage mode” giãn rộng ranh giới và hiển thị cảnh báo mạnh hơn.

Con trỏ

Nguồn:
  • Triển khai slippage/impact của Raydium SDK v2.
  • Flashbots / Jito trên Solana MEV.