# Judging criteria (Colosseum) Colosseum states that its hackathons are "startup competitions": a submission is read as a pitch to its venture fund, other investors and its accelerator. Score a draft against what a seed investor would ask, not against a code-quality checklist. **No weights are published.** Colosseum lists its factors without scores or percentages, so this file gives none. Any rubric quoting "functionality 30%" or similar is invented. ## The factors Colosseum lists From the [hackathon FAQ](https://colosseum.com/hackathon) ("How will submissions be judged?"), in the order given, paraphrased: | Factor | The question behind it | Where the submission has to answer it | |---|---|---| | Founder–market fit | Does this team have the skills and experience for this market, and why are they motivated to solve it? | Pitch video (team background), team section | | Insight | Does the team understand the problem space well enough to see something others don't, such as a new technology or trend? | Pitch video, the "why now" in the description | | Product and execution | How well does it work, how does it compare with competitors, and how fast does the team ship and respond to users? | Demo video, repo history, weekly updates | | Potential market size | Is the addressable market large, or small and growing fast? | Description, go-to-market section | | Founder communication | Is the vision communicated clearly, and can these founders grow a user base? | Pitch video above all | | Viability | Can this become a scalable, sustainable business? | Business model, go-to-market section | | Traction | Is there demand or revenue already, and how durable is it? | Demand-validation section, onchain metrics | The same page says Colosseum also looks at how the opportunity was found, how the team prioritises, and whether the founders mean to build a venture-scale company. ## What the repo is checked for Per the FAQ, judges look for evidence that the team did significant work during the hackathon, did it themselves, and prioritised features sensibly. They are explicitly **not** checking for a particular language or framework, design patterns, or code-quality conventions. Only work done between the start and end dates is judged. Pre-existing code must be disclosed in the submission form; undisclosed prior work risks disqualification. ## Process Several rounds of internal review, a shortlist to the judging panel, then a 15-minute video interview for a smaller group. Winners and accelerator picks are announced roughly a month after the deadline ([FAQ](https://colosseum.com/hackathon)). ## What the workshop adds From Colosseum's [submission workshop recap](https://blog.colosseum.com/perfecting-your-hackathon-submission/) (8 May 2025): - The pitch video is the most important element. Treat it as a short startup pitch, not a product demo; a clear narrative beats production polish. - The technical demo video should be specific about the Solana integration, the onchain logic and the architecture, and about why you made those choices. - Judges look for evidence of real users: conversations, early traction, or for public goods, adoption. - Common misses: going over three minutes, buzzwords, flashy visuals with little substance, no team background, a vague Solana integration, empty optional fields, and links (docs, videos, a private repo) that judges can't open. The older [how-to-win guide](https://blog.colosseum.com/how-to-win-a-colosseum-hackathon/) (20 Feb 2024) adds that prizes go to teams intending to build full-time with a potentially viable business model, with a separate award for the best public good. ## Other organisers Superteam bounties, sponsor side tracks and regional hackathons publish their own criteria on the listing. Read that page and score against it; don't carry Colosseum's factors over unchanged.