> ## 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.

# Biaya prioritas dan anggaran komputasi

> Menyesuaikan batas compute unit dan biaya prioritas untuk transaksi Raydium — benchmark per instruksi, strategi estimasi, dan pola penanganan kemacetan.

<Info>
  **Halaman ini diterjemahkan secara otomatis oleh AI. Versi bahasa Inggris adalah acuan resmi.**

  [Lihat versi bahasa Inggris →](/integration-guides/priority-fee-tuning)
</Info>

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

```ts theme={null}
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.

| Instruksi                        | SPL Token            | Token-2022 (sederhana) | Token-2022 (biaya transfer) |
| -------------------------------- | -------------------- | ---------------------- | --------------------------- |
| CPMM initialize\_pool            | 180.000              | 200.000                | —                           |
| CPMM swap\_base\_input           | 140.000              | 180.000                | 200.000                     |
| CPMM swap\_base\_output          | 150.000              | 185.000                | 205.000                     |
| CPMM deposit                     | 130.000              | 160.000                | 180.000                     |
| CPMM withdraw                    | 120.000              | 150.000                | 170.000                     |
| CLMM create\_pool                | 70.000               | 85.000                 | —                           |
| CLMM open\_position\_v2          | 120.000              | 140.000                | 160.000                     |
| CLMM increase\_liquidity\_v2     | 150.000              | 175.000                | 195.000                     |
| CLMM decrease\_liquidity\_v2     | 140.000              | 165.000                | 185.000                     |
| CLMM swap\_v2 (0 tick crossings) | 170.000              | 205.000                | 225.000                     |
| CLMM swap\_v2 (1 tick crossing)  | 220.000              | 255.000                | 275.000                     |
| CLMM swap\_v2 (3 tick crossings) | 320.000              | 355.000                | 375.000                     |
| CLMM collect\_fee                | 80.000               | 95.000                 | 105.000                     |
| AMM v4 swap\_base\_in            | 140.000              | —                      | —                           |
| AMM v4 deposit                   | 120.000              | —                      | —                           |
| AMM v4 withdraw                  | 110.000              | —                      | —                           |
| Farm v6 create\_farm             | 70.000               | 85.000                 | —                           |
| Farm v6 deposit (1 slot reward)  | 130.000              | 155.000                | 175.000                     |
| Farm v6 deposit (3 slot reward)  | 220.000              | 255.000                | 275.000                     |
| Farm v6 withdraw                 | cocok dengan deposit |                        |                             |
| Farm v6 harvest                  | cocok dengan deposit |                        |                             |
| Farm v3/v5 deposit               | 100.000              | —                      | —                           |
| LaunchLab initialize             | 100.000              | —                      | —                           |
| LaunchLab buy\_exact\_in         | 140.000              | —                      | —                           |
| LaunchLab graduate               | 250.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 creation** — `create_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:

```ts theme={null}
// 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:

| Level    | Persentil | Kasus penggunaan                           |
| -------- | --------- | ------------------------------------------ |
| Min      | 25th      | Traffic bot latar belakang, tidak mendesak |
| Low      | 50th      | Swap pengguna normal                       |
| Medium   | 60th      | Default untuk UI dompet                    |
| High     | 75th      | Arbitrase time-sensitive                   |
| VeryHigh | 95th      | Likuidasi, exit last-chance                |

Penyedia: Helius (`getPriorityFeeEstimate`), Triton (`getRecentPrioritizationFees` dengan daftar akun), QuickNode (serupa).

### Strategi 2: Query RPC langsung

Gunakan RPC standar `getRecentPrioritizationFees`:

```ts theme={null}
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:

```bash theme={null}
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`](/id/integration-guides/routing-and-mev). Bundle melewati antrian paket publik.

Kerangka logika percobaan ulang:

```ts theme={null}
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:

| Parameter                    | Kondisi normal        | Kondisi kemacetan                     |
| ---------------------------- | --------------------- | ------------------------------------- |
| Batas CU                     | +25% di atas estimasi | +25% di atas estimasi (tidak berubah) |
| Persentil biaya prioritas    | 50th                  | 75th–95th                             |
| Jumlah retry                 | 3                     | 5–7                                   |
| Backoff retry                | 500ms                 | 1000ms                                |
| Gunakan bundle Jito          | Opsional              | Sangat direkomendasikan               |
| Refresh blockhash pada retry | Ya                    | Ya, 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

* [`integration-guides/routing-and-mev`](/id/integration-guides/routing-and-mev) — strategi bundle Jito.
* [`integration-guides/aggregator`](/id/integration-guides/aggregator) — perakitan transaksi.
* [`integration-guides/cpi-integration`](/id/integration-guides/cpi-integration) — stacking CU di seluruh CPI yang dikomposisi.
* [Dokumen program compute budget Solana](https://docs.solana.com/developing/programming-model/runtime#compute-budget)

Sumber:

* [Solana `getRecentPrioritizationFees` RPC](https://docs.solana.com/api/http#getrecentprioritizationfees)
* [Helius priority fee API](https://docs.helius.dev/solana-apis/priority-fee-api)
* Benchmark: mainnet execution logs (Raydium SDK integration tests, April 2026).