> ## 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.
# Instruksi CLMM
> Referensi instruksi CLMM lengkap: siklus hidup pool, manajemen posisi, swap, dan aliran reward.
**Halaman ini diterjemahkan secara otomatis oleh AI. Versi bahasa Inggris adalah acuan resmi.**
[Lihat versi bahasa Inggris →](/products/clmm/instructions)
Halaman ini berpasangan dengan [`products/clmm/accounts`](/id/products/clmm/accounts) (apa itu akun) dan [`products/clmm/math`](/id/products/clmm/math) (apa itu matematika). Halaman ini adalah acuan otoritatif untuk argumen dan urutan akun; tata letak byte spesifik berasal dari IDL.
Upgrade program 2026-09 membangun kembali CLMM di Anchor 1.0.2 / Solana 3.1.10, menambahkan instruksi admin `CollectExcessLamports`, dan mengubah apa yang `CreateAmmConfig` tulis ke `owner` / `fund_owner`. Tidak ada instruksi yang menghadap pengguna yang mengubah akun, argumen, atau matematikanya. Lihat [entri changelog 2026-09-30](/id/reference/changelog/2026-09-30-clmm-anchor-1-and-excess-lamports).
## Inventaris instruksi
| Grup | Instruksi | Catatan |
| - | - | - |
| Admin | `CreateAmmConfig` | Tentukan tier biaya baru. |
| Admin | `UpdateAmmConfig` | Ubah tarif pada tier yang ada. |
| Admin | `UpdatePoolStatus` | Jeda/lanjutkan operasi pada pool. |
| Admin | `CreateSupportMintAssociated` | Izinkan konfigurasi ekstensi mint Token-2022 untuk digunakan di pool CLMM. |
| Admin | `CreateOperationAccount` | Inisialisasi akun operasi tingkat program (sekali saja). |
| Admin | `UpdateOperationAccount` | Ubah whitelist akun operasi. |
| Admin | `CreateDynamicFeeConfig` | Buat set parameter dynamic-fee yang dapat digunakan kembali di bawah indeks u16. |
| Admin | `UpdateDynamicFeeConfig` | Ubah `DynamicFeeConfig` yang ada. Pool yang sudah mengambil snapshot tidak terpengaruh. |
| Admin | `CreatePermissionPda` | Berikan otoritas hak untuk memanggil `CreatePermissionedPool` dengan menginisialisasi PDA `Permission`-nya. |
| Admin | `ClosePermissionPda` | Cabut izin yang sebelumnya diberikan dengan menutup PDA `Permission`-nya; sewa dikembalikan ke pemanggil. |
| Pool | `CreatePool` | Inisialisasi pool CLMM yang terikat pada `AmmConfig`. Jalur standar, FromInput-fee. Berdampingan dengan `CreateCustomizablePool`. |
| Pool | `CreateCustomizablePool` | Direkomendasikan untuk pool baru. Bentuk yang sama dengan `CreatePool` ditambah `collect_fee_on` dan flag `enable_dynamic_fee` opt-in. |
| Pool | `CreatePermissionedPool` | Buat pool **tambahan** untuk pasangan yang sudah memiliki satu, menggunakan `seed_index` yang disediakan klien dilipat ke dalam PDA pool. Pembayar harus memegang PDA `Permission`. |
| Posisi | `OpenPosition` / `OpenPositionV2` / `OpenPositionWithToken22Nft` | Mint NFT posisi. `OpenPositionV2` menggantikan V1; `OpenPositionWithToken22Nft` mengeluarkan NFT sebagai Token-2022. Jalur V2 membekukan akun NFT hanya ketika freeze authority mint vault yang mendasar cocok dengan daftar restricted-issuer. Jika tidak, akun tetap tidak beku. |
| Posisi | `IncreaseLiquidity` / `IncreaseLiquidityV2` | Tambahkan likuiditas ke posisi yang ada. |
| Posisi | `DecreaseLiquidity` / `DecreaseLiquidityV2` | Hapus likuiditas; mengumpulkan biaya yang terhutang. |
| Posisi | `ClosePosition` | Bakar NFT dan tutup `PersonalPositionState`. Jika akun NFT beku, cair terlebih dahulu dengan pool PDA yang disediakan sebagai akun sisa. |
| Posisi | `CloseProtocolPosition` | Sapuan admin-only untuk PDA `ProtocolPositionState` warisan. Program saat ini tidak lagi membuat atau membaca `ProtocolPositionState` — instruksi ini ada semata-mata untuk mengklaim kembali sewa pada akun yang dibuat oleh versi program yang lebih lama. |
| Swap | `Swap` / `SwapV2` | Swap likuiditas konstan. Kedua varian menerapkan dynamic fee, single-sided fee routing, dan limit-order matching; satu-satunya perbedaan adalah `SwapV2` menerima mint Token-2022 (varian V1 memerlukan kedua vault menjadi SPL Token klasik). |
| Swap | `SwapRouterBaseIn` | Multi-hop, digunakan oleh router. |
| Limit order | `OpenLimitOrder` | Tempatkan pesanan jual pada tick. Token yang tidak terisi duduk di tick; mesin pencocokan mengisinya saat harga melintasi. |
| Limit order | `IncreaseLimitOrder` | Tambahkan ke pesanan terbuka yang ada. |
| Limit order | `DecreaseLimitOrder` | Kurangi atau batalkan pesanan terbuka; membayar sisa yang tidak terisi ditambah output apa pun yang sudah diselesaikan. |
| Limit order | `SettleLimitOrder` | Dorong token output yang terisi ke pemilik pesanan. Dapat dipanggil oleh pemilik atau oleh keeper operasional. |
| Limit order | `CloseLimitOrder` | Tutup akun pesanan yang sepenuhnya dikonsumsi. Sewa selalu kembali ke `owner` pesanan. Dapat dipanggil oleh pemilik atau keeper. |
| Biaya | `CollectProtocolFee` | Sapuan admin biaya protokol. |
| Biaya | `CollectFundFee` | Sapuan admin biaya dana. |
| Reward | `InitializeReward` | Lampirkan aliran reward baru ke pool. |
| Reward | `SetRewardParams` | Ubah tingkat emisi/akhir reward yang ada. |
| Reward | `UpdateRewardInfos` | Selesaikan pertumbuhan reward hingga sekarang (dipanggil oleh swap / perubahan posisi apa pun). |
| Reward | `TransferRewardOwner` | Transfer otoritas yang dapat mengatur atau mengisi ulang aliran reward. |
| Reward | `CollectRemainingRewards` | Setelah `end_time` aliran reward, sapukan token apa pun yang tidak pernah dialokasikan kembali ke pendana. |
| Admin | `CloseSupportMintAssociated` | Hapus pendaftaran `SupportMintAssociated` mint dan kembalikan sewanya. |
| Admin | `CollectExcessLamports` | Sapukan lamport di atas minimum rent-exempt dari `PoolState` satu pool dan vault, ditambah PDA apa pun yang dimiliki CLMM yang dilewatkan. `admin` atau dompet collect-lamports khusus. Ditambahkan 2026-09. |
**Tidak ada instruksi init-tick-array, dan tidak ada yang diperlukan.** Array tick dibuat *di dalam*
`OpenPosition*` / `IncreaseLiquidity*` oleh `TickArrayState::get_or_create_tick_array`, dibayar oleh
`payer`. Lewatkan PDA tick-array (mungkin masih belum diinisialisasi, dimiliki sistem) sebagai
`tick_array_lower` / `tick_array_upper` dan program mengalokasikannya jika hilang.
`OpenLimitOrder` melakukan hal yang sama untuk `tick_array` tunggalnya.
Sebagian besar instruksi admin-only (`CreateAmmConfig`, `UpdateAmmConfig`, `UpdatePoolStatus`, `CreateOperationAccount`, `UpdateOperationAccount`, `CloseProtocolPosition`) dijaga oleh pubkey `admin` yang dikodekan keras program. `CreatePermissionPda` / `ClosePermissionPda` menerima pubkey `admin` **atau** kunci `permission_pda_admin` khusus; `CreateSupportMintAssociated` / `CloseSupportMintAssociated` menerima pubkey `admin` **atau** kunci pemilik support-mint khusus; `CollectExcessLamports` menerima pubkey `admin` **atau** dompet collect-lamports khusus. Instruksi admin aliran reward (`TransferRewardOwner`, `CollectRemainingRewards`) dijaga oleh pendana reward, bukan admin program.
Akhiran V2 berarti "mendukung Token-2022 di vault / NFT, memerlukan slot bitmap-extension". SDK memilih V2 secara default untuk pool baru.
## `CreatePool`
**Argumen**
```
sqrt_price_x64: u128 // harga awal
open_time: u64 // swap ditolak sebelum waktu ini
```
**Akun (ringkas)**
| # | Nama | W | S | Catatan |
| - | - | - | - | - |
| 1 | `pool_creator` | W | S | |
| 2 | `amm_config` | | | Tier biaya yang dipilih. |
| 3 | `pool_state` | W | | `init` di sini. |
| 4 | `token_mint_0` | | | Diurutkan. |
| 5 | `token_mint_1` | | | |
| 6 | `token_vault_0` | W | | `init` di sini, dimiliki oleh PDA otoritas pool. |
| 7 | `token_vault_1` | W | | |
| 8 | `observation_state` | W | | `init` di sini. |
| 9 | `tick_array_bitmap` | W | | PDA `TickArrayBitmapExtension`; `init` di sini. |
| 10 | `token_program_0` | | | Program yang memiliki `token_mint_0` — SPL Token **atau** Token-2022. |
| 11 | `token_program_1` | | | Program yang memiliki `token_mint_1`. |
| 12 | `system_program` | | | |
| 13 | `rent` | | | |
Slot 10 dan 11 adalah **per-mint**, bukan "SPL Token lalu Token-2022". Masing-masing dibatasi oleh
`mint::token_program` pada mint yang cocok, jadi untuk pool yang `token_mint_0` adalah Token-2022 dan
`token_mint_1` adalah SPL klasik Anda harus melewatkan Token-2022 di slot 10 dan SPL Token di slot 11.
`CreateCustomizablePool` dan `CreatePermissionedPool` menggunakan dua slot yang sama.
**Prekondisi**
* `token_mint_0 < token_mint_1` menurut urutan byte.
* `amm_config.disable_create_pool == false`.
* Mint tidak ditolak oleh daftar izin ekstensi Token-2022.
**Postkondisi**
* `pool_state.sqrt_price_x64 = sqrt_price_x64`, `tick_current = floor(log_{1.0001}(price))`.
* `pool_state.liquidity = 0` (belum ada posisi).
* `pool_state.fee_on = FromInput` (default warisan).
* `pool_state.dynamic_fee_info` adalah nol (dynamic fee dinonaktifkan).
## `CreateCustomizablePool`
Direkomendasikan untuk pool baru. Efek yang sama dengan `CreatePool` ditambah mode pengumpulan biaya per-pool dan opt-in dynamic-fee opsional.
**Argumen**
```rust theme={null}
pub struct CreateCustomizableParams {
pub sqrt_price_x64: u128,
pub collect_fee_on: CollectFeeOn, // FromInput | Token0Only | Token1Only
pub enable_dynamic_fee: bool,
}
```
**Akun** — tepat 13 akun yang dideklarasikan dari `CreatePool`. `dynamic_fee_config` **bukan** akun yang dideklarasikan.
Ketika `enable_dynamic_fee = true`, `DynamicFeeConfig` yang akan diambil snapshot harus disediakan sebagai
**akun sisa terakhir** — handler membaca `ctx.remaining_accounts.last()`. Setiap
PDA bypass `SupportMintAssociated` harus datang *sebelumnya*, atau program mengambil snapshot akun yang salah dan gagal deserialisasi. Menghilangkannya saat flag diatur gagal dengan
`AccountLack`.
**Prekondisi** — sama dengan `CreatePool`. Jika `enable_dynamic_fee = false`, tidak ada `remaining_account` yang diperlukan dan yang dilewatkan hanya dipindai untuk catatan support-mint.
**Postkondisi**
* `pool_state.fee_on` diatur ke varian `CollectFeeOn` yang dipilih.
* Jika dynamic fee diaktifkan: `pool_state.dynamic_fee_info` diinisialisasi dari `DynamicFeeConfig` yang disediakan (lima parameter kalibrasi disalin; bidang state dinolkan).
* Jika tidak: `pool_state.dynamic_fee_info` adalah nol (= dynamic fee tidak aktif selamanya untuk pool ini).
`fee_on` dan bit enablement dynamic-fee diatur **hanya** saat pembuatan pool. Tidak ada upgrade in-place — pool yang dibuat melalui `CreatePool` warisan tidak dapat secara retroaktif mendapatkan dynamic fee atau single-sided fee. Deployment baru harus default ke instruksi ini.
## `CreatePermissionedPool`
Baik `CreatePool` maupun `CreateCustomizablePool` menurunkan PDA pool dari `["pool", amm_config, token_mint_0, token_mint_1]`, jadi ada tepat **satu** alamat pool kanonik per triple `(config, mint0, mint1)` — `init` kedua pada seed yang sama gagal. `CreatePermissionedPool` menghilangkan pembatasan itu dengan melipat `seed_index: u16` yang disediakan klien ke dalam seed PDA pool, memungkinkan **beberapa pool untuk pasangan dan tier biaya yang sama** — masing-masing di alamatnya sendiri. Karena alamat pool yang sewenang-wenang adalah kemampuan istimewa, pembayar harus memegang PDA `Permission` yang mengotorisasinya.
Segalanya tentang pool identik dengan `CreateCustomizablePool`: ia mengambil `CreateCustomizableParams` yang sama dan mendukung single-sided fee dan opt-in dynamic-fee.
**Argumen**
```rust theme={null}
customizable_params: CreateCustomizableParams // struct yang sama dengan CreateCustomizablePool
seed_index: u16 // harus bukan nol; dilipat ke dalam seed PDA pool
```
**Akun (ringkas)** — sama dengan `CreateCustomizablePool` ditambah, di depan:
| # | Nama | W | S | Catatan |
| - | - | - | - | - |
| 1 | `payer` | W | S | Membayar sewa. Harus menjadi otoritas PDA `permission` di bawah. |
| 2 | `pool_creator` | | | Dicatat sebagai `pool_state.owner`. Mungkin berbeda dari `payer`. |
| 3 | `permission` | | | PDA `["permission", payer]`. Anchor menolak panggilan jika tidak ada / tidak dimiliki oleh program. |
| … | (`amm_config`, `pool_state`, mint, vault, `observation_state`, `tick_array_bitmap`, token/system program) | | | Seperti di `CreateCustomizablePool`. |
PDA `pool_state` diturunkan dari `["pool", amm_config, token_mint_0, token_mint_1, seed_index.to_le_bytes()]`.
**Prekondisi**
* `seed_index != 0`. `seed_index` dari `0` dicadangkan untuk pool warisan dan ditolak di sini; komponen seed `[0, 0]` adalah apa yang membuat alamat pool warisan runtuh ke bentuk empat-seed klasik.
* PDA `permission` untuk `payer` ada (dibuat oleh admin melalui `CreatePermissionPda`).
* Aturan mint / allow-list yang sama dengan `CreatePool`.
**Postkondisi**
* `pool_state` baru ada di alamat yang diturunkan `seed_index`, dengan `pool_state.seed_index = seed_index`.
* Semua post-state lainnya cocok dengan `CreateCustomizablePool` (mode biaya, dynamic fee opsional).
Instruksi ini **tidak** memperluas akses pembuatan pool umum — pembuatan tanpa izin terus melalui `CreatePool` / `CreateCustomizablePool`, yang tetap satu-pool-per-pasangan. `CreatePermissionedPool` ada untuk kasus spesifik di mana operator yang terdaftar dalam whitelist memerlukan beberapa pool untuk pasangan yang sama (misalnya harga awal yang berbeda atau kohort peluncuran) dan memegang PDA `Permission` yang diberikan oleh admin.
## `OpenPositionV2` / `OpenPositionWithToken22Nft`
Buat posisi baru di dalam pool yang ada.
**Argumen**
```
tick_lower_index: i32
tick_upper_index: i32
tick_array_lower_start_index: i32
tick_array_upper_start_index: i32
liquidity: u128 // L yang diinginkan (atau 0 untuk menggunakan jumlah di bawah)
amount_0_max: u64
amount_1_max: u64
with_metadata: bool // tulis metadata NFT (Metaplex)
base_flag: Option // true = sesuaikan dengan amount0; false = sesuaikan dengan amount1
```
**Akun** — dua varian memiliki *daftar akun yang berbeda*. `OpenPositionV2` mendeklarasikan 22; `OpenPositionWithToken22Nft` mendeklarasikan 20.
`OpenPositionV2`, dalam urutan:
| # | Nama | W | S | Catatan |
| - | - | - | - | - |
| 1 | `payer` | W | S | |
| 2 | `position_nft_owner` | | | |
| 3 | `position_nft_mint` | W | S | Keypair segar. |
| 4 | `position_nft_account` | W | | ATA pemilik untuk NFT. |
| 5 | `metadata_account` | W | | PDA metadata Metaplex. Dideklarasikan **tanpa syarat**, bahkan ketika `with_metadata = false`. |
| 6 | `pool_state` | W | | |
| 7 | `protocol_position` | | | Vestigial; `UncheckedAccount` read-only. |
| 8 | `tick_array_lower` | W | | Dibuat di sini jika belum diinisialisasi. |
| 9 | `tick_array_upper` | W | | Sama. |
| 10 | `personal_position` | W | | Dibuat di sini. |
| 11 | `token_account_0` | W | | ATA sumber pengguna. |
| 12 | `token_account_1` | W | | |
| 13 | `token_vault_0` | W | | |
| 14 | `token_vault_1` | W | | |
| 15 | `rent` | | | |
| 16 | `system_program` | | | |
| 17 | `token_program` | | | |
| 18 | `associated_token_program` | | | |
| 19 | `metadata_program` | | | Metaplex Token Metadata. |
| 20 | `token_program_2022` | | | |
| 21 | `vault_0_mint` | | | |
| 22 | `vault_1_mint` | | | |
`OpenPositionWithToken22Nft` adalah daftar yang sama dengan `metadata_account` (5) dan `metadata_program` (19) **dihapus** — ia menulis metadata posisi melalui ekstensi metadata Token-2022 pada mint NFT sebagai gantinya — memberikan 20 akun. `position_nft_mint`-nya adalah `Signer` bare dan `position_nft_account` adalah `UncheckedAccount`.
**`tick_array_bitmap_extension` bukan akun yang dideklarasikan pada varian mana pun.** Ketika jangkauan posisi jatuh di luar `tick_array_bitmap` inline pool (±512 tick array), tambahkan
PDA `TickArrayBitmapExtension` di seed `["pool_tick_array_bitmap_extension", pool_state]` sebagai
`remaining_accounts[0]`.
**Matematika** — lihat [`products/clmm/math`](/id/products/clmm/math). Diberikan `base_flag`, program menyelesaikan baik `liquidity` atau `(amount_0_max, amount_1_max)` menjadi `L` aktual dan jumlah token aktual yang dikonsumsi.
**Prekondisi**
* `tick_lower < tick_upper`, keduanya kelipatan `pool.tick_spacing`, dalam `[MIN_TICK, MAX_TICK]`.
* Dua PDA tick-array dilewatkan. Mereka **tidak perlu** sudah ada — `get_or_create_tick_array` mengalokasikan yang hilang dengan biaya `payer` di dalam instruksi ini. Tidak ada instruksi init-tick-array terpisah.
* Pengguna memiliki setidaknya `amount_0_max` dan `amount_1_max` di ATA sumber.
**Postkondisi**
* `personal_position` ada, `liquidity` diatur, `fee_growth_inside_last` diambil snapshot.
* Entri tick-array di `tick_lower` dan `tick_upper` diperbarui (`liquidity_gross += L`, `liquidity_net ± L`, snapshot pertumbuhan biaya dipertahankan).
* `pool_state.liquidity += L` jika posisi dalam jangkauan (`tick_lower ≤ tick_current < tick_upper`).
* Mint NFT posisi mencatat `pool_state` sebagai freeze authority. Mint authority dihapus setelah NFT tunggal dimint. Mencatat freeze authority tidak mengubah status akun token NFT.
* Akun token NFT tetap tidak beku kecuali instruksinya adalah `OpenPositionV2` atau `OpenPositionWithToken22Nft` **dan** freeze authority mint vault cocok dengan daftar restricted-issuer CLMM. Hanya jalur V2 yang cocok yang membekukan akun. `OpenPosition` V1 tidak membekukan.
**Kesalahan umum** — `TickInvalidOrder` (`tick_lower >= tick_upper`), `TickAndSpacingNotMatch` (endpoint bukan kelipatan `tick_spacing`), `InvalidTickIndex` (di luar `[MIN_TICK, MAX_TICK]`), `MissingTickArrayBitmapExtensionAccount` (jangkauan di luar bitmap inline dan ekstensi tidak ditambahkan), `NotApproved` (`pool_state.status` memblokir pembukaan), `ZeroAmountSpecified`.
Pembekuan posisi tidak menambahkan akun instruksi yang dideklarasikan atau argumen. Klien dapat membuka posisi ini dengan tata letak V2 yang ada. Perilaku dipilih on-chain dari `vault_0_mint` dan `vault_1_mint`.
## `IncreaseLiquidityV2`
Tambahkan likuiditas ke posisi yang sudah terbuka.
**Argumen**
```
liquidity: u128
amount_0_max: u64
amount_1_max: u64
base_flag: Option
```
**Akun** — 15, dan *tidak* dapat diturunkan dari `OpenPosition`: tidak ada `rent`, tidak ada `system_program`, tidak ada `associated_token_program` dan tidak ada akun metadata.
| # | Nama | W | S |
| - | - | - | - |
| 1 | `nft_owner` | | S |
| 2 | `nft_account` | | |
| 3 | `pool_state` | W | |
| 4 | `protocol_position` | | |
| 5 | `personal_position` | W | |
| 6 | `tick_array_lower` | W | |
| 7 | `tick_array_upper` | W | |
| 8 | `token_account_0` | W | |
| 9 | `token_account_1` | W | |
| 10 | `token_vault_0` | W | |
| 11 | `token_vault_1` | W | |
| 12 | `token_program` | | |
| 13 | `token_program_2022` | | |
| 14 | `vault_0_mint` | | |
| 15 | `vault_1_mint` | | |
Tambahkan PDA `TickArrayBitmapExtension` di depan sebagai `remaining_accounts[0]` ketika jangkauan posisi berada di luar bitmap inline.
**Efek**
* Mentransfer `amount_0_actual` / `amount_1_actual` dari pengguna → vault.
* Menambah `personal_position.liquidity` dan `pool_state.liquidity` (jika dalam jangkauan), dan `liquidity_gross` / `liquidity_net` tick endpoint sesuai.
* **Mengumpulkan biaya dan reward yang terhutang sejak sentuhan terakhir** dan mengkreditkannya ke `token_fees_owed_{0,1}` / `reward_amount_owed`. Ini dibayarkan hanya pada `DecreaseLiquidity` / `DecreaseLiquidityV2`, bukan pada peningkatan — tidak ada instruksi pengumpulan standalone.
## `DecreaseLiquidityV2`
Hapus likuiditas dari posisi.
**Argumen**
```
liquidity: u128
amount_0_min: u64
amount_1_min: u64
```
**Akun** — 16, dan **bukan** bentuk atau urutan yang sama dengan `IncreaseLiquidityV2`: `personal_position` dan `pool_state` ditukar, vault datang sebelum tick array, akun sisi pengguna dinamai `recipient_token_account_*`, dan ada `memo_program` ekstra.
| # | Nama | W | S |
| - | - | - | - |
| 1 | `nft_owner` | | S |
| 2 | `nft_account` | | |
| 3 | `personal_position` | W | |
| 4 | `pool_state` | W | |
| 5 | `protocol_position` | | |
| 6 | `token_vault_0` | W | |
| 7 | `token_vault_1` | W | |
| 8 | `tick_array_lower` | W | |
| 9 | `tick_array_upper` | W | |
| 10 | `recipient_token_account_0` | W | |
| 11 | `recipient_token_account_1` | W | |
| 12 | `token_program` | | |
| 13 | `token_program_2022` | | |
| 14 | `memo_program` | | |
| 15 | `vault_0_mint` | | |
| 16 | `vault_1_mint` | | |
**Akun sisa** — tiga per reward aktif yang dikumpulkan, dalam urutan `reward_token_vault(W)`, `recipient_token_account(W)`, `reward_vault_mint`. Tambahkan PDA `TickArrayBitmapExtension` ketika jangkauan posisi berada di luar bitmap inline.
Ini juga **satu-satunya** cara untuk mengumpulkan biaya dan reward. Untuk mengumpulkan tanpa mengubah
posisi, panggilnya dengan `liquidity = 0`, `amount_0_min = 0`, `amount_1_min = 0`.
**Efek**
* Menghitung `(amount_0, amount_1)` untuk `L` yang dihapus diberikan `sqrt_price_x64` saat ini.
* Menyelesaikan biaya/reward yang terkumpul sejak sentuhan terakhir, sama dengan `IncreaseLiquidity`.
* Mentransfer `amount_0 + fees_owed_0` dan `amount_1 + fees_owed_1` keluar dari vault ke pengguna.
* Mengurangi penghitung likuiditas; jika `personal_position.liquidity` baru == 0, posisi memenuhi syarat untuk `ClosePosition`.
**Slippage** — `amount_0_min` dan `amount_1_min` adalah minimum yang diterima pengguna bersih biaya transfer Token-2022 di sisi output.
## `ClosePosition`
Bakar NFT posisi dan tutup `PersonalPositionState`.
**Akun yang dideklarasikan**
| # | Nama | W | S | Catatan |
| - | - | - | - | - |
| 1 | `nft_owner` | W | S | Harus memiliki akun token NFT yang memegang jumlah `1`. |
| 2 | `position_nft_mint` | W | | Harus cocok dengan `personal_position.nft_mint`. |
| 3 | `position_nft_account` | W | | Akun pemilik NFT; mungkin SPL Token klasik atau Token-2022. |
| 4 | `personal_position` | W | | Ditutup ke `nft_owner`. |
| 5 | `system_program` | | | Menutup status posisi. |
| 6 | `token_program` | | | Harus memiliki mint NFT dan akun token. |
**Akun sisa**
* NFT tidak beku: tidak ada yang diperlukan; akun pool ekstra tidak berbahaya karena handler tidak membacanya.
* NFT beku: tambahkan `personal_position.pool_id` sebagai akun sisa pertama. Program memuatnya sebagai `PoolState` dan menggunakan seed PDA-nya untuk menandatangani pencairan.
**Prekondisi**
* `personal_position.liquidity == 0`.
* `tokens_fees_owed_{0,1} == 0`.
* Semua penghitung reward `reward_amount_owed == 0`.
(Yaitu, kumpulkan semuanya dan kurangi ke nol terlebih dahulu.)
**Efek**
* Jika akun token NFT beku, verifikasi akun sisa pertama sama dengan `personal_position.pool_id`, lalu cairkan dengan PDA pool.
* Bakar NFT.
* Tutup akun token NFT dan `personal_position`, kembalikan sewa ke `nft_owner`. Jika NFT posisi menggunakan Token-2022, ia juga menutup mint NFT; mint SPL Token klasik tidak dapat ditutup dan tetap dengan pasokan nol.
Pencairan, pembakaran, dan penutupan bersifat atomik. NFT tidak dapat menjadi dapat ditransfer di antara langkah-langkah tersebut.
**Pemecahan klien bersyarat** — tata letak IDL yang dideklarasikan tidak berubah, jadi klien warisan terus menutup posisi yang ada dan tidak beku. Pembangun warisan yang menghilangkan akun sisa pool gagal dengan `AccountLack` saat menutup posisi beku. Melewatkan pool untuk setiap penutupan adalah strategi kompatibel paling sederhana.
## `SwapV2`
Berjalan di kurva likuiditas; input tepat *atau* output tepat tergantung pada `is_base_input`.
**Argumen**
```
amount: u64 // input jika is_base_input=true, output sebaliknya
other_amount_threshold: u64 // min out atau max in
sqrt_price_limit_x64: u128 // batas keras; 0 ⇒ tidak terbatas
is_base_input: bool
```
**Akun (ringkas)**
| # | Nama | W | S | Catatan |
| - | - | - | - | - |
| 1 | `payer` | | S | |
| 2 | `amm_config` | | | |
| 3 | `pool_state` | W | | |
| 4 | `input_token_account` | W | | |
| 5 | `output_token_account` | W | | |
| 6 | `input_vault` | W | | |
| 7 | `output_vault` | W | | |
| 8 | `observation_state` | W | | |
| 9 | `token_program` | | | |
| 10 | `token_program_2022` | | | V2. |
| 11 | `memo_program` | | | V2 (diperlukan untuk beberapa jalur Token-2022). |
| 12 | `input_vault_mint`, `output_vault_mint` | | | V2. |
| 13 | `tick_array_bitmap_extension` (opsional) | W | | Jika swap berjalan ke ekstensi. |
| 14+ | `tick_array` (sisa) | W | | Array yang cukup untuk mencakup jangkauan berjalan yang diharapkan. |
Pemanggil melewatkan daftar tick array berperingkat yang mencakup berjalan swap yang diharapkan; program menggunakan sebanyak yang dibutuhkan. SDK menghitung daftar ini melalui `PoolUtils.computeAmountOutFormat` atau endpoint quote API.
**Prekondisi**
* `pool_state.status` memungkinkan swap.
* `now >= open_time`.
* `sqrt_price_limit_x64` berada di sisi yang benar dari `sqrt_price_x64` untuk arahnya.
**Kesalahan umum** — `TooLittleOutputReceived` (slippage exact-in), `TooMuchInputPaid` (slippage exact-out), `SqrtPriceLimitOverflow`, `NotEnoughTickArrayAccount`, `InvalidFirstTickArrayAccount`, `MissingTickArrayBitmapExtensionAccount`, `LiquidityInsufficient`, `NotApproved` (bit swap diatur pada `pool_state.status`). CLMM tidak memiliki varian `ExceededSlippage` — nama itu adalah CPMM — dan tidak ada `TickArrayNotFound`.
**Apa yang `SwapV2` lakukan secara internal yang harus diketahui pemanggil** (rilis pasca-2025):
1. **Surcharge dynamic fee** — jika `pool.dynamic_fee_info` bukan nol, program memperbarui akumulator volatilitas menggunakan jarak tick yang dilintasi sejak swap terakhir (dengan aturan filter/decay dari [`products/clmm/fees`](/id/products/clmm/fees)) dan menambahkan `dynamic_fee_component` di atas `AmmConfig.trade_fee_rate`. Total biaya dibatasi pada 10% (`MAX_FEE_RATE_NUMERATOR / 1_000_000`).
2. **Limit-order matching** — ketika berjalan harga melintasi tick yang memegang pesanan limit terbuka, program pertama-tama mengisi likuiditas limit-order yang tersedia di tick itu (FIFO oleh `order_phase`), kemudian melanjutkan di sepanjang kurva likuiditas LP. Jumlah yang terisi memperbarui `tick.unfilled_ratio_x64` dan `tick.part_filled_orders_remaining` untuk penyelesaian nanti; pesanan itu sendiri tetap tidak dihabiskan sampai pemiliknya memanggil `SettleLimitOrder`.
3. **Single-sided fee routing** — ketika `pool.fee_on = Token0Only` atau `Token1Only`, langkah swap masih menghitung perdagangan input-output yang sama; biaya kemudian dirutekan ke sisi yang dikonfigurasi. Untuk arah di mana sisi biaya yang dikonfigurasi adalah output, biaya dikurangi dari output swap (pengguna menerima `out − fee`); untuk arah di mana itu adalah input, perilaku cocok dengan `FromInput`. Lihat `is_fee_on_input(zero_for_one)` dan `is_fee_on_token0(zero_for_one)` pada `PoolState`.
`Swap` (V1) mengimplementasikan dynamic fee yang sama, single-sided fee routing, dan limit-order matching seperti `SwapV2`; satu-satunya fitur yang kurang adalah dukungan Token-2022 — kedua vault harus SPL Token klasik. Pool dengan mint Token-2022 apa pun harus ditukar melalui `SwapV2`. Agregator dan SDK sudah lebih suka V2 untuk setiap leg CLMM jadi pemanggil tidak harus bercabang pada jenis mint.
## `OpenLimitOrder`
Tempatkan pesanan jual pada tick tertentu. Pesanan duduk di kohort FIFO per-tick dan terisi saat harga berjalan melewati.
**Argumen**
```
nonce_index: u8 // indeks akun nonce yang dipilih pengguna (0..255 per dompet)
zero_for_one: bool // true: jual token0 untuk token1; false: jual token1 untuk token0
tick_index: i32 // harus kelipatan pool.tick_spacing
amount: u64 // jumlah token input
```
**Akun (ringkas)**
| # | Nama | W | S | Catatan |
| - | - | - | - | - |
| 1 | `payer` | W | S | Pemilik pesanan; membayar sewa. |
| 2 | `pool_state` | W | | |
| 3 | `tick_array` | W | | Array tick yang berisi `tick_index`. |
| 4 | `limit_order_nonce` | W | | PDA. `init_if_needed` — dibuat pada pesanan pertama pengguna di bawah `nonce_index` ini. |
| 5 | `limit_order` | W | | PDA. `init` di sini. |
| 6 | `input_token_account` | W | | ATA input pengguna. Diperiksa untuk `frozen`. |
| 7 | `output_token_account` | W | | ATA **output** pengguna. Tidak didebit saat pembukaan — diperlukan hanya agar program dapat mengkonfirmasi tidak `frozen` (yaitu pengisian dapat dikirim nanti). |
| 8 | `input_vault` | W | | Vault input pool. |
| 9 | `output_vault` | W | | Vault output pool. Mengidentifikasi mint output untuk pemeriksaan `output_token_account` / `output_vault_mint`. |
| 10 | `input_vault_mint` | | | Penanganan biaya Token-2022. |
| 11 | `output_vault_mint` | | | Mint sisi output (pemeriksaan pasangan beku). |
| 12 | `input_token_program` | | | SPL atau Token-2022. |
| 13 | `system_program` | | | Dana `limit_order`, `limit_order_nonce` dan — jika diperlukan — alokasi `tick_array`. |
**Akun sisa** — `[0]` `tick_array_bitmap_extension`, diperlukan hanya saat menginisialisasi array tick yang indeks awalnya jatuh di luar bitmap inline pool. Lewatkan tidak ada sebaliknya.
Tidak ada akun `rent`: struct berakhir di `system_program`, 13 akun yang dideklarasikan. `rent` yang tersesat di posisi 14 mendarat tepat di mana ekstensi bitmap opsional dibaca, jadi pesanan tampak bekerja sampai pertama kali array tick di luar bitmap inline harus dibuat — dan kemudian gagal.
**Perubahan daftar akun (rilis 2026-07).** `OpenLimitOrder` sekarang juga mengambil akun **sisi output** — `output_token_account`, `output_vault`, dan `output_vault_mint` — selain sisi input. Mereka digunakan hanya untuk validasi: program menolak pesanan jika akun token input **atau** output pemilik beku. Ini menjamin bahwa pengisian dapat benar-benar diselesaikan ke ATA output pemilik, yang penting untuk mint Token-2022 allow-list / default-frozen (misalnya token berizin) di mana akun mungkin belum dicairkan. Klien yang dibangun terhadap daftar akun satu sisi yang lebih lama harus menambahkan tiga akun output.
**Prekondisi**
* Baik `input_token_account` maupun `output_token_account` tidak beku (jika tidak `NotApproved`).
* `pool_state.status` memungkinkan operasi swap (bit 4) dan limit-order (bit 5) (jika tidak `NotApproved`).
* `tick_index % pool.tick_spacing == 0` dan dalam `[MIN_TICK, MAX_TICK]`.
* `tick_index` berada di **sisi kanan `pool.tick_current`** untuk arah yang dipilih (menjual token0 → tick harus di atas saat ini, dan sebaliknya). Menjual pada tick yang sudah dilintasi akan cocok segera dan ditolak.
**Postkondisi**
* `limit_order` ada, mengambil snapshot `tick.order_phase` dan `tick.unfilled_ratio_x64` saat pembukaan.
* `tick.orders_amount += amount` (dalam kohort saat ini).
* `limit_order_nonce.order_nonce += 1`.
* `OpenLimitOrderEvent` dipancarkan.
**Kesalahan umum** — `NotApproved` (akun token input atau output beku, atau pool memiliki swap / limit-order dinonaktifkan), `ZeroAmountSpecified` (`amount == 0` setelah biaya transfer sisi input), `InvalidLimitOrderAmount` (jumlah akan menghasilkan output di bawah 1 unit dasar pada tick itu, atau overflow `u64`), `InvalidTickIndex` (di luar `[MIN_TICK, MAX_TICK]`, atau di sisi yang salah dari `tick_current` untuk arah yang dipilih), `TickAndSpacingNotMatch` (`tick_index % pool.tick_spacing != 0`), `OrderPhaseSaturated`.
## `IncreaseLimitOrder`
Tambahkan ke pesanan terbuka yang ada. Hanya dapat dipanggil oleh `owner` pesanan.
**Argumen**
```
amount: u64 // jumlah token input tambahan
```
**Akun** — 8, sisi input saja. Ini menghilangkan akun nonce, ketiga akun sisi output **dan** `system_program`.
| # | Nama | W | S |
| - | - | - | - |
| 1 | `owner` | | S |
| 2 | `pool_state` | W | |
| 3 | `tick_array` | W | |
| 4 | `limit_order` | W | |
| 5 | `input_token_account` | W | |
| 6 | `input_vault` | W | |
| 7 | `input_vault_mint` | | |
| 8 | `input_token_program` | | |
**Prekondisi**
* `limit_order.owner == signer`.
* Pesanan masih dalam kohort yang sama (`tick.order_phase == limit_order.order_phase`). Jika kohort sudah mulai terisi, pesanan sebagian diselesaikan — pemanggil harus memanggil `DecreaseLimitOrder` atau `SettleLimitOrder` terlebih dahulu untuk maju.
**Efek**
* Mentransfer `amount` dari ATA pemilik ke `input_vault`.
* `limit_order.total_amount += amount`; `tick.orders_amount += amount`.
## `DecreaseLimitOrder`
Kurangi atau batalkan sepenuhnya pesanan terbuka. Membayar sisa yang tidak terisi kembali ke pemilik, ditambah output apa pun yang sudah diselesaikan oleh pengisian parsial masa lalu.
**Argumen**
```
amount: u64 // jumlah token input untuk ditarik (maks = sisa yang tidak terisi)
amount_min: u64 // lantai slippage pada penarikan sisi input
```
**Akun** — sisi token input dan output:
| # | Nama | W | S |
| - | - | - | - |
| 1 | `owner` | | S |
| 2 | `pool_state` | W | |
| 3 | `tick_array` | W | |
| 4 | `limit_order` | W | |
| 5 | `input_token_account` | W | |
| 6 | `output_token_account` | W | |
| 7 | `input_vault` | W | |
| 8 | `output_vault` | W | |
| 9 | `input_vault_mint`, `output_vault_mint` | | |
| 10 | `token_program`, `token_program_2022` | | |
**Efek**
* Menghitung ulang jumlah yang terisi pesanan dari `unfilled_ratio_x64` kohort sejak pembukaan.
* Mengirim output yang terisi ke `output_token_account`.
* Mengirim `amount` input yang tidak terisi kembali ke `input_token_account`.
* Memperbarui `limit_order` sesuai. Jika sisa yang tidak terisi baru adalah nol, program menutup akun dan mengembalikan sewa ke `owner`.
## `SettleLimitOrder`
Dorong token output yang terisi ke pemilik tanpa mengubah sisa yang tidak terisi pesanan. Berguna ketika keeper `auto_withdraw` ingin drip-pay pengisian parsial jangka panjang.
**Pemanggil** — baik `owner` pesanan, atau `limit_order_admin` program (dompet panas operasional off-chain yang menjalankan loop keeper otomatis). Keeper tidak memiliki otoritas lain — ia tidak dapat memindahkan dana pengguna di luar mendorong output yang terisi ke ATA `owner` pesanan.
**Akun**
| # | Nama | W | S | Catatan |
| - | - | - | - | - |
| 1 | `signer` | | S | pemilik *atau* `limit_order_admin` |
| 2 | `pool_state` | | | |
| 3 | `tick_array` | | | |
| 4 | `limit_order` | W | | |
| 5 | `output_token_account` | W | | ATA output pemilik. |
| 6 | `output_vault` | W | | Vault output pool. |
| 7 | `output_vault_mint` | | | |
| 8 | `output_token_program` | | | |
**Efek**
* Menghitung output kumulatif yang terhutang menggunakan `(limit_order.unfilled_ratio_x64, tick.unfilled_ratio_x64)`.
* Mentransfer delta ke `output_token_account`.
* Memperbarui `limit_order.settled_output`.
* **Tidak** menutup pesanan; masih terbuka terhadap input yang tersisa.
## `CloseLimitOrder`
Tutup akun pesanan yang sepenuhnya dikonsumsi. Sewa selalu dikembalikan ke `limit_order.owner` terlepas dari siapa yang menandatangani.
**Pemanggil** — baik `owner` atau `limit_order_admin`.
**Prekondisi**
* Pesanan memiliki sisa yang tidak terisi nol (baik `amount == total_amount` terisi dan diselesaikan, atau pemilik sebelumnya mengurangi pesanan ke nol dan lupa menutup).
**Efek**
* Menutup `limit_order`; sewa dikirim ke `limit_order.owner`.
## `CreateDynamicFeeConfig` (admin)
Buat set parameter yang dapat digunakan kembali di bawah indeks u16.
**Argumen**
```
index: u16
filter_period: u16 // detik; misalnya 30
decay_period: u16 // detik; misalnya 600. Harus > filter_period
reduction_factor: u16 // 1..10_000; misalnya 5_000 = 50% retensi per jendela decay
dynamic_fee_control: u32 // 1..100_000; gain pada kurva volatilitas-ke-biaya
max_volatility_accumulator: u32 // plafon
```
**Akun**
| # | Nama | W | S | Catatan |
| - | - | - | - | - |
| 1 | `owner` | W | S | Pubkey admin yang dikodekan keras. |
| 2 | `dynamic_fee_config` | W | | PDA, `init` di sini. |
| 3 | `system_program` | | | |
**Kesalahan umum** — `InvalidDynamicFeeConfigParams` jika `decay_period <= filter_period` atau bidang bernilai 0 apa pun di luar batas.
## `UpdateDynamicFeeConfig` (admin)
Ubah `DynamicFeeConfig` yang ada. Pool yang sudah mengambil snapshot config saat pembuatan **tidak** diperbarui secara retroaktif; hanya pool yang baru dibuat yang mereferensikan config ini akan mengambil nilai baru.
**Argumen** — lima bidang kalibrasi yang sama dengan `CreateDynamicFeeConfig` (`filter_period`, `decay_period`, `reduction_factor`, `dynamic_fee_control`, `max_volatility_accumulator`); `index` diperbaiki saat pembuatan dan tidak dilewatkan ulang di sini.
## `CollectProtocolFee` / `CollectFundFee`
Sapukan biaya protokol/dana yang terkumpul dari vault pool ke penerima, menolkan bidang `PoolState.protocol_fees_*` / `fund_fees_*` yang sesuai. **Ini bukan tata letak CPMM** — CLMM tidak memiliki akun `authority`, dan bidang penerima dinamai `recipient_token_account_{0,1}` bukan `recipient_token_{0,1}_account`.
**Argumen** — `amount_0_requested: u64`, `amount_1_requested: u64`.
| # | Nama | W | S | Catatan |
| - | - | - | - | - |
| 1 | `owner` | | S | `amm_config.owner` (atau `amm_config.fund_owner` untuk varian dana), atau admin program; jika tidak `NotApproved`. |
| 2 | `pool_state` | W | | |
| 3 | `amm_config` | | | `address = pool_state.amm_config`. |
| 4 | `token_vault_0` | W | | |
| 5 | `token_vault_1` | W | | |
| 6 | `vault_0_mint` | | | |
| 7 | `vault_1_mint` | | | |
| 8 | `recipient_token_account_0` | W | | |
| 9 | `recipient_token_account_1` | W | | |
| 10 | `token_program` | | | |
| 11 | `token_program_2022` | | | |
**Berubah di 2026-09: config baru tidak lagi mengambil pemilik biaya dari penandatangan.** `create_amm_config` sekarang menulis `protocol_fee_owner::ID` yang dikodekan keras program ke `owner` dan `fund_fee_owner::ID` ke `fund_owner`. Sebelumnya, ia menyalin kunci penandatangan admin ke keduanya. Di mainnet ini adalah kunci yang sama yang sudah disimpan di semua 21 config yang ada. Alamat ada di [`reference/program-addresses`](/id/reference/program-addresses#clmm-fee-owner-wallets).
Penandatangan yang diterima di atas tidak berubah. Admin masih dapat mengumpulkan dari config apa pun, dan akun `AmmConfig` **yang ada tidak ditulis ulang**. Baca `owner` / `fund_owner` dari akun bukan asumsi nilai apa pun. Parameter `UpdateAmmConfig` `3` dan `4` masih merotasinya.
## `CollectExcessLamports`
Sapuan admin lamport di atas minimum rent-exempt pada akun yang CLMM kontrol. Ini ditambahkan dalam upgrade 2026-09 untuk mengklaim over-funding yang [SIMD-0437 rent reduction](/id/solana-fundamentals/rent-and-reclaimable-rent) tinggalkan pada akun yang dibuat sebelum setiap langkah.
Hanya kelebihan yang bergerak. Saldo token, data akun, pemilik, status pool dan kurva harga tidak tersentuh. Akun yang sudah di minimum dibiarkan apa adanya, jadi instruksi dapat dijalankan kembali dengan aman setelah setiap peluncuran.
**Argumen**: tidak ada.
**Akun**
| # | Nama | W | S | Catatan |
| - | - | - | - | - |
| 1 | `collect_lamports_wallet` | W | S | Menerima setiap lamport yang disapu. Harus menjadi admin program CLMM atau dompet collect-lamports khusus (lihat [`reference/program-addresses`](/id/reference/program-addresses#excess-lamports-collection-wallets)). Penandatangan lain gagal dengan `NotApproved`. |
| 2 | `pool_state` | W | | Pool yang disapu. Seed PDA-nya menandatangani CPI token-program, dan akun selalu disapu sendiri. |
| 3 | `token_program` | | | SPL Token. |
| 4 | `token_program_2022` | | | Token-2022. Kedua program diperlukan; instruksi memilih satu per akun sumber. |
| 5.. | `remaining_accounts` | W | | `M` akun sumber, jumlah berapa pun, urutan apa pun. |
**Cakupan: satu pool per panggilan.** CLMM tidak memiliki otoritas vault tingkat program. Vault setiap pool dimiliki oleh `PoolState`-nya sendiri. Setiap sumber token-program harus memiliki `pool_state` di slot 2 sebagai otoritasnya: `token_vault_0`, `token_vault_1`, atau salah satu vault reward pool itu. Jika Anda melewatkan vault pool lain atau akun token pengguna, pemeriksaan pemilik token program gagal dan seluruh instruksi kembali. Itu tidak dilewati. Mint NFT posisi tidak dapat disapu, karena mint authority-nya dicabut saat posisi dibuka.
**Bagaimana setiap akun sumber ditangani**
Program membuat dua lintasan atas `remaining_accounts`: setiap CPI token-program terlebih dahulu, kemudian debit langsung. Menyelipkan keduanya membatalkan dengan kesalahan `UnbalancedInstruction` runtime, jadi urutan diperbaiki dalam program dan Anda tidak harus mengurutkan daftar sendiri.
| Lintasan | Pemilik akun sumber | Penanganan |
| - | - | - |
| 1 | SPL Token atau Token-2022, akun token non-native | CPI `WithdrawExcessLamports` (diskriminan token-program `38`), ditandatangani oleh `pool_state`. |
| 1 | SPL Token atau Token-2022, **native** (wSOL) akun token | `WithdrawExcessLamports` menolak akun native. Program CPI `SyncNative`, mengukur berapa banyak `amount` yang dibungkus tumbuh, dan memanggil `UnwrapLamports` (diskriminan `45`) untuk delta yang tepat. Kemudian memerlukan saldo yang dibungkus sama dengan nilai pra-sync-nya, atau gagal dengan `LamportsCalculateError` (`6052`). Vault pool sisi SOL menyimpan likuiditas penuhnya. |
| 2 | `pool_state` (slot 2) | Didebit langsung ke `rent.minimum_balance(data_len)`. |
| 2 | Program CLMM: `AmmConfig`, `ObservationState`, `TickArrayBitmapExtension`, `TickArrayState`, `PersonalPositionState`, `LimitOrderState`, dan sebagainya | Didebit langsung ke `rent.minimum_balance(data_len)`. Akun **tidak** harus milik pool di slot 2. |
| — | Apa pun yang lain | **Dilewati diam-diam.** Tidak ada kesalahan, tidak ada lamport yang bergerak. |
**Lintasan 2 mencakup akun yang sewanya dibayar pengguna.** `PersonalPositionState` atau `LimitOrderState` yang dilewatkan di sini menyerah kelebihannya seperti akun CLMM lainnya. Itu tetap rent-exempt dan menyimpan datanya. Ketika nanti ditutup, pemilik mendapat kembali apa pun yang dipegang akun pada saat itu, yang setelah sapuan adalah minimum sewa saat ini.
Ukuran transaksi adalah batas nyata pada berapa banyak sumber yang cocok dalam satu panggilan. Ini adalah batasan yang sama dengan sapuan sisi dompet yang dijelaskan dalam [`solana-fundamentals/rent-and-reclaimable-rent`](/id/solana-fundamentals/rent-and-reclaimable-rent#batching-how-many-fit-in-one-transaction).
**Kesalahan umum**:
* `NotApproved` (`6000`): penandatangan yang salah.
* `LamportsCalculateError` (`6052`): putaran wSOL tidak netto ke nol.
* Kesalahan ketidakcocokan pemilik token-program: sumber token tidak dimiliki oleh `pool_state`.
* `InsufficientFunds`: akun yang dimiliki program menyimpan kurang dari minimum sewa-nya sendiri.
**Tidak ada pembangun SDK.** `@raydium-io/raydium-sdk-v2` tidak mengirimkan pembangun untuk jalur admin ini. Enkode dengan tangan dari IDL.
## `InitializeReward`
Tambahkan aliran reward baru ke pool.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.