Ліквідний стейкінг на Solana працює через програми (смарт-контракти), які приймають нативний SOL, делегують його валідаторам і випускають ліквідні токени (LST) як підтвердження депозиту. На відміну від нативного стейкінгу, де кошти заблоковані безпосередньо в протоколі Solana і контролюються лише власником облікового запису, ліквідний стейкінг додає проміжний програмний шар. Саме цей шар несе смартконтрактні ризики — можливість втрати коштів або порушення роботи протоколу через помилки, вразливості або навмисні дії в коді програми.
Які вразливості можливі в контрактах стейкінгу
Програми ліквідного стейкінгу на Solana написані переважно на Rust із використанням фреймворку Anchor. Хоча ці інструменти забезпечують високий рівень безпеки за замовчуванням, конкретні реалізації можуть містити вразливості. Нижче наведено основні категорії ризиків, притаманні саме стейкінг-протоколам.
Помилки в логіці випуску та спалювання LST. Ліквідний токен має випускатися лише при надходженні SOL у пул і спалюватися лише при виведенні. Якщо в логіці програми є помилка, що дозволяє випуск LST без відповідного депозиту, це призводить до неконтрольованої емісії та знецінення токена. Зворотна ситуація — неможливість спалити LST і повернути SOL — блокує кошти користувачів.
Вразливості в роботі з PDA (Program Derived Address). У Solana програми не зберігають стан безпосередньо, а використовують спеціальні адреси, похідні від програми (PDA). Якщо насіння (seed), з якого генерується PDA, обрано некоректно, або якщо програма не перевіряє, що працює саме з власним PDA, це може дозволити сторонньому контракту або користувачу маніпулювати станом пулу.
Небезпечні виклики через CPI (Cross-Program Invocation). Стейкінг-програма взаємодіє з іншими програмами Solana: системною програмою стейкінгу, програмою токенів (Token Program), іноді з DEX для реінвестування. Якщо CPI виконується без належних перевірок адрес програм-цілей, атакувальник може підмінити виклик і перенаправити кошти. Це особливо небезпечно, коли протокол дозволяє адміністративному обліковому запису вказувати довільні адреси програм.
Проблеми з контролем доступу та правами адміністратора. Багато протоколів зберігають можливість оновлення програми (upgrade authority) або мають адміністративні функції: зміна комісії, оновлення адрес валідаторів, пауза. Якщо ці права не розподілені через мультисигнатуру або не обмежені тимчасовими замками (timelock), єдиний власник ключа може одноосібно змінити логіку програми, зокрема — вивести кошти з пулу.
Ризики оновлення програми. На Solana програму можна оновити, якщо обліковий запис із правом оновлення не скасовано. Навіть якщо початковий код безпечний, наступне оновлення може містити вразливість або навмисно шкідливу логіку. Користувач, який делегував SOL у минулому, не контролює момент оновлення.
Помилки в розподілі винагород і комісій. Програма має коректно обчислювати частку кожного депозиту в загальному пулі, враховувати накопичені винагороди від валідаторів та стягувати протокольну комісію. Помилки в арифметиці з фіксованою точкою або в обробці округлень можуть призвести до некоректного нарахування LST або до втрати частини винагород.
Як перевірити безпеку смарт-контракту
Повна перевірка смарт-контракту доступна лише розробникам із досвідом аудиту коду на Rust і Solana. Проте делегатор може виконати низку практичних кроків, щоб оцінити рівень довіри до протоколу.
Перевірка наявності та якості аудиту. Надійні протоколи публікують звіти від незалежних аудиторських компаній (наприклад, OtterSec, Sec3, Trail of Bits, Neodyme). Важливо не просто наявність звіту, а його зміст: чи виявлено вразливості, як вони усунуті, чи є критичні залишкові проблеми. Якщо протокол працює без аудиту — це самостійний фактор ризику.
Перевірка відкритості вихідного коду. Вихідний код програми має бути опублікований на GitHub із прив'язкою до конкретного розгортання на mainnet (через хеш коміту). Якщо код закритий, неможливо незалежно перевірити, що саме розгорнуто в мережі.
Перевірка upgrade authority на ланцюгу. За допомогою інструментів на кшталт Solana Explorer або CLI можна переглянути обліковий запис програми і знайти, хто володіє правом оновлення. Якщо це одиночний гаманець без мультисигнатури — це червоний прапор. Ідеальний варіант — скасоване право оновлення (immutable program) або управління через мультисигнатуру з кількома незалежними підписантами.
Аналіз адміністративних функцій. У відкритому коді слід знайти інструкції, доступні лише авторизованим обліковим записам, і перевірити, які дії вони дозволяють. Критично небезпечні функції: можливість виведення SOL з пулу на довільну адресу, зміна адреси програми-оракула, встановлення довільної комісії без обмежень.
Перевірка відповідності розгорнутої програми опублікованому коду. Навіть якщо код відкритий, необхідно переконатися, що саме ця версія компільована і розгорнута на mainnet. Для цього порівнюють хеш байт-коду програми на ланцюгу з результатом локальної компіляції опублікованого коду. Цей крок вимагає технічних навичок, але деякі протоколи публікують інструкції для самостійної перевірки.
Моніторинг активності розробників. Регулярні коміти, відповіді на проблеми (issues), прозора комунікація про знайдені вразливості — непрямі, але корисні сигнали. Протокол, який не оновлював репозиторій місяцями або ігнорує повідомлення про баги, викликає менше довіри.
Ознаки безпечного протоколу: Що робити при виявленні вразливості
Безпечний протокол ліквідного стейкінгу зазвичай має такі ознаки:
- Пройшов щонайменше один аудит від визнаної компанії з опублікованим звітом.
- Вихідний код повністю відкритий із прив'язкою до mainnet-розгортання.
- Право оновлення програми або скасоване, або передано мультисигнатурі з не менше ніж трьома незалежними підписантами.
- Адміністративні функції мінімальні та не дозволяють одноосібного виведення коштів користувачів.
- Протокол має публічну політику реагування на вразливості (bug bounty або чіткий контакт для відповідального розкриття).
- Історія розгортання без раптових оновлень без пояснень.
Якщо ви виявили можливу вразливість у смартконтракті протоколу, де утримуються ваші кошти, дійте послідовно:
- Не публікуйте деталі вразливості відкрито (у соцмережах, чатах), поки протокол не відреагує. Це захищає інших користувачів від експлуатації.
- Зв'яжіться з командою протоколу через офіційні канали: спеціальну електронну адресу для безпеки (security@), форму відповідального розкриття або безпосередньо через issue у GitHub із позначкою «confidential».
- За відсутності реакції протягом розумного строку (зазвичай 24–72 години для критичних вразливостей), зверніться до аудиторів, які перевіряли протокол, або до незалежних дослідників безпеки в екосистемі Solana.
- Оцініть доцільність виведення коштів. Якщо вразливість дозволяє несанкціоноване виведення і команда не реагує, найбезпечніший крок — вивести свої LST і обміняти їх на SOL, поки пул має достатню ліквідність. Зверніться до розділу Як вивести SOL з ліквідного стейкінгу для конкретних кроків.
- Не покладайтеся на словесні запевнення команди про те, що «вразливість не експлуатується». Перевірте на ланцюгу стан пулу: чи відповідає баланс SOL у стейк-акаунтах сумі випущених LST із урахуванням накопичених винагород.
Смартконтрактні ризики неможливо усунути повністю — це властивість будь-якої програмної інфраструктури. Проте свідомий вибір протоколу з відкритим кодом, незалежним аудитом та розподіленим контролем оновлень суттєво знижує ймовірність втрати коштів через помилки або зловмисні дії.