Кожна взаємодія з DeFi-протоколом на Solana — це виклик програмного коду (смарт-контракту), який керує вашими токенами. Навіть якщо ви не втрачаєте seed-фразу, помилка в логіці контракту може призвести до втрати коштів. Нижче розібрано, які саме вразливості трапляються на Solana, як їх мінімізувати та що робити, якщо протокол уже зламано.
Типи вразливостей смарт-контрактів
Solana використовує архітектуру, яка принципово відрізняється від EVM-мереж: тут немає «контрактів» у традиційному розумінні, натомість працюють програми, написані на Rust або C, а стан зберігається в окремих акаунтах. Це створює специфічний клас вразливостей.
Маніпуляції з акаунтами та PDA
Program Derived Address (PDA) — це детерміновані адреси, які контролюються програмою, а не приватним ключем. Якщо розробник неправильно перевіряє, чи є переданий акаунт справді PDA від очікуваної програми, атакувальник може підставити власний акаунт і обдурити логіку протоколу. Це одна з найпоширеніших помилок у протоколах на Anchor.
Помилки в Cross-Program Invocation (CPI)
CPI — це механізм, за якого одна програма на Solana викликає іншу (наприклад, lending-протокол звертається до токен-програми для переказу). Вразливості виникають, коли програма не перевіряє, яку саме програму вона викликає, або передає неправильні інструкції. Атакувальник може змусити контракт викликати шкідливу програму замість легітимної.
Реініціалізація акаунтів
На Solana акаунт можна закрити (звільнити місце) і знову створити з тим самим адресом. Якщо програма не перевіряє, чи акаунт уже ініціалізовано, атакувальник може повторно ініціалізувати його з новими параметрами — наприклад, змінити власника пулу ліквідності або адміністративні налаштування.
Логічні помилки в лендінгу та ліквідаціях
Неправильний розрахунок коефіцієнта забезпечення, відсутність перевірки ціни оракула або можливість маніпулювати ціною колатералу безпосередньо перед ліквідацією — усе це класичні вразливості lending-протоколів, які не залежать від блокчейна, але реалізуються через специфічні для Solana механізми оракулів та акаунтів.
Проблеми з правами оновлення (upgrade authority)
Програми на Solana за замовчуванням є оновлюваними. Якщо upgrade authority зберігається на одному EOA-гаманці без multisig, компрометація цього гаманця дозволяє замінити програму на шкідливу — навіть без виявлення вразливостей у початковому коді.
Маніпуляції з оракулами
Протоколи, що покладаються на ціни з низьколіквідних пулів або з єдиного джерела, вразливі до сплеш-атак. Атакувальник створює велику позицію в пулі, різко зсуває ціну і використовує спотворене значення в протоколі кредитування чи торгівлі.
Історичні приклади експлойтів на Solana
Нижче наведено загальновідомі інциденти без вказання точних сум — ці дані швидко застарівають і їх варто перевіряти за офіційними звітами протоколів та аудиторських компаній.
- Cashio Dollar. Стейблкоїн, забезпечений LP-токенами Saber. Атакувальник скористався відсутністю перевірки, чи депонований collateral-токен справді є легітимним LP-токеном, і створив підроблений токен з тією самою програмою-майнтером. Це дозволило безконтрольно генерувати CASH без реального забезпечення.
- Mango Markets. Експлойт використав маніпулювання ціною оракула через величезні позиції в низьколіквідному періоді. Протокол кредитування прийняв спотворену ціну як достовірну, що дозволило отримати безпідставні позики.
- Crema Finance. Вразливість у логіці обробки тіків (tick) у концентрованій ліквідності дозволила атакувальнику маніпулювати розрахунками і вивести кошти з пулів.
- Senzu / інші протоколи з оракульними вразливостями. Кілька менших протоколів постраждали через використання цін із власних AMM-пулів як оракулів без додаткових перевірок на маніпуляцію.
Зверніть увагу: цей перелік не є вичерпним. Актуальну статистику інцидентів варто перевіряти в звітах аудиторських фірм (OtterSec, Sec3, Neodyme) та трекерів експлойтів.
Як перевірити безпеку контракту перед використанням
Повна перевірка коду доступна лише розробникам, але користувач може оцінити ризик за кількома критеріями.
Наявність аудиту
Перевірте, чи є у протоколу опублікований звіт від хоча б однієї визнаної аудиторської компанії, що спеціалізується на Solana. Відсутність аудиту — критичний сигнал для протоколів, де ви блокуєте значні суми.
Статус upgrade authority
На Solscan або подібних експлорерах знайдіть адресу програми та перевірте, хто володіє upgrade authority. Ідеальний варіант — multisig-гаманець (Squads, Squad) з кількома підписантами або повністю відкликана authority (immutable program). Єдиний EOA-гаманець як authority — це червоний прапорець.
Відкритий вихідний код
Наявність GitHub-репозиторію з кодом, що відповідає розгорнутій програмі, дозволяє незалежним дослідникам перевіряти логіку. Закритий код не гарантує наявність вразливостей, але унеможливлює незалежну перевірку.
Час роботи та TVL
Протокол, що працює кілька місяців із значним TVL і без інцидентів, зазвичай надійніший за щойно запущений. Проте це не є гарантією — вразливість може існувати в коді з першого дня і бути виявленою через рік.
Програма баунті
Наявність bug bounty-програми (на Immunefi або власній платформі) свідчить про те, що розробники зацікавлені у виявленні вразливостей до того, як їх знайдуть атакувальники.
Що саме перевірити перед депозитом
- Адреса програми на експлорері — чи збігається з офіційно заявленою.
- Upgrade authority — хто контролює оновлення програми.
- Наявність хоча б одного аудиту від Solana-специфічної фірми.
- Чи не використовує протокол ціни з власних пулів як єдине джерело оракула.
- Чи є у протоколу офіційні комунікаційні канали для екстрених повідомлень.
Що робити після хаку протоколу
Якщо ви дізналися, що протокол, де у вас є позиція, зламано, дійте послідовно.
Не взаємодійте з протоколом
Не намагайтеся вивести кошти, закрити позицію або взаємодіяти з зараженою програмою будь-яким чином. Деякі експлойти створюють пастки для тих, хто намагається екстрено вийти — транзакція може бути скомпрометована.
Оцініть, чи зачеплено ваші кошти
Перевірте баланси відповідних акаунтів на експлорері. Якщо ваші токени все ще на місці (наприклад, ви мали позицію в пулі, який не був цільовим для атаки), не варто панікувати, але взаємодіяти з протоколом також не треба до офіційних повідомлень.
Слідкуйте за офіційними каналами
Надійне джерело інформації — офіційний Twitter/Discord протоколу. Уникайте неперевірених Telegram-груп, де можуть поширювати «рішення» або «інструкції з порятунку коштів» — це частий метод вторинного скаму.
Перевірте та відкличіть дозволи за потреби
Якщо протокол мав дозволи на витрачання ваших токенів (approval), і є ризик, що скомпрометована програма може їх використати, відкличте ці дозволи через інструменти управління акаунтами. Проте на Solana більшість DeFi-взаємодій працює через CPI з підписом, а не через approval-модель, тому цей крок залежить від архітектури конкретного протоколу.
Не покладайтеся на компенсації як на гарантію
Деякі протоколи після хаків оголошують про плани відшкодування, але це ніколи не є гарантією і не зобов'язанням. Розглядайте будь-які кошти в DeFi як такі, що можуть бути втрачені через помилку в коді, незалежно від репутації протоколу.
Технічні деталі для розробників
Цей матеріал орієнтований на користувачів протоколів. Якщо ви розробник і вас цікавить архітектура вразливостей, паттерни безпечного написання програм на Anchor, перевірки PDA, безпечний CPI та методики аудиту — детальний розбір доступний у розділі solana-dev-advanced.
Цей матеріал містить загальну інформацію про технічні ризики DeFi-протоколів і не є інвестиційною порадою. Рішення про використання будь-якого протоколу приймається вами на власний ризик. Перед блокуванням значних сум коштів рекомендується консультація з незалежним технічним експертом.