Журнал изменений

Датированный реестр обновлений этого набора документации. Записи отражают, какие главы изменились, почему и когда содержание было проверено в сравнении с состоянием в цепи и исходным кодом программы.

Эта страница переведена с помощью ИИ. За эталон принимается английская версия.

Открыть английскую версию →

Это журнал изменений документации — реестр обновлений этих страниц с момента запуска проекта. Для временной шкалы самого протокола см. introduction/history-and-milestones. Каждая запись содержит дату, список затронутых глав, причину изменения и дату проверки, указывающую на момент последней перекрёстной проверки содержания с состоянием в цепи и исходным кодом программы.

​

2026-05-18 — CLMM: лимитные ордера, односторонний сбор комиссии, динамическая комиссия

Следующий релиз CLMM добавляет три возможности на уровне пула. Они являются опциональными при создании пула и обратно совместимы с существующими пулами и позициями.

​

Краткое резюме для интеграторов

• Лимитные ордера теперь становятся примитивами CLMM первого класса. LP-поставщики могут открыть однотиковый ордер на пуле, который их поддерживает; ордер заполняется в порядке FIFO при пересечении тика своп-ом, и автоматизированный хранитель (limit_order_admin) может урегулировать заполненный результат без необходимости присутствия владельца в сети. Семь новых методов SDK (openLimitOrder, increaseLimitOrder, decreaseLimitOrder, settleLimitOrder, closeLimitOrder, closeAllLimitOrder, settleAllLimitOrder) и три новые конечные точки Temp API под /limit-order/ (активные ордера, историю пользователя, логи событий по PDA) охватывают полный цикл.
• Односторонний сбор комиссии (CollectFeeOn) позволяет пулу собирать комиссию своп-а с входной стороны (наследование, режим 0), или всегда из token_0 (режим 1), или всегда из token_1 (режим 2). Полезно, когда одна сторона пары является канонической бухгалтерской единицей.
• Динамическая комиссия позволяет пулу выбрать отслеживание волатильности с надбавкой, которая растёт при быстром движении тика и затухает со временем, калибруемая по DynamicFeeConfig на уровень и по DynamicFeeInfo на пул. Новая конечная точка /main/clmm-dynamic-config выводит список уровней.
• Новая инструкция CreateCustomizablePool предоставляет все три регулятора при создании пула. Классическая инструкция CreatePool продолжает работать для пулов с комиссией по умолчанию и без лимитных ордеров.
• Критическое изменение индексатора: счётчики объёма по направлениям (swap_in_amount_token_{0,1}, swap_out_amount_token_{0,1}) и пожизненные счётчики комиссии (total_fees_token_{0,1}, total_fees_claimed_token_{0,1}) в PoolState были перемещены в заполнение (padding) для освобождения места под fee_on и dynamic_fee_info. Индексаторы, которые читают эти поля напрямую, должны перейти на кольцо Observation в цепи или на API.

​

Почему это важно (для трейдеров, LP-поставщиков и интеграторов)

• Трейдеры получают более точные котировки на долгохвостовых парах и парах, подверженных событиям: динамическая комиссия позволяет пулу поглотить надбавки волатильности от принимающей стороны без того, чтобы LP-поставщики активно расширяли диапазоны, а лестницы лимитных ордеров углубляют ликвидность в цепи по конкретным ценам без привязки капитала по всему диапазону.
• LP-поставщики получают третью стратегию наряду с концентрированными диапазонами и полнодиапазонными позициями: припарковать ордера по точной цене, заполнить их при посещении цены, урегулировать в токене котировки. Никакой активной переbalансировки не требуется для заполненной части.
• Интеграторы могут детерминистически моделировать пулы с динамической комиссией — алгоритм и параметры полностью находятся в цепи, уровни калибровки подлежат запросу, а путь своп-а остаётся неизменным по форме (только комиссия за каждый шаг варьируется).

​

Что изменилось в программе

​

Новые аккаунты

• DynamicFeeConfig — запись калибровки на уровень (период фильтра, период затухания, коэффициент снижения, управление динамической комиссией, максимальный накопитель волатильности). Создаётся с помощью CreateDynamicFeeConfig (администратор), ссылается на CreateCustomizablePool при включении динамической комиссии.
• LimitOrderState — аккаунт на ордер (PDA-семена: [owner, limit_order_nonce, order_nonce]), содержащий пул, тик, направление, входную сумму, коэффициент незаполненной части, фазу когорты FIFO и снимки учёта. Жизненный цикл неявный (filled_amount vs total_amount, плюс существование аккаунта): Open → Filled → Settled → Closed.
• LimitOrderNonce — монотонно возрастающий счётчик на пару (владелец, индекс_nonce), который получает PDA-семена лимитного ордера. nonce_index: u8 позволяет одному владельцу разделить ордера на до 256 независимых потоков nonce.

См. Accounts → DynamicFeeConfig and DynamicFeeInfo и Accounts → LimitOrderState.

​

Переструктуризация PoolState

Группа полей	Старая раскладка	Новая раскладка
Счётчики объёма по направлениям	swap_in_amount_token_0, swap_out_amount_token_0, swap_in_amount_token_1, swap_out_amount_token_1	Свёрнуты в padding5: [u128; 4]
Пожизненные счётчики комиссии	total_fees_token_0, total_fees_claimed_token_0, total_fees_token_1, total_fees_claimed_token_1	Свёрнуты в padding6: [u64; 4]
Односторонний сбор комиссии	—	fee_on: u8 (0 = FromInput, 1 = Token0Only, 2 = Token1Only)
Динамическая комиссия	—	dynamic_fee_info: DynamicFeeInfo (встроенная)

Общий размер аккаунта остаётся неизменным. Индексаторам: переместите отслеживание объёма с PoolState на кольцо Observation или на API. Снятые со счёта счётчики не обнуляются в существующих пулах (они содержат то, что они последний раз несли), поэтому повторное чтение их после обновления вернёт устаревшие данные.

​

Добавления TickState (без критических изменений)

Четыре новых поля добавляются в конец TickState, заменяя часть его заполнения:

• order_phase: u64 — счётчик, который разграничивает когорты лимитных ордеров на этом тике.
• orders_amount: u64 — общая входная сумма, привязанная ко всем открытым ордерам на этом тике (не все из которых полностью незаполнены).
• part_filled_orders_remaining: u64 — входная сумма, всё ещё незаполненная в когорте, которая в данный момент потребляется своп-ами.
• unfilled_ratio_x64: u128 — коэффициент Q64.64, используемый для вычисления доли заполнения каждого ордера.

Раскладка массива тиков, размер и PDA-семена остаются неизменными.

​

Новые инструкции

• CreateDynamicFeeConfig (администратор) — создание калибруемого уровня DynamicFeeConfig. Полномочия: тот же казначейский мультиподпис, что и CreateAmmConfig.
• UpdateDynamicFeeConfig (администратор) — обновление параметров существующего уровня.
• CreateCustomizablePool — точка входа создания пула, которая предоставляет collect_fee_on, enable_dynamic_fee и dynamic_fee_config. Сосуществует с CreatePool; мы рекомендуем CreateCustomizablePool для любого нового пула, которому нужны новые регуляторы.
• OpenLimitOrder — открыть однотиковый лимитный ордер. Увеличивает LimitOrderNonce, выделяет LimitOrderState, помещает ордер в когорту FIFO на тике.
• IncreaseLimitOrder / DecreaseLimitOrder — отрегулировать незаполненную часть ордера. Возвращает ошибку на полностью заполненном ордере с InvalidOrderPhase.
• SettleLimitOrder — переместить заполненный результат в ATA владельца. Вызывающей стороной может быть владелец или хранитель limit_order_admin пула.
• CloseLimitOrder — закрыть полностью урегулированный ордер для возврата арендной платы.

​

Изменения поведения SwapV2

Форма пути своп-а остаётся неизменной, но три вещи теперь происходят на ходу:

1. Динамическая комиссия (при включении): DynamicFeeInfo пула обновляется на каждом шаге (затухание → накопление → колпачок), и результирующая надбавка добавляется сверху базовой комиссии за этот шаг.
2. Сопоставление лимитных ордеров (когда шаг пересекает инициализированный тик с открытыми ордерами): часть входной суммы своп-а потребляется в порядке FIFO для заполнения когорты на этом тике, с атомарным обновлением unfilled_ratio_x64.
3. Маршрутизация односторонней комиссии (когда fee_on != 0): комиссия берётся из token_0 или token_1 независимо от направления своп-а вместо того, чтобы всегда браться с входной стороны.

Каждое из этих действий является холостой операцией, когда пул был создан с наследуемыми значениями по умолчанию. См. Instructions → SwapV2 для обновленной матрицы изменения состояния.

​

Новые коды ошибок

Перечисление ErrorCode было переномеровано в этом релизе: пять наследуемых вариантов (LOK, ZeroMintAmount, InvalidLiquidity, TransactionTooOld, InvalidRewardDesiredAmount) были удалены, и одиннадцать новых вариантов были добавлены. Поскольку Anchor нумерует ошибки по порядку перечисления начиная с 6000, каждый код ошибки на позициях удаления или после них был сдвинут — клиенты, которые жёстко кодировали числовые коды, должны переотобразить.

Новые коды:

• 6040 OrderAlreadyFilled
• 6041 InvalidOrderPhase
• 6042 InvalidLimitOrderAmount
• 6043 OrderPhaseSaturated
• 6044 InvalidDynamicFeeConfigParams
• 6045 InvalidFeeOn
• 6046 ZeroSqrtPrice
• 6047 ZeroLiquidity
• 6048 MissingBaseFlag
• 6049 MissingMintAccount
• 6050 MissingTokenProgram2022

Полные строки и таблица после сдвига для всех ошибок CLMM находятся в Error codes.

​

Что изменилось в SDK (@raydium-io/raydium-sdk-v2)

• Новые методы в raydium.clmm: createCustomizablePool, openLimitOrder, increaseLimitOrder, decreaseLimitOrder, settleLimitOrder, settleAllLimitOrder, closeLimitOrder, closeAllLimitOrder.
• Новые помощники REST в raydium.api: getClmmDynamicConfigs, getClmmLimitOrderConfigs.
• Новые типы: перечисление CollectFeeOn, DynamicFeeConfig, DynamicFeeInfo, LimitOrderState, LimitOrderConfig.
• Внутренняя реорганизация: utils/ перемещён в libraries/. Экспортная точка пакета остаётся неизменной; только глубокие импорты под @raydium-io/raydium-sdk-v2/utils/... требуют обновления на …/libraries/....

Полные пошаговые инструкции на TypeScript находятся в products/clmm/code-demos.

​

Что изменилось в API

• api-v3 — две новые конечные точки под /main/:
  • GET /main/clmm-dynamic-config — список уровней DynamicFeeConfig.
  • GET /main/clmm-limit-order-config — конфигурация лимитных ордеров на пул.
• temp-api-v1 — три новые конечные точки под /limit-order/:
  • GET /limit-order/order/list?wallet=… — парковочные ордера кошелька в данный момент (открытые и частично заполненные, обслуживаются из кэша Redis индексатора; один и тот же результат охватывает обе фазы через totalAmount / filledAmount / pendingSettle).
  • GET /limit-order/history/order/list-by-user?wallet=… — историческое история лимитных ордеров кошелька. Опциональные фильтры: poolId, mint1, mint2, hideCancel. Курсорная пагинация через nextPageId / size (макс 100).
  • GET /limit-order/history/event/list-by-pda?pda=… — логи событий на PDA (open / increase / decrease / settle / close) для одного или более разделённых запятыми PDA-адресов лимитных ордеров. Курсорная пагинация через nextPageId / size (макс 100).

Все пять документированы во вкладке API Reference.

​

Поверхность полномочий

limit_order_admin — это автоматизированный оперативный хранитель, не мультиподпис. Он может только вызывать SettleLimitOrder и CloseLimitOrder на существующие ордера, и результат урегулирования всегда попадает в ATA владельца. Он не может мутировать поля пула, открывать или изменять ордера или подписывать что-либо ещё. См. Admin keys and multisig → CLMM.

​

Обновленные страницы

• products/clmm/overview — новая секция “What’s new” и обновленные указатели следующих шагов.
• products/clmm/accounts — три новых аккаунта, переструктуризация PoolState с предупреждением о миграции, добавления TickState, новые помощники PDA.
• products/clmm/instructions — семь новых инструкций, дополнение поведения SwapV2, обновленная матрица изменения состояния.
• products/clmm/fees — секция односторонней комиссии, секция динамической комиссии с таблицей параметров.
• products/clmm/math — псевдокод сопоставления лимитных ордеров, выведение динамической комиссии.
• products/clmm/code-demos — демонстрация createCustomizablePool, полный пошаговый ордер лимитного, новые ловушки.
• algorithms/clmm-math — перекрёстная ссылка на сопоставление лимитных ордеров и динамическую комиссию в многотиковом цикле своп-а.
• sdk-api/typescript-sdk — секция добавлений модуля CLMM, примечание о миграции utils/ → libraries/.
• api-reference/openapi/api-v3.yaml — две новые конечные точки с схемами ответов.
• api-reference/openapi/temp-api-v1.yaml — три новые конечные точки лимитных ордеров (/limit-order/order/list, /limit-order/history/order/list-by-user, /limit-order/history/event/list-by-pda) с их схемами запроса и ответа.
• api-reference/api-v3/overview — примечание о новых конечных точках конфигурации CLMM.
• api-reference/temp-api-v1/overview — примечание о новых конечных точках активных ордеров, истории пользователя и событий по PDA.
• reference/error-codes — одиннадцать новых кодов ошибок CLMM (6040–6050) плюс пять удалённых наследуемых кодов; числовые коды после точек удаления были сдвинуты.
• security/admin-and-multisig — новая строка администратора DynamicFeeConfig и строка хранителя limit_order_admin с объяснением ограниченных полномочий.

Проверено по:

• исходному коду raydium-clmm.
• исходному коду @raydium-io/raydium-sdk-v2.
• исходному коду api-v3 и temp-api-v1.

​

2026-04-26 — Первичная публикация

Первый публичный релиз набора документации Raydium.

Проверено по:

• Живым развёртываниям программ на mainnet-beta Solana.
• @raydium-io/raydium-sdk-v2@0.2.42-alpha.
• Общедоступным документам Raydium и ссылкам в цепи до апреля 2026.

Далее, каждое обновление протокола, аудит или редакция документации выступает как новая запись в этом файле.

​

Соглашения по документированию

• Версионирование: эта документация использует версионирование на основе календаря (YYYY-MM-DD). Каждое обновление создаёт новую запись в верхней части файла.
• Дата проверки: каждая запись фиксирует, когда содержание последний раз было перекрёстно проверено с состоянием в цепи / API и исходным кодом программы. Если не указано, предположите основную дату записи.
• Критические изменения: вызваны в контейнере предупреждения на затронутых страницах и помечены в записи ниже.
• Охват: этот журнал изменений охватывает сам набор документации. Собственная историческая шкала времени протокола находится в introduction/history-and-milestones и является источником истины для “когда произошло X на Raydium”.

​

Исправления

Если вы найдёте ошибку в этой документации, пожалуйста, откройте Issue или Pull Request в репозитории документации. Исправления логируются в этом журнале изменений.

​

Ссылки

• introduction/history-and-milestones — собственная временная шкала протокола.
• security/audits — история аудитов.
• ray/protocol-fees — расделение комиссии протокола.
• reference/program-addresses — источник истины адреса программы.