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

Що варто винести з цього сценарію
Редакція «солана.укр» не публікує тверджень про поточний статус українського Web3-стартапу без прямого підтвердження з боку команди, перевірки відкритих даних мережі та зіставлення цих джерел між собою. Якщо хоча б один із цих елементів відсутній — редакція формулює висновок як припущення, вказує межу знання або утримується від конкретного статусу.
Що змінюється під час використання
Процес перевірки складається з кількох послідовних кроків, кожен із яких має власну мету та обмеження.
Перший крок — прямі джерела команди. Редакція звертається до офіційних каналів стартапу: сайт, документація, офіційні акаунти в соціальних мережах, репозиторії на GitHub. Ці джерела дозволяють зрозуміти, що команда сама заявляє про свій продукт, етап розробки та технічний стек. Якщо стартап позиціює себе як проєкт на Solana, редакція перевіряє, чи є в відкритому доступі відповідні смарт-контракти, написані на Rust або за допомогою фреймворку Anchor, чи задокументовано взаємодію з мережею Solana через RPC-вузли.
Другий крок — дані мережі. Для проєктів, які стверджують, що працюють на Solana, редакція перевіряє наявність розгорнутих програм (smart contracts) у блокчейні. Це означає пошук програмних акаунтів (Program ID) у блокчейн-експлорерах, перевірку історії транзакцій та аналіз того, чи взаємодіють ці програми з реальними користувацькими гаманцями. Відсутність розгорнутих програм у мережі при твердженні про «працюючий продукт на Solana» є червоним прапорцем.
Третій крок — зіставлення джерел. Редакція порівнює те, що команда заявляє публічно, з тим, що видно в мережі. Якщо на сайті вказано, що продукт уже запущено, але в блокчейні немає відповідної активності або програми перебувають у тестовому стані — редакція фіксує цю розбіжність і формулює статус відповідно до фактичних даних, а не маркетингових заяв.
Четвертий крок — прямий контакт за чутливими фактами. Якщо статус стартапу залежить від інформації, яку неможливо перевірити через відкриті джерела (наприклад, юридична структура, наявність фінансування, склад команди, поточні партнерства), редакція звертається безпосередньо до представників проєкту. Без такої перевірки ці твердження не потрапляють у текст як підтверджені факти.
Кому це справді важливо
Перевірка статусу стартапу потрібна кільком аудиторіям, кожна з яких має власний інтерес.
- Інвестори та грантодавці. Перед прийняттям рішення про фінансування важливо розуміти, чи відповідає заявлений етап реальному стану проєкту. Редакційна перевірка дає незалежну точку відліку.
- Потенційні користувачі. Людина, яка планує використовувати DeFi-протокол, NFT-маркетплейс або інший інструмент, має право знати, чи працює продукт у mainnet, чи перебуває на стадії тестування, чи взагалі не має розгорнутих контрактів.
- Інші команди екосистеми. Стартапи, які розглядають інтеграцію або партнерство, потребують розуміння реального технічного стану потенційного партнера. Детальніше про те, де українські команди шукають партнерів і технічну підтримку, можна прочитати в окремому матеріалі.
- Організатори хакатонів, акселераторів та програм підтримки. Вони використовують перевірені дані для оцінки заявок та формування когорт.
На чому легко помилитися
Жодна редакційна перевірка не є аудитом безпеки чи юридичною due diligence. Це важливо розуміти як редакції, так і читачам.
Обмеження відкритих даних. Не всі аспекти стартапу видимі в мережі. Команда може мати розроблений продукт, який ще не розгорнутий публічно. У таких випадках редакція не може підтвердити статус «працюючий продукт» і вказує, що перевірка можлива лише за умови надання доступу до тестового середовища або відповідних доказів від команди.
Ризик застарілих даних. Статус стартапу в Web3 може змінитися швидко: протокол може бути активним сьогодні та призупиненим завтра. Редакція вказує, на які саме дані спирається, і рекомендує читачам перевіряти актуальний стан самостійно, особливо перед прийняттям фінансових рішень.
Типова помилка — довіра до єдиного джерела. Якщо редакція спирається лише на пресреліз або заяву в Twitter без перевірки в мережі, ризик публікації хибного статусу зростає суттєво. Саме тому обов’язковим є зіставлення щонайменше двох типів джерел.
Типова помилка — ототожнення українського походження з наявністю продукту. Те, що засновник або частина команди з України, не означає, що стартап має працюючий продукт на Solana. Редакція перевіряє технічний статус окремо від інформації про склад команди. Більше контексту про українські команди в екосистемі є в загальному огляді українських команд і стартапів на Solana.
Типова помилка — екстраполяція минулого статусу на сьогодення. Стартап, який успішно пройшов акселератор рік тому, може не мати активної розробки зараз. Редакція не переносить підтверджений статус з минулого періоду в сьогодення без нової перевірки.
Куди веде цей висновок
Якщо ви читаєте матеріал про український Web3-стартап на «солана.укр» і хочете самостійно перевірити його статус, ось що варто зробити.
- Знайдіть Program ID. Зазвичай він вказаний у документації проєкту або в репозиторії на GitHub. Введіть його в блокчейн-експлорер Solana і перевірте, чи існує ця програма в мережі, коли вона була розгорнута та чи є транзакції, що до неї звертаються.
- Перевірте репозиторій. Наявність відкритого коду не гарантує безпеки, але його відсутність при заявленому «працюючому продукті» — це сигнал для додаткових запитань.
- Зіставте заяви з реальністю. Якщо на сайті написано «live on Solana», але програма розгорнута в devnet — це різні речі. Devnet використовується для тестування і не є основною мережею.
- Зверніть увагу на формулювання в матеріалах. Якщо редакція пише «команда заявляє» або «за даними на момент перевірки» — це означає, що статус не підтверджений незалежно або може змінитися.
- Для власних рішень — звертайтеся до фахівців. Редакційна перевірка не замінює технічний аудит безпеки смарт-контрактів, юридичну перевірку чи фінансову due diligence. Якщо ви плануєте інвестувати, інтегрувати продукт або передавати йому кошти — залучайте профільних спеціалістів.
Щоб побачити ширший контекст того, хто будує на Solana в Україні, перегляньте розділ Solana в Україні: люди, команди й можливості. Якщо ви самі розробляєте проєкт і шукаєте практичні кроки від ідеї до працюючого продукту, корисним буде посібник «Будувати на Solana: від ідеї до працюючого продукту». Історії та досвід конкретних людей екосистеми зібрані в розділі «Люди Solana: рішення, досвід і команди».
Редакція солана.укр
