Web3 Hackathon Winning Guide

Synthesized from analysis of 226 real hackathon projects spanning ETHGlobal, DoraHacks, Devpost, Chainlink Hackathon, Colosseum (Solana), and ecosystem-specific events. This guide covers what actually separates winning submissions from the rest.

---

Part 1: Platform Selection

The platform you choose shapes everything: prize structure, judging criteria, sponsor tracks, and the competition level.

Key insight: Sponsor-track prizes at ETHGlobal (e.g., "Best Use of Chainlink CCIP", "Best Use of Safe") are dramatically less competitive than the main prize. Among 226 analyzed projects, the winning pattern is consistent — target 2–3 sponsor prizes and one main track, rather than main track only.

---

Part 2: Team Assembly

Optimal team size: 3 people. Analysis of high-performing projects shows:

• Solo projects can win (tokensubscription.com — ⭐78, WyoHackathon winner) but require a very tight scope
• 2-person teams dominate mid-tier events
• 4-person teams are optimal for multi-track prize targeting
• 5+ people spend too much time on coordination

Role breakdown for 48-hour events:

• 1× Smart contract developer — Solidity/Rust; owns the protocol core
• 1× Full-stack developer — frontend + API integration; owns the demo
• 1× Integrations lead — sponsor SDK integrations + architecture diagram + pitch deck

Finding teammates (pre-event):

• ETHGlobal Discord #team-formation opens 2 weeks before each event
• DoraHacks has a built-in team matching feature
• Post "LFT" on X/Twitter with your tech skills 1 week before

---

Part 3: Project Selection — The Formula That Wins

The Winning Formula

Real problem + Minimal scope + Creative sponsor tech use + Working demo = Prize

Direction Frequency Across 226 Projects

The Scope Rule

Build exactly one user journey, end-to-end. Projects that fail to demo fall into a predictable pattern: overscoped.

Good scope for 48 hours:

• 1 smart contract with 3–5 functions
• Frontend that calls those functions
• 1 integration with a sponsor SDK
• Deployed on testnet (or mainnet for simple contracts)

Examples of winning minimal-scope projects from the dataset:

• anon-aadhaar: One thing — prove you own an Aadhaar ID on-chain using ZK. Nothing else.
• farcaster-frames-onchain-payment: One thing — pay inside a Farcaster Frame. One button.
• zkEmail: One thing — prove you received an email, verified on-chain. That's it.

The "Unfair Advantage" Test

Before committing, answer: Why can only this team build this in this hackathon?

• You know the domain (you have a real pain point)
• Unusual technical combination the judges haven't seen (ZK + gaming, AI + ERC-4337)
• You already have a codebase/prototype to start from

---

Part 4: Execution Template (48 Hours)

Hour-by-Hour Breakdown

Hours 0–4: Alignment

• Lock the idea. Stop debating after hour 2.
• Create shared GitHub repo, assign roles
• Identify 2–3 sponsor tracks you are targeting
• Start the submission form immediately (fill what you can, save as draft)

Hours 4–24: Core Build

• Smart contracts first — they take longest and cannot be faked in a demo
• No premature optimization; get a working deployment on testnet
• Frontend can be rough but must show the main user flow

Hours 24–40: Integration + Demo Prep

• Connect frontend to deployed contracts
• Walk through the main user flow as a real user would
• Record demo video backup (even a screen recording)

Hours 40–48: Polish + Submission

• Fill the submission form completely (video, GitHub, live URL)
• Write README with setup instructions
• Finalize architecture diagram
• Practice the 3-minute pitch

Priority if time runs short: Working demo > README > design > extra features > tests

---

Part 5: What Judges Actually Evaluate

Based on patterns across ETHGlobal, DoraHacks, and Chainlink events, judges weight:

1. Technical innovation (30%) — Did you use the sponsor's tech in an interesting way? Did you build something genuinely new?
2. Working demo (25%) — Does it run? Can they try it? Projects with live demos win over slides-only.
3. Real-world impact (20%) — Would someone actually use this? Is the problem real?
4. Code quality + architecture (15%) — Is the GitHub readable? Does the architecture diagram make sense?
5. Presentation clarity (10%) — Can they explain what it does in 30 seconds?

The most common reason strong projects don't win: no working demo. Never present a project you can't demonstrate end-to-end.

---

Part 6: Sponsor Track Strategy

Every ETHGlobal event has 20–40 sponsor prizes. Most teams ignore this. The winners don't.

How to win sponsor prizes:

1. Study each sponsor's docs and Twitter before the event — know what they're excited about
2. Use their SDK or contract in a non-trivial way (not just import "@chainlink/contracts" for one line)
3. Reach out to the sponsor's engineer at the event — they often advocate for your project in judging
4. In your submission, write a dedicated section: "Why this deserves the [Sponsor] Prize"

Sponsor tracks with historically high win rates (from the dataset):

• Chainlink CCIP / VRF / price feeds — always present, well-staffed
• Safe (smart accounts) — SDK is mature, judges know what good integration looks like
• IPFS / Filecoin — decentralized storage integration is easy to add to any project
• The Graph — a subgraph on any project earns bonus points
• Push Protocol / XMTP — messaging layer adds UX polish to any dApp

---

Part 7: Demo Construction

The 90-Second Demo Formula

1. 0–15s: Show the pain (screenshot of the broken/manual UX)
2. 15–60s: Walk through your solution live (show the UI, not the code)
3. 60–80s: Highlight the key technical innovation ("Under the hood, we use...")
4. 80–90s: Repeat project name + tagline

Live Demo Checklist

• Deployment on stable testnet (not localhost)
• Wallet funded with test ETH/SOL
• Fresh browser profile (no extensions)
• Demo flow tested 3× before presentation
• Backup screen recording saved locally and in cloud

---

Part 8: Common Failure Modes

From post-mortem analysis across 226 projects, these are the most common failure patterns:

1. Scope creep — Adding a second feature at hour 20 usually kills the first feature's demo
2. Late pivot — Changing direction after hour 30 means you finish with nothing working
3. Missing demo video — Most events require it; judges who can't see your demo skip you
4. "Coming soon" features — Judges do not fund roadmaps. Only demo what works.
5. Generic description — "A decentralized platform for transactions" is not a submission
6. Shallow sponsor integration — Importing one function from a sponsor's lib and calling it a prize entry
7. No README — Judges who visit your GitHub need to understand it in under 60 seconds
8. Wrong pitch for the judge — Sponsor booth judges care about their SDK; main track judges care about users

---

Part 9: Pitch Materials Checklist

Before submitting, verify:

• Project name: 1–2 words, memorable, pronounceable
• Tagline: One sentence, no jargon, says what it does and for whom
• Problem statement: 3 sentences with specific numbers ("costs X", "takes Y minutes")
• Solution bullets: Each bullet maps to a technical component with a specific tool
• Architecture diagram: User flow (left to right), smart contracts, off-chain, protocol integrations
• Demo video: 60–120 seconds, no code walkthroughs
• GitHub README: Setup instructions, how to run locally, screenshots
• Live deployment URL: On testnet or mainnet

---

Resources

• ETHGlobal event calendar: ethglobal.com
• DoraHacks hackathons: dorahacks.io/hackathon
• Colosseum (Solana): colosseum.org
• Scaffold-ETH 2 (fastest EVM starter): github.com/scaffold-eth/scaffold-eth-2
• Foundry Book: book.getfoundry.sh
• Anchor (Solana): anchor-lang.com