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 →

​
Router tidak melakukan matematika apa pun

Program routing tidak menerapkan logika penentuan harga apa pun. Ini adalah orkestratur murni: menerima rute, meneruskan akun ke program anak, dan menghubungkan aliran token. Setiap hop menentukan harga berdasarkan kurva pool-nya sendiri:
  • Hop AMM v4: menggunakan formula constant-product (x · y = k) dengan penentuan harga hibrida OpenBook. Lihat products/amm-v4/math.
  • Hop CPMM: menggunakan formula constant-product dengan tingkat biaya yang dapat dikonfigurasi. Lihat products/cpmm/math.
  • Hop CLMM: menggunakan matematika tick likuiditas terkonsentrasi. Lihat algorithms/clmm-math.
  • Hop Stable: menggunakan kurva stable-swap untuk aset sejenis. Lihat products/stable/math.
Keterlibatan router hanya mencakup:
  1. Memanggil instruksi swap setiap pool melalui CPI.
  2. Mengumpulkan jumlah output.
  3. Meneruskannya sebagai jumlah input ke hop berikutnya.
  4. Memeriksa output akhir terhadap batas slippage pengguna.

​
Slippage gabungan

Pada rute multi-hop, slippage pada setiap hop bersifat gabungan. Slippage kecil pada hop 1 menjadi slippage yang lebih besar pada hop 2 karena volume yang masuk ke hop 2 sudah berkurang. Contoh: 
Route: USDC → SOL → STEP

Pool 1 (USDC / SOL):
  Input: 1000 USDC
  Slippage: 1% (spot akan memberikan 0.5 SOL, tetapi Anda mendapatkan 0.495 SOL)
  Output: 0.495 SOL

Pool 2 (SOL / STEP):
  Input: 0.495 SOL (sudah berkurang)
  Slippage: 1% (spot akan memberikan 495 STEP, tetapi Anda mendapatkan 490 STEP)
  Output: 490 STEP

Total slippage efektif pada USDC → STEP: 1.99%, bukan 1% + 1% = 2%.
Ketika Anda menyediakan minimum_amount_out, router memeriksa output akhir Anda terhadap batas global ini. Setiap hop juga memeriksa swap-nya terhadap struktur biaya lokal-nya sendiri, tetapi router tidak melakukan re-quote di tengah rute—Anda harus pre-compute rute dan menyediakan toleransi slippage yang cukup.

​
Hop CLMM dan limit_prices

Untuk setiap hop ke dalam pool CLMM, router memeriksa bahwa sqrt_price_x64 pool saat ini berada dalam batas yang ditentukan. Batas diteruskan sebagai VecDeque<u128> bernama limit_prices:
  • Satu sqrt_price_x64 per hop CLMM dalam rute.
  • sqrt_price_x64 adalah representasi harga berbasis tick yang digunakan oleh CLMM. Lihat algorithms/clmm-math untuk definisinya.
  • Router menerapkan:
  sqrt_price_lower <= pool.sqrt_price_x64 <= sqrt_price_upper
untuk setiap hop CLMM, menolak swap jika harga berada di luar batas.

​
Varian instruksi dan limit_prices

  • SwapBaseInWithUserAccount, SwapBaseOutWithUserAccount (Legacy, tag 0 dan 1): VecDeque limit_prices adalah wajib. Deque kosong ditolak dengan kesalahan jika ada hop adalah pool CLMM. Anda harus menyediakan satu harga per hop CLMM, secara berurutan.
  • SwapBaseIn, SwapBaseOut (Current, tag 8 dan 9): VecDeque limit_prices adalah opsional. Deque kosong diabaikan tanpa suara; tidak ada pemeriksaan harga yang dilakukan. Kode baru harus menggunakan ini.

​
Membangun limit_prices

Untuk rute dengan M hop CLMM, deque harus berisi tepat M entri. Urutkan berdasarkan hop: 
limit_prices = [
  sqrt_price_for_first_clmm_hop,
  sqrt_price_for_second_clmm_hop,
  ...
]

​
Kapan memeriksa limit_prices

sqrt_price_x64 adalah snapshot dari harga pool saat ini. Ini berubah secara terus-menerus saat swap dieksekusi. Anda harus:
  1. Mengambil state pool saat ini dari on-chain.
  2. Menghitung batas yang dapat diterima (mis., ±0,5% dari harga saat ini).
  3. Mengodekan batas tersebut ke dalam limit_prices.
  4. Sertakan batas dalam instruksi router Anda.
Jika harga pool bergeser melampaui batas Anda sebelum transaksi tertanam, router akan menolaknya.

​
Penanganan biaya

Setiap pool mengenakan biaya sesuai dengan konfigurasinya:
  • AMM v4: 0,25% (tetap) dibagi antara LP, protokol, dan dana.
  • CPMM: dapat dikonfigurasi per AmmConfig (default 0,25%, pembagian bervariasi menurut tingkat).
  • CLMM: dapat dikonfigurasi per pool, diambil dari jumlah input.
  • Stable: seperti AMM v4, 0,25% dibagi.
Router tidak mengenakan biaya sendiri. Semua penanganan biaya didelegasikan ke setiap pool anak. Output dari hop N sudah memiliki biaya hop-nya yang dipotong. Lihat dokumentasi biaya pool individual:

​
Contoh akuntansi multi-hop

Misalkan Anda merutekan USDC → SOL → STEP di seluruh dua pool constant-product, masing-masing dengan biaya 0,25%: 
Input: 1000 USDC
Pool 1 (USDC/SOL):
  Biaya yang diambil: ceil(1000 * 0.25%) = 2.5 USDC
  Input bersih ke kurva: 997.5 USDC
  Output kurva (sebelum slippage): 0.5 SOL
  Margin slippage: asumsikan 1%, jadi Anda mendapatkan ~0.495 SOL

Pool 2 (SOL/STEP):
  Input: 0.495 SOL
  Biaya yang diambil: ceil(0.495 * 0.25%) ≈ 0.001 SOL
  Input bersih ke kurva: 0.494 SOL
  Output kurva: ~494 STEP
  Margin slippage: 1%, jadi Anda mendapatkan ~489 STEP

Final output: ~489 STEP
Router memverifikasi: 
489 >= minimum_amount_out  // ditentukan oleh pengguna
Jika salah, seluruh rute gagal secara atomik.

​
Pertimbangan presisi

Seperti semua program Solana, router menggunakan aritmetika bilangan bulat:
  • Semua jumlah adalah u64 (lamports atau unit terkecil token).
  • Kalkulasi kurva menggunakan perantara u128 jika diperlukan untuk menghindari overflow.
  • Konvensi pembulatan tergantung pada program anak. Router tidak melakukan re-round.
Jika hop menghasilkan jumlah nol karena rasio harga ekstrem (mis., menukar 1 lamport pada pool 1B:1), router meneruskan nol itu ke hop berikutnya, yang mungkin kemudian menolaknya sebagai tidak cukup. Lihat kode kesalahan pool individual.

​
Kemana selanjutnya