Перейти к основному содержанию

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 проходят несколько раундов аудитов; на этой странице они перечислены с обсуждением того, что каждый аудит на самом деле проверил.

​
Таблица аудитов по программам

ПрограммаАудиторДатаОтчёт
Order-book AMMKudelski SecurityQ2 2021Просмотр
Concentrated liquidity (CLMM)OtterSecQ3 2022Просмотр
Обновлённый order-book AMMOtterSecQ3 2022Просмотр
StakingOtterSecQ3 2022Просмотр
Order-book AMM и миграция OpenBookMadShieldQ2 2023Просмотр
Constant-product AMM (CPMM)MadShieldQ1 2024Просмотр
Burn & Earn (блокировка ликвидности)HalbornQ4 2024Просмотр
LaunchLabHalbornQ2 2025Просмотр
CPMM (обновление)Sec3Q3 2025Просмотр
CLMM обновление — Limit Order, Dynamic Fee, Single Asset FeeSec3Q2 2026Просмотр
Члены команды Neodyme также проводили обширные проверки в рамках соглашений программы поиска ошибок. Все отчёты об аудитах программ Raydium зеркалируются в github.com/raydium-io/raydium-docs/audit/. Каждый аудитор также публикует результаты на собственном сайте.

​
Что проверяют аудиты

Типичный аудит Raydium (3–6 недель, 2 аудитора) охватывает:
  • Контроль доступа — правильно ли закрыты все привилегированные операции?
  • Арифметика — переполнения, подтечки, направление округления, точность с фиксированной точкой.
  • Валидация счётов — имеет ли каждый счёт правильного владельца, монету, полномочия?
  • Reentrancy-подобные паттерны — обновляется ли состояние до или после CPI?
  • Вычисление PDA — согласованны ли семена во всех местах использования?
  • Коды ошибок и сообщения — корректно ли происходит откат при ошибках?
  • Качество кода — идиоматичный Rust, мёртвый код, недостижимые ветви.

​
Что аудиты не проверяют

  • Экономическую теорию игр — например, «если я смогу создать 1000 пулов бесплатно, смогу ли я заблокировать маршрутизатор?»
  • MEV / упорядочение — атаки sandwich, front-running через сговор валидатора.
  • Инфраструктуру off-chain — надёжность RPC, корректность индексера, фронтенд.
  • Интеграцию с другими программами — ошибки, которые проявляются только при композиции с конкретными контрактами кредитования, опционов или агрегаторов.
  • Возникающее поведение со временем — что происходит после 10 миллионов позиций? Аудиты проверяют небольшие тестовые сценарии.
Вот почему аудит ≠ гарантия безопасности. Raydium дополняет аудиты программами поиска ошибок, мониторингом и защитным инженерингом.

​
Статус разрешения проблем

Каждый аудит выявляет список проблем (критические / высокие / средние / низкие / информационные) с подсчётом серьёзности и статусом каждой проблемы (Исправлено / Принято / Не будет исправляться). Детализированные разбиение по проблемам здесь не дублируется — прочитайте каждый отчёт непосредственно через таблицу выше.

​
Повторный аудит после значительных изменений

Когда программа развёртывает значительное обновление (новая инструкция, новое поле счёта, поддержка нового расширения), Raydium заказывает повторный аудит. Проверка Sec3 Q3 2025 CPMM и проверка Sec3 Q2 2026 CLMM (Limit Order, Dynamic Fee, Single Asset Fee), перечисленные в таблице выше, — оба повторных аудита этого типа. Область повторного аудита уже (только diff), но это действительно повторный аудит — не просто проверка кода. Отчёты повторных аудитов добавляются к основному отчёту об аудите.

​
Верификация в сети

Хеш развёрнутой программы должен совпадать с хешем проверенного кода. Любой может проверить: 
# Получить развёрнутый байткод программы.
solana program dump <PROGRAM_ID> program.so

# Собрать репозиторий на проверенном коммите.
git clone https://github.com/raydium-io/raydium-cp-swap
cd raydium-cp-swap
git checkout <audited_commit_hash>
anchor build --verifiable

# Сравнить.
sha256sum program.so target/deploy/raydium_cp_swap.so
Anchor verifiable builds производят детерминированный байткод; хеши должны совпадать точно. Если нет, развёрнутая программа — не та, которая была проверена — сообщите об этом. Raydium публикует ожидаемые хеши для каждого развёртывания в разделе releases репозитория.

​
Как читать отчёт об аудите

Краткое руководство для не-аудиторов:
  1. Перейдите к итоговой таблице проблем — таблица подсчётов по серьёзности. Если счётчик «Critical» > 0 и вы видите статус «Open», копайте глубже.
  2. Прочитайте описание и статус каждой проблемы. «Исправлено в коммите XYZ» означает разрешено; «Принято» означает, что команда приняла риск; «Частично исправлено» стоит рассмотреть подробнее.
  3. Сканируйте раздел области покрытия. Если аудит не охватывал инструкцию или счёт, который вас интересует, отсутствие проблем там — не доказательство безопасности.
  4. Пролистайте раздел рекомендаций аудитора. Часто полезнее, чем проблемы — выявляет примечания вроде «мы не можем формально доказать, но нас это тревожит».

​
Интеграция с программой поиска ошибок

Аудиты выполняются перед развёртыванием; программы поиска ошибок работают непрерывно после развёртывания. Программа поиска ошибок Raydium (security/disclosure) охватывает всё, что проверяют аудиты, плюс:
  • Экономические атаки, которые не проверяют аудиты.
  • Ошибки, найденные в новых интеграциях.
  • Ошибки реализации в SDK и off-chain компонентах.
Находка whitehate в программе поиска ошибок обычно получает вознаграждение быстрее, чем ожидание следующего цикла аудита; стимулы выравнены на быстрое раскрытие. Активная программа размещена на Immunefi: immunefi.com/bug-bounty/raydium/information.

​
Исторические инциденты

Программы Raydium имели два заметных инцидента в реальном мире:

​
Exploit полномочий пула (декабрь 2022 г.)

Что произошло: приватный ключ полномочий пула AMM v4 был скомпрометирован, что позволило злоумышленнику осушить несколько пулов. Область: управление операционными ключами, а не ошибка программы. Аудит не отметил код, так как код был корректным; процесс управления ключами был причиной сбоя. Исправление: миграция на многоподпись (все роли полномочий перемещены на Squads multisig); дополнительные операционные средства контроля. Урок: аудиты не охватывают управление ключами. См. security/admin-and-multisig.

​
Заморозка интеграции OpenBook (январь 2023 г.)

Что произошло: обновление программы OpenBook изменило семантику счётов; MonitorStep crank AMM v4 не смог рассчитать PnL до выпуска патча AMM v4. Область: ошибка интеграции — ни одна программа не была неправильной в изоляции. Исправление: патч AMM v4 и скоординированное развёртывание. Урок: аудиты программы A не выявляют ошибки в интеграции программы A с программой B. Правильный инструмент — интеграционное тестирование + поэтапные развёртывания.

​
Ссылки

Источники: