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

Що таке due diligence і чого чекати

Due diligence — це структурована перевірка стартапу перед інвестицією. Інвестор збирає інформацію, перевіряє факти та оцінює ризики. Це не співбесіда з гарними питаннями, а аудит вашої документації, коду, фінансів і юридичної чистоти.

Чого чекати:

  • Запит на дані (data room). Інвестор або його юридична команда надішле список документів, які потрібно надати. Зазвичай це 40–80 позицій.
  • Технічний аудит. Якщо у вас є розгорнуті смарт-контракти, їх перевірятиме окрема команда або залучена аудиторська фірма.
  • Співбесіди з фаундерами. Неформальні розмови, де перевіряють консистентність ваших відповідей із тим, що написано в документах.
  • Перевірка бекграунду. Інвестори зв'яжуться з вашими попередніми колегами, партнерами та радниками.
  • Терміни. Від двох тижнів до двох місяців залежно від розміру раунду та складності проєкту.

Що перевіряють інвестори

Продукт

Чи вирішує продукт реальну проблему, чи це рішення, яке шукає завдання. Інвестор подивиться метрики: скільки активних користувачів, яка утримуваність (retention), чи є фідбек від реальних людей. Якщо продукт ще не запущений — перевірять, чи є докази попиту: листи очікування, результати інтерв'ю з користувачами, прототип із тестуванням.

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

Команда

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

Фінанси

Як ви витрачали гроші до цього моменту, який ваш бьорнрейт (burn rate), скільки грошей потрібно і на що саме. Інвестор хоче побачити фінансову модель, де видно: коли закінчяться гроші, на що підуть інвестиції, коли стартап вийде на беззбитковість або наступний раунд.

Юридика

Де зареєстрована компанія, хто власник, чи є корпоративні договори між фаундерами, чи підписані NDAs з підрядниками, чи оформлені інтелектуальні права на код і бренд. У Web3 це особливо болюча точка, бо багато команд працюють без юридичної структури місяцями.

Технологія

Який стек, чому обрано саме його, де розгорнуто, як забезпечено надійність. Інвестор або технічний експерт подивиться архітектуру, інфраструктуру, наявність тестів, процес розробки.

Токеноміка

Якщо у проєкті є токен — інвестор перевірить логіку його існування. Чи потрібен він функціонально, чи це спосіб залучити гроші. Подивляться розподіл токенів, графік розблокування (vesting), механіки утилізації, моделі попиту та пропозиції.

Як підготуватися заздалегідь

Порядок у документації з першого дня

Не чекайте на запит від інвестора, щоб почати шукати договори. Створіть структуровану папку (data room) ще до перших розмов. Базовий набір:

  • Реєстраційні документи компанії та статут
  • Корпоративний договір між фаундерами (founders' agreement)
  • Договори з підрядниками, консультантами, радниками
  • Угоди про передачу інтелектуальних прав
  • Фінансова модель у форматі таблиці
  • Історія витрат (якщо були попередні інвестиції чи гранти)
  • Технічна документація: архітектура, опис рішень
  • Токеноміка (якщо є токен) із описом припущень

Регулярно оновлюйте цю папку. Кожен новий підписаний документ має потрапляти туди одразу.

Чіткий cap table, розподіл equity

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

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

Специфіка due diligence для Web3

Аудит смарт-контрактів, безпека коштів

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

Що потрібно знати:

  • Аудит проводять спеціалізовані компанії. Вибір аудитора має сенс обговорювати з інвестором — деякі фонди приймають результати лише певних аудиторів.
  • Аудит — це не гарантія відсутності вразливостей. Це доказ того, що ви серйозно ставитеся до безпеки.
  • Підготуйте перелік усіх розгорнутих контрактів, їхніх версій, адрес на mainnet та testnet.
  • Опишіть, де зберігаються приватні ключі, хто має до них доступ, чи використовується multisig, чи є процедура екстреного призупинення (pause).

Регуляторний статус токена

Це найскладніша частина Web3-due diligence. Юридичний статус токена залежить від юрисдикції, функціональності та того, як ви його позиціонуєте. Інвестор перевірить:

  • Чи є юридичний висновок (legal opinion) щодо статусу токена
  • У якій юрисдикції видано висновок і наскільки він релевантний для фонду
  • Чи не позиціонується токен як цінний папір у комунікаціях, документах, на сайті
  • Чи є обмеження для резидентів певних країн (зокрема США)

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

Червоні прапорці, які зупинять інвестора

  • Невідповідність у розповідях. Один фаундер каже одне, інший — інше. Документи кажуть третє. Це вбиває довіру миттєво.
  • Відсутність юридичної структури. «Ми працюємо як DAO, у нас немає компанії» — це може працювати для спільноти, але не для інвестиційного раунду.
  • Нечіткий розподіл власності. «Ми ще не домовилися, хто скільки має» — інвестор не вкладатиме гроші в компанію, де фаундери не змогли домовитися між собою.
  • Токен без функції. Якщо токен потрібен лише для фандрайзингу й не має ролі в продукті, інвестор побачить це одразу.
  • Немає аудиту, але контракти вже на mainnet і керують коштами. Це сигнал, що команда не розуміє або ігнорує ризики.
  • Невідомі радники з великими алокаціями. Якщо 15% токенів дістаються людям, чиї імена не розкриті або чий внесок незрозумілий — це підозріло.
  • Копіпаст з інших проєктів. Токеноміка, скопійована з популярного протоколу без адаптації до вашої моделі, викликає питання про розуміння команди.
  • Приховані фінансові зобов'язання. Борги, незадекларовані гранти, умови попередніх інвесторів, про які ви «забули» згадати.

Як відповідати на складні запитання

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

Типові складні питання та як до них підготуватися:

«Чому саме Solana, а не Ethereum чи інший L1?»
Готовте відповідь на рівні продукту, не маркетингу. Швидкість транзакцій і низькі комісії — це характеристики, не аргументи. Аргумент: «Наш продукт вимагає X транзакцій на секунду з затримкою менше Y мілісекунд, тому Solana — єдина мережа, де це технічно можливе без компромісів».

«Що буде, якщо ваш головний розробник піде?»
Інвестор перевіряє залежність від однієї людини. Якщо весь код знає одна людина — це ризик. Підготуйте відповідь про документацію, процес код-рев'ю, розподіл знань у команді.

«Як ви будете захищатися від експлойтів?»
Конкретика: аудит, bug bounty програма, формальна верифікація (якщо застосовна), процес реагування на інциденти, multisig для оновлень контрактів.

«Хто ваша цільова аудиторія і як ви її залучаєте?»
Без абстракцій на кшталт «всі користувачі DeFi». Назвіть конкретний сегмент, опишіть, де ці люди зараз, як ви до них достукаєтеся, скільки коштує залучення одного користувача і чи перевіряли ви це.

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

Типові помилки при підготовці до due diligence

Готуватися після запиту. Коли інвестор надсилає список із 60 пунктів і дає тиждень, ви не встигнете все знайти. Договори губляться, колишні підрядники не відповідають, бухгалтерія в хаосі. Починайте готуватися з першого дня існування компанії.

Вважати, що due diligence — це формальність. Деякі фаундери думають: «Нас уже запросили на термшит, значить, гроші наші». Ні. Due diligence — це етап, де угоди розриваються найчастіше.

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

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

Не мати єдиної версії правди. Усі фаундери мають розповідати одне й те саме. Перед due diligence проведіть внутрішній мок-аудит: нехайте хтось із команди або зовнішній радник поставить вам найскладніші питання й перевірить, чи збігаються відповіді.

Ігнорувати комунікацію. Due diligence — це не лише документи, а й те, як ви спілкуєтеся. Пізні відповіді, незрозумілі пояснення, ухилення від питань — усе це формує враження. Відповідайте швидко, чітко й по суті.

Due diligence у Web3 вимагає більшої підготовки, ніж у традиційному tech, але це не привід боятися. Це привід навести порядок у тому, що й так має бути впорядковано: документи, розподіл відповідальності, безпека коду, розуміння регуляторного середовища. Якщо цей порядок є, due diligence стане не перешкодою, а підтвердженням того, що ви — команда, якій можна довіряти.

Джерела