Стейк у Solana не починає працювати миттєво після натискання кнопки делегування, і так само не стає доступним для виведення одразу після команди деактивації. Обидва процеси привʼязані до епох — і саме ця затримка є ключовим практичним нюансом, який варто розуміти перед будь-якою операцією зі стейком.

Процес активації стейку після делегування

Коли ви створюєте стейк-акаунт і делегуєте SOL на валідатора, транзакція підтверджується в межах кількох секунд. Проте стейк-акаунт переходить у стан activating (активується), а не active (активний). У цьому стані ваші кошти вже заблоковані на стейк-акаунті, але винагороди вони ще не приносять.

Перехід у повністю активний стан відбувається на початку наступної епохи після того, як транзакцію делегування було включено до блоку. Тобто, якщо ви делегували в середині поточної епохи, стейк активується з початком наступної. Якщо транзакція потрапила в блок наприкінці епохи — активация також відбудеться з наступною епохою.

Важливий протокольний факт: момент включення транзакції в блок визначає, з якої епохи почнеться активация. Час підтвердження транзакції (секунди) і час активації стейку (початок наступної епохи) — це різні речі.

Процес деактивації стейку

Деактивація — це окрема команда (instrukcia deactivace у стейк-програмі Solana), яка переводить стейк-акаунт із стану active у стан deactivating. Після цього стейк припиняє приносити винагороди, але кошти ще не можна вивести.

Повний перехід у стан inactive (неактивний), коли стає можливим виведення SOL на гаманець, відбувається на початку наступної епохи після обробки команди деактивації. Тобто механіка дзеркальна до активації: ви подаєте команду, вона підтверджується швидко, але реальний перехід стану привʼязаний до межі епохи.

Після того як стейк-акаунт став inactive, потрібно окремо виконати команду виведення (withdraw), щоб перевести SOL назад на ваш основний гаманець. Деактивація сама по собі не повертає кошти.

Часові рамки: скільки чекати

Оскільки тривалість епохи змінюється (це окрема тема), точний час у годинах або хвилинах неможливо вказати як константу. Проте структурно ситуація така:

  • Активація: від моменту підтвердження транзакції делегування до початку наступної епохи — максимум одна повна епоха.
  • Деактивація: від моменту підтвердження команди деактивації до початку наступної епохи — максимум одна повна епоха.
  • Виведення: миттєво після того, як акаунт став inactive, але тільки після окремої команди withdraw.

Мінімальний час очікування в обох випадках — частину поточної епохи (якщо транзакцію подано на самому її початку). Максимальний — майже всю епоху (якщо транзакцію подано наприкінці). На практиці це означає, що плани щодо ліквідності варто будувати з орієнтиром на одну-дві епохи як типову затримку.

Що можна і чого не можна під час активації: Чому деактивація може затриматися

Поки стейк-акаунт перебуває у стані activating, діють такі обмеження:

  • Можна: розділити стейк-акаунт (split) на частини — нові акаунти успадкують той самий стан активації.
  • Можна: подати команду деактивації, щоб скасувати процес — акаунт перейде до deactivating і з наступної епохи стане inactive, навіть не досягнувши active.
  • Не можна: вивести SOL — акаунт не є inactive.
  • Не можна: обʼєднати (merge) активований акаунт із тим, що ще активується — для merge обидва акаунти мають бути в однаковому стані.

Під час деактивації (deactivating) обмеження подібні: виведення неможливе до переходу в inactive, але split технічно доступний.

Чому деактивація може затриматися понад один епох:

  • Пізня транзакція. Якщо ваша команда деактивації потрапила в блок у самому кінці епохи, вона може не встигнути обробитися до її завершення. У такому разі перехід стану зсунеться ще на одну епоху.
  • Перевантаження мережі. За високого навантаження транзакція може затриматися в черзі або не потрапити в блок поточної епохи.
  • Lockup (блокування). Якщо на стейк-акаунті встановлено lockup, команда деактивації буде відхилена до моменту закінчення терміну блокування. Це окремий параметр, який задається при створенні акаунта.
  • Проблеми валідатора. Валідатор, на якого делеговано стейк, може перестати голосувати. Хоча це не блокує деактивацію безпосередньо, непрацездатний валідатор може ускладнити моніторинг стану акаунта та створити враження затримки.

Практична порада: перед деактивацією перевірте стан стейк-акаунта через експлорер або CLI, переконайтеся у відсутності lockup і подавайте транзакцію з запасом часу до кінця поточної епохи. Це мінімізує ризик непередбачуваного подовження очікування.