Призначення чек-листа

Чек-лист призначений для команд, які готують фінальну подачу (submission) на хакатон у екосистемі Solana. Він структурує останні години перед дедлайном: допомагає перевірити технічну працездатність, completeness подачі та відповідність вимогам організаторів. Ресурс не замінює правила конкретного хакатону — він доповнює їх системним контролем.

Етапи підготовки submission

Перевірка функціональності на devnet

  • Розгортання на devnet. Переконайтеся, що смарт-контракти (програми) успішно задеплоєні на devnet і їхні адреси збігаються з тими, що вказані в подачі.
  • Клієнтська частина. Фронтенд підключено до devnet-RPC, а не до mainnet-beta або localhost. Перевірте це в конфігурації змінних середовища.
  • Повний користувацький сценарій. Пройдіть основний флоу від початку до кінця: створення транзакції, підписання, відправка, очікування підтвердження, відображення результату в інтерфейсі.
  • Обробка помилок. Спробуйте навмисно викликати типові помилки (недостатньо SOL для комісії, невірний підпис, timeout RPC) і переконайтеся, що інтерфейс показує зрозуміле повідомлення, а не «undefined error».
  • PDA та CPI. Якщо проєкт використовує PDA (Program Derived Address) або міжпрограмні виклики (CPI), перевірте, що адреси обчислюються коректно саме в devnet-контексті.
  • Тестові кошти. Переконайтеся, що на демо-акаунтах достатньо devnet-SOL для повного проходження сценарію. За потреби поповніть через faucet.

Відеодемо та презентація

  • Тривалість. Перевірте обмеження хакатону: зазвичай це 2–5 хвилин. Не перевищуйте ліміт — жюрі може обрізати відео.
  • Структура відео. Проблема → рішення → демо → технічна архітектура → наступні кроки. Уникайте довгого вступу без контексту.
  • Якість звуку та екрана. Переконайтеся, що голос розбірливий, а елементи інтерфейсу читабельні. Якщо записуєте екран у високій роздільній здатності, перевірте, що текст не зменшився до нерозбірливого розміру після стиснення.
  • Наявність презентації. Якщо хакатон вимагає окремий pitch deck, переконайтеся, що він завантажений у правильному форматі (PDF, не редакційний файл).

Документація та README

  • Інструкція зі встановлення та запуску. Чітко вказані передумови (Node.js, Rust, Anchor, Solana CLI), версії та покрокові команди.
  • Опис архітектури. Коротко пояснено, які програми задіяні, як вони взаємодіють через CPI, які акаунти створюються.
  • Devnet-адреси програм. Вказані конкретні адреси на devnet, щоб жюрі могло перевірити код на ланцюжку.
  • Відомі обмеження. Чесно вкажіть, що не реалізовано та чому. Це краще, ніж жюрі самостійно виявить недоліки.

Детальнішу структуру README дивіться в окремому ресурсі: Шаблон README для хакатонного проєкту.

Форма заявки та дедлайни

  • Часовий пояс. Перевірте, в якому часовому поясі вказано дедлайн, і конвертуйте у свій. Додайте запас мінімум 2–3 години.
  • Обов'язкові поля. Пройдіть форму до кінця без заповнення — так ви побачите всі обов'язкові поля і не здивуєтеся в останню хвилину.
  • Посилання на репозиторій. Переконайтеся, що репозиторій публічний (якщо не обумовлено інше) і жюрі має доступ без запиту на дозвіл.
  • Команда та ролі. Перевірте, що всі учасники додані до команди в платформі хакатону та їхні профілі заповнені.
  • Трек або категорія. Виберіть правильний трек, якщо хакатон пропонує кілька. Неправильний вибір може призвести до дискваліфікації з потрібної категорії.

Фінальна перевірка перед подачею

  1. Відкрийте submission-форму в інкогніто. Перевірте, що всі зовнішні посилання (відео, репозиторій, демо) відкриваються без авторизації.
  2. Запустіть демо на «чистому» пристрої. Ідеально — на комп'ютері колеги, який не брав участі в розробці. Якщо він може пройти флоу без ваших підказок, демо готове.
  3. Перевірте відповідність вимогам треку. Знову відкрийте правила обраного треку і звірте кожен пункт із вашою подачею.
  4. Збережіть скріншот підтвердження. Після натискання «Submit» збережіть скріншот або PDF-підтвердження на випадок технічних збоїв платформи.
  5. Не тисніть «Edit» після дедлайну. Деякі платформи фіксують час останньої зміни. Навіть незначне редагування може перевести submission у статус «пізній».

Обмеження чек-листа

  • Чек-лист узагальнює типові вимоги Solana-хакатонів, але кожен захід має власні правила. Обов'язково звіряйтеся з офіційною сторінкою конкретного хакатону.
  • Ресурс не охоплює юридичні аспекти: інтелектуальну власність, умови розподілу призів, податкові зобов'язання. З цих питань звертайтеся до організаторів або юридичного фахівця.
  • Чек-лист не містить порад щодо вибору ідеї, формування команди або стратегії презентації — для цього призначені інші ресурси.

Версія ресурсу

Ресурс «Робочий чек-лист submission для Solana-хакатону»: статична версія 1.0. Сторінка містить готовий текстовий чек-лист і готова до практичного використання без очікування окремого інтерактивного інструмента. Остання редакційна перевірка: 2 серпня 2026 року.

Джерела