Web3 Hackathons, Done Right: A Pragmatic Playbook for 2025
· 12 min read
If you want a fast route to sharpen your skills, meet co-founders, and pressure-test an idea, few environments beat a web3 hackathon. But the difference between a “fun weekend” and a “career-changing launch” is a plan.
This guide gives you a concrete, builder-first playbook: how to pick the right event, prep smart, build fast, and present with clarity—plus checklists you can copy-paste into your next hack.
TL;DR
- Pick events intentionally. Favor ecosystems you already ship in—or ones with judges and sponsors who are perfectly aligned with your idea.
- Decide your win condition. Are you there for learning, a specific bounty, or a finalist spot? Each choice changes your team, scope, and stack.
- Pre-bake the boring stuff. Have your project scaffolds, auth flows, wallet connections, design system, and a demo script outline ready before the clock starts.
- Build the smallest lovable demo. Show one killer feature loop working end-to-end. Everything else is just narrative and slides.
- Submit like a pro. Respect the “start fresh” rules, formally register for every bounty track you target, and reserve significant time for a tight video and a clear README.
Why web3 hackathons are worth your weekend
- Compressed learning: In a single weekend, you’ll touch infrastructure, smart contracts, front-end UX, and deployment pipelines. It’s a full development cycle in 48 hours—a learning curve that would normally take months.
- High-signal networking: The mentors, judges, and sponsor engineers aren't just names on a website; they are concentrated in one room or Discord server, ready to give feedback. This is your chance to connect with the core developers of the protocols you use every day.
- Real funding paths: This isn't just for bragging rights. Prize pools and follow-on grants can provide meaningful capital to keep a project going. Events like Solana’s Summer Camp have offered up to $5M in prizes and seed funding, turning weekend projects into viable startups.
- A portfolio of proof: A public GitHub repository with a functional demo is infinitely more valuable than a bullet point on a résumé. It's tangible proof that you can build, ship, and articulate an idea under pressure.
Where to find the good ones
- ETHGlobal: The gold standard for both in-person and asynchronous events. They feature robust judging processes, high-quality participants, and public project showcases that are perfect for inspiration.
- Devpost: A broad marketplace for all kinds of hackathons, with strong filters for blockchain, specific protocols, and prize tracks. It's a great place to discover ecosystem-specific events.
- DoraHacks: A platform focused on ecosystem-driven web3 hackathons and grant rounds, often with a global and community-centric feel.
Tip: Durations vary widely. A long-form async event like ETHOnline runs for multiple weeks, while an extended in-person sprint like ETHDenver’s #BUIDLathon can last up to nine days. You must plan your project’s scope accordingly.
Decode the rules (so you don’t DQ yourself)
- “Start Fresh.” This is the most common and critical rule. Most events require that all substantial work begins after the official kickoff. Using older, pre-written code for core logic can get you disqualified from finals and partner prizes. Boilerplate is usually fine, but the secret sauce has to be new.
- Judging structure. Understand the funnel. Often, an async screening round narrows hundreds of projects down to a finalist pool before live judging begins. Knowing this helps you focus on making your submission video and README as clear as possible for that first cut.
- Team sizing. Don't show up with a team of ten. Many events set limits, such as the typical 2–4 person teams seen at ETHDenver. This ensures a level playing field and encourages tight collaboration.
- Bounty mechanics. You can’t win a prize you didn’t register for. If you’re targeting sponsor bounties, you often must formally enroll your project for each specific prize through the event platform. This is a simple step that many teams forget.
Judging rubric: what “good” looks like
Across major organizers, judges are typically evaluating projects across four recurring buckets. Design your scope and demo to score points in each.
- Technicality: Is the problem non-trivial? Does the solution involve a clever or elegant use of technology? Did you go beyond a simple front-end wrapper on a single smart contract?
- Originality: Is there a novel mechanism, a unique user experience, or a clever remix of existing primitives? Have we seen this a hundred times before, or does it present a fresh take?
- Practicality: Can someone use this today? A complete, end-to-end user journey, even if narrow, matters far more than a project with broad but half-finished features.
- Usability (UI/UX/DX): Is the interface clear, fast, and pleasant to use? For developer tools, how good is the developer experience? A smooth onboarding and clear error handling can set you apart.
Team design: small, sharp, complementary
For speed and alignment, a team of two to four is the sweet spot. It's large enough to parallelize work but small enough to make decisions without endless debate.
- Smart contracts / protocol: Owns the on-chain logic. Responsible for writing, testing, and deploying the contracts.
- Front-end / DX: Builds the user interface. Manages wallet connections, data fetching, error states, and the final demo polish that makes the project feel real.
- Product / story: The scope keeper and narrator. This person ensures the team stays focused on the core loop, writes the project description, and runs the final demo.
- (Optional) Designer: A dedicated designer can be a secret weapon, preparing components, icons, and micro-interactions that elevate the project's perceived quality.
Idea selection: the P-A-C-E filter
Use this simple filter to pressure-test your ideas before writing a single line of code.
- Pain: Does this solve a real developer or user pain point? Think wallet UX, data indexing, MEV protection, or fee abstraction. Avoid solutions looking for a problem.
- Atomicity: Can you build and demo a single, atomic loop end-to-end in 48 hours? Not the whole vision—just one complete, satisfying user action.
- Composable: Does your idea lean on existing primitives like oracles, account abstraction, or cross-chain messaging? Using battle-tested lego blocks helps you go further, faster.
- Ecosystem fit: Is your project visible and relevant to the event’s judges, sponsors, and audience? Don’t pitch a complex DeFi protocol on a gaming-focused track.
If you’re bounty-driven, pick one primary and one secondary sponsor track. Spreading your focus across too many bounties dilutes your depth and chances of winning any of them.
Default stacks that fight you less
Your novelty should be in what you build, not how you build it. Stick to boring, reliable technology.
EVM track (fast path)
- Contracts: Foundry (for its speed in testing, scripting, and running a local node).
- Front-end: Next.js or Vite, combined with
wagmiorviemand a wallet kit like RainbowKit or ConnectKit for modals and connectors. - Data/indexing: A hosted indexer or subgraph service if you need to query historical data. Avoid running your own infrastructure.
- Off-chain triggers: A simple job runner or a dedicated automation service.
- Storage: IPFS or Filecoin for assets and metadata; a simple KV store for session state.
Solana track (fast path)
- Programs: Anchor (to cut down on boilerplate and benefit from safer defaults).
- Client: React or a mobile framework with the Solana Mobile SDKs. Use simple hooks for RPC and program calls.
- Data: Rely on direct RPC calls or ecosystem indexers. Cache aggressively to keep the UI snappy.
- Storage: Arweave or IPFS for permanent asset storage if relevant.
A realistic 48-hour plan
T-24 to T-0 (before kickoff)
- Align on your win condition (learning, bounty, finals) and target track(s).
- Sketch the full demo loop on paper or a whiteboard. Know exactly what you’ll click and what should happen on-chain and off-chain at each step.
- Fork a clean monorepo scaffold that includes boilerplate for both your contracts and your front-end app.
- Pre-write your README outline and a rough draft of your demo script.
Hour 0–6
- Validate your scope with event mentors and sponsors. Confirm the bounty criteria and ensure your idea is a good fit.
- Set hard constraints: one chain, one primary use-case, and one "wow" moment for the demo.
- Divide the work into 90-minute sprints. Your goal is to ship the first full vertical slice of your core loop by Hour 6.
Hour 6–24
- Harden the critical path. Test both the happy path and common edge cases.
- Add observability. Implement basic logs, UI toasts, and error boundaries so you can debug quickly.
- Create a minimal landing page that clearly explains the "why" behind your project.
Hour 24–40
- Record a backup demo video as soon as the core feature is stable. Do not wait until the last minute.
- Start writing and editing your final submission text, video, and README.
- If time permits, add one or two thoughtful flourishes, like great empty states, a gasless transaction, or a helpful code snippet in your docs.
Hour 40–48
- Freeze all features. No more new code.
- Finalize your video and submission package. Experienced winners often recommend reserving ~15% of your total time for polish and creating a video with a clear 60/40 split between explaining the problem and demoing the solution.
Demo & submission: make judges’ jobs easy
- Open with the “why.” Start your video and README with a single sentence explaining the problem and your solution’s outcome.
- Live the loop. Show, don't just tell. Walk through a single, credible user journey from start to finish without skipping steps.
- Narrate your constraints. Acknowledge what you didn't build and why. Saying, “We scoped this to a single use case to ensure real users can complete the flow today,” shows focus and maturity.
- Leave clear markers. Your README should have an architecture diagram, links to your live demo and deployed contracts, and simple, one-click steps to run the project locally.
- Video basics. Plan your video early, script it tightly, and ensure it clearly highlights what the project does, what problem it solves, and how it works under the hood.
Bounties without burnout
- Register for each prize you target. On some platforms, this involves an explicit “Start Work” button click.
- Don’t chase more than two sponsor bounties unless their technologies naturally overlap in your stack.
- In your submission, mirror their rubric. Use their keywords, reference their APIs by name, and explain how you met their specific success metrics.
After the hackathon: turn momentum into traction
- Publish a short blog post and a social media thread with your demo link and GitHub repository. Tag the event and sponsors.
- Apply to grants and accelerator rounds that are specifically designed for hackathon alumni and early-stage open-source projects.
- If the reception is strong, create a simple one-week roadmap focused on bug fixes, a UX pass, and a tiny pilot with a few users. Set a hard date for a v0.1 release to maintain momentum.
Common pitfalls (and the fix)
- Breaking “start fresh” rules. The fix: Keep any prior code completely out of scope or declare it explicitly as a pre-existing library you’re using.
- Over-scoping. The fix: If your planned demo has three major steps, cut one. Be ruthless about focusing on the core loop.
- Going multi-chain too early. The fix: Ship on one chain perfectly. Talk about your plans for bridges and cross-chain support in the "What's next" section of your README.
- The last-minute polish tax. The fix: Pre-allocate a 4-6 hour block at the end of the hackathon exclusively for your README, video, and submission form.
- Forgetting to enroll in bounties. The fix: Make this one of the first things you do after kickoff. Register for every potential prize so sponsors can find and support your team.
Checklists you can copy
Submission pack
- Repo (MIT/Apache-2.0 license), concise README, and local run steps
- Short Loom/MP4 demo video + a backup recording
- Simple architecture diagram (one slide or image)
- One-pager: problem → solution → who cares → what’s next
- Links: live frontend, contract addresses on a block explorer
IRL packing list
- Extension cord and power strip
- Headphones and a decent microphone
- HDMI/USB-C display dongles
- Refillable water bottle and electrolytes
- Your favorite comfortable keyboard/mouse (if you’re picky)
Rules sanity check
- Start-fresh policy understood and followed
- Team size is within the event’s bounds (if applicable)
- Judging flow (async vs. live) is noted
- All target bounties are formally registered (“Start Work” or equivalent)
Useful links for your next hack
- Find events: Check out the ETHGlobal events calendar, the Devpost blockchain hub, and DoraHacks for upcoming competitions.
- Get inspired: Browse the ETHGlobal Showcase to see winning demos and explore their code.
- EVM scaffolding: Review the Foundry documentation and quickstart guides.
- Solana scaffolding: Look at the Anchor documentation and its “basics” guide.
- Video tips: Search for guides on how to craft a crisp and compelling demo video.
Final note
Hackathons reward clarity under constraint. Pick a narrow problem, lean on boring tools, and obsess over creating one delightful, end-to-end moment. Do that, and you’ll learn a tremendous amount—even if your name isn’t on the winners slide this time. And if it is, you’ll have earned it.