Общая инфраструктура

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

Продукты Raydium — это независимые кодовые базы, но они разработаны на основе единого набора соглашений. Эта страница является эталонным справочником этих соглашений. Главы по продуктам описывают, как соглашения реализуются в их аккаунтах; на этой странице описаны сами соглашения.

Что здесь означает «общее»

Через кодовую базу пролегают три разновидности совместного использования:

Совместное использование соглашений. Каждая программа использует одну и ту же схему выведения PDA, одну и ту же форму разделения комиссий и одну и ту же идею аккаунта наблюдений — но каждая реализует их в своей программе с собственными зёрнами (seeds).
Совместное использование аккаунтов. Несколько аккаунтов — это буквально одна и та же запись для множества пулов (глобальный PDA-авторитет в CPMM, аккаунты AmmConfig).
Внецепевое совместное использование. Один REST API и один TypeScript SDK обслуживают все четыре программы. Интеграторы взаимодействуют с одним HTTP-хостом и одним NPM-пакетом, независимо от того, какую программу они в итоге вызывают.

Пять примитивов ниже охватывают всё, что пересекает границы программ.

1. PDA-авторитеты

Каждая программа Raydium имеет ровно один PDA, который владеет её хранилищами токенов. Пользователи никогда не держат авторитет хранилища напрямую — PDA-авторитет является единственным подписывающим, который может вывести средства, и он подписывает только когда валидная программная инструкция это предписывает. Схема идентична для всех продуктов; зёрна (seeds) различаются:

Программа	Зёрна PDA-авторитета	Примечания
AMM v4	`[poolId]`	Авторитет для каждого пула. Аналогична форме per-pool дизайна v4.
CPMM	`[b"vault_and_lp_mint_auth_seed"]`	Единственный PDA, общий для всех CPMM пулов. Без pool-specific зёрна.
CLMM	`[b"pool_vault_and_lp_mint_auth_seed"]`	Единственный PDA, общий для всех CLMM пулов.
Farm v3 / v5 / v6	`[farmId]`	Per-farm. PDA владеет стейкингом и хранилищами наград этой фермы.
LaunchLab	`[b"vault_auth", launchId]`	Per-launch. Владеет базовым и котируемым хранилищами до выпуска.

Из этого следует несколько выводов:

Для CPMM и CLMM PDA-авторитет — это глобальный аккаунт — каждый пул этого типа его использует. Если вы выполняете CPI в CPMM, он вам нужен один раз, а не на каждый пул.
Для per-pool / per-farm авторитетов вы выводите PDA из ID пула/фермы. SDK делает это в getPoolKeys / getFarmKeys; если вы интегрируетесь напрямую, выводите с помощью findProgramAddressSync.
Владельца хранилища изменить невозможно. После того как аккаунт токена создан с PDA-авторитетом в качестве владельца, только этот PDA — вызванный программой — может переводить средства. Нет никакого переопределения администратором.

Точные зёрна и макеты ATA для каждой программы см. в products/cpmm/accounts, products/clmm/accounts, products/amm-v4/accounts, products/farm-staking/accounts, products/launchlab/accounts.

2. Аккаунты администратора и конфигурации

CPMM и CLMM используют паттерн аккаунта конфигурации под названием AmmConfig: небольшой глобальный аккаунт, индексируемый по u16, содержащий ставки комиссий и адреса администратора, которые применяются к целому ярусу комиссий. Пулы привязываются к конфигурации при создании и никогда не переусловливаются.

// CPMM AmmConfig (сокращённо — версия CLMM структурно аналогична)
pub struct AmmConfig {
    pub bump: u8,
    pub disable_create_pool: bool,        // закрыть создание новых пулов в этом ярусе
    pub index: u16,                       // индекс яруса
    pub trade_fee_rate: u64,              // доля торговли идущая в комиссии
    pub protocol_fee_rate: u64,           // доля комиссии торговли идущая в протокол
    pub fund_fee_rate: u64,               // доля комиссии торговли идущая в фонд
    pub create_pool_fee: u64,             // одноразовая комиссия создания за пул
    pub protocol_owner: Pubkey,           // подписывающий для CollectProtocolFee
    pub fund_owner: Pubkey,               // подписывающий для CollectFundFee
    pub padding: [u64; 16],
}

Правила игры:

Ярусы комиссий глобальны. Когда пул говорит «это пул с комиссией 0.25%», это означает, что он привязан к AmmConfig, чья trade_fee_rate составляла 0.25% на момент создания. Нет переопределения per-pool ставки.
Конфигурацию можно изменить, но пулы это не отслеживают. Если администратор конфигурации редактирует AmmConfig, каждый существующий пул, привязанный к этой конфигурации, сразу же получает новую ставку. Это особенность, а не баг; так распространяются экономические изменения на уровне протокола без миграций per-pool.
disable_create_pool — рычаг устаревания. Когда ярус комиссий закрывается, мультиподпись протокола устанавливает этот флаг — существующие пулы продолжают работать, но никакие новые пулы не могут выбрать этот ярус.
protocol_owner / fund_owner — это подписывающие для вызовов сбора комиссий. Установка их в мультиподпись — это то, что закрывает вывод комиссий. Они НЕ являются адресами-назначениями для самих комиссий; это protocol_fee_destination / fund_fee_destination на том же аккаунте.

AMM v4 не имеет AmmConfig — его параметры комиссий per-pool, жёстко закодированы при создании. Farm и LaunchLab имеют свои эквиваленты (FarmConfig, LaunchConfig), описанные в своих соответствующих главах. Полная таблица того, кто что может менять, находится в security/admin-and-multisig. Текущие пользовательские разделения комиссий в ray/protocol-fees.

3. Разделение комиссий между протоколом / фондом / создателем

Каждая CPMM и CLMM комиссия от торговли разделяется на пути до четырёх адресов-назначений:

                         общая комиссия торговли
                              │
              ┌───────────────┼───────────────┬──────────────┐
              ▼               ▼               ▼              ▼
        LP пул сторона    Казначейство    Мультиподпись  Создатель
        (увеличивает k)   протокола       фонда          (пулы LaunchLab)

Механически:

Комиссия торговли накапливается в пуле. Комиссия вычитается из входящей стороны своппа и пост-комиссионный размер это то, что видит математика constant-product. Вот что означает «LP зарабатывает комиссию» — k растёт и вместе с ним растёт подразумеваемая стоимость за LP-токен.
Доля протокола/фонда/создателя вычитается из этого накопления на стороне LP в per-pool аккаунты счётчиков. Они остаются в состоянии пула (protocol_fees_token{0,1}, fund_fees_token{0,1} и т. д.) пока кто-нибудь не вызовет CollectProtocolFee / CollectFundFee / CollectCreatorFee. Они не покидают хранилища пула до этого; с точки зрения своппа они всё ещё «в пуле».
Сбор выводит их. Соответствующий подписывающий (ключи protocol_owner / fund_owner на AmmConfig, или создатель выпуска для пулов LaunchLab) вызывает инструкцию сбора и программа переводит из хранилища пула в адрес-назначение ATA.

Несколько нагруженных наблюдений:

Процентные доли разделения — от торговой комиссии, а не от торговли. Торговая комиссия 0.25% с долей протокола 12% означает, что протокол получает 0.25% × 12% = 0.03% торговли — а не 12% торговли.
Комиссии создателя существуют только в пулах, выпущенных на LaunchLab. Стандартные пулы CPMM/CLMM имеют трёхстороннее разделение (LP / протокол / фонд). LaunchLab добавляет четвёртый слот, маршрутизируемый тому, кто выпустил токен, настраивается при Initialize и неизменяемо.
AMM v4 разделяет только двумя способами, жёстко закодировано per-pool: LP и протокол. Нет слота фонда, нет слота создателя.
Фонд против протокола — оба являются адресами-назначениями казначейства протокола, но у них разные подписывающие и разные предполагаемые использования. protocol исторически финансирует операции; fund — это долгосрочное казначейство. Разделение между ними само по себе регулируемо.

Конкретные ставки находятся в reference/fee-comparison и ray/protocol-fees.

4. Аккаунты наблюдений (кольцевой буфер TWAP)

Как CPMM, так и CLMM ведут аккаунт наблюдений на пул — кольцевой буфер фиксированного размера образцов (timestamp, cumulative_price), который другие контракты могут использовать для вывода устойчивого к манипуляциям TWAP.

// CPMM ObservationState (сокращённо)
pub struct ObservationState {
    pub initialized: bool,
    pub observation_index: u16,            // следующий слот для перезаписи
    pub pool_id: Pubkey,
    pub observations: [Observation; OBSERVATION_NUM],
    pub padding: [u64; 4],
}

pub struct Observation {
    pub block_timestamp: u64,
    pub cumulative_token_0_price_x32: u128,  // сумма (цена × dt) с инициализации
    pub cumulative_token_1_price_x32: u128,
}

Как это работает:

Каждый своп вызывает update_observation. Программа читает текущую цену, умножает на истёкшие секунды с момента предыдущего наблюдения и добавляет в кумулятивный счётчик. Новая запись перезаписывает самый старый слот (в стиле кольцевого буфера).
TWAP за период = (cumul[end] − cumul[start]) / (timestamp[end] − timestamp[start]). Потребители выбирают два наблюдения, охватывающие желаемый период и делят.
Raydium сам не использует TWAP для ценообразования. Математика AMM читает spot-резервы напрямую. Наблюдения — это внешний эффект — Raydium платит стоимость их записи, чтобы другие контракты могли читать.
AMM v4 не имеет аккаунта наблюдений. Он старше, чем дизайн ObservationState; интеграторы, желающие v4 TWAP, должны вычислять его off-chain из истории логов.

Детали макета и математика индексирования находятся в products/cpmm/accounts и products/clmm/accounts.

5. REST API + SDK + IDL

Внецепевая поверхность — это единственный триумвират, используемый каждым продуктом:

REST API — https://api-v3.raydium.io. Индексированное в основном для чтения представление всего состояния on-chain плюс engine для котировок. Один хост, одна схема.
TypeScript SDK — @raydium-io/raydium-sdk-v2 на NPM. Создаёт и подписывает транзакции для каждой программы. Обращается к API для котировок/метаданных, обращается к Solana RPC для обновления состояния перед подписанием.
Реестр IDL — Anchor IDL для каждой опубликованной программы находятся в репозитории raydium-idl (один JSON на программу: CPMM, CLMM, LaunchLab). TypeScript SDK потребляет эти IDL’ы внутренне; downstream Rust / Python клиенты регенерируют из этих же файлов.

Граница между ними резкая:

Компонента	Читает из	Записывает в	Допуск устаревания
REST API	Индексер (парсит логи цепи)	— (read-only для интеграторов)	Несколько секунд
SDK	API + RPC	Создаёт транзакции; не трансляционирует	Ничего — должен переполучить состояние перед подписанием
IDL	Исходный код программы	—	Версионирован на обновление программы

Частая ошибка — подавать output REST API прямо в транзакцию. Не делайте этого — переполучите соответствующее состояние пула/позиции от Solana RPC в слоте, в котором вы подписываете. SDK делает это автоматически для первосторонних потоков; если вы обходите SDK, вы должны делать это сами. Полный справочник находится в sdk-api/, с поверхностью IDL специально в sdk-api/anchor-idl.

6. Индексеры и ценовые ленты

REST API питается индексером Raydium, который подписывается на логи программ из флота Solana RPC и пишет денормализованные записи в SQL-хранилище. Два следствия для интеграторов:

Индексер — это единственное, что «знает» о кросс-программном состоянии. Сопоставление пула CPMM с его CLMM-аналогом, вычисление объёма за 24ч по версиям программ, поиск фермы, связанной с LP-минтом — всё это работа индексера. Программы сами этого не делают.
Простой индексера — это простой API. Если API возвращает устаревшие или пустые данные, подозревайте индексер. On-chain состояние не затрагивается; интеграторы со своим собственным RPC и SDK могут продолжать заключать транзакции.

Ценовые ленты — это отдельная задача. API публикует поле priceUsd на большинстве ответов пула; это вычисляется off-chain из снимка представления пула индексером резервов и цены-ориентира (пулы USDC как обычный стержень). Этого достаточно для UI; это не безопасно использовать как on-chain оракл. Используйте observation TWAP для этого.

Что не разделяется

Стоит перечислить явно, потому что новые читатели часто предполагают больше совместного использования, чем существует на самом деле:

Программы не вызывают друг друга. Своп CPMM никогда не выполняет CPI в CLMM или AMM v4. Единственная программа, которая составляет несколько AMM’ов — это программа AMM Routing — и она сама тонкая, просто выполняя CPI в каждый AMM последовательно.
Нет общего авторитета обновления для программ. Каждая on-chain программа имеет свой ключ обновления программы (мультиподпись 3/4 плюс 24-часовая блокировка). Они не связаны.
Нет общего состояния между фермами и AMM’ами. Ферма не знает, является ли LP, который она ставит, из пула CPMM, NFT-минта позиции CLMM или несвязанного SPL-токена. Программа фермы рассматривает минт стейкинга как непрозрачный.
Нет зависимости оракла. Ценообразование основано на резервах on-chain. Нет fallback’а Pyth/Switchboard; AMM не проверяет оракл перед клирингом.

Ссылки

protocol-overview/architecture — канонический диаграмма, показывающая как эти компоненты составляются.
protocol-overview/versions-and-migration — как соглашения развивались по версиям программ.
security/admin-and-multisig — кто контролирует ключи за AmmConfigs.
reference/fee-comparison — матрица ставок комиссий на продукт.
reference/program-addresses — канонические ID программ.

Источники:

Raydium SDK v2 — единственный источник истины для зёрен PDA, макетов аккаунтов и определений IDL.
Реестр Raydium IDL — Anchor IDL’ы.
Страницы аккаунтов по продуктам упоминаются inline выше.

Добро пожаловать

Обзор протокола

Общая инфраструктура

Что здесь означает «общее»

1. PDA-авторитеты

2. Аккаунты администратора и конфигурации

3. Разделение комиссий между протоколом / фондом / создателем

4. Аккаунты наблюдений (кольцевой буфер TWAP)

5. REST API + SDK + IDL

6. Индексеры и ценовые ленты

Что не разделяется

Ссылки

Добро пожаловать

Обзор протокола

Documentation Index

​Что здесь означает «общее»

​1. PDA-авторитеты

​2. Аккаунты администратора и конфигурации

​3. Разделение комиссий между протоколом / фондом / создателем

​4. Аккаунты наблюдений (кольцевой буфер TWAP)

​5. REST API + SDK + IDL

​6. Индексеры и ценовые ленты

​Что не разделяется

​Ссылки

Что здесь означает «общее»

1. PDA-авторитеты

2. Аккаунты администратора и конфигурации

3. Разделение комиссий между протоколом / фондом / создателем

4. Аккаунты наблюдений (кольцевой буфер TWAP)

5. REST API + SDK + IDL

6. Индексеры и ценовые ленты

Что не разделяется

Ссылки