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

​

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

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

​

1. PDA органов управления

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

​

2. Учетные записи администратора и конфигурации

// CPMM AmmConfig (сокращенно — версия CLMM структурно похожа)
pub struct AmmConfig {
    pub bump: u8,
    pub disable_create_pool: bool,        // gate new pool creation in this tier
    pub index: u16,                       // tier index
    pub trade_fee_rate: u64,              // fraction of trade going to fees
    pub protocol_fee_rate: u64,           // fraction of trade fee to protocol
    pub fund_fee_rate: u64,               // fraction of trade fee to fund
    pub create_pool_fee: u64,             // one-time per-pool creation fee
    pub protocol_owner: Pubkey,           // signer for CollectProtocolFee
    pub fund_owner: Pubkey,               // signer for CollectFundFee
    pub padding: [u64; 16],
}

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

​

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

                         total swap fee
                              │
              ┌───────────────┼───────────────┬──────────────┐
              ▼               ▼               ▼              ▼
        LP pool side     Protocol         Fund         Creator
        (raises k)       treasury         multisig     (LaunchLab pools)

1. Комиссия за торговлю накапливается в пуле. Комиссия удаляется из входной стороны обмена, и сумма после комиссии — это то, что видит математика постоянного произведения. Это то, что означает «LP получает комиссию» — k растет и растет подразумеваемая стоимость на токен LP.
2. Доли протокола/фонда/создателя вычитаются из этого накопления на стороне LP в учетные записи счетчиков для каждого пула. Они находятся в состоянии пула (protocol_fees_token{0,1}, fund_fees_token{0,1} и т. д.) до тех пор, пока кто-нибудь не вызовет соответствующую инструкцию сбора. Они не покидают хранилища пула до этого момента; с точки зрения обмена они все еще «в пуле».
3. Сбор перемещает их. Пути протокола и фонда требуют соответствующего подписанта protocol_owner / fund_owner из AmmConfig. Комиссии создателя CPMM используют либо путь CollectCreatorFee, подписанный создателем, либо CollectCreatorFeePermissionless, который может запустить любой плательщик, но который фиксирует направления на канонические ATA создателя.

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

​

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

// CPMM ObservationState (сокращенно)
pub struct ObservationState {
    pub initialized: bool,
    pub observation_index: u16,            // next slot to overwrite
    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,  // sum of (price × dt) since init
    pub cumulative_token_1_price_x32: u128,
}

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

​

5. REST API + SDK + IDL

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

​

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

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

​

Что не является общим

• Программы не вызывают друг друга. Обмен CPMM никогда не выполняет CPI в CLMM или AMM v4. Единственная программа, которая компонует несколько AMM, — это программа маршрутизации AMM — и она сама тонкая, просто выполняя CPI в каждый AMM по очереди.
• Нет общего органа управления обновлениями между программами. Каждая программа в цепи имеет свой собственный ключ обновления программы (мультиподпись 3/4 плюс блокировка на 24 часа). Они не связаны.
• Нет общего состояния между фермами и AMM. Ферма не знает, из какого пула CPMM, NFT позиции CLMM или несвязанного токена SPL происходит LP, который она ставит. Программа фермы рассматривает минт ставок как непрозрачный.
• Нет зависимости от оракула. Ценообразование — это резервы в цепи. Нет резервного варианта 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 — источник истины для seeds PDA, макетов учетных записей и определений IDL.
• Реестр Raydium IDL — Anchor IDL.
• Страницы учетных записей для каждого продукта, цитируемые выше.