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 →
Setiap transaksi Solana menetapkan (secara implisit atau eksplisit) dua parameter: batas compute unit (CU maksimum yang mungkin dikonsumsi oleh tx; default 200.000 × jumlah instruksi hingga batas per-tx) dan biaya prioritas dalam micro-lamports per CU. Mengecilkan salah satu dari keduanya membunuh transaksi — batas CU yang terlalu rendah menyebabkan ProgramFailedToComplete; biaya prioritas yang terlalu rendah menyebabkan tx tetap tidak dikonfirmasi hingga kadaluarsa.

Dua pengaturan

import { ComputeBudgetProgram } from "@solana/web3.js";

const tx = new Transaction()
  .add(ComputeBudgetProgram.setComputeUnitLimit({ units: 250_000 }))
  .add(ComputeBudgetProgram.setComputeUnitPrice({ microLamports: 50_000 }))
  .add(yourRaydiumSwapIx);
  • setComputeUnitLimit(units) — membatasi komputasi; transaksi membayar paling banyak units CU.
  • setComputeUnitPrice(microLamports) — penawaran biaya prioritas, dalam micro-lamports per CU. Total biaya prioritas = units × microLamports × 1e-6 lamports.
Matematika biaya: batas 250k CU pada 50k micro-lamports/CU menawarkan 250_000 × 50_000 / 1e6 = 12.500 lamports ≈ 0,0000125 SOL ≈ $0,003 pada SOL $200. Biaya prioritas pada skala ini adalah noise untuk sebagian besar swap pengguna tetapi signifikan untuk bot yang melakukan 1000 txs/hari.

Benchmark CU per instruksi

Benchmark dari log eksekusi mainnet, rata-rata di berbagai run terbaru. Angka-angka bersifat perkiraan (±15%); ukur ulang untuk alur spesifik Anda.
InstruksiSPL TokenToken-2022 (sederhana)Token-2022 (biaya transfer)
CPMM initialize_pool180.000200.000
CPMM swap_base_input140.000180.000200.000
CPMM swap_base_output150.000185.000205.000
CPMM deposit130.000160.000180.000
CPMM withdraw120.000150.000170.000
CLMM create_pool70.00085.000
CLMM open_position_v2120.000140.000160.000
CLMM increase_liquidity_v2150.000175.000195.000
CLMM decrease_liquidity_v2140.000165.000185.000
CLMM swap_v2 (0 tick crossings)170.000205.000225.000
CLMM swap_v2 (1 tick crossing)220.000255.000275.000
CLMM swap_v2 (3 tick crossings)320.000355.000375.000
CLMM collect_fee80.00095.000105.000
AMM v4 swap_base_in140.000
AMM v4 deposit120.000
AMM v4 withdraw110.000
Farm v6 create_farm70.00085.000
Farm v6 deposit (1 slot reward)130.000155.000175.000
Farm v6 deposit (3 slot reward)220.000255.000275.000
Farm v6 withdrawcocok dengan deposit
Farm v6 harvestcocok dengan deposit
Farm v3/v5 deposit100.000
LaunchLab initialize100.000
LaunchLab buy_exact_in140.000
LaunchLab graduate250.000
Baris “tick crossings” untuk CLMM adalah variabel CU terbesar. Jika Anda tidak tahu berapa banyak tick yang akan dicapai swap, anggaran untuk kasus terburuk — 8 crossing adalah batas keras (program memuat paling banyak 8 tick arrays).

Transaksi yang dikomposisi

Jumlahkan anggaran individual dan tambahkan:
  • +1.500 CU per frame CPI — overhead tetap runtime untuk setiap cross-program call.
  • +20.000 CU per ATA creationcreate_associated_token_account tidak gratis.
  • +5.000 CU untuk setComputeUnitLimit / setComputeUnitPrice masing-masing.
Contoh: swap pengguna yang membuat output ATA dan membungkus SOL native:
wrap_sol (create_ata + system transfer + sync_native)   ≈ 30.000
CPMM swap_base_input (SPL)                              ≈ 140.000
close_account (unwrap)                                  ≈ 5.000
ComputeBudget instructions                              ≈ 10.000
────────────────────────────────────────────────────────
Total                                                   ≈ 185.000 → budget 250.000
Padding: tetapkan batas CU ~25% di atas penggunaan yang diharapkan. Meremehkan biaya keseluruhan tx; meremehkan hanya menaikkan biaya biaya prioritas secara proporsional (biaya prioritas adalah units × microLamports, jadi ~25% over-budget berharga 25% ekstra dalam biaya prioritas).

Estimasi biaya prioritas

Pasar fee lokal Solana berarti biaya prioritas adalah per-writable-account. Tx yang menulis ke akun hot (pool state populer) membayar lebih dari tx yang menulis ke akun cold. Level fee global bukan metrik yang tepat untuk swap Raydium; Anda ingin biaya pada pool spesifik yang Anda sentuh.

Strategi 1: Estimator penyedia RPC

Setiap penyedia RPC utama mempublikasikan estimator biaya prioritas yang menanyakan biaya terbaru pada akun spesifik:
// Helius
const response = await fetch(`https://mainnet.helius-rpc.com/?api-key=${apiKey}`, {
  method: "POST",
  body: JSON.stringify({
    jsonrpc: "2.0",
    id:      "fee-estimate",
    method:  "getPriorityFeeEstimate",
    params: [{
      accountKeys: [poolStatePubkey.toBase58()],
      options:     { priorityLevel: "High" },
    }],
  }),
});
const { result } = await response.json();
const microLamports = result.priorityFeeEstimate;
Level prioritas di seluruh sebagian besar penyedia: Min / Low / Medium / High / VeryHigh / UnsafeMax. Petakan ke persentil:
LevelPersentilKasus penggunaan
Min25thTraffic bot latar belakang, tidak mendesak
Low50thSwap pengguna normal
Medium60thDefault untuk UI dompet
High75thArbitrase time-sensitive
VeryHigh95thLikuidasi, exit last-chance
Penyedia: Helius (getPriorityFeeEstimate), Triton (getRecentPrioritizationFees dengan daftar akun), QuickNode (serupa).

Strategi 2: Query RPC langsung

Gunakan RPC standar getRecentPrioritizationFees:
const fees = await connection.getRecentPrioritizationFees({
  lockedWritableAccounts: [poolStatePubkey],
});

// fees: Array<{ slot, prioritizationFee }>
// Slot N terbaru; default ~150 slot.

const median = percentile(fees.map(f => f.prioritizationFee), 0.5);
Ini adalah metode RPC Solana vanilla; bekerja dengan penyedia mana pun. Downside: sampelnya kecil (150 slot ≈ 60 detik) dan bising. Untuk estimasi yang lebih mulus, gunakan agregasi penyedia.

Strategi 3: Penyesuaian diri historis

Untuk bot yang menjalankan alur konstan, lacak laju landed vs. expired Anda sendiri:
per-pool target: 80% land rate pada <30s
if current_land_rate < 80%: priorityFee += 10%
if current_land_rate > 95%: priorityFee -= 5%
Ini self-corrects lebih cepat dari estimator publik dan menangkap struktur per-pool yang tidak selalu dilihat estimator publik.

Menangani kegagalan CU-exhaustion

Gejala: tx gagal dengan exceeded maximum number of instructions allowed (200000) atau ProgramFailedToComplete. Diagnosis:
solana confirm <tx-sig> -v
# Cari "consumed N of M compute units" dan instruksi mana yang menghabiskan.
Perbaikan:
  1. Naikkan batas CU. Jika tx Anda menggunakan 195k dari anggaran 200k, naikkan ke 300k.
  2. Pisahkan transaksi. Jika Anda mencapai batas 1,4M per-tx, pecah menjadi dua tx. Farm harvest then stake adalah satu klasik untuk dipecah ketika rewards banyak.
  3. Trim akun. Setiap akun writable tambahan menambah ~2.000 CU. Memangkas akun yang tidak digunakan membantu pada kasus marginal.
  4. Gunakan lookup tables. Lookup LUT adalah ~50 CU per resolved address, menghemat 5.000 CU dari referensi akun penuh per entry.

Menangani transaksi yang macet

Gejala: tx dikirim, tidak pernah confirm, akhirnya kadaluarsa dengan BlockhashNotFound. Diagnosis:
  • getSignatureStatuses([sig]) mengembalikan null → leader tidak pernah melihatnya.
  • Mengembalikan { confirmationStatus: null } → leader melihatnya tetapi tidak memasukkan.
Perbaikan:
  1. Naikkan biaya prioritas. Kirim ulang dengan 2× biaya saat ini.
  2. Bangun ulang dengan blockhash segar. Waktu hidup blockhash adalah ~60 detik; di luar itu tx tidak valid terlepas dari biaya.
  3. Broadcast multi-RPC. Beberapa RPC memiliki konektivitas leader yang lebih baik daripada yang lain. Kirim ke 3–5 secara paralel.
  4. Beralih ke bundle Jito. Lihat integration-guides/routing-and-mev. Bundle melewati antrian paket publik.
Kerangka logika percobaan ulang:
async function submitWithRetry(buildTx, maxAttempts = 5) {
  for (let attempt = 0; attempt < maxAttempts; attempt++) {
    const tx = await buildTx({
      priorityFee: basePriorityFee * Math.pow(1.5, attempt),
      blockhash:   (await connection.getLatestBlockhash()).blockhash,
    });

    try {
      const sig = await connection.sendRawTransaction(tx.serialize(), {
        skipPreflight: attempt > 0,  // skip after first try to save latency
      });

      const result = await connection.confirmTransaction(sig, "confirmed");
      if (result.value.err) {
        // Logic error; don't retry.
        throw result.value.err;
      }
      return sig;

    } catch (e) {
      if (isExpiredError(e)) continue;  // retry
      if (isRevertError(e)) throw e;    // don't retry; deterministic failure
      throw e;
    }
  }
  throw new Error("submit: exhausted retries");
}

Dalam kemacetan

Ketika jaringan kemacetan (dashboard Jupiter / Jito bundle menunjukkan backlog, latensi RPC melonjak, tingkat kadaluarsa tx naik), sesuaikan:
ParameterKondisi normalKondisi kemacetan
Batas CU+25% di atas estimasi+25% di atas estimasi (tidak berubah)
Persentil biaya prioritas50th75th–95th
Jumlah retry35–7
Backoff retry500ms1000ms
Gunakan bundle JitoOpsionalSangat direkomendasikan
Refresh blockhash pada retryYaYa, wajib
Menonton sinyal kemacetan:
  • Persentil 75th biaya prioritas > 500k micro-lamports: kemacetan.
  • Jito persentil 50th tip > 0,001 SOL: kemacetan.
  • RPC response p99 > 2s: masalah RPC-spesifik atau kemacetan.

Anggaran fee untuk bot

Bot trading yang menjalankan ~1000 txs/hari memerlukan anggaran biaya prioritas. Kalkulasi kasar:
Rata-rata CU per tx:          ~250.000
Biaya persentil 50th:        ~20.000 micro-lamports/CU
Biaya per tx:                250_000 × 20_000 × 1e-6 = 5_000 lamports = 5e-6 SOL
Biaya harian (1000 tx):       5e-3 SOL ≈ $1 @ $200 SOL
Biaya bulanan:               ~$30
Itu minimum. Selama kemacetan, kalikan dengan 5–10×. Rencanakan ~$150–300/bulan dalam biaya prioritas untuk bot alur steady-state. Bot yang harus mendarat di slot spesifik (likuidasi, arb) membayar persentil 95th terus-menerus dan menghabiskan ~10× lebih banyak. Tips bundle Jito mendominasi pada skala itu — sering $1000+/bulan — tetapi alternatifnya (front-run atau kadaluarsa) lebih buruk.

Jebakan

1. Lupa batas CU

Default adalah 200k CU × (instruksi dalam tx). Single-instruction swap default ke 200k; itu cukup untuk CPMM pada SPL Token tetapi bukan CLMM dengan tick crossings atau apa pun Token-2022. Selalu tetapkan secara eksplisit.

2. Biaya prioritas pada akun yang salah

Jika Anda memperkirakan biaya prioritas terhadap token mint tetapi akun hot adalah pool state, estimasi Anda terlalu rendah. Pool state adalah akun writable yang tepat untuk ditargetkan untuk Raydium.

3. Biaya skala dengan batas CU

total_priority_fee = units × microLamports. Menaikkan units dari 200k ke 1M pada 50k micro-lamports/CU mengalikan biaya prioritas 5×. Jangan over-budget CU hanya untuk berjaga-jaga; ukur.

4. Versi tx default

Transaksi legacy memiliki batas akun yang lebih rendah; transaksi V0 dengan address lookup tables membuka rute yang lebih besar. SDK menggunakan V0 secara default dalam txVersion: TxVersion.V0. Jangan turun ke legacy kecuali Anda memerlukan kompatibilitas dompet.

5. skipPreflight menyembunyikan kesalahan CU

skipPreflight: true mengirim tx tanpa simulasi lokal. Anda menghemat ~100ms tetapi kehilangan feedback awal tentang CU exhaustion. Gunakan hanya pada percobaan ulang, bukan pada upaya pertama.

Penunjuk

Sumber: