Chuyển đến nội dung chính
Trang này được dịch tự động bằng AI. Phiên bản tiếng Anh là bản chính thức.Xem bản tiếng Anh →
Một mục nhập changelog tài liệu. Để xem chỉ mục tất cả các cập nhật, hãy xem reference/changelog. Để xem dòng thời gian lịch sử của giao thức, hãy xem introduction/history-and-milestones.
Phiên bản CLMM tiếp theo bổ sung ba khả năng ở cấp pool. Chúng là tùy chọn tại thời điểm tạo pool và tương thích ngược với các pool và vị trí hiện có.

​
TL;DR cho các nhà tích hợp

  • Limit orders hiện là các nguyên thủy CLMM hạng nhất. LP có thể mở một lệnh tick đơn trên pool hỗ trợ chúng; lệnh được điền FIFO khi swap vượt qua tick, và một keeper ngoài chuỗi (limit_order_admin) có thể thanh toán đầu ra đã điền mà không cần chủ sở hữu trực tuyến. Bảy phương thức SDK mới (openLimitOrder, increaseLimitOrder, decreaseLimitOrder, settleLimitOrder, closeLimitOrder, closeAllLimitOrder, settleAllLimitOrder) và ba điểm cuối Temp API mới dưới /limit-order/ (lệnh hoạt động, lịch sử theo người dùng, nhật ký sự kiện theo PDA) bao gồm toàn bộ quy trình.
  • Single-sided fee (CollectFeeOn) cho phép pool thu phí swap từ phía đầu vào (cũ, chế độ 0), hoặc luôn từ token_0 (chế độ 1), hoặc luôn từ token_1 (chế độ 2). Hữu ích khi một bên của cặp là token kế toán chính tắc.
  • Dynamic fee cho phép pool tham gia vào một khoản phí bổ sung theo dõi biến động tăng lên khi chuyển động tick nhanh chóng và giảm theo thời gian, được hiệu chỉnh bởi DynamicFeeConfig theo tầng và DynamicFeeInfo theo pool. Điểm cuối /main/clmm-dynamic-config mới hiển thị danh sách tầng.
  • Một hướng dẫn mới, CreateCustomizablePool, hiển thị cả ba công tắc tại thời điểm tạo pool. CreatePool cổ điển tiếp tục hoạt động cho các pool không có limit order, phí mặc định.
  • Thay đổi ngắt indexer: các bộ đếm khối lượng theo hướng (swap_in_amount_token_{0,1}, swap_out_amount_token_{0,1}) và bộ đếm phí suốt đời (total_fees_token_{0,1}, total_fees_claimed_token_{0,1}) trên PoolState đã bị loại bỏ vào padding để tạo chỗ cho fee_on và dynamic_fee_info. Các indexer đọc các trường đó trực tiếp phải di chuyển sang vòng Observation trên chuỗi hoặc API.

​
Tại sao điều này quan trọng (cho các nhà giao dịch, LP và nhà tích hợp)

  • Các nhà giao dịch nhận được báo giá chặt hơn trên các cặp long-tail và theo sự kiện: dynamic fee cho phép pool hấp thụ khoản phí bổ sung biến động từ taker mà không cần LP phải chủ động mở rộng phạm vi, và các bậc limit order làm sâu hơn thanh khoản trên chuỗi ở các giá cụ thể mà không cần cam kết vốn trên toàn phạm vi.
  • LP nhận được chiến lược thứ ba bên cạnh các phạm vi tập trung và vị trí toàn phạm vi: đỗ các lệnh giá chính xác, được điền khi giá ghé thăm, thanh toán vào token báo giá. Không cần cân bằng lại hoạt động cho phần đã điền.
  • Các nhà tích hợp có thể mô hình hóa các pool dynamic-fee một cách xác định — thuật toán và tham số hoàn toàn trên chuỗi, các tầng hiệu chỉnh có thể truy vấn được, và đường dẫn swap không thay đổi về hình dạng (chỉ phí mỗi bước thay đổi).

​
Những gì đã thay đổi trong chương trình

​
Tài khoản mới

  • DynamicFeeConfig — bản ghi hiệu chỉnh theo tầng (khoảng thời gian lọc, khoảng thời gian phân rã, hệ số giảm, kiểm soát dynamic fee, bộ tích lũy biến động tối đa). Được tạo bởi CreateDynamicFeeConfig (admin), được tham chiếu bởi CreateCustomizablePool khi dynamic fee được bật.
  • LimitOrderState — tài khoản mỗi lệnh (hạt giống PDA: [owner, limit_order_nonce, order_nonce]) giữ pool, tick, bên, số tiền đầu vào, tỷ lệ chưa điền, giai đoạn cohort FIFO và ảnh chụp sổ sách. Vòng đời là ngầm (filled_amount vs total_amount, cộng với sự tồn tại của tài khoản): Open → Filled → Settled → Closed.
  • LimitOrderNonce — bộ đếm tăng đơn điệu theo-(owner, nonce_index) nhận hạt giống PDA limit order. nonce_index: u8 cho phép chủ sở hữu cùng phân vùng các lệnh thành tối đa 256 luồng nonce độc lập.
Xem Accounts → DynamicFeeConfig and DynamicFeeInfo và Accounts → LimitOrderState.

​
Reshape PoolState

Nhóm trườngBố cục cũBố cục mới
Bộ đếm khối lượng theo hướngswap_in_amount_token_0, swap_out_amount_token_0, swap_in_amount_token_1, swap_out_amount_token_1Gấp vào padding5: [u128; 4]
Bộ đếm phí suốt đờitotal_fees_token_0, total_fees_claimed_token_0, total_fees_token_1, total_fees_claimed_token_1Gấp vào padding6: [u64; 4]
Single-sided fee—fee_on: u8 (0 = FromInput, 1 = Token0Only, 2 = Token1Only)
Dynamic fee—dynamic_fee_info: DynamicFeeInfo (nhúng)
Kích thước tài khoản tổng thể không thay đổi. Indexers: chuyển theo dõi khối lượng từ PoolState sang vòng Observation hoặc API. Các bộ đếm đã loại bỏ không được đặt lại thành 0 trên các pool hiện có (chúng giữ bất kỳ dữ liệu nào mà chúng tình cờ mang lại), vì vậy đọc lại chúng sau khi nâng cấp sẽ trả về dữ liệu cũ.

​
Bổ sung TickState (không có thay đổi ngắt)

Bốn trường mới được thêm vào cuối TickState, thay thế một số padding đuôi của nó:
  • order_phase: u64 — bộ đếm phân biệt các cohort limit order tại tick này.
  • orders_amount: u64 — tổng đầu vào được cam kết bởi tất cả các lệnh mở tại tick này (không phải tất cả đều chưa điền hoàn toàn).
  • part_filled_orders_remaining: u64 — đầu vào vẫn chưa điền trong cohort hiện đang được tiêu thụ bởi swap.
  • unfilled_ratio_x64: u128 — tỷ lệ Q64.64 được sử dụng để tính phần điền của mỗi lệnh.
Bố cục mảng tick, kích thước và hạt giống PDA không thay đổi.

​
Hướng dẫn mới

  • CreateDynamicFeeConfig (admin) — tạo tầng DynamicFeeConfig được hiệu chỉnh. Quyền: cùng multisig kho bạc như CreateAmmConfig.
  • UpdateDynamicFeeConfig (admin) — cập nhật các tham số của tầng hiện có.
  • CreateCustomizablePool — điểm vào tạo pool hiển thị collect_fee_on, enable_dynamic_fee và dynamic_fee_config. Tồn tại cùng với CreatePool; chúng tôi khuyên dùng CreateCustomizablePool cho bất kỳ pool mới nào cần các công tắc mới.
  • OpenLimitOrder — mở một lệnh limit order tick đơn. Bumps LimitOrderNonce, phân bổ LimitOrderState, đặt lệnh vào cohort FIFO tại tick.
  • IncreaseLimitOrder / DecreaseLimitOrder — điều chỉnh phần chưa điền của lệnh. Hoàn nguyên trên lệnh đã điền hoàn toàn với InvalidOrderPhase.
  • SettleLimitOrder — quét đầu ra đã điền vào ATA của chủ sở hữu. Người gọi có thể là chủ sở hữu hoặc keeper limit_order_admin của pool.
  • CloseLimitOrder — đóng lệnh đã thanh toán hoàn toàn để lấy lại tiền thuê.

​
Thay đổi hành vi SwapV2

Đường dẫn swap tự nó không thay đổi về hình dạng, nhưng ba điều xảy ra dọc theo đường:
  1. Dynamic fee (khi được bật): DynamicFeeInfo của pool được cập nhật mỗi bước (phân rã → tích lũy → giới hạn), và khoản phí bổ sung kết quả được thêm vào trên cùng phí cơ sở cho bước đó.
  2. Limit-order matching (khi bước vượt qua tick được khởi tạo có các lệnh mở): một phần đầu vào swap được tiêu thụ FIFO để điền cohort tại tick đó, với unfilled_ratio_x64 được cập nhật nguyên tử.
  3. Single-sided fee routing (khi fee_on != 0): phí được lấy từ token_0 hoặc token_1 bất kể hướng swap, thay vì luôn từ phía đầu vào.
Mỗi cái này là no-op khi pool được tạo với các mặc định cũ. Xem Instructions → SwapV2 để xem ma trận thay đổi trạng thái được cập nhật.

​
Mã lỗi mới

Enum ErrorCode được đánh số lại trong phiên bản này: năm biến thể cũ (LOK, ZeroMintAmount, InvalidLiquidity, TransactionTooOld, InvalidRewardDesiredAmount) đã bị xóa, và mười một biến thể mới được thêm vào. Vì Anchor đánh số lỗi theo thứ tự enum từ 6000, mọi mã lỗi ở hoặc sau các vị trí bị xóa đã thay đổi — các client đã mã hóa cứng mã số cần ánh xạ lại. Các mã mới là:
  • 6040 OrderAlreadyFilled
  • 6041 InvalidOrderPhase
  • 6042 InvalidLimitOrderAmount
  • 6043 OrderPhaseSaturated
  • 6044 InvalidDynamicFeeConfigParams
  • 6045 InvalidFeeOn
  • 6046 ZeroSqrtPrice
  • 6047 ZeroLiquidity
  • 6048 MissingBaseFlag
  • 6049 MissingMintAccount
  • 6050 MissingTokenProgram2022
Các chuỗi đầy đủ và bảng sau shift cho tất cả các lỗi CLMM nằm trong Error codes.

​
Những gì đã thay đổi trong SDK (@raydium-io/raydium-sdk-v2)

  • Phương thức mới trên raydium.clmm: createCustomizablePool, openLimitOrder, increaseLimitOrder, decreaseLimitOrder, settleLimitOrder, settleAllLimitOrder, closeLimitOrder, closeAllLimitOrder.
  • Trợ giúp REST mới trên raydium.api: getClmmDynamicConfigs, getClmmLimitOrderConfigs.
  • Các loại mới: enum CollectFeeOn, DynamicFeeConfig, DynamicFeeInfo, LimitOrderState, LimitOrderConfig.
  • Tổ chức lại nội bộ: utils/ được chuyển sang libraries/. Barrel gói không thay đổi; chỉ nhập sâu dưới @raydium-io/raydium-sdk-v2/utils/... cần cập nhật thành …/libraries/....
Các hướng dẫn TypeScript end-to-end nằm trong products/clmm/code-demos.

​
Những gì đã thay đổi trong các API

  • api-v3 — hai điểm cuối mới dưới /main/:
    • GET /main/clmm-dynamic-config — danh sách các tầng DynamicFeeConfig.
    • GET /main/clmm-limit-order-config — cấu hình limit order theo pool.
  • temp-api-v1 — ba điểm cuối mới dưới /limit-order/:
    • GET /limit-order/order/list?wallet=… — các lệnh đang đỗ hiện tại của ví (mở và điền một phần, được phục vụ từ bộ nhớ cache Redis của indexer; cùng một payload bao gồm cả hai giai đoạn thông qua totalAmount / filledAmount / pendingSettle).
    • GET /limit-order/history/order/list-by-user?wallet=… — các limit order lịch sử của ví. Bộ lọc tùy chọn: poolId, mint1, mint2, hideCancel. Phân trang con trỏ thông qua nextPageId / size (tối đa 100).
    • GET /limit-order/history/event/list-by-pda?pda=… — nhật ký sự kiện theo PDA (open / increase / decrease / settle / close) cho một hoặc nhiều PDA limit order được phân tách bằng dấu phẩy. Phân trang con trỏ thông qua nextPageId / size (tối đa 100).
Cả năm cái đều được ghi chép trong tab API Reference.

​
Bề mặt quyền hạn

limit_order_admin là một keeper hoạt động ngoài chuỗi, không phải multisig. Nó chỉ có thể gọi SettleLimitOrder và CloseLimitOrder trên các lệnh hiện có, và đầu ra của một settle luôn hạ cánh trong ATA của chủ sở hữu. Nó không thể thay đổi các trường pool, mở hoặc sửa đổi các lệnh, hoặc ký cho bất cứ điều gì khác. Xem Admin keys and multisig → CLMM.

​
Trang được cập nhật

  • products/clmm/overview — phần “What’s new” mới và con trỏ bước tiếp theo được cập nhật.
  • products/clmm/accounts — ba tài khoản mới, reshape PoolState với cảnh báo di chuyển, bổ sung TickState, trợ giúp PDA mới.
  • products/clmm/instructions — bảy hướng dẫn mới, phụ lục hành vi SwapV2, ma trận thay đổi trạng thái được cập nhật.
  • products/clmm/fees — phần single-sided fee, phần dynamic fee với bảng tham số.
  • products/clmm/math — mã giả limit order matching, dẫn xuất dynamic fee.
  • products/clmm/code-demos — demo createCustomizablePool, hướng dẫn limit order đầy đủ, cạm bẫy mới.
  • algorithms/clmm-math — tham chiếu chéo đến limit order matching và dynamic fee trong vòng lặp swap đa tick.
  • sdk-api/typescript-sdk — phần bổ sung mô-đun CLMM, ghi chú di chuyển utils/ → libraries/.
  • api-reference/openapi/api-v3.yaml — hai điểm cuối mới với lược đồ phản hồi.
  • api-reference/openapi/temp-api-v1.yaml — ba điểm cuối limit order mới (/limit-order/order/list, /limit-order/history/order/list-by-user, /limit-order/history/event/list-by-pda) với các lược đồ yêu cầu và phản hồi của chúng.
  • api-reference/api-v3/overview — ghi chú về các điểm cuối cấu hình CLMM mới.
  • api-reference/temp-api-v1/overview — ghi chú về các điểm cuối lệnh hoạt động, lịch sử theo người dùng và sự kiện theo PDA mới.
  • reference/error-codes — mười một mã lỗi CLMM mới (6040–6050) cộng với năm mã cũ đã loại bỏ; các mã số sau các điểm loại bỏ đã thay đổi.
  • security/admin-and-multisig — hàng DynamicFeeConfig admin mới và hàng keeper limit_order_admin, với trình giải thích quyền hạn giới hạn.
Xác minh chống lại:
  • Nguồn raydium-clmm.
  • Nguồn @raydium-io/raydium-sdk-v2.
  • Nguồn api-v3 và temp-api-v1.