> ## 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.

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

> Примитивы, которые используют все программы Raydium — PDA-авторитеты, аккаунты AmmConfig, разделение комиссий между протоколом/фондом/создателем, аккаунты наблюдений и публичный REST API — определены один раз, чтобы главы по продуктам могли на них ссылаться.

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

  [Открыть английскую версию →](/protocol-overview/shared-infrastructure)
</Info>

Продукты 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`](/ru/products/cpmm/accounts), [`products/clmm/accounts`](/ru/products/clmm/accounts), [`products/amm-v4/accounts`](/ru/products/amm-v4/accounts), [`products/farm-staking/accounts`](/ru/products/farm-staking/accounts), [`products/launchlab/accounts`](/ru/products/launchlab/accounts).

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

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

```rust theme={null}
// 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`](/ru/security/admin-and-multisig). Текущие пользовательские разделения комиссий в [`ray/protocol-fees`](/ru/ray/protocol-fees).

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

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

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

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

1. **Комиссия торговли накапливается в пуле.** Комиссия вычитается из входящей стороны своппа и *пост-комиссионный* размер это то, что видит математика constant-product. Вот что означает «LP зарабатывает комиссию» — `k` растёт и вместе с ним растёт подразумеваемая стоимость за LP-токен.
2. **Доля протокола/фонда/создателя вычитается из этого накопления на стороне LP в per-pool аккаунты счётчиков.** Они остаются в состоянии пула (`protocol_fees_token{0,1}`, `fund_fees_token{0,1}` и т. д.) пока кто-нибудь не вызовет `CollectProtocolFee` / `CollectFundFee` / `CollectCreatorFee`. Они не покидают хранилища пула до этого; с точки зрения своппа они всё ещё «в пуле».
3. **Сбор выводит их.** Соответствующий подписывающий (ключи `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`](/ru/reference/fee-comparison) и [`ray/protocol-fees`](/ru/ray/protocol-fees).

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

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

```rust theme={null}
// 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`](/ru/products/cpmm/accounts) и [`products/clmm/accounts`](/ru/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`](https://github.com/raydium-io/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/`](/ru/sdk-api), с поверхностью IDL специально в [`sdk-api/anchor-idl`](/ru/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`](/ru/protocol-overview/architecture) — канонический диаграмма, показывающая как эти компоненты составляются.
* [`protocol-overview/versions-and-migration`](/ru/protocol-overview/versions-and-migration) — как соглашения развивались по версиям программ.
* [`security/admin-and-multisig`](/ru/security/admin-and-multisig) — кто контролирует ключи за AmmConfigs.
* [`reference/fee-comparison`](/ru/reference/fee-comparison) — матрица ставок комиссий на продукт.
* [`reference/program-addresses`](/ru/reference/program-addresses) — канонические ID программ.

Источники:

* [Raydium SDK v2](https://github.com/raydium-io/raydium-sdk-V2) — единственный источник истины для зёрен PDA, макетов аккаунтов и определений IDL.
* [Реестр Raydium IDL](https://github.com/raydium-io/raydium-idl) — Anchor IDL'ы.
* Страницы аккаунтов по продуктам упоминаются inline выше.