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 →

​
Invariant

Pool mempertahankan coin_reserve × pc_reserve = k, di mana: 
coin_reserve = coin_vault_balance
             + orders_posted_on_openbook.base
             + pending_coin_fill_not_yet_settled
pc_reserve   = pc_vault_balance
             + orders_posted_on_openbook.quote
             + pending_pc_fill_not_yet_settled
             - accrued_pnl_pc
Ada dua hal yang perlu diperhatikan:
  1. Reserve mencakup jumlah yang ter-commit di OpenBook. Limit order AMM tetap menjadi bagian dari likuiditasnya — bukan “hilang” ke order book, hanya disimpan di sana. Menghitung k hanya dari saldo vault on-chain meremehkan reserve.
  2. Akrual PnL (need_take_pnl_*) dikurangi agar kurva terjaga saat admin menyapu biaya. Prinsip yang sama dengan pengecualian protocol_fees_* CPMM.
Setiap operasi Swap* memaksa k' ≥ k setelah menambahkan bagian biaya LP kembali ke dalam reserve.

​
Konvensi biaya

AMM v4 menggunakan biaya rasio (pasangan numerator/denominator) daripada konvensi 1/1_000_000 CPMM / CLMM. Struct Fees on-chain (lihat Fees::initialize di sumber program) secara default adalah: 
Fees {
  min_separate_numerator:    5,
  min_separate_denominator:  10_000,   //  5/10_000 = 0.05%

  trade_fee_numerator:      25,
  trade_fee_denominator:    10_000,    // 25/10_000 = 0.25% — digunakan untuk pricing limit order OpenBook

  pnl_numerator:            12,
  pnl_denominator:          100,       // 12/100   = 12%   — bagian protokol DARI biaya swap

  swap_fee_numerator:       25,
  swap_fee_denominator:     10_000,    // 25/10_000 = 0.25% — biaya bruto pada swap path AMM
}
Interpretasi (default mainnet yang dipublikasikan):
  • Total biaya swap: swap_fee = amount_in × 25 / 10_000 = 0.25% dari input bruto.
  • Bagian protokol: pnl_numerator / pnl_denominator = 12 / 100 = 12% dari biaya swap, yang setara dengan 0.25% × 12% = 0.03% dari volume. Bagian ini terakrual ke counter PnL dan disapu oleh WithdrawPnl.
  • Bagian LP: sisa 88% dari biaya swap, yang setara dengan 0.25% × 88% = 0.22% dari volume. Tetap dalam pool dan meningkatkan k.
  • Tanpa bagian dana. AMM v4 tidak memiliki pemisahan biaya dana CPMM/CLMM.
Perhatikan bahwa pnl_numerator / pnl_denominator adalah fraksi dari biaya, bukan dari volume perdagangan — salah baca umum dari nama-nama field ini. trade_fee_numerator / trade_fee_denominator (juga 25 / 10_000) adalah field terpisah yang digunakan integrasi OpenBook saat menghitung harga termasuk-biaya untuk grid limit order AMM; secara default sama dengan swap_fee tetapi dibaca dari path kode yang berbeda. Penyimpangan dari default ini jarang terjadi tetapi ada di beberapa pool legacy; selalu baca biaya dari AmmInfo.fees sebelum memberikan kutipan.

​
Matematika swap langsung (path AMM)

Kasus paling sederhana: pengguna swap terhadap vault pool tanpa berinteraksi dengan OpenBook. Reserve internal pool (termasuk alokasi on-book) adalah penyebut. SwapBaseIn (input tepat): 
amount_after_fee = amount_in − ceil(amount_in × swap_fee_numerator / swap_fee_denominator)
amount_out = amount_after_fee × out_reserve
           / (in_reserve + amount_after_fee)
require(amount_out >= minimum_amount_out)
Reserve yang digunakan di sini adalah reserve efektif. Secara historis ini adalah coin_vault_balance + coin_posted_on_openbook + ... (vault AMM plus token yang dikunci dalam order OpenBook). Sejak deaktivasi OpenBook, saldo on-book adalah nol, jadi reserve efektif sama dengan saldo vault mentah. Path MonitorStep / implicit-settle yang pernah menyegarkan sisi OpenBook tidak lagi diperlukan secara praktis. SwapBaseOut (output tepat): 
amount_in_after_fee = ceil(in_reserve × amount_out / (out_reserve − amount_out))
amount_in_gross     = ceil(amount_in_after_fee × swap_fee_denominator
                            / (swap_fee_denominator − swap_fee_numerator))
require(amount_in_gross <= maximum_amount_in)

​
Interaksi order-book (historis)

Tidak lagi aktif. Konstruksi grid yang dijelaskan di bagian ini mencerminkan bagaimana AMM v4 awalnya mencerminkan kurva ke pasar OpenBook. Integrasi OpenBook telah dinonaktifkan; pool tidak lagi memposting atau mempertahankan order di OpenBook. Matematika di bawah dipertahankan untuk konteks — menjelaskan apa yang akun target_orders / amm_open_orders on-chain diukur dan mengapa program masih memvalidasi parameter terkait MonitorStep meskipun keeper tidak lagi menjalankannya.
Terpisah dari user swap, AMM v4 secara historis menempatkan grid limit order di pasar OpenBook. Grid dihitung dari parameter AmmInfo:
  • depth — jumlah level harga per sisi.
  • amount_wave — unit dasar ukuran per level.
  • min_size, coin_lot_size, pc_lot_size — batasan pasar OpenBook.
  • state_data.swap_acc_coin_fee, swap_acc_pc_fee — counter biaya kumulatif sejak TakePnl terakhir.
Program menurunkan harga per-level dengan berjalan keluar dari harga kurva saat ini dalam langkah rasio konstan: 
price_level(k) = curve_price × (1.0001 ^ k)       # secara konseptual
size_level(k)  = amount_wave × f(depth, k)        # terpangkas oleh depth
Harga dan ukuran eksak ditentukan oleh target_orders yang dihitung dalam build_orders dan dibandingkan dengan amm_open_orders setiap MonitorStep. Setiap perbedaan menghasilkan pembatalan + posting baru. Order yang baru diisi di OpenBook settle ke vault pool pada operasi berikutnya yang menyegarkan sisi OpenBook. Integrator jarang perlu menghitung grid — keeper Raydium mempertahankannya — tetapi berguna mengetahui bahwa:
  • Pool dengan likuiditas on-book signifikan memiliki likuiditas itu berkontribusi ke k, bukan menganggur.
  • Pasar OpenBook yang basi (event queue penuh, crank terblokir) mencegah update grid; AMM kemudian dapat mengutip harga yang berbeda dari order book yang terlihat hingga crank berikutnya.

​
Langkah settlement (PnL)

Bagian protokol 0.03% terakrual menjadi state_data.need_take_pnl_coin dan state_data.need_take_pnl_pc. TakePnl memindahkan jumlah ini keluar dari vault ke destinasi yang ditentukan admin, kemudian menolkan counter. Properti penting: reserve dalam invariant selalu dihitung minus PnL yang terakrual, jadi TakePnl tidak menggerakkan kurva. Ini cocok dengan konvensi CPMM.

​
Contoh terinci

State pool:
  • coin_reserve = 1_000_000_000_000 (1.000.000 coin-side; 6 desimal)
  • pc_reserve = 2_000_000_000_000 (2.000.000 pc-side; 6 desimal)
  • Biaya: default swap = 25/10_000, pnl = 3/10_000.
Pengguna: SwapBaseIn input-tepat 1_000_000_000 coin (1.000 coin). 
swap_fee        = ceil(1_000_000_000 * 25 / 10_000)    = 2_500_000
amount_after_fee =                                      997_500_000

amount_out = amount_after_fee * pc_reserve
           / (coin_reserve + amount_after_fee)
           = 997_500_000 * 2_000_000_000_000
           / (1_000_000_000_000 + 997_500_000)
           ≈ 1_995_015_009  (1.995,015 pc)

// Dari biaya swap 2_500_000:
pnl_share = 2_500_000 * 3 / 25  = 300_000    (pergi ke protokol via need_take_pnl_coin)
lp_share  = 2_500_000 * 22 / 25 = 2_200_000  (tetap dalam coin_reserve)

new coin_reserve = 1_000_000_000_000 + 1_000_000_000                 = 1_001_000_000_000
                   (di mana 300_000 adalah PnL yang terakrual)
  curve coin_reserve = 1_001_000_000_000 − 300_000 = 1_000_999_700_000
new pc_reserve   = 2_000_000_000_000 − 1_995_015_009                 ≈ 1_998_004_984_991

k' = curve_coin_reserve * new_pc_reserve
   ≈ 2.000_002_701E24
k  = 1_000_000_000_000 * 2_000_000_000_000
   = 2.0E24
k' > k   ✓
Bagian LP (2_200_000) tidak dipecah di mana pun — hanya residual yang menaikkan k'.

​
Aturan presisi

  • Perkalian reserve menggunakan u128; pembagian final pembulatan menuju nol.
  • swap_fee pembulatan naik (agar pool tidak kurang mengenai biaya).
  • amount_in untuk SwapBaseOut pembulatan naik (agar pengguna tidak kurang bayar).
  • Pool dengan rasio reserve ekstrem dapat hit ZeroTradingTokens pada input sangat kecil; konvensi yang sama seperti CPMM.

​
Keterbatasan vs CPMM

  • Reserve AMM v4 mencakup porsi yang disimpan di OpenBook, jadi integrator tidak dapat mengutip dengan benar dari getTokenAccountBalance saja. Selalu ambil state lengkap (vault + open_orders.free + open_orders.locked), atau gunakan SDK / API quote.
  • AMM v4 tidak mengekspos TWAP terstruktur on-chain. Konsumen eksternal yang menginginkan harga dengan dukungan AMM-v4 harus menghitungnya sendiri dari log perdagangan.
  • Token-2022 tidak didukung.

​
Ke mana selanjutnya

Sumber: