Перейти к основному контенту

Хакатоны Web3: как всё сделать правильно. Прагматичное руководство на 2025 год

· 11 мин чтения
Dora Noda
Dora Noda
Software Engineer

Краткое содержание​

  • Выбирайте мероприятия осознанно. Отдавайте предпочтение экосистемам, в которых вы уже работаете, или тем, где судьи и спонсоры идеально соответствуют вашей идее.
  • Определите условие победы. Вы здесь ради обучения, конкретного вознаграждения (баунти) или места в финале? Каждый выбор меняет состав команды, масштаб проекта и технологический стек.
  • Подготовьте рутину заранее. Еще до начала отсчета времени у вас должны быть готовы шаблоны проектов, процессы аутентификации, подключения кошельков, дизайн-система и набросок сценария демо-версии.
  • Создайте минимально жизнеспособное демо (lovable demo). Покажите один цикл ключевой функции, работающий от начала до конца. Все остальное — это просто рассказ и слайды.
  • Подавайте работу как профессионал. Соблюдайте правила «чистого старта», официально регистрируйтесь на каждое направление баунти, на которое претендуете, и оставьте достаточно времени на качественное видео и понятный README.

Почему хакатоны Web3 стоят ваших выходных​

  • Сжатое обучение: Всего за один уикенд вы соприкоснетесь с инфраструктурой, смарт-контрактами, UX фронтенда и пайплайнами развертывания. Это полный цикл разработки за 48 часов — кривая обучения, которая в обычном темпе заняла бы месяцы.
  • Нетворкинг высокого качества: Менторы, судьи и инженеры спонсоров — это не просто имена на сайте; они собраны в одном зале или Discord-сервере и готовы дать обратную связь. Это ваш шанс пообщаться с основными разработчиками протоколов, которые вы используете каждый день.
  • Реальные пути финансирования: Это не только ради престижа. Призовые фонды и последующие гранты могут обеспечить значительный капитал для продолжения проекта. Мероприятия уровня Solana Summer Camp предлагали до 5 миллионов долларов в виде призов и посевного финансирования, превращая проекты выходного дня в жизнеспособные стартапы.
  • Портфолио доказательств: Публичный репозиторий на GitHub с функциональным демо бесконечно ценнее, чем строчка в резюме. Это осязаемое доказательство того, что вы можете создавать, выпускать и аргументированно представлять идею под давлением.

Где найти достойные мероприятия​

  • ETHGlobal: Золотой стандарт как для очных, так и для асинхронных мероприятий. Они отличаются надежными процессами судейства, высококлассными участниками и публичными витринами проектов, которые идеально подходят для вдохновения.
  • Devpost: Широкая площадка для всевозможных хакатонов с удобными фильтрами по блокчейну, конкретным протоколам и призовым категориям. Отличное место для поиска мероприятий конкретных экосистем.
  • DoraHacks: Платформа, ориентированная на экосистемные хакатоны Web3 и раунды грантов, часто с глобальным охватом и упором на сообщество.

Совет: Продолжительность сильно варьируется. Длительное асинхронное мероприятие, такое как ETHOnline, длится несколько недель, в то время как расширенный очный спринт, например #BUIDLathon на ETHDenver, может длиться до девяти дней. Вы должны соответствующим образом планировать масштаб своего проекта.

Разбираемся в правилах (чтобы не вылететь)​

  • «Начинайте с нуля» (Start Fresh). Это самое распространенное и критически важное правило. Большинство мероприятий требуют, чтобы вся основная работа начиналась после официального старта. Использование старого, заранее написанного кода для основной логики может привести к дисквалификации из финала и лишению призов от партнеров. Шаблонный код (boilerplate), как правило, разрешен, но «секретный соус» должен быть новым.
  • Структура судейства. Поймите, как работает воронка. Часто асинхронный отборочный тур сужает сотни проектов до пула финалистов еще до начала живого судейства. Понимание этого поможет вам сосредоточиться на том, чтобы сделать видео и README максимально понятными для первого этапа отбора.
  • Размер команды. Не приходите командой из десяти человек. На многих мероприятиях установлены лимиты, например, команды из 2–4 человек, как на ETHDenver. Это обеспечивает равные условия игры и стимулирует тесное взаимодействие.
  • Механика баунти. Вы не можете выиграть приз, на который не зарегистрировались. Если вы нацелены на баунти от спонсоров, зачастую вы должны официально заявить свой проект в каждой конкретной категории через платформу мероприятия. Это простой шаг, о котором многие команды забывают.

Критерии оценки: что такое «хорошо»​

У большинства организаторов судьи обычно оценивают проекты по четырем повторяющимся категориям. Спланируйте свой проект и демо так, чтобы набрать баллы в каждой из них.

  • Техническая сложность: Является ли проблема нетривиальной? Включает ли решение грамотное или элегантное использование технологий? Вышли ли вы за рамки простой фронтенд-оболочки для одного смарт-контракта?
  • Оригинальность: Есть ли в проекте новый механизм, уникальный пользовательский опыт или интересная комбинация существующих примитивов? Видели ли мы это сотни раз до этого или это свежий взгляд?
  • Практичность: Может ли кто-то использовать это сегодня? Полный пользовательский путь, пусть и в узкой области, значит гораздо больше, чем проект с широким, но недоделанным функционалом.
  • Удобство использования (UI / UX / DX): Является ли интерфейс понятным, быстрым и приятным? Если это инструменты для разработчиков, насколько хорош опыт взаимодействия (DX)? Плавный онбординг и понятная обработка ошибок помогут вам выделиться.

Дизайн команды: небольшая, эффективная, взаимодополняющая​

Для скорости и слаженности команда из двух-четырех человек — это золотая середина. Этого достаточно для параллельного выполнения задач, но при этом команда остается достаточно маленькой, чтобы принимать решения без бесконечных споров.

  • Смарт-контракты / протокол: отвечает за ончейн-логику. Ответственный за написание, тестирование и развертывание контрактов.
  • Фронтенд / DX: создает пользовательский интерфейс. Управляет подключениями кошельков, получением данных, обработкой ошибок и финальной полировкой демо, которая делает проект реальным.
  • Продукт / история: хранитель скоупа и рассказчик. Этот человек следит за тем, чтобы команда была сфокусирована на основном цикле (core loop), пишет описание проекта и проводит финальное демо.
  • (Опционально) Дизайнер: выделенный дизайнер может стать секретным оружием, подготавливая компоненты, иконки и микро-взаимодействия, которые повышают воспринимаемое качество проекта.

Выбор идеи: фильтр P-A-C-E​

Используйте этот простой фильтр для стресс-теста ваших идей, прежде чем написать хотя бы одну строку кода.

  • Pain (Боль): решает ли это реальную проблему разработчика или пользователя? Подумайте о UX кошельков, индексации данных, защите от MEV или абстракции комиссий. Избегайте решений, которые ищут проблему.
  • Atomicity (Атомарность): можете ли вы собрать и продемонстрировать один атомарный цикл от начала до конца за 48 часов? Не все видение целиком — только одно завершенное, приносящее результат действие пользователя.
  • Composable (Композируемость): опирается ли ваша идея на существующие примитивы, такие как оракулы, абстракция аккаунтов или кроссчейн-сообщения? Использование проверенных временем «лего-блоков» помогает продвинуться дальше и быстрее.
  • Ecosystem fit (Соответствие экосистеме): заметен ли ваш проект и актуален ли он для судей, спонсоров и аудитории мероприятия? Не предлагайте сложный DeFi-протокол на треке, ориентированном на игры.

Если вы ориентированы на баунти, выберите один основной и один второстепенный спонсорский трек. Распыление внимания на слишком большое количество баунти снижает глубину проработки и ваши шансы на победу в любом из них.

Стандартные стеки, которые не мешают работе​

Ваша новизна должна заключаться в том, что вы строите, а не в том, как вы это делаете. Придерживайтесь скучных, надежных технологий.

EVM трек (быстрый путь)

  • Контракты: Foundry (за его скорость в тестировании, написании скриптов и запуске локального узла).
  • Фронтенд: Next.js или Vite в сочетании с wagmi или viem и набором для кошельков (wallet kit), таким как RainbowKit или ConnectKit для модальных окон и коннекторов.
  • Данные / индексация: хостинг-сервис индексатора или сабграфа, если вам нужно запрашивать исторические данные. Избегайте запуска собственной инфраструктуры.
  • Офчейн-триггеры: простой раннер задач или специальный сервис автоматизации.
  • Хранение: IPFS или Filecoin для активов и метаданных; простое KV-хранилище для состояния сессий.

Solana трек (быстрый путь)

  • Программы: Anchor (чтобы сократить объем шаблонного кода и использовать более безопасные настройки по умолчанию).
  • Клиент: React или мобильный фреймворк с Solana Mobile SDK. Используйте простые хуки для RPC и вызовов программ.
  • Данные: полагайтесь на прямые вызовы RPC или экосистемные индексаторы. Агрессивно кэшируйте данные, чтобы интерфейс работал быстро.
  • Хранение: Arweave или IPFS для постоянного хранения активов, если это необходимо.

Реалистичный 48-часовой план​

От T-24 до T-0 (до старта)

  • Определите ваше условие победы (обучение, баунти, финал) и целевой трек(и).
  • Набросайте полный цикл демо на бумаге или доске. Точно знайте, куда вы нажмете и что должно произойти ончейн и офчейн на каждом шаге.
  • Сделайте форк чистого монорепозитория, который включает шаблоны (boilerplate) как для контрактов, так и для фронтенд-приложения.
  • Заранее напишите план README и черновик сценария для демо.

Часы 0–6

  • Подтвердите ваш скоуп с менторами и спонсорами мероприятия. Уточните критерии баунти и убедитесь, что ваша идея подходит.
  • Установите жесткие ограничения: одна сеть, один основной кейс использования и один «wow-момент» для демо.
  • Разделите работу на 90-минутные спринты. Ваша цель — выпустить первый полный вертикальный срез вашего основного цикла к 6-му часу.

Часы 6–24

  • Укрепите критический путь. Протестируйте как основной сценарий (happy path), так и типичные пограничные случаи.
  • Добавьте наблюдаемость (observability). Внедрите базовые логи, уведомления в интерфейсе (toasts) и границы ошибок (error boundaries), чтобы вы могли быстро проводить отладку.
  • Создайте минимальный лендинг, который четко объясняет «почему» стоит за вашим проектом.

Часы 24–40

  • Запишите запасное демо-видео, как только основной функционал станет стабильным. Не ждите до последнего момента.
  • Начните писать и редактировать финальный текст заявки, видео и README.
  • Если позволяет время, добавьте пару продуманных деталей, таких как качественные состояния для пустых списков, транзакция без газа или полезный фрагмент кода в документации.

Часы 40–48

  • Заморозка всех функций. Больше никакого нового кода.
  • Завершите работу над видео и пакетом для подачи. Опытные победители часто рекомендуют оставлять около 15% общего времени на полировку и создание видео с четким разделением 60/40 между объяснением проблемы и демонстрацией решения.

Демо и подача: облегчите задачу судьям​

  • Начните с «почему». Начните ваше видео и README с одного предложения, объясняющего проблему и результат вашего решения.
  • Проживите цикл. Показывайте, а не просто рассказывайте. Пройдите через один правдоподобный путь пользователя от начала до конца, не пропуская шаги.
  • Озвучьте ваши ограничения. Признайте, что вы не построили и почему. Фраза: «Мы ограничили скоуп одним вариантом использования, чтобы гарантировать, что реальные пользователи могут пройти весь путь уже сегодня», демонстрирует фокус и зрелость.
  • Оставьте четкие маркеры. В вашем README должна быть диаграмма архитектуры, ссылки на живое демо и развернутые контракты, а также простые шаги в один клик для локального запуска проекта.
  • Основы видео. Планируйте видео заранее, пишите сценарий кратко и убедитесь, что оно четко подчеркивает, что делает проект, какую проблему решает и как он работает «под капотом».

Баунти без выгорания​

  • Регистрируйтесь на каждый приз, на который вы претендуете. На некоторых платформах это требует явного нажатия кнопки «Start Work».
  • Не гонитесь более чем за двумя спонсорскими баунти, если их технологии не пересекаются естественным образом в вашем стеке.
  • В своей заявке соответствуйте их критериям. Используйте их ключевые слова, ссылайтесь на их API по названию и объясните, как вы достигли их конкретных показателей успеха.

После хакатона: превратите импульс в развитие​

  • Опубликуйте короткий пост в блоге и тред в социальных сетях со ссылкой на демо и репозиторий GitHub. Отметьте мероприятие и спонсоров.
  • Подавайте заявки на гранты и акселераторы, специально разработанные для выпускников хакатонов и open-source проектов на ранней стадии.
  • Если проект получил хороший отклик, создайте простой план (roadmap) на одну неделю, сфокусированный на исправлении багов, доработке UX и небольшом пилотном запуске с несколькими пользователями. Установите жесткую дату выпуска v0.1, чтобы сохранить темп.

Распространенные ошибки (и способы их решения)​

  • Нарушение правил «разработки с нуля». Решение: Оставьте любой предыдущий код полностью за рамками проекта или явно объявите его как уже существующую библиотеку, которую вы используете.
  • Слишком широкий охват (over-scoping). Решение: Если ваше запланированное демо состоит из трех основных шагов, уберите один. Будьте беспощадны, фокусируясь на основном цикле (core loop).
  • Слишком ранний переход на мультичейн. Решение: Идеально запуститесь в одной сети. Расскажите о своих планах по мостам и кроссчейн-поддержке в разделе «Что дальше» (What's next) вашего README.
  • «Налог» на полировку в последнюю минуту. Решение: Заранее выделите 4–6-часовой блок в конце хакатона исключительно для README, видео и формы подачи заявки.
  • Забыли записаться на баунти. Решение: Сделайте это одним из первых дел после старта. Регистрируйтесь на все потенциальные призы, чтобы спонсоры могли найти и поддержать вашу команду.

Чек-листы, которые можно скопировать​

Пакет для подачи заявки

  • Репозиторий (лицензия MIT/Apache-2.0), краткий README и шаги для локального запуска
  • Короткое демо-видео Loom/MP4 + резервная запись
  • Простая диаграмма архитектуры (один слайд или изображение)
  • One-pager: проблема → решение → кому это важно → что дальше
  • Ссылки: работающий фронтенд, адреса контрактов в блокчейн-эксплорере

Список вещей для офлайн-мероприятия (IRL)

  • Удлинитель и сетевой фильтр
  • Наушники и приличный микрофон
  • Переходники для дисплея HDMI/USB-C
  • Многоразовая бутылка для воды и электролиты
  • Ваша любимая удобная клавиатура/мышь (если вы требовательны)

Проверка соблюдения правил

  • Политика «разработки с нуля» изучена и соблюдена
  • Размер команды находится в рамках события (если применимо)
  • Порядок судейства (асинхронный или в реальном времени) отмечен
  • Все целевые баунти официально зарегистрированы («Start Work» или эквивалент)

Полезные ссылки для вашего следующего хакатона​

  • Поиск мероприятий: Следите за календарем событий ETHGlobal, блокчейн-хабом Devpost и DoraHacks для участия в будущих соревнованиях.
  • Вдохновение: Просмотрите ETHGlobal Showcase, чтобы увидеть победные демо и изучить их код.
  • EVM-шаблоны: Ознакомьтесь с документацией Foundry и руководствами по быстрому старту.
  • Solana-шаблоны: Посмотрите документацию Anchor и его руководство по основам.
  • Советы по видео: Ищите руководства о том, как создать четкое и убедительное демо-видео.

Заключительное примечание​

Хакатоны вознаграждают ясность в условиях ограничений. Выберите узкую проблему, опирайтесь на проверенные инструменты и сосредоточьтесь на создании одного восхитительного, завершенного момента. Сделайте это, и вы узнаете очень много — даже если вашего имени на этот раз не окажется на слайде победителей. А если окажется, вы это заслужите.

Share on Twitter