Saltar para o conteúdo principal

Hackathons Web3 Bem Feitos: Um Guia Prático para 2025

· 13 min de leitura
Dora Noda
Dora Noda
Software Engineer

TL;DR​

  • Escolha eventos intencionalmente. Dê preferência a ecossistemas onde você já desenvolve — ou àqueles com juízes e patrocinadores que estejam perfeitamente alinhados com sua ideia.
  • Decida sua condição de vitória. Você está lá para aprender, por uma recompensa (bounty) específica ou por uma vaga de finalista? Cada escolha muda sua equipe, o escopo e a tecnologia utilizada (stack).
  • Prepare as coisas chatas com antecedência. Tenha as estruturas do seu projeto (scaffolds), fluxos de autenticação, conexões de carteira, sistema de design e um rascunho do roteiro da demo prontos antes que o cronômetro comece a rodar.
  • Construa a menor demo encantadora possível. Mostre um ciclo de funcionalidade matadora funcionando de ponta a ponta. Todo o resto é apenas narrativa e slides.
  • Envie como um profissional. Respeite as regras de “começar do zero”, registre-se formalmente para cada trilha de recompensa que você almeja e reserve um tempo significativo para um vídeo conciso e um README claro.

Por que hackathons web3 valem o seu fim de semana​

  • Aprendizado comprimido: Em um único fim de semana, você terá contato com infraestrutura, contratos inteligentes (smart contracts), UX de front-end e pipelines de implantação. É um ciclo completo de desenvolvimento em 48 horas — uma curva de aprendizado que normalmente levaria meses.
  • Networking de alto sinal: Os mentores, juízes e engenheiros patrocinadores não são apenas nomes em um site; eles estão concentrados em uma sala ou servidor no Discord, prontos para dar feedback. Esta é a sua chance de se conectar com os desenvolvedores principais dos protocolos que você usa todos os dias.
  • Caminhos reais de financiamento: Isso não é apenas para ganhar prestígio. Os prêmios (prize pools) e subsídios subsequentes (grants) podem fornecer capital significativo para manter um projeto funcionando. Eventos como o Summer Camp da Solana ofereceram até $ 5M em prêmios e financiamento inicial, transformando projetos de fim de semana em startups viáveis.
  • Um portfólio de prova: Um repositório público no GitHub com uma demo funcional é infinitamente mais valioso do que um item em um currículo. É uma prova tangível de que você consegue construir, entregar e articular uma ideia sob pressão.

Onde encontrar os bons​

  • ETHGlobal: O padrão ouro para eventos presenciais e assíncronos. Eles apresentam processos de julgamento robustos, participantes de alta qualidade e vitrines de projetos públicos que são perfeitas para inspiração.
  • Devpost: Um mercado amplo para todos os tipos de hackathons, com filtros fortes para blockchain, protocolos específicos e trilhas de prêmios. É um ótimo lugar para descobrir eventos específicos de ecossistemas.
  • DoraHacks: Uma plataforma focada em hackathons web3 impulsionados por ecossistemas e rodadas de subsídios, muitas vezes com uma atmosfera global e centrada na comunidade.

Dica: As durações variam muito. Um evento assíncrono de formato longo como o ETHOnline dura várias semanas, enquanto um sprint presencial estendido como o #BUIDLathon da ETHDenver pode durar até nove dias. Você deve planejar o escopo do seu projeto adequadamente.

Decifre as regras (para não ser desclassificado)​

  • “Começar do Zero” (Start Fresh). Esta é a regra mais comum e crítica. A maioria dos eventos exige que todo o trabalho substancial comece após o início oficial. Usar código antigo e pré-escrito para a lógica principal pode fazer com que você seja desclassificado das finais e dos prêmios de parceiros. Boilerplates geralmente são permitidos, mas o diferencial principal deve ser novo.
  • Estrutura de julgamento. Entenda o funil. Frequentemente, uma rodada de triagem assíncrona reduz centenas de projetos a um grupo de finalistas antes do início do julgamento ao vivo. Saber disso ajuda você a se concentrar em tornar seu vídeo de envio e seu README o mais claros possível para esse primeiro corte.
  • Tamanho da equipe. Não apareça com uma equipe de dez pessoas. Muitos eventos estabelecem limites, como as típicas equipes de 2 – 4 pessoas vistas no ETHDenver. Isso garante condições de igualdade e incentiva uma colaboração estreita.
  • Mecânica de recompensas (Bounties). Você não pode ganhar um prêmio para o qual não se inscreveu. Se você está visando recompensas de patrocinadores, muitas vezes deve inscrever formalmente seu projeto para cada prêmio específico através da plataforma do evento. Este é um passo simples que muitas equipes esquecem.

Critérios de avaliação: o que é considerado “bom”​

Entre os principais organizadores, os juízes geralmente avaliam os projetos em quatro categorias recorrentes. Planeje seu escopo e demo para marcar pontos em cada uma delas.

  • Tecnicidade: O problema é complexo? A solução envolve um uso inteligente ou elegante da tecnologia? Você foi além de um simples wrapper de front-end em um único contrato inteligente?
  • Originalidade: Existe um mecanismo inovador, uma experiência de usuário única ou um remix inteligente de primitivas existentes? Já vimos isso centenas de vezes antes ou apresenta uma abordagem nova?
  • Praticidade: Alguém pode usar isso hoje? Uma jornada de usuário completa e de ponta a ponta, mesmo que restrita, importa muito mais do que um projeto com recursos amplos, mas inacabados.
  • Usabilidade (UI / UX / DX): A interface é clara, rápida e agradável de usar? Para ferramentas de desenvolvedor, quão boa é a experiência do desenvolvedor (DX)? Uma integração (onboarding) suave e um tratamento de erros claro podem destacar você.

Design de equipe: pequena, ágil, complementar​

Para velocidade e alinhamento, uma equipe de duas a quatro pessoas é o ponto ideal. É grande o suficiente para paralelizar o trabalho, mas pequena o suficiente para tomar decisões sem debates intermináveis.

  • Contratos inteligentes / protocolo: Responsável pela lógica on-chain. Encarregado de escrever, testar e implantar os contratos.
  • Front-end / DX: Constrói a interface do usuário. Gerencia conexões de carteira, busca de dados, estados de erro e o polimento final da demo que faz o projeto parecer real.
  • Produto / história: O guardião do escopo e narrador. Esta pessoa garante que a equipe mantenha o foco no fluxo principal (core loop), escreve a descrição do projeto e conduz a demonstração final.
  • (Opcional) Designer: Um designer dedicado pode ser uma arma secreta, preparando componentes, ícones e micro-interações que elevam a qualidade percebida do projeto.

Seleção de ideias: o filtro P-A-C-E​

Use este filtro simples para testar o estresse de suas ideias antes de escrever uma única linha de código.

  • Pain (Dor): Isso resolve uma dor real do desenvolvedor ou do usuário? Pense em UX de carteira, indexação de dados, proteção MEV ou abstração de taxas. Evite soluções à procura de um problema.
  • Atomicity (Atomicidade): Você consegue construir e demonstrar um único fluxo atômico de ponta a ponta em 48 horas? Não a visão completa — apenas uma ação do usuário completa e satisfatória.
  • Composable (Composível): Sua ideia se apoia em primitivas existentes como oráculos, abstração de conta ou mensagens cross-chain? Usar blocos de lego testados em batalha ajuda você a ir mais longe, mais rápido.
  • Ecosystem fit (Ajuste ao ecossistema): Seu projeto é visível e relevante para os juízes, patrocinadores e público do evento? Não apresente um protocolo DeFi complexo em uma trilha focada em jogos.

Se você for movido por recompensas (bounties), escolha uma trilha principal e uma secundária de patrocinadores. Dispersar seu foco em muitos bounties dilui sua profundidade e as chances de ganhar qualquer um deles.

Stacks padrão que causam menos atrito​

Sua inovação deve estar no o quê você constrói, não em como você constrói. Atenha-se a tecnologias confiáveis e consolidadas.

Trilha EVM (caminho rápido)

  • Contratos: Foundry (pela sua velocidade em testes, scripts e execução de um nó local).
  • Front-end: Next.js ou Vite, combinados com wagmi ou viem e um kit de carteira como RainbowKit ou ConnectKit para modais e conectores.
  • Dados/indexação: Um indexador hospedado ou serviço de subgraph se você precisar consultar dados históricos. Evite rodar sua própria infraestrutura.
  • Gatilhos off-chain: Um executor de tarefas simples ou um serviço de automação dedicado.
  • Armazenamento: IPFS ou Filecoin para ativos e metadados; um armazenamento KV simples para o estado da sessão.

Trilha Solana (caminho rápido)

  • Programas: Anchor (para reduzir o boilerplate e se beneficiar de padrões mais seguros).
  • Cliente: React ou um framework mobile com os SDKs Mobile da Solana. Use hooks simples para chamadas RPC e de programas.
  • Dados: Dependa de chamadas RPC diretas ou indexadores do ecossistema. Use cache de forma agressiva para manter a interface ágil.
  • Armazenamento: Arweave ou IPFS para armazenamento permanente de ativos, se relevante.

Um plano realista de 48 horas​

T-24 a T-0 (antes do início)

  • Alinhe sua condição de vitória (aprendizado, bounty, finais) e a(s) trilha(s) alvo.
  • Esboce o fluxo completo da demo no papel ou em um quadro branco. Saiba exatamente onde clicará e o que deve acontecer on-chain e off-chain em cada etapa.
  • Faça um fork de um scaffold de monorepo limpo que inclua o boilerplate tanto para seus contratos quanto para seu aplicativo front-end.
  • Escreva previamente o esboço do seu README e um rascunho do roteiro da sua demo.

Hora 0–6

  • Valide seu escopo com mentores e patrocinadores do evento. Confirme os critérios do bounty e garanta que sua ideia se encaixe bem.
  • Defina restrições rígidas: uma rede, um caso de uso principal e um momento "uau" para a demo.
  • Divida o trabalho em sprints de 90 minutos. Seu objetivo é entregar a primeira fatia vertical completa do seu fluxo principal até a Hora 6.

Hora 6–24

  • Fortaleça o caminho crítico. Teste tanto o caminho feliz quanto os casos de borda comuns.
  • Adicione observabilidade. Implemente logs básicos, toasts de interface e limites de erro (error boundaries) para que possa depurar rapidamente.
  • Crie uma landing page minimalista que explique claramente o "porquê" por trás do seu projeto.

Hora 24–40

  • Grave um vídeo de demonstração de backup assim que a funcionalidade principal estiver estável. Não espere até o último minuto.
  • Comece a escrever e editar o texto final da sua submissão, vídeo e README.
  • Se o tempo permitir, adicione um ou dois detalhes cuidadosos, como ótimos estados vazios, uma transação sem gás (gasless) ou um trecho de código útil em sua documentação.

Hora 40–48

  • Congele todas as funcionalidades. Sem novos códigos.
  • Finalize seu vídeo e pacote de submissão. Vencedores experientes costumam recomendar reservar ~15% do seu tempo total para polimento e criar um vídeo com uma divisão clara de 60/40 entre explicar o problema e demonstrar a solução.

Demonstração e submissão: facilite o trabalho dos juízes​

  • Abra com o "porquê". Comece seu vídeo e README com uma única frase explicando o problema e o resultado da sua solução.
  • Viva o fluxo. Mostre, não apenas fale. Percorra uma jornada de usuário única e plausível do início ao fim, sem pular etapas.
  • Narre suas restrições. Reconheça o que você não construiu e o porquê. Dizer: “Limitamos o escopo a um único caso de uso para garantir que usuários reais possam concluir o fluxo hoje”, demonstra foco e maturidade.
  • Deixe marcadores claros. Seu README deve ter um diagrama de arquitetura, links para sua demo ao vivo e contratos implantados, e etapas simples de um clique para executar o projeto localmente.
  • Básico do vídeo. Planeje seu vídeo cedo, escreva um roteiro conciso e garanta que ele destaque claramente o que o projeto faz, qual problema resolve e como funciona nos bastidores.

Bounties sem burnout​

  • Registre-se para cada prêmio que você almeja. Em algumas plataformas, isso envolve um clique explícito no botão “Start Work” (Iniciar Trabalho).
  • Não persiga mais do que dois bounties de patrocinadores, a menos que as tecnologias deles se sobreponham naturalmente em sua stack.
  • Em sua submissão, espelhe a rubrica deles. Use as palavras-chave deles, mencione suas APIs pelo nome e explique como você atendeu aos critérios de sucesso específicos.

Após o hackathon: transforme o ímpeto em tração​

  • Publique um post curto em um blog e uma thread nas redes sociais com o link da sua demonstração e o repositório no GitHub. Marque o evento e os patrocinadores.
  • Inscreva-se em programas de grants e rodadas de aceleração que são especificamente projetados para ex-participantes de hackathons e projetos de código aberto em estágio inicial.
  • Se a recepção for forte, crie um roteiro (roadmap) simples de uma semana focado em correções de bugs, uma revisão de UX e um pequeno piloto com alguns usuários. Defina uma data fixa para o lançamento da v0.1 para manter o ímpeto.

Armadilhas comuns (e a solução)​

  • Violar as regras de “começar do zero”. A solução: Mantenha qualquer código anterior completamente fora do escopo ou declare-o explicitamente como uma biblioteca pré-existente que você está usando.
  • Escopo excessivo. A solução: Se a sua demo planejada tem três etapas principais, corte uma. Seja implacável ao focar no loop principal.
  • Tornar-se multi-chain cedo demais. A solução: Entregue em uma única chain perfeitamente. Fale sobre seus planos para pontes (bridges) e suporte cross-chain na seção "O que vem a seguir" do seu README.
  • A taxa de polimento de última hora. A solução: Reserve um bloco de 4 a 6 horas no final do hackathon exclusivamente para o seu README, vídeo e formulário de submissão.
  • Esquecer de se inscrever nos bounties. A solução: Torne isso uma das primeiras coisas que você fará após o início. Registre-se para cada prêmio potencial para que os patrocinadores possam encontrar e apoiar sua equipe.

Checklists que você pode copiar​

Pacote de submissão

  • Repositório (licença MIT/Apache-2.0), README conciso e etapas para execução local
  • Vídeo de demonstração curto (Loom/MP4) + uma gravação de backup
  • Diagrama de arquitetura simples (um slide ou imagem)
  • One-pager: problema → solução → quem se importa → o que vem a seguir
  • Links: frontend ao vivo, endereços de contratos em um explorador de blocos

Lista de itens para levar (IRL)

  • Cabo de extensão e filtro de linha
  • Fones de ouvido e um microfone decente
  • Adaptadores de vídeo HDMI/USB-C
  • Garrafa de água reutilizável e eletrólitos
  • Seu teclado/mouse confortável favorito (se você for exigente)

Verificação de sanidade das regras

  • Política de "começar do zero" compreendida e seguida
  • O tamanho da equipe está dentro dos limites do evento (se aplicável)
  • O fluxo de julgamento (assíncrono vs. ao vivo) foi anotado
  • Todos os bounties pretendidos estão formalmente registrados (“Start Work” ou equivalente)
  • Encontre eventos: Confira o calendário de eventos da ETHGlobal, o hub de blockchain do Devpost e o DoraHacks para as próximas competições.
  • Inspire-se: Navegue pelo ETHGlobal Showcase para ver demonstrações vencedoras e explorar o código delas.
  • Scaffolding EVM: Revise a documentação do Foundry e os guias de início rápido.
  • Scaffolding Solana: Veja a documentação do Anchor e seu guia de “conceitos básicos”.
  • Dicas de vídeo: Procure guias sobre como criar um vídeo de demonstração nítido e convincente.

Nota final​

Hackathons premiam a clareza sob restrição. Escolha um problema específico, utilize ferramentas consolidadas e foque obsessivamente em criar um momento excepcional de ponta a ponta. Faça isso e você aprenderá muito — mesmo que seu nome não esteja no slide dos vencedores desta vez. E se estiver, você terá merecido.

Share on Twitter