Web3 Hackathons: What to Know Before, During, and After the Event

Picking the Event

Most ecosystems announce their hackathon through official channels first — protocol blogs, X accounts, and Discord servers. Aggregators like Web3Voyager let you filter by event type and ecosystem, which helps when multiple events are running in parallel and you need to compare formats without tracking down each one individually. At any given point there are usually several options on the calendar, so the real question is which one fits.

The mistake most first-timers make is treating the total prize pool as the primary signal.

Prize pools are structured to look larger than they are. A $100k event often concentrates $60–70k in a single grand prize track built around specific technology. The category tracks below that top tier sometimes attract very few submissions — which matters if you’re going in with a realistic scope and a focused idea.

The sponsor list tells you more. Web3 hackathons are organized by companies that want developers building on their infrastructure, and the judging criteria, the mentors, and the bounty structure all reflect that. As the organizer of FarHack— the hack day portion of FarCon, the annual summit for the Farcaster protocol — @limone.eth put it:

“If somebody is joining a hackathon, it’s because they’re interested in the tech or the bounties. The selection is self-filtering — when a team shows up misaligned with the ecosystem, it shows in the submission.”

Harry Papacharissiou, Head of Developer Relations at Chainlink Labs, sees the same dynamic from the other side. After over half a decade running Chainlink hackathons, the approach is to leave zero room for ambiguity in how tracks are presented:

“We do get invalid projects submitted to our hackathons, often relating to not following the criteria, but overall, the rest of the submissions are typically well aligned with our ecosystem and priorities. If we want to see developers experimenting with Chainlink and prediction markets, we clearly specify a prediction market track, with examples of types of applications that teams could build that leverage Chainlink technology in the prediction market space.”

Protocol-specific hackathons — the kind Chainlink, Aave, or Uniswap run independently — work differently from open-format events. Sponsors there are looking for teams who might keep building after the event ends. The prize structure is usually less top-heavy, the mentors are internal to the protocol, and the judging criteria are narrower but more legible. For developers who already know what they want to build within one ecosystem, these are often better starting points.

The Discord is worth joining two weeks before registration closes. Organizers of well-run events respond to questions, ecosystem teams show up before building starts, and there’s enough ambient activity to get a read on who attends and why. We’ve skipped events based on this alone — a quiet Discord two weeks out usually reflects how the event itself will go.

The First Day

The opening ceremony is typically a YouTube stream. Sponsor presentations, a few keynotes, and then you’re dropped into a Discord server or virtual space and expected to form a team and find an idea within a few hours. This part is chaotic regardless of how many times you’ve done it.

Teams that got moving quickly were almost always the ones who handled logistics before the event opened. Not with a complete plan — those rarely survive the first conversation with a potential teammate — but with the basics: a funded testnet wallet, a preferred framework already initialized, API keys from the sponsor tools they expected to use. In a 72-hour event, losing two or three hours to environment setup in the first six is a meaningful drag.

Joining someone else’s project in the first few hours is a legitimate path. We’ve done this. The experience is comparable to leading a project from your own idea. The constraints are the same, the learning is the same, and it removes the pressure of coming up with a concept from scratch while simultaneously trying to orient to an unfamiliar environment.

If you’re going in without a team, the meet-and-greet channels are where that gets resolved. Most well-run Web3 hackathons have a structured way to connect people looking for teammates. Use it early — the further into day one it gets, the more teams have already formed and started building.

Teams

More hackathon teams collapse mid-event than most people expect going in. From what we’ve observed, it typically surfaces around day two, and the cause is almost always a conversation that didn’t happen before building started.

The conversation is short: how many hours can you realistically put into this, what do you want to walk away with, and what happens if someone goes quiet for a day. Teams that skip it because it feels transactional at the start of something collaborative tend to have a version of it anyway — under pressure and late in the event, which is a worse time for it.

Time zones are a constraint people consistently underestimate. A five or six hour difference is manageable with coordination. More than that and you’re losing real working hours every day in an event where days are the entire budget.

Solo submissions are a legitimate path but require deliberate scoping from the start. The strongest solo submissions we’ve seen follow a consistent pattern: one contract with a clear purpose, a minimal frontend that allows a judge to interact with it, and a README that’s honest about what’s missing. That consistently outperformed more ambitious solo projects that shipped broken.

Scope

This is where most teams lose the event, and it happens during the planning conversation on day one.

The initial session goes well. Someone suggests a feature. Someone else adds to it. An hour in you have a protocol with four interconnected contracts, a frontend, a governance mechanism, and a subgraph. None of it gets built.

We saw this pattern enough times that we now treat scope as the primary risk in any Web3 hackathon — ahead of technical difficulty, ahead of team coordination. The test before writing any code: describe the project in a single sentence. If that’s not possible, the idea needs to be reduced before it gets any implementation.

The other side of this is knowing when to stop adding once the core is working. Teams that finished their primary feature with time to spare and spent the remaining hours on the submission consistently did better than teams that kept building until the deadline and scrambled to write the README in the last twenty minutes.

Packaging the Submission

Submission rates vary widely depending on event format. For global online hackathons, the drop-off between registrations and completed submissions can be steep. As Harry Papacharissiou puts it:

“Generally, for global online hackathons, the drop-off between registrations and final submissions can be around 80% from sign-up to a completed project submission. That can be the case because of low-intent signups and people registering without a clear plan to build. When you get really focused on the right audience, total registration might be lower, but participants can be much more intentional, and that’s when you can see that number start to drop.”

At more focused, in-person events the picture looks different. At FarHack, submission rates reach around 95%. @Limone.eth puts the smaller drop-off down to one consistent pattern:

“Those who don’t submit usually dedicate effort to the writeup only in the last few minutes — by the time they sit down to document what they built, the deadline has passed.”

So do your future self a favor and block time for the submission before you write a single line of code.

The README gets read carefully. It needs to cover what the project does, why it exists, how to run it, and what the team would have built with more time. Setup instructions matter more than they seem: a judge who hits an undocumented dependency or a missing environment variable will move on. The roadmap section matters to sponsors and protocol teams looking for builders who were thinking beyond the weekend.

The video is not optional: three to five minutes, showing the project running, narrated clearly. Production quality is secondary. A basic screen recording with clear narration is worth more than a polished one where it’s not clear what the project does. A live demo does more than anything else to establish that the project is real and usable — free hosting is available for testnet deployments, and there’s no good reason to skip it if the project runs.

On what separates submissions that place from ones that don’t, @Limone.eth was direct:

“It’s not only about the tech, it’s also about packaging the project in the right way.”

Harry Papacharissiou points to the same issue from a judging perspective, and adds a caveat on a newer problem:

“Just because something is very complex, technical, and thorough, doesn’t mean it can’t be explained in a digestible way that makes sense to the average developer in a README or a video demo. If it can’t be understood, there’s a good chance it won’t get the merit it deserves. With the use of AI, we’re seeing less of that now, but teams need to be sure that AI accurately reflects their submission and doesn’t just confidently give them incorrect information.”

Judges evaluate the full submission — the clarity of the idea, how well it’s documented, and whether it answers the question we heard most often across events: why does this need to be on a blockchain? Submissions that answered it clearly scored better consistently.

Run a basic security pass before submitting. Check for reentrancy issues, verify access controls, confirm function visibility is intentional. No one expects audit-ready code in 72 hours. Critical vulnerabilities that suggest the team didn’t think about how the contract behaves under adversarial conditions leave an impression that’s hard to separate from the rest of the work.

After the Event

The repository cleanup gets skipped almost universally. Teams submit, the event ends, they move on.

Protocol teams and ecosystem foundations follow hackathon results. Hiring managers search submission archives months after events close. The visibility window is real, but it requires the repository to be readable to someone landing on it for the first time. Cleaning up the repo, writing a short case study, and linking it from a GitHub profile takes a few hours. We’ve seen that lead to recruiting conversations and grant inquiries months after the event closed.

Most major protocol sponsors run follow-on grant programs, and the teams that benefit are almost always the ones who go looking. Chainlink’s approach is more hands-on than most — Harry Papacharissiou describes it as a white-glove service:

“We get our team to personally reach out to all winners and top projects, and speak to them about our Build program and explain how Chainlink can support them in their next steps — from helping them get on mainnet, to introducing them to places where they can try and get funding, to offering marketing and ecosystem support as they continue building out their newly formed startups. Not every team wants to turn a hackathon project into a company, but among top projects, a meaningful percentage engage in follow-on conversations, and a smaller subset go on to pursue funding or full-time development. Some projects built during our hackathons go on to secure funding and become fully fledged mainnet-deployed protocols.”

However, not every organizer operates at that level. @Limone.eth was candid about where the responsibility more commonly sits:

“It’s hard for organizers doing that, it’s companies and sponsors that should invest more time on it.”

Which means the onus is usually on the team. Go find those programs. Don’t wait for an introduction that may not come. Follow-up messages to people you met during the event are worth sending in the first week, while the context is still present. Most of the ongoing collaborations we’ve seen come out of hackathons started this way.

Judge feedback, when it comes, is worth reading specifically. The distance between a submission that placed and one that didn’t is usually narrower and more concrete than it felt during the event. Most developers we’ve spoken with said the second hackathon was significantly more useful than the first, simply because they knew what they were walking into. The format rewards preparation more than any other variable.

If you’re looking for what’s coming up, the full calendar of Web3 hackathons is on Web3Voyager. If you’re organizing one, you can list it here.