Хакатонний MVP — це не скорочена версія повноцінного продукту. Це окремий формат із власною логікою: він має довести, що ідея працює на блокчейні Solana, а не що вона готова до запуску. Нижче — чіткий перелік того, що обовʼязково має бути у вашому поданні, а що можна відкласти.

Актуальність: Для теми «Що має входити в хакатонний MVP» відкриті позиції, суми винагород, правила та дедлайни змінюються. Станом на 2 серпня 2026 року остаточні умови потрібно звіряти на офіційній сторінці конкретної можливості перед поданням заявки.

Ознаки хакатонного MVP проти повноцінного продукту

Головна різниця — у меті. Повноцінний продукт має розвʼязувати проблему для реальних користувачів і генерувати прибуток. Хакатонний MVP має продемонструвати технічну здійсненність і звʼязок із блокчейном.

  • Обсяг функцій. Хакатонний MVP містить одну-дві ключові дії. Повноцінний продукт — цілий користувацький шлях із налаштуваннями, історією, сповіщеннями.
  • Стабільність. Для хакатону достатньо, щоб сценарій відпрацював щонайменше один раз без помилок під час демо. Продукт має витримувати навантаження та обробляти крайові випадки.
  • Інфраструктура. Хакатонний MVP працює на Devnet із тестовими токенами. Продукт — на Mainnet із реальними коштами та аудитами безпеки.
  • Дизайн. Хакатонний MVP може мати мінімальний інтерфейс без адаптивності. Продукт вимагає продуманого UX/UI та тестування з користувачами.
  • Залучення даних. У хакатоні дані можуть бути хардкоденими або згенерованими. У продукті — реальні, оновлювані, валідовані.

Якщо ви сумніваєтесь, чи не переробляєте продукт замість MVP, поставте питання: «Чи втратить ця фіча сенс для журі, якщо її прибрати?» Якщо ні — прибирайте.

Обовʼязкові компоненти

Робочий користувацький потік від початку до кінця

Журі має побачити повний цикл: від ініціації дії до підтвердженого результату на блокчейні. Розірваний потік — це не MVP, а набір фрагментів.

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

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

Інтеграція з Solana

Ваш проєкт має бути саме на Solana, а не просто з кнопкою «Connect Wallet». Інтеграція означає реальну взаємодію з блокчейном.

  • Транзакція. Переказ SOL або SPL-токена між акаунтами.
  • Смарт-контракт. Програма на Rust або Anchor, яка змінює стан on-chain.
  • Інший on-chain елемент. Створення токена, NFT-мінт, запис даних у акаунт через PDA (Program Derived Address — похідна адреса програми), виклик CPI (Cross-Program Invocation — міжпрограмний виклик).

Мінімум — одна підтверджена транзакція в мережі Devnet, яку можна перевірити через експлорер.

Базовий інтерфейс

Інтерфейс не має бути красивим, але має бути зрозумілим. Журі не буде вгадувати, куди натиснути.

  • Кнопка підключення гаманця (Phantom, Solflare або інший сумісний).
  • Основна зона дії: форма, кнопка мінту, таблиця даних — залежно від типу проєкту.
  • Індикатор статусу: «Очікування підписання», «Транзакція підтверджена», «Помилка».
  • Відображення результату: оновлений баланс, змінений стан, посилання на транзакцію.

Фреймворк не важливий — підійде React, Next.js, навіть простий HTML із Vanilla JS. Головне — функціональність.

Що можна безпечно пропустити

Ці елементи часто зʼїдають час, але майже не впливають на оцінку журі.

  • Авторизація та реєстрація користувачів. Гаманець — це вже аутентифікація. Не будуйте окрему систему логіну.
  • Адаптивний дизайн для мобільних. Достатньо, щоб демо нормально виглядало на екрані ноутбука, з якого ви презентуєте.
  • Обробка всіх крайових випадків. Якщо користувач відмовить підписання — достатньо показати помилку. Не потрібно витрачати години на graceful degradation.
  • Локалізація та мультиязичність. Англійська цілком достатня.
  • Анімації, мікровзаємодії, завантажувальні спінери. Краса не компенсує відсутність робочої транзакції.
  • Адмін-панель. Журі оцінює користувацький досвід, не інструменти модератора.
  • Оптимізація продуктивності. Якщо транзакція проходить за 3 секунди замість 1 — це не критично для хакатону.

Приклади мінімальних MVP, які перемагали

Ці приклади ілюструють принцип «менше, але працює».

  • On-chain реєстр учасників події. Програма на Anchor зберігає PDA-акаунти з даними реєстрації. Фронтенд — одна сторінка з полем імені та кнопкою «Зареєструватися». Транзакція створює акаунт на Devnet. Немає профілів, немає списку учасників, немає адмінки. Перемога в номінації «Найкраще використання PDA».
  • SPL-токен із умовним мінтом. Користувач підключає гаманець, натискає «Mint», фронтенд викликає програму, яка перевіряє наявність іншого токена на балансі. Якщо умова виконана — мінтить новий токен. Усього два екрани, одна транзакція, жодного додаткового функціоналу.
  • Простий DAO з одним голосуванням. Програма зберігає пропозицію та рахує голоси. Фронтенд показує пропозицію, дві кнопки «За»/«Проти» та лічильник. Після голосування стан оновлюється on-chain. Немає делегування, немає створення пропозицій через UI, немає періодів голосування.

Спільне в усіх цих прикладах: один повний цикл дії, одна on-chain транзакція, мінімальний інтерфейс, жодних зайвих модулів.

Наступний крок: розгортання на Devnet

Коли ваш MVP функціонально готовий локально, наступний обовʼязковий етап — розгортання на Devnet. Журі має можливість самостійно перевірити вашу роботу, а не лише дивитися на записаний скрінкаст.

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

  • Розгорнути смарт-контракт (програму) на Devnet через solana program deploy.
  • Налаштувати фронтенд на підключення до Devnet RPC-ендпоінту.
  • Забезпечити тестовими SOL для гаманців, які будуть використовуватися під час демо (з крану Devnet).
  • Перевірити повний користувацький потік у Devnet-середовищі, а не локально.
  • Зафіксувати посилання на деплойовану програму та хоча б одну тестову транзакцію в експлорері.

Перед розгортанням переконайтеся, що ідентифікатор програми (Program ID) у фронтенді збігається з тим, що отримали після розгортання. Це найчастіша помилка, через яку демо ламається прямо під час презентації.

Після успішного розгортання на Devnet перейдіть до оформлення репозиторію — читайте наступний матеріал про те, як правильно оформити GitHub і README для хакатону.

Джерела