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

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.

​

Не выпущено — CLMM: лимитные ордера, односторонняя комиссия, динамическая комиссия

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

​

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

• Лимитные ордера теперь являются полноценными примитивами CLMM. LP могут открыть ордер на одном тике в пуле, который их поддерживает; ордер исполняется по принципу FIFO, когда своп пересекает тик, а офчейн-кипер (limit_order_admin) может расчитать исполненный вывод без присутствия владельца онлайн. Семь новых методов SDK (openLimitOrder, increaseLimitOrder, decreaseLimitOrder, settleLimitOrder, closeLimitOrder, closeAllLimitOrder, settleAllLimitOrder) и три новых эндпоинта Temp API под /limit-order/ (активные ордера, история по пользователю, лог событий по PDA) покрывают полный флоу.
• Односторонняя комиссия (CollectFeeOn) позволяет пулу взимать комиссию за своп со стороны входа (legacy, режим 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 убраны в паддинг, чтобы освободить место для fee_on и dynamic_fee_info. Индексаторы, читающие эти поля напрямую, должны перейти на on-chain кольцо Observation или API.

​

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

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

​

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

​

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

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

См. Аккаунты → DynamicFeeConfig и DynamicFeeInfo и Аккаунты → LimitOrderState.

​

Изменение структуры PoolState

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

​

Дополнения в TickState (без ломающих изменений)

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

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

Структура массива тиков, его размер и PDA seeds не изменились.

​

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

• 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 независимо от направления свопа, а не всегда со входной стороны.

Каждый из этих механизмов является no-op, если пул был создан со стандартными (legacy) параметрами. Обновлённую матрицу изменений состояний см. в Инструкции → SwapV2.

​

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

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

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

Полные строки ошибок и таблица смещений для всех ошибок CLMM приведены в разделе Коды ошибок.

​

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

• Новые методы в raydium.clmm: createCustomizablePool, openLimitOrder, increaseLimitOrder, decreaseLimitOrder, settleLimitOrder, settleAllLimitOrder, closeLimitOrder, closeAllLimitOrder.
• Новые REST-хелперы в raydium.api: getClmmDynamicConfigs, getClmmLimitOrderConfigs.
• Новые типы: enum CollectFeeOn, DynamicFeeConfig, DynamicFeeInfo, LimitOrderState, LimitOrderConfig.
• Внутренняя реорганизация: utils/ перемещён в libraries/. Публичный barrel-экспорт пакета не изменился; обновить нужно только глубокие импорты вида @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-кэша индексатора; один и тот же payload охватывает обе фазы через 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=… — лог событий (open / increase / decrease / settle / close) для одного или нескольких лимитных ордеров PDA через запятую. Курсорная пагинация через nextPageId / size (максимум 100).

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

​

Полномочия

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

​

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

• products/clmm/overview — новый раздел «Что нового» и обновлённые ссылки на следующие шаги.
• 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. Сверено с:

• развёрнутыми программами на Solana mainnet-beta;
• @raydium-io/raydium-sdk-v2@0.2.42-alpha;
• публичной документацией Raydium и on-chain источниками по апрель 2026 года включительно.

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

​

Соглашения о документации

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

​

Исправления

Если вы обнаружили ошибку в документации, пожалуйста, откройте issue или pull request в репозитории документации. Исправления фиксируются в данном журнале изменений.

​

Ссылки

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