Skip to main content
本頁內容由 AI 自動翻譯,所有內容以英文版本為準。查看英文版 →
本頁說明每個帳戶的配置和角色。種子(Seeds)是規範的,列在 reference/program-addresses。CLMM 池比 CPMM 池需要更多帳戶,因為流動性稀疏地分佈在整個 tick 範圍內;理解這種稀疏性是本頁的重點。

帳戶清單

一個活躍的 CLMM 池由以下帳戶族群描述。除了兩個 mint 及其金庫外,所有帳戶都由 CLMM 程式擁有。

PoolState

池的活躍狀態,在每次交換和每次位置變更時讀取。
你實際會接觸的欄位:
  • sqrt_price_x64tick_current 是池的價格狀態。它們在每次交換時一起更新。tick_currentlog_{1.0001}(price) 的下限。
  • liquidity活躍流動性——所有位置的 L 值之和,其範圍包含 tick_current。每次交換跨越 tick 時以及每次位置開啟/關閉/調整大小時都會變更。
  • fee_growth_global_{0,1}_x64 是整個池歷史中每單位流動性累積的費用。位置讀取此值以計算欠他們的費用。
  • tick_spacing 在初始化時鎖定到 AmmConfig,永遠不會改變。它決定哪些 tick 索引可以作為位置端點。
  • tick_array_bitmap 是一個內聯位圖,涵蓋現貨價格周圍的「接近」範圍——±1,024 個 tick 陣列。對於位置範圍很遠的池,溢出追蹤位於單獨的 TickArrayBitmapExtension
  • fee_on 在池建立時固定。0(FromInput)重現經典 Uniswap-V3 行為。12 將交換費路由到書籍的單一側——參見 products/clmm/fees 以了解權衡。
  • seed_index 對於透過 CreatePool / CreateCustomizablePool 建立的每個池都是 [0, 0](每對一個規範池)。非零值表示池是透過 CreatePermissionedPool 建立的,索引是池 PDA 種子的一部分,允許多個池為相同的 (config, mint0, mint1) 共存。要重新衍生這樣的池的地址,你必須知道其 seed_index
  • dynamic_fee_info 攜帶動態費用機制的波動性狀態。啟用時,每次交換都會在 AmmConfig.trade_fee_rate 之上重新計算 dynamic_fee_component。配置在 DynamicFeeInfo 下記錄;沒有動態費用的池將整個結構保留為零。

AmmConfig

一組典型發佈的 CLMM 費用等級(確認對比 GET https://api-v3.raydium.io/main/clmm-config): protocol_fee_ratefund_fee_rate 是交易費的分數;與 CPMM 相同的慣例。參見 products/clmm/fees

TickArrayState

CLMM 不為每個 tick 儲存單一記錄。那會是數十億個帳戶。相反,它將**TICK_ARRAY_SIZE 個相鄰的已初始化或未初始化 tick**(通常為 60 或 88,取決於程式版本)分組到一個 TickArrayState 中,該狀態在首次使用時延遲建立。
四個限價單欄位在任何從未用於限價單的 tick 上都是零。當訂單在 tick 上開啟時,程式將它們追蹤為一系列群組:
  • order_phase 是群組 ID。每次群組從「全部未填充」轉換為「部分填充」時遞增。
  • orders_amount 是目前(最新)群組的輸入代幣總額。
  • part_filled_orders_remaining 追蹤目前正在被進行中的交換填充的前一個群組。
  • unfilled_ratio_x64 是在群組上進行的 Q64.64 乘數:當交換填充群組的 X% 時,比率乘以 (1 − X)。每個開放訂單在開啟時儲存自己的 (order_phase, unfilled_ratio_x64) 快照,因此結算數學簡化為比較快照。
規則:
  • 位置端點 tick t 必須滿足 t % tick_spacing == 0。程式拒絕不符合間距的位置。
  • tick 的陣列位於 floor(t / (TICK_ARRAY_SIZE * tick_spacing)) * (TICK_ARRAY_SIZE * tick_spacing)
  • tick 陣列延遲初始化:第一個接觸未初始化陣列的位置或交換會建立它,支付租金。
  • tick 陣列永遠不會被程式關閉。一旦分配,它就會在池的整個生命週期內持續存在,即使其中的每個 tick 都回到 liquidity_gross == 0。後續位置和交換無需額外租金即可重用現有帳戶。沒有 ClosePosition 驅動的 tick 陣列清理路徑。

TickArrayBitmapExtension

PoolState.tick_array_bitmap(內聯)涵蓋「接近現貨」範圍——±1,024 個 tick 陣列。超出該範圍(對於極端 tick 值),程式維護一個擴展帳戶:
如果你的位置範圍是「正常的」,你永遠不會考慮擴展帳戶。全範圍位置(例如 (MIN_TICK, MAX_TICK))需要它;SDK 為你解決它。

位置

CLMM 位置是三個帳戶加一個 mint 的組合

位置 NFT mint

一個供應量為 1 的 SPL Token 或 Token-2022 mint。擁有者錢包中的位置 NFT 是持有該單一代幣的 ATA。程式將授權鑰匙設定為 NFT ATA 餘額的目前持有者,而不是儲存在狀態中的 Pubkey。 新位置 NFT mint 在鑄造單一代幣並移除 mint 授權之前將 pool_state 設定為其凍結授權。設定凍結授權本身不會凍結 NFT 帳戶。 帳戶保持未凍結和可轉移,除非兩個條件都成立:呼叫者使用 OpenPositionV2OpenPositionWithToken22Nft,且至少一個基礎金庫 mint 的凍結授權出現在 CLMM 的受限發行者清單上。只有這樣,CLMM 才會在鑄造後凍結 NFT 帳戶。這不會改變任何 PersonalPositionStatePoolState 位元組。

PersonalPositionState

每個開放位置一個。以 NFT mint 為鑰匙。

ProtocolPositionState(已棄用)

較舊的 CLMM 版本在 ProtocolPositionState PDA 中儲存每個 (pool, tick_lower, tick_upper) 的聚合簿記。較新的版本不再建立或讀取此帳戶。 該位置仍然出現在 OpenPosition / IncreaseLiquidity / DecreaseLiquidity 帳戶清單上,作為 UncheckedAccount 以保持 ABI 相容性,但程式不會寫入它。鏈上現有帳戶是遺留的;管理員可以呼叫 CloseProtocolPosition 以回收其租金。聚合範圍簿記現在直接從兩個端點 tick(liquidity_grossliquidity_net 和每個 tick 的 fee_growth_outside_* / reward_growths_outside_x64)在 TickArrayState 中衍生。費用增長內部公式 fee_growth_inside = global − outside_lower − outside_upper 無需聚合位置帳戶即可繼續工作。

觀察

CLMM 的觀察緩衝區儲存累積 tick,而不是累積價格。外部消費者從 (tick_cumulative[t1] − tick_cumulative[t0]) / (t1 − t0) 計算區間上的幾何平均價格,然後 price = 1.0001 ** tick。參見 algorithms/clmm-math

DynamicFeeConfigDynamicFeeInfo

動態費用參數位於兩個地方。可重用的範本——DynamicFeeConfig——由管理員管理並在選擇加入的池之間共享。每個池的執行時狀態——DynamicFeeInfo——嵌入在 PoolState 中並由每次交換更新。

DynamicFeeConfig

PDA 種子:["dynamic_fee_config", index.to_be_bytes()]。透過 create_dynamic_fee_config(管理員門控)建立,透過 update_dynamic_fee_config 修改。使用 enable_dynamic_fee = true 建立的池在建立時將配置的五個校準參數(filter_perioddecay_periodreduction_factordynamic_fee_controlmax_volatility_accumulator)快照到自己的 DynamicFeeInfo 中;稍後對 DynamicFeeConfig 的編輯不會追溯影響現有池。

DynamicFeeInfo(嵌入在 PoolState 中)

底部四個欄位是狀態;頂部五個是從 DynamicFeeConfig 複製的校準。費用數學和衰減規則記錄在 products/clmm/mathproducts/clmm/fees 下。 公式使用的常數:

LimitOrderState

每個開放限價單一個帳戶。
生命週期:
  1. 開啟——使用者呼叫 open_limit_order,存入輸入代幣的 total_amount,訂單綁定到 TickState 群組。
  2. (可選)增加/減少——increase_limit_order 添加到 total_amountdecrease_limit_order 返回未填充的代幣(以及到該點為止的任何已結算輸出)。
  3. 結算——當群組被完全或部分填充時,擁有者操作保管人呼叫 settle_limit_order 將輸出代幣推送到擁有者的 ATA。
  4. 關閉——一旦 unfilled_amount == 0,帳戶就可以關閉。租金始終返回給 owner
PDA 種子:[owner.as_ref(), limit_order_nonce.key().as_ref(), limit_order_nonce.order_nonce.to_be_bytes().as_ref()]。訂單 PDA 因此對每個 (owner, nonce_index, order_nonce) 都是唯一的。

LimitOrderNonce

每個 (wallet, nonce_index) 計數器,讓單一使用者執行多個平行的限價單管道,而不會在 PDA 上發生衝突。
PDA 種子:[user_wallet.as_ref(), &[nonce_index]]。大多數客戶端使用 nonce_index = 0 並讓 order_nonce 進行基數計算。

Permission

一個能力帳戶,其存在就是授權:如果為給定的授權衍生 Permission PDA,該授權可以呼叫 CreatePermissionedPool。它除了建立它的授權外不儲存任何內容。
PDA 種子:["permission", authority.as_ref()]。由管理員透過 CreatePermissionPda 建立,透過 ClosePermissionPda 拆除(租金退款給呼叫者)。兩個管理員指令都接受程式 admin 或專用 permission_pda_admin 鑰匙。關閉 PDA 會撤銷授權——授權不再能建立額外的池,但它已建立的池不受影響。

衍生關鍵帳戶

確切的種子字串應始終對照鏈上 IDL 和 reference/program-addresses 進行雙重檢查。

生命週期快速參考

TickArrayState 帳戶永遠不會被程式關閉——它們在池的整個生命週期內持續存在。一旦 tick 陣列已初始化,即使其中的每個 tick 都回到 liquidity_gross == 0,它也會保留在鏈上。重用現有 tick 陣列是免費的;只有第一個接觸從未初始化陣列的位置才支付其租金。

在哪裡閱讀什麼

來源: