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

Яка інформація обов'язкова в описі

Кожна платформа для подачі має свої поля, але змістовий мінімум універсальний. Перевірте, чи ваш опис містить усі п'ять елементів:

  • Назва проєкту та одне речення-питашка (pitch sentence). Не «інноваційна DeFi-платформа», а «Протокол для автоматичного ребалансування портфеля RWA-активів на Solana, який зменшує сліпідж до 0,3%».
  • Проблема. Хто страждає від цієї проблеми, як часто вона виникає, чому існуючі рішення не працюють. Конкретика: не «транзакції дорогі», а «користувачі платять від 0,5 до 2 USD за своп у пулі з низькою ліквідністю під час волатильності».
  • Рішення. Як саме ваш проєкт усуває проблему. Один-два абзаци без маркетингових прикметників.
  • Технічна реалізація. Що саме розгорнуто на Devnet: смарт-контракти на Anchor, інтеграція з яким RPC, які PDA (Program Derived Address — похідні адреси програми) використовуються, чи є CPI (Cross-Program Invocation — міжпрограмні виклики).
  • Що зроблено за час хакатону. Чіткий перелік: «написано 3 смарт-контракти, розгорнуто фронтенд на Vercel, проведено 12 тестових транзакцій на Devnet». Журі має бачити межу між тим, що існувало до хакатону, і тим, що створено під час нього.

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

Як стисло пояснити технічну складову для журі

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

Працює така формула: архітектура + стек + ключове рішення + статус розгортання.

Приклад технічного абзацу:

«Смарт-контракти написані на Anchor (версія 0.29). Основна програма керує станом пулу через PDA-акаунти, які deriv-яться від сиду користувача та ідентифікатора пулу. Для оновлення цін використовується Switchboard Oracle через CPI. Фронтенд підключається до публічного RPC Helius. Усе розгорнуто на Devnet, адреса програми: [ваш адрес]. Транзакції проходять валідацію у Solana CLI».

Що тут зроблено правильно:

  • Вказано версію Anchor — це важливо, оскільки міграції між версіями ломають сумісність.
  • Пояснено, навіщо використовуються PDA, а не просто згадано термін.
  • Зрозуміло, звідки беруться дані (Switchboard) і як вони потрапляють у програму (CPI).
  • Вказано конкретний RPC-провайдер — це показує, що ви стикалися з реальними обмеженнями rate limits.
  • Є адреса програми на Devnet — журі може перевірити.

Чого уникати: перелікувати всі залежності з package.json, описувати UI-компоненти фронтенду або пояснювати, що таке блокчейн. Якщо використовуєте нестандартний підхід — наприклад, кастомні інструкції без Anchor або власний парсер транзакцій для MEV — це варто виділити окремим реченням, бо саме тут журі побачить інженерну глибину.

Як показати унікальність проєкту в кількох реченнях

Унікальність не означає «ми перші у світі». У хакатоні достатньо показати, що ви вирішили проблему інакше, ніж інші учасники, або застосували механіку, яку ніхто інший у цьому треку не використав.

Три робочі стратегії для кількох речень:

  1. Контраст із існуючим. «На відміну від стандартних AMM, де ціна визначається виключно співвідношенням резервів, ми використовуємо зовнішній оракул для прив'язки до ринкової ціни, що усуває тимчасову втрату коштів (impermanent loss) для провайдерів ліквідності».
  2. Несподіване поєднання. «Ми поєднали on-chain голосування з NFT-репутацією: вага голосу користувача залежить не від кількості токенів, а від історії його участі в DAO, зафіксованої у метаданих NFT».
  3. Обмеження, перетворене на перевагу. «Замість того, щоб боротися з обмеженням розміру транзакції на Solana (1232 байти), ми розбили логіку на ланцюжок інструкцій, де кожна змінює стан частково. Це дозволило реалізувати складну логіку розподілу без компресії даних».

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

Приклади сильних описів переможців

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

Приклад 1: DeFi-протокол (фокус на технічне рішення)

PoolSplitter — протокол автоматичного розподілу ліквідності між кількома DEX на Solana.

Проблема: провайдери ліквідності змушені вручну розподіляти кошти між Raydium, Orca та Meteora, втрачаючи прибуток через затримки.

Рішення: смарт-контракт на Anchor приймає депозит, аналізує поточні ставки через on-chain дані та розподіляє кошти пропорційно. Перебалансування відбувається кожні 15 хвилин через Cron.

Техніка: Anchor 0.29, три програми (vault, router, oracle), PDA для кожного пулу, CPI до Raydium та Orca SDK. Розгорнуто на Devnet, 8 тестових депозитів пройшли успішно.

Що зроблено за хакатон: усі три програми написані з нуля, фронтенд з графіком розподілу, базові тести на Anchor TS.

Приклад 2: Інфраструктурний інструмент (фокус на нішеву проблему)

TxLens — інструмент для розробників, який візуалізує виконання транзакції крок за кроком і показує, де саме виникає помилка.

Проблема: при дебазі смарт-контрактів на Solana розробник бачить лише фінальний статус транзакції та лог-повідомлення, але не бачить послідовності викликів між програмами.

Рішення: парсер транзакцій, який бере serialized transaction та симулює її виконання локально, відображаючи дерево CPI-викликів із вказанням кожного акаунта, що змінюється.

Техніка: Rust-бібліотека для парсингу, інтеграція з solana-sdk, фронтенд на React з візуалізацією графа. Працює локально без RPC.

Що зроблено за хакатон: парсер для базових транзакцій (transfer, invoke), візуалізація дерева викликів, обробка 5 типів помилок.

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

Наступний крок: фінальна перевірка submission

Коли опис написаний, не відправляйте його одразу. Проведіть фінальну перевірку за чотирма пунктами:

  1. Читабельність. Прочитайте опис вголос. Якщо речення довше трьох рядків — розбийте. Якщо є термін, який ви не пояснили і який не входить до базового словника Solana — додайте пояснення в дужках або замініть.
  2. Відповідність критеріям. Відкрийте сторінку хакатону й перевірте, чи ваш опис відповідає кожному пункту оцінювання. Якщо в критеріях є «вплив на екосистему Solana» — у тексті має бути речення про це.
  3. Перевірність. Чи є в описі адреса програми на Devnet, посилання на репозиторій або відео демо? Журі не шукає ваші лінки — вони мають бути в тексті.
  4. Межа хакатону. Чи чітко вказано, що саме створено за час події? Якщо проєкт існував раніше — виділіть, що додано.

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

Джерела