Що команда має пояснити користувачам перед завершенням роботи сервісу

Коли сервіс оголошує про закриття, користувачам потрібні не вибачення й не розмови про «важкий ринок» — потрібна конкретна інформація, яка дозволяє прийняти рішення щодо своїх активів і даних. Нижче — перелік того, що команда зобов’язана пояснити, і критерії, за якими можна перевірити, чи достатньо цих пояснень.

З чого починаємо повторну оцінку

Головна теза проста: перед завершенням роботи сервісу команда має надати користувачам достатньо перевірюваної інформації, щоб жодна людина не втратила доступ до своїх коштів або даних через брак розуміння процесу. Це мінімальний стандарт, а не «краща практика».

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

Що відбувається під капотом

Процес завершення роботи сервісу в Web3-середовищі принципово відрізняється від традиційного SaaS. Коли звичайний застосунок закривається, користувач втрачає доступ до функціоналу, але його дані часто можна експортувати, а підписка просто припиняється. У випадку блокчейн-сервісу ситуація складніша: користувач може мати депоновані токени, NFT у смарт-контракті проєкту, активні позиції в лендінгу або незавершені транзакції.

Умовний приклад. Уявіть сервіс, який керує депозитами користувачів через смарт-контракт. Команда оголошує: «Ми закриваємося, будь ласка, виведіть кошти до 15 числа». Формально — повідомлення є. Фактично — воно неповне, якщо не містить низки обов’язкових елементів.

Що має бути пояснено:

• Точна хронологія. Не «скоро» чи «у найближчі тижні», а конкретні дати: коли вимикається інтерфейс, коли зупиняється серверна частина, коли смарт-контракт переходить у режим «тільки зняття», коли повністю блокуються всі операції.
• Механіка виведення коштів. Який саме шлях використовувати — через веб-інтерфейс, безпосередньо через смарт-контракт, через інший інструмент. Чи потребує виведення затвердження від команди, чи це автоматизована функція контракту.
• Стан смарт-контрактів після закриття. Чи залишаться програми розгорнутими on-chain, чи їхню роботу буде зупинено або деактивовано, чи буде передано контроль іншій адресі. Це критично, бо від цього залежить, чи зможе користувач звернутися до контракту безпосередньо, якщо інтерфейс вже не працює.
• Доступ до даних. Які саме дані користувача зберігаються на стороні сервісу, як їх можна отримати до вимкнення, чи є альтернативні джерела цієї інформації (наприклад, on-chain історія).
• Статус ключів і управління. Що відбувається з приватними ключами, якщо сервіс їх зберігав. Що відбувається з адміністративними ключами смарт-контрактів після закриття.

Дані та аргументи

Ключова проблема більшості оголошень про закриття — вони містять твердження, які неможливо перевірити. «Ми повернули всі кошти» або «Контракт безпечний» — це позиція команди, а не дані.

Що має бути доступно для незалежної перевірки:

• Адреси смарт-контрактів із вказівкою мережі та посиланням на експлорер. Це дозволяє будь-кому перевірити поточний баланс контракту, історію транзакцій і поточний стан функцій.
• Хеш останньої версії контракту або посилання на репозиторій із зазначенням коміту. Без цього неможливо визначити, чи відповідає розгорнутий контракт опублікованому коду.
• Стан коштів на момент оголошення. Не «ми маємо достатньо для всіх виведень», а конкретні цифри: загальний баланс контракту, сума зобов’язань перед користувачами, різниця між ними.
• Відомості про зовнішні ризики. Чи є відкриті аудити контракту, чи були виявлені вразливості після останнього аудиту, чи є активні баг-баунті програми.

Позиція користувача в цій ситуації асиметрична: команда має повну інформацію, користувач — лише те, що команда вирішила повідомити. Тому стандартом має бути не «ми повідомили те, що вважаємо за потрібне», а «ми надали все, що потрібно для незалежної перевірки».

Ризики та межі висновку

Чесно визнати: є речі, які команда не завжди може розкрити повністю. Юридичні обмеження, умови конфіденційності, незавершені переговори з контрагентами — усе це реально існує. Але наявність обмежень не означає, що можна замінити інформацію розмитими формулюваннями.

Як має виглядати чесне визнання обмеження: «Ми не можемо опублікувати повний звіт про розподіл коштів через угоду NDA з партнером, але ми публікуємо баланс смарт-контракту та підтверджуємо, що сума покриває всі зобов’язання перед користувачами. Ви можете перевірити це самостійно за такою-то адресою».

Типові ризики для користувачів у період закриття:

• Часовий тиск. Команда встановлює жорсткий дедлайн, користувач поспішає, робить помилки в транзакціях — відправляє на неправильну мережу, використовує неправильний токен. Команда має передбачити це й дати чіткі інструкції з перевірками.
• Залежність від інфраструктури. Навіть якщо смарт-контракт дозволяє пряме виведення, користувач може покладатися на RPC-вузол, який контролює команда. Якщо цей вузол вимикається разом із сервісом, користувач має знати, як підключитися до альтернативного.
• Невизначеність із «забутими» коштами. Що станеться з коштами користувачів, які не виведуть їх у встановлений термін? Це має бути проговорено явно, а не залишене на розсуд «пізніше вирішимо».

Компроміс, який команда не має права робити: жертвувати ясністю заради збереження репутації. Коротке чесне повідомлення про проблему завжди краще за красиве повідомлення, яке не відповідає на питання.

Підсумок і спосіб перевірки

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

Для інших команд, які зараз працюють, цей матеріал пропонує простий тест: відкрийте своє поточне оголошення про будь-що — запуск, оновлення, міграцію — і перевірте, чи відповідає воно на запитання «що конкретно має зробити користувач і як це перевірити». Якщо ні, це не комунікація, а маркетинг.

Наступний крок для читача: якщо ви стикаєтеся з оголошенням про закриття сервісу, використовуйте цей перелік як чек-лист. Якщо бракує хоча б одного пункту — вимагайте уточнень. Якщо команда ігнорує запити — це окремий сигнал, який варто враховувати при оцінці ризиків.

Більше контексту про те, як ми аналізуємо подібні ситуації, доступно в розділі «Після хайпу». Щоб стежити за тим, які продукти в екосистемі залишаються функціональними, дивіться «Продукти Solana», а для розуміння змін у самій мережі — «Радар Solana».

Редакція солана.укр