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

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

Основні категорії оцінювання

Технічна реалізація та якість коду

Журі дивиться, чи проєкт реально працює на Solana, а не є лише макетом. Оцінюють архітектуру смарт-контрактів (зазвичай на Anchor), правильність використання PDA (Program Derived Address — техніка для визначення адрес програмних акаунтів), безпеку транзакцій та взаємодію з RPC-вузлами (Remote Procedure Call — точки входу для взаємодії з блокчейном). Важливо: код має бути відкритим у репозиторії, зрозумілим для ревʼю та придатним до подальшої розробки.

  • Чи розгорнуто проєкт на devnet або testnet
  • Чи є чистий README із інструкцією для запуску
  • Чи оброблені типові edge-кейси (недостатній баланс, відхилення транзакції)

Дизайн та користувацький досвід

Блокчейн-продукт оцінюють як звичайний цифровий сервіс. Журі звертає увагу на те, наскільки зрозумілий шлях користувача: від підключення гаманця до виконання ключової дії. Головне — не візуальна вишуканість, а відсутність перешкод, які змушують здаватися до завершення транзакції.

  • Зрозумілість інтерфейсу для людини без криптографічної підготовки
  • Наявність зворотного звʼязку під час очікування транзакції
  • Адаптивність під різні екрани, якщо це веб-додаток

Оригінальність ідеї та потенціал ринку

Клон існуючого проєкту з мінімальними змінами отримає низький бал у цій категорії. Журі шукає рішення, які вирішують реальну проблему й використовують переваги Solana — швидкість, низькі комісії, composability (можливість комбнувати протоколи). Важливо показати, хто ваш користувач і чому саме ця проблема потребує блокчейн-рішення.

  • Чи є чітке визначення проблеми та цільової аудиторії
  • Чи обґрунтоване використання блокчейну замість централізованої бази даних
  • Чи відрізняється підхід від існуючих рішень в екосистемі

Якість подання (demo, pitch deck, README)

Навіть найкращий код не виграє, якщо журі не зрозуміє, що ви зробили. Demo-відео має показувати реальну роботу проєкту, а не анімацію. Pitch deck — коротко пояснювати суть без зайвої термінології. README — дати технічному оглядачу можливість запустити проєкт за пʼять хвилин.

  • Demo триває 2–3 хвилини й показує ключовий юзкейс від початку до кінця
  • Pitch deck містить проблему, рішення, архітектуру та наступні кроки
  • README має секції: що це, як запустити, стек технологій, структура репозиторію

Як журі зважує критерії між собою

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

Щоб дізнатися точні пропорції, відкрийте офіційну сторінку хакатону на платформі проведення (зазвичай це devpost.com або спеціалізований портал Solana) і знайдіть секцію Judging Criteria. Якщо ваги не вказані явно, орієнтуйтеся на рівномірний розподіл між чотирма категоріями.

На що звернути увагу залежно від треку

Хакатони Solana часто мають тематичні треки від спонсорів-протоколів. Кожен трек додає до базових критеріїв власний фокус:

  • DeFi-треки: акцент на безпеці смарт-контрактів, коректності математичних моделей, обробці MEV (Maximal Extractable Value — можливість вилучення додаткової вартості з порядку транзакцій)
  • Gaming-треки: важливіша плавність ігрового процесу, інтеграція з NFT як ігровими активами, швидкість відповідей від ланцюга
  • DePIN-треки (Decentralized Physical Infrastructure Networks): журі дивиться на реалістичність звʼязку між ончейн-логікою та фізичним пристроєм або даними
  • RWA-треки (Real World Assets): ключовий критерій — правдоподібність моделі токенізації реального активу, а не лише технічна реалізація
  • Треки інтеграції з конкретним протоколом: перевіряють глибину використання API або CPI (Cross-Program Invocation — виклик однією програмою іншої на Solana) спонсора, а не просто підключення гаманця

Перед стартом розробки визначтеся з треком: це безпосередньо впливає на те, які завдання варто пріоритезувати.

Як використати критерії для пріоритезації завдань

Критерії оцінювання — це готовий фреймворк для планування. Замість того щоб робити «все потроху», розподіліть завдання за впливом на фінальний бал:

  1. Перший пріоритет — робочий core на devnet. Без цього технічний бал близький до нуля. Розгорніть програму, переконайтеся, що ключова транзакція проходить.
  2. Другий пріоритет — demo-відео з повним юзкейсом. Запишіть скрінкаст щойно основний потік працює. Навіть якщо далі щось зламається, у вас є зафіксований робочий стан.
  3. Третій пріоритет — інтеграція з треком спонсора. Якщо ви подаєтеся на конкретний трек, переконайтеся, що використання протоколу спонсора очевидне з першого погляду на код чи інтерфейс.
  4. Четвертий пріоритет — поліпшення UX та оформлення README. Це дає приріст балів, але не компенсує відсутність робочого прототипу.

Якщо залишається менше двох годин до дедлайну й ви обираєте між «додати ще одну фічу» та «записати demo та дописати README» — завжди обирайте друге.

Наступний крок: підготовка подання

Коли проєкт відповідає критеріям, наступне завдання — правильно оформити submission. Перейдіть до матеріалу про підготовку подання на Solana-хакатоні, де розібрано структуру форми, вимоги до demo-відео та типові помилки в останні години перед дедлайном.

Джерела