Skip to main content
Bu sayfa yapay zekâ tarafından otomatik olarak çevrilmiştir. İngilizce sürüm esas alınır.İngilizce sürümü görüntüle →
Bu sayfa products/clmm/accounts (hesaplar nedir) ve products/clmm/math (matematik nedir) ile birlikte çalışır. Argümanlar ve hesap sıralaması için yetkilidir; belirli bayt düzenleri IDL’den gelir.2026-09 program yükseltmesi CLMM’yi Anchor 1.0.2 / Solana 3.1.10 üzerinde yeniden oluşturdu, admin talimatı CollectExcessLamports ekledi ve CreateAmmConfig’in owner / fund_owner alanlarına ne yazıldığını değiştirdi. Hiçbir kullanıcı tarafından erişilen talimat hesaplarını, argümanlarını veya matematiklerini değiştirmedi. 2026-09-30 changelog girişine bakın.

Talimat envanteri

Tick array başlatma talimatı yoktur ve buna gerek yoktur. Tick array, OpenPosition* / IncreaseLiquidity* içinde TickArrayState::get_or_create_tick_array tarafından oluşturulur; payer tarafından ödenir. (Muhtemelen hala başlatılmamış, sistem tarafından sahip olunan) tick-array PDA’sını tick_array_lower / tick_array_upper olarak geçirin ve program eksikse onu ayırır. OpenLimitOrder tek tick_array’i için aynısını yapar.
Çoğu yalnızca admin talimatı (CreateAmmConfig, UpdateAmmConfig, UpdatePoolStatus, CreateOperationAccount, UpdateOperationAccount, CloseProtocolPosition) program’ın sabit kodlanmış admin genel anahtarı tarafından kapılanır. CreatePermissionPda / ClosePermissionPda admin genel anahtarını veya özel permission_pda_admin anahtarını kabul eder; CreateSupportMintAssociated / CloseSupportMintAssociated admin genel anahtarını veya özel destek-mint sahibi anahtarını kabul eder; CollectExcessLamports admin genel anahtarını veya özel lamport toplama cüzdanını kabul eder. Ödül akışı admin talimatları (TransferRewardOwner, CollectRemainingRewards) program admin’i değil, ödül fon sağlayıcısı tarafından kapılanır. V2 soneki “Token-2022’yi kasa / NFT’de destekler, bitmap-uzantı yuvası gerektirir” anlamına gelir. SDK yeni havuzlar için varsayılan olarak V2’yi seçer.

CreatePool

Argümanlar
Hesaplar (kısaltılmış)
Yuva 10 ve 11 mint başına, “SPL Token sonra Token-2022” değildir. Her biri eşleşen mint’teki mint::token_program tarafından kısıtlanır; bu nedenle token_mint_0’ı Token-2022 ve token_mint_1’i klasik SPL olan bir havuz için yuva 10’da Token-2022 ve yuva 11’de SPL Token geçirmelisiniz. CreateCustomizablePool ve CreatePermissionedPool aynı iki yuvayı kullanır.
Ön koşullar
  • token_mint_0 < token_mint_1 bayt sırasına göre.
  • amm_config.disable_create_pool == false.
  • Mint’ler Token-2022 uzantı izin listesi tarafından reddedilmez.
Son koşullar
  • pool_state.sqrt_price_x64 = sqrt_price_x64, tick_current = floor(log_{1.0001}(price)).
  • pool_state.liquidity = 0 (henüz pozisyon yok).
  • pool_state.fee_on = FromInput (eski varsayılan).
  • pool_state.dynamic_fee_info sıfırlanır (dinamik ücret devre dışı).

CreateCustomizablePool

Yeni havuzlar için önerilir. CreatePool ile aynı etki artı havuz başına ücret toplama modu ve isteğe bağlı dinamik ücret katılımı. Argümanlar
Hesaplar — tam olarak CreatePool’un 13 beyan edilen hesabı. dynamic_fee_config beyan edilen hesap değildir.
enable_dynamic_fee = true olduğunda, anlık görüntü alınacak DynamicFeeConfig son remaining_account olarak sağlanmalıdır — işleyici ctx.remaining_accounts.last() okur. Herhangi bir SupportMintAssociated bypass PDA’sı bu nedenle bundan önce gelmelidir, aksi takdirde program yanlış hesabın anlık görüntüsünü alır ve deserialization başarısız olur. Bayrak ayarlanmışken bunu atlarsanız AccountLack ile başarısız olur.
Ön koşullar — CreatePool ile aynı. enable_dynamic_fee = false ise, remaining_account gerekli değildir ve geçirilen herhangi biri yalnızca destek-mint kayıtları için taranır. Son koşullar
  • pool_state.fee_on seçilen CollectFeeOn varyantına ayarlanır.
  • Dinamik ücret etkinleştirilirse: pool_state.dynamic_fee_info sağlanan DynamicFeeConfig’den başlatılır (beş kalibrasyon parametresi kopyalanır; durum alanları sıfırlanır).
  • Aksi takdirde: pool_state.dynamic_fee_info sıfırlanır (= bu havuz için dinamik ücret sonsuza kadar etkin değil).
fee_on ve dinamik ücret etkinleştirme biti yalnızca havuz oluşturma sırasında ayarlanır. Yerinde yükseltme yoktur — eski CreatePool aracılığıyla oluşturulan havuzlar dinamik ücret veya tek taraflı ücret kazanamaz. Yeni dağıtımlar varsayılan olarak bu talimata geçmelidir.

CreatePermissionedPool

Hem CreatePool hem de CreateCustomizablePool havuz PDA’sını ["pool", amm_config, token_mint_0, token_mint_1]’den türetir; bu nedenle (config, mint0, mint1) üçlüsü başına tam olarak bir kanonik havuz adresi vardır — aynı seed’lerde ikinci bir init başarısız olur. CreatePermissionedPool bu kısıtlamayı kaldırır; istemci tarafından sağlanan seed_index: u16’yı havuz PDA seed’lerine katarak, aynı çift ve ücret katmanı için birden fazla havuza izin verir — her biri kendi adresinde. Keyfi bir havuz adresi ayrıcalıklı bir yetenek olduğundan, ödeyici bunu yetkilendiren Permission PDA’sı tutmalıdır. Havuzun diğer her şeyi CreateCustomizablePool ile aynıdır: aynı CreateCustomizableParams’ı alır ve tek taraflı ücret ve dinamik ücret katılımını destekler. Argümanlar
Hesaplar (kısaltılmış) — CreateCustomizablePool ile aynı artı, başında: pool_state PDA’sı ["pool", amm_config, token_mint_0, token_mint_1, seed_index.to_le_bytes()]’den türetilir. Ön koşullar
  • seed_index != 0. seed_index değeri 0 eski havuzlar için ayrılmıştır ve burada reddedilir; [0, 0] seed bileşeni, eski havuz adresinin klasik dört seed formuna çökmesini sağlayan şeydir.
  • payer için permission PDA’sı vardır (admin tarafından CreatePermissionPda aracılığıyla oluşturulur).
  • CreatePool ile aynı mint / izin listesi kuralları.
Son koşullar
  • Yeni pool_state seed_index-türetilmiş adresinde vardır; pool_state.seed_index = seed_index.
  • Diğer tüm son durum CreateCustomizablePool ile eşleşir (ücret modu, isteğe bağlı dinamik ücret).
Bu talimat genel havuz oluşturma erişimini genişletmez — izinsiz oluşturma CreatePool / CreateCustomizablePool aracılığıyla devam eder; bunlar çift başına bir havuz kalır. CreatePermissionedPool zaten bir havuza sahip olan bir çift için birden fazla havuza ihtiyaç duyan (örn. farklı başlangıç fiyatları veya başlatma kohortları) ve admin tarafından verilen Permission PDA’sı tutan beyaz listeye alınmış bir operatör için özel durum için vardır.

OpenPositionV2 / OpenPositionWithToken22Nft

Mevcut bir havuz içinde yeni bir pozisyon oluşturun. Argümanlar
Hesaplar — iki varyantın farklı hesap listeleri vardır. OpenPositionV2 22’yi beyan eder; OpenPositionWithToken22Nft 20’yi beyan eder. OpenPositionV2, sırasında: OpenPositionWithToken22Nft metadata_account (5) ve metadata_program (19) kaldırılmış aynı listedir — pozisyonun meta verilerini NFT mint’inde Token-2022 meta veri uzantısı aracılığıyla yazar — 20 hesap verir. position_nft_mint’i çıplak Signer ve position_nft_account’u UncheckedAccount’dur.
tick_array_bitmap_extension her iki varyantda da beyan edilen hesap değildir. Pozisyonun aralığı havuzun satır içi tick_array_bitmap’inin dışına düştüğünde (±512 tick dizileri), TickArrayBitmapExtension PDA’sını seed’lerde ["pool_tick_array_bitmap_extension", pool_state] olarak remaining_accounts[0] olarak ekleyin.
Matematik — products/clmm/math bakın. base_flag verildiğinde, program liquidity veya (amount_0_max, amount_1_max)’ı gerçek L ve tüketilen gerçek token tutarlarına çözer. Ön koşullar
  • tick_lower < tick_upper, her ikisi pool.tick_spacing’in katları, [MIN_TICK, MAX_TICK] içinde.
  • İki tick-array PDA’sı geçirilir. Zaten var olması gerekmez — get_or_create_tick_array eksik olanı bu talimat içinde payer’ın masrafına ayırır. Ayrı bir init-tick-array talimatı yoktur.
  • Kullanıcı kaynak ATA’larında en az amount_0_max ve amount_1_max vardır.
Son koşullar
  • personal_position vardır; liquidity ayarlanır; fee_growth_inside_last anlık görüntü alınır.
  • Tick-array girdileri tick_lower ve tick_upper’da güncellenir (liquidity_gross += L, liquidity_net ± L, ücret büyümesi anlık görüntüleri korunur).
  • pool_state.liquidity += L pozisyon aralıkta ise (tick_lower ≤ tick_current < tick_upper).
  • Pozisyon NFT mint’i pool_state’i dondurma yetkilisi olarak kaydeder. Mint yetkilisi tek NFT basıldıktan sonra kaldırılır. Dondurma yetkilisini kaydetmek NFT token hesabının durumunu değiştirmez.
  • NFT token hesabı, talimat OpenPositionV2 veya OpenPositionWithToken22Nft ve kasa mint’inin dondurma yetkilisi CLMM’nin kısıtlı-yayıncı listesiyle eşleşmediği sürece donmuş kalır. Yalnızca eşleşen V2 yolu hesabı dondurur. OpenPosition V1 dondurmaz.
Yaygın hatalar — TickInvalidOrder (tick_lower >= tick_upper), TickAndSpacingNotMatch (bir uç nokta tick_spacing’in katı değil), InvalidTickIndex ([MIN_TICK, MAX_TICK] dışında), MissingTickArrayBitmapExtensionAccount (aralık satır içi bitmap dışında ve uzantı eklenmedi), NotApproved (pool_state.status açmayı engeller), ZeroAmountSpecified.
Pozisyon dondurma beyan edilen talimat hesapları veya argümanları eklemez. İstemciler mevcut V2 düzenleriyle bu pozisyonları açabilir. Davranış zincir üzerinde vault_0_mint ve vault_1_mint’den seçilir.

IncreaseLiquidityV2

Zaten açık olan bir pozisyona likidite ekleyin. Argümanlar
Hesaplar — 15 ve OpenPosition’dan türetilemez: rent, system_program, associated_token_program ve meta veri hesabı yoktur. Pozisyonun aralığı satır içi bitmap dışında olduğunda TickArrayBitmapExtension PDA’sını remaining_accounts[0] olarak başına ekleyin. Etki
  • amount_0_actual / amount_1_actual’ı kullanıcı → kasalar’dan aktarır.
  • personal_position.liquidity ve pool_state.liquidity (aralıkta ise) artırır ve uç nokta-tick liquidity_gross / liquidity_net’i buna göre artırır.
  • Son dokunuştan bu yana borçlu ücretleri ve ödülleri toplar ve token_fees_owed_{0,1} / reward_amount_owed’e kredi verir. Bunlar yalnızca DecreaseLiquidity / DecreaseLiquidityV2’de ödenir; artışta değil — bağımsız bir toplama talimatı yoktur.

DecreaseLiquidityV2

Bir pozisyondan likiditeyi kaldırın. Argümanlar
Hesaplar — 16 ve IncreaseLiquidityV2 ile aynı şekil veya sıra değildir: personal_position ve pool_state değiştirilir; kasalar tick dizilerinden önce gelir; kullanıcı tarafı hesaplar recipient_token_account_* olarak adlandırılır; ve ekstra memo_program vardır. Kalan hesaplar — etkin olan her ödül için üç tane; reward_token_vault(W), recipient_token_account(W), reward_vault_mint sırasında. Pozisyonun aralığı satır içi bitmap dışında olduğunda TickArrayBitmapExtension PDA’sını başına ekleyin.
Bu aynı zamanda ücretleri ve ödülleri toplamak için tek yoldur. Pozisyonu değiştirmeden toplamak için liquidity = 0, amount_0_min = 0, amount_1_min = 0 ile çağırın.
Etki
  • Geçerli sqrt_price_x64 verilen kaldırılan L için (amount_0, amount_1) hesaplar.
  • Son dokunuştan bu yana tahakkuk eden ücretleri/ödülleri kapatır; IncreaseLiquidity ile aynı.
  • amount_0 + fees_owed_0 ve amount_1 + fees_owed_1’i kasalardan kullanıcıya aktarır.
  • Likidite sayaçlarını azaltır; yeni personal_position.liquidity == 0 ise, pozisyon ClosePosition için uygun hale gelir.
Kayma — amount_0_min ve amount_1_min kullanıcının çıktı tarafında Token-2022 transfer ücretleri net olarak kabul ettiği minimumlardır.

ClosePosition

Pozisyon NFT’sini yakın ve PersonalPositionState’i kapatın. Beyan edilen hesaplar Kalan hesaplar
  • Donmuş olmayan NFT: hiçbiri gerekli değil; ekstra havuz hesabı işleyici bunu okumadığı için zararsızdır.
  • Donmuş NFT: personal_position.pool_id’yi ilk kalan hesap olarak ekleyin. Program bunu PoolState olarak yükler ve çözmek için PDA seed’lerini kullanır.
Ön koşullar
  • personal_position.liquidity == 0.
  • tokens_fees_owed_{0,1} == 0.
  • Tüm ödül sayaçları reward_amount_owed == 0.
(Yani, her şeyi toplayın ve önce sıfıra azaltın.) Etki
  • NFT token hesabı donmuşsa, ilk kalan hesabın personal_position.pool_id’ye eşit olduğunu doğrular; ardından havuz PDA’sı ile çözer.
  • NFT’yi yakar.
  • NFT token hesabını ve personal_position’ı kapatır; kirayı nft_owner’a geri öder. Pozisyon NFT’si Token-2022 kullanıyorsa, NFT mint’ini de kapatır; klasik SPL Token mint’leri kapatılamaz ve sıfır arzla kalır.
Çözme, yakma ve kapatma atomiktir. NFT bu adımlar arasında aktarılabilir hale gelemez. Koşullu istemci kırılması — beyan edilen IDL düzeni değişmez; bu nedenle eski istemciler mevcut ve donmuş olmayan pozisyonları kapatmaya devam eder. Havuz kalan hesabını atlayan eski bir oluşturucu donmuş bir pozisyonu kapatırken AccountLack ile başarısız olur. Her kapatma için havuzu geçirmek en basit uyumlu stratejidir.

SwapV2

Likidite eğrisini yürüyün; is_base_input’a bağlı olarak tam giriş veya tam çıkış. Argümanlar
Hesaplar (kısaltılmış) Arayanlar yürüyüşün beklenen aralığını kapsayan sıralanmış tick dizileri listesi geçerler; program ihtiyaç duyduğu kadarını kullanır. SDK bu listeyi PoolUtils.computeAmountOutFormat veya API’nin quote uç noktası aracılığıyla hesaplar. Ön koşullar
  • pool_state.status swap’a izin verir.
  • now >= open_time.
  • sqrt_price_limit_x64 yön için sqrt_price_x64’ün doğru tarafındadır.
Yaygın hatalar — TooLittleOutputReceived (tam giriş kayması), TooMuchInputPaid (tam çıkış kayması), SqrtPriceLimitOverflow, NotEnoughTickArrayAccount, InvalidFirstTickArrayAccount, MissingTickArrayBitmapExtensionAccount, LiquidityInsufficient, NotApproved (swap biti pool_state.status’da ayarlanır). CLMM’nin ExceededSlippage varyantı yoktur — bu ad CPMM’nindir — ve TickArrayNotFound yoktur. SwapV2’nin arayanların bilmesi gereken şeyi dahili olarak yaptığı (2025 sonrası sürüm):
  1. Dinamik ücret ek ücreti — pool.dynamic_fee_info sıfır değilse, program son swap’tan bu yana geçilen tick mesafesini kullanarak volatilite biriktiricisini günceller (filtre/bozunma kuralları products/clmm/fees’den) ve AmmConfig.trade_fee_rate’nin üzerine dynamic_fee_component ekler. Toplam ücret %10 ile sınırlanır (MAX_FEE_RATE_NUMERATOR / 1_000_000).
  2. Limit emri eşleştirmesi — fiyat yürüyüşü açık limit emirleri tutan bir tick’i geçtiğinde, program önce o tick’te mevcut limit emri likiditeyi doldurur (FIFO order_phase tarafından), ardından LP likidite eğrisi boyunca ilerler. Doldurulmuş tutarlar tick.unfilled_ratio_x64 ve tick.part_filled_orders_remaining’i daha sonraki kapatma için günceller; emirler kendileri sahibi SettleLimitOrder çağırana kadar harcı olmaz.
  3. Tek taraflı ücret yönlendirmesi — pool.fee_on = Token0Only veya Token1Only olduğunda, swap adımı yine de aynı giriş-çıkış ticaretini hesaplar; ücret daha sonra yapılandırılan tarafa yönlendirilir. Yapılandırılan ücret tarafının çıkış olduğu yönler için, ücret swap çıkışından düşülür (kullanıcı out − fee alır); yapılandırılan tarafın giriş olduğu yönler için davranış FromInput ile eşleşir. PoolState’de is_fee_on_input(zero_for_one) ve is_fee_on_token0(zero_for_one) bakın.
Swap (V1) SwapV2 ile aynı dinamik ücret, tek taraflı ücret yönlendirmesi ve limit emri eşleştirmesini uygular; tek eksik özelliği Token-2022 desteğidir — her iki kasa da klasik SPL Token olmalıdır. Herhangi bir Token-2022 mint’i olan havuzlar SwapV2 aracılığıyla swap’lanmalıdır. Toplayıcı ve SDK zaten her CLMM bacağı için V2’yi tercih eder; bu nedenle arayanlar mint türüne göre dallanmak zorunda değildir.

OpenLimitOrder

Belirli bir tick’te satış emri verin. Emir, tick başına FIFO kohortunda oturur ve fiyat geçtikçe doldurulur. Argümanlar
Hesaplar (kısaltılmış) Kalan hesaplar — [0] tick_array_bitmap_extension, yalnızca başlangıç indeksi havuzun satır içi bitmap’inin dışına düşen bir tick dizisini başlatırken gerekli. Aksi takdirde hiçbir şey geçirmeyin.
rent hesabı yoktur: yapı system_program’da biter; 13 beyan edilen hesap. Konum 14’te dolaşan rent tam olarak isteğe bağlı bitmap uzantısının okunduğu yere iner; bu nedenle sıra satır içi bitmap dışında bir tick dizisinin ilk kez oluşturulması gerekene kadar çalışıyor gibi görünür — ve ardından başarısız olur.
Hesap listesi değişikliği (2026-07 sürümü). OpenLimitOrder artık çıkış tarafı hesaplarını da alır — output_token_account, output_vault ve output_vault_mint — giriş tarafına ek olarak. Bunlar yalnızca doğrulama için kullanılır: program sahibinin giriş veya çıkış token hesabı donmuşsa emri reddeder. Bu, doldurmanın gerçekten sahibinin çıkış ATA’sına kapatılabileceğini garanti eder; bu, izin listesi / varsayılan donmuş Token-2022 mint’leri (örn. izinli tokenler) için önemlidir; burada bir hesap henüz çözülmemiş olabilir. Eski tek taraflı hesap listesine karşı oluşturulan istemciler üç çıkış hesabı eklemelidir.
Ön koşullar
  • Ne input_token_account ne de output_token_account donmuş değildir (aksi takdirde NotApproved).
  • pool_state.status hem swap (bit 4) hem de limit emri (bit 5) işlemlerine izin verir (aksi takdirde NotApproved).
  • tick_index % pool.tick_spacing == 0 ve [MIN_TICK, MAX_TICK] içinde.
  • tick_index seçilen yön için pool.tick_current’ın doğru tarafında (token0 satmak → tick mevcut üzerinde olmalı ve tersi). Zaten geçilmiş bir tick’te satmak hemen eşleştirilir ve reddedilir.
Son koşullar
  • limit_order vardır; tick.order_phase ve tick.unfilled_ratio_x64’ü açık zamanda anlık görüntü alır.
  • tick.orders_amount += amount (mevcut kohortda).
  • limit_order_nonce.order_nonce += 1.
  • OpenLimitOrderEvent yayınlanır.
Yaygın hatalar — NotApproved (giriş veya çıkış token hesabı donmuş veya havuzun swap / limit emri devre dışı), ZeroAmountSpecified (giriş tarafı transfer ücreti sonra amount == 0), InvalidLimitOrderAmount (tutar o tick’te 1 temel birim altında çıkış üretir veya u64 taşar), InvalidTickIndex ([MIN_TICK, MAX_TICK] dışında veya seçilen yön için tick_current’ın yanlış tarafında), TickAndSpacingNotMatch (tick_index % pool.tick_spacing != 0), OrderPhaseSaturated.

IncreaseLimitOrder

Mevcut açık emre ekleyin. Yalnızca emrin owner’ı tarafından çağrılabilir. Argümanlar
Hesaplar — 8, yalnızca giriş tarafı. Nonce hesabını, tüm üç çıkış tarafı hesabını ve system_program’ı bırakır. Ön koşullar
  • limit_order.owner == signer.
  • Emir hala aynı kohortda (tick.order_phase == limit_order.order_phase). Kohort zaten doldurulmaya başlamışsa, emir kısmen kapatılmıştır — çağıran önce DecreaseLimitOrder veya SettleLimitOrder çağırmalıdır.
Etki
  • amount’ı sahibi ATA’sından input_vault’a aktarır.
  • limit_order.total_amount += amount; tick.orders_amount += amount.

DecreaseLimitOrder

Açık emri azaltın veya tamamen iptal edin. Doldurulmayan kalanı sahibine geri ödeyin; artı geçmiş kısmi doldurmalar tarafından zaten kapatılan çıktı. Argümanlar
Hesaplar — hem giriş hem de çıkış token tarafları: Etki
  • Emrin doldurulmuş tutarını açılıştan bu yana kohortun unfilled_ratio_x64’ünden yeniden hesaplar.
  • Doldurulmuş çıktıyı output_token_account’a gönderir.
  • amount doldurulmayan girişi input_token_account’a geri gönderir.
  • limit_order’ı buna göre günceller. Yeni doldurulmayan kalan sıfırsa, program hesabı kapatır ve kirayı owner’a geri öder.

SettleLimitOrder

Emrin doldurulmayan kalanını değiştirmeden doldurulmuş çıktı tokenlerini sahibine gönderin. auto_withdraw bekçileri uzun süreli kısmi doldurmalar damla ödemek istediğinde kullanışlıdır. Çağıran — emrin owner’ı veya programın limit_order_admin’i (otomatik bekçi döngüsü çalıştıran çevrimdışı operasyonel sıcak cüzdan). Bekçinin başka yetkilendirmesi yoktur — doldurulmuş çıktıyı emrin owner ATA’sına göndermek dışında kullanıcı fonlarını hareket ettiremez. Hesaplar Etki
  • (limit_order.unfilled_ratio_x64, tick.unfilled_ratio_x64) kullanarak kümülatif çıkış borçlu tutarını hesaplar.
  • Deltayı output_token_account’a aktarır.
  • limit_order.settled_output’u günceller.
  • Emri kapatmaz; kalan giriş karşısında hala açıktır.

CloseLimitOrder

Tamamen tüketilmiş emir hesabını kapatın. Kira her zaman limit_order.owner’a geri döner; kim imzalarsa imzalasın. Çağıran — owner veya limit_order_admin. Ön koşullar
  • Emrin sıfır doldurulmayan kalanı vardır (ya amount == total_amount dolduruldu ve kapatıldı, ya da sahibi daha önce emri sıfıra azalttı ve kapatmayı unuttu).
Etki
  • limit_order’ı kapatır; kira limit_order.owner’a gönderilir.

CreateDynamicFeeConfig (admin)

u16 indeksi altında yeniden kullanılabilir parametre seti oluşturun. Argümanlar
Hesaplar Yaygın hatalar — InvalidDynamicFeeConfigParams eğer decay_period <= filter_period veya herhangi bir 0 değerli alan sınırların dışında.

UpdateDynamicFeeConfig (admin)

Mevcut DynamicFeeConfig değiştirin. Oluşturma sırasında yapılandırmayı zaten anlık görüntü alan havuzlar retroaktif olarak güncellenmez; yalnızca bu yapılandırmaya başvuran yeni oluşturulan havuzlar yeni değerleri alacaktır. Argümanlar — CreateDynamicFeeConfig ile aynı beş kalibrasyon alanı (filter_period, decay_period, reduction_factor, dynamic_fee_control, max_volatility_accumulator); index oluşturma sırasında sabitlenir ve burada yeniden geçirilmez.

CollectProtocolFee / CollectFundFee

Havuzun kasalarından tahakkuk eden protokol/fon ücretlerini alıcıya tarayın; karşılık gelen PoolState.protocol_fees_* / fund_fees_* alanlarını sıfırlayın. Bu CPMM’nin düzeni değildir — CLMM’nin authority hesabı yoktur ve alıcı alanları recipient_token_{0,1}_account yerine recipient_token_account_{0,1} olarak adlandırılır. Argümanlar — amount_0_requested: u64, amount_1_requested: u64.