# Colosseum pitch brief

Version 1.0, 8 October 2026. Maintained by Superteam Türkiye: https://tr.superteam.fun/colosseum/pitch-coach

A reference for preparing a Colosseum Crypto World's Fair submission: the one-liner, the pitch video, the demo video, the deck, and the form answers. It is a document, not a program. Paste it into a chat, drop it in your repo, or give your assistant its URL. Nothing here runs by itself, and nothing here replaces the official rules.

## Rules for an assistant using this brief

If you are an AI assistant and a founder gave you this document, follow these rules. If you are a founder, you can read them too: they are what you should expect.

1. **Read before you ask.** If you can read files, read the README, docs, package manifests, landing copy, any deck export and any earlier script first. Check the git history for commit count, contributors and cadence. Ask only for what is missing.
2. **At most three questions at a time.** Never ask for something the material already answers.
3. **Tag every fact** as `[repo]`, `[deck]`, `[user]` or `[unverified]`. Only `[unverified]` facts need confirming before they go in a script.
4. **Never invent.** No numbers, users, quotes, partners, traction or team experience. If a gap exists, name the gap. Separate what works today from what is planned. Do not promise a win.
5. **Never pretend to have opened a file or link you cannot open.** Ask for an export.
6. **Stop and ask when the deck and the repo describe different projects**, or when key facts conflict. Do not merge them silently.
7. **Respect decisions the founder already made.** If they have a one-liner, a script or a deck they like, improve it; do not replace it. Offer a change only when you can name what is wrong with the original.
8. **You write words, not video direction.** Give the exact sentences to say. Do not direct framing, editing, zoom, captions or music. A short on-screen cue such as `[Open the app]` is fine, on its own line, never read aloud.
9. **Do not restyle a deck.** Branding is the founder's choice. Work on story, order, density, hierarchy and proof.
10. **Official rules win.** If this brief disagrees with the rules at https://colosseum.com/legal/Crypto%20World's%20Fair%20Hackathon%20Rules.pdf or with the live form, the rules and the form are right.
11. **Reply in the language the founder writes in.** Everything that goes into the submission (script, one-liner, slide copy, form answers) is written in English.

## 1. The format

Colosseum asks for two different videos. They are separate uploads with separate jobs. Never mix them.

| | Pitch video | Demo video |
|---|---|---|
| Length | Up to 2 minutes | Up to 3 minutes |
| Visibility | Public on the project page | Shared with team, judges and Colosseum; you choose whether it also shows publicly |
| Job | Who you are, what you are building, why you are the people to build it | The live product, running, start to finish |
| Not | A product tour, or a company overview | Slides, a code walkthrough, or a second pitch |
| Host | YouTube, Loom or Vimeo | Same |

- The 2-minute budget belongs to the pitch alone. Do not subtract demo time from it, and do not write one script for both.
- The Superteam Türkiye Earn listing accepts up to 3 minutes for the pitch, but if you upload the same video to both places, keep it to 2.
- Colosseum says judges usually open the pitch video first, and judges are looking for a reason to say no. A calm, clear, human video that does not hand them one is most of the job.
- About 88% of the 139 winning submissions in the last three hackathons were a recorded video rather than a static deck (Superteam Balkan's count, not a Colosseum statistic). Build the video first, then the deck from it.
- Everything in the submission is in English.

## 2. The one-liner comes first

Write it before anything else. It is what a judge still remembers after fifty other pitches, and it may be the only thing they remember tomorrow. These rules come from Josip Volarević, who has won Colosseum, mentored winners and judged.

- **Five words or fewer.** Six is already too many for a timeline scroll.
- **Priority order: unambiguous, exciting, truthful.**
  - Unambiguous: ten different people reading it should picture the same product. "Copilot for e-commerce" fails. "Reddit for agents" passes.
  - Exciting: it should make someone feel something. Curiosity counts.
  - Truthful enough: it paints the right picture and is defensible with a number you can show. It does not have to be true in every case, but it must never be invented. "Negative interest loans on Solana" was acceptable because over 90 percent of that product's users really had negative rates.
- **No jargon or buzzwords.** Not revolutionary, disruptive, redefining, the future of. No abstract metaphors: legos, layers, glue, building blocks. Use the words a parent would use over coffee.
- Two formats work most often. The analogue: a thing everyone knows plus your twist ("Reddit for agents"). The descriptive: a verb, an object and a context ("Launch tokens without seeding liquidity", "Shop anything online with stablecoins").
- **Test it.** Say it to three people and ask what they picture. If the answers differ, rewrite it.
- It goes in three places unchanged: the first slide, the first line of the form's description field (up to 500 characters), and the close of the pitch video.

If you keep a category name or slogan that already exists in your material ("agentic payments"), keep it exactly. Do not rewrite it into something more generic ("AI payments").

An assistant should offer three candidates, pick one, and say in a sentence or two why.

## 3. The pitch video

### What to write

Two minutes is very short. Do not turn it into a company overview. Choose the strongest story and use only what supports it.

**Outer order: Problem, Solution, Demo, Team.** This is the order Colosseum's own guidance and this hub recommend, and deviating from it costs clarity. In practice: problem and solution first, a few seconds of the product working, then the team, then numbers and what is next.

**Inside the problem and solution, use the Pixar spine** to decide what to say. Each beat is a sentence or two. You do not need every beat.

1. **Once upon a time.** The world and the specific people in it, in a way that is interesting.
2. **And every day.** How those people handle the problem today, and what it costs them: time, money, effort.
3. **Until one day.** Your product, in plain words, narrow and specific.
4. **And because of that.** The one way it is meaningfully better, answering the biggest pain in beat 2.
5. **And because of that.** Your strongest proof: users, interviews, tests, a pilot, speed of shipping.
6. **Until finally.** Where this goes, and the first market you can actually reach, not a trillion-dollar total.

The Pixar beats organise the content. They do not reorder the outer sequence above.

### The first ten seconds

The first ten seconds decide the rest. Open with who it is for and what you built, or with the problem as something a named person lives through today. Do not open with your team's origin story, and do not open with a general lament about the industry.

If you want an opening about the problem, make it a specific cost, not a negative generalisation. "A freelancer waits days for a payment and loses a slice of it to fees" works. "Payments are broken" does not. (That freelancer line is an invented illustration, not a statistic. Use only real numbers from the founder.)

Never define the problem as "there is no X". That is the absence of a solution, not a problem.

Give the listener something they did not know. A real, specific fact or a piece of research you did teaches more than a general claim.

### What to leave out of the video

- The business model and the roadmap. They read as padding at two minutes. Write the business model in three sentences in the form field, which scores it explicitly.
- Long market explanations, feature lists, architecture detail and general blockchain stories. These are the first things to cut.
- A fundraising ask, unless the founder wants one.

### Length and timing

- Speaking pace is about 130 to 145 words per minute. Leave a few seconds for breathing and pauses.
- A full, well-supported script lands between about **215 and 255 words**. At 135 words a minute that is 1:35 to 1:52 of speech before pauses. Each number, date or URL takes about a second longer to say than it looks, and pauses add about 5 seconds, so the safe ceiling is about 240 words. Reading the script aloud once and timing it is the real test.
- Do the arithmetic and show it: word count, pace assumed, estimated time, pause allowance, and whether the total is under two minutes.
- Going over is not acceptable. Never ask the founder to speak faster. If a draft runs over, cut in this order: repeated points, secondary detail, jargon, setup sentences, anything the product will show on screen. The main message and the strongest proof go last.
- If a script honestly finishes near 1:30 to 1:40 with every important beat in it, say so and stop. Do not pad. Under about 1:30, check whether the proof or the team is missing.

### The team, in the video and on the slide

Do not list names and titles, and do not use adjectives. Say what each person did that makes them the right one for this. Weak: "We're a passionate, hardworking team." Good (illustrative): "Aylin wrote the backend of an app that reached 400 users at the last hackathon." Claim only results the person was directly responsible for. If there is no such result yet, the user and transaction numbers produced now are the first proof.

### Delivering it

- A script is for learning the flow, not for reading. Learn the flow and the key sentences. Do not memorise word for word and do not read from the screen; viewers can tell.
- Speak the way you would to someone across a table, relaxed and aware that a person is listening.
- **Camera.** The founder speaks to camera, on their own face, in one continuous take: no cuts, no music. If you cannot speak for ninety seconds without edits, a judge will wonder how you will pitch anyone else. A few seconds of product on screen during the pitch is allowed. If there are two founders, both are in the same frame. Contractors and non-founders do not appear.
- Practise several days ahead and record when rested.

## 4. The demo video

Write this only when asked, as a separate script.

- Open with one sentence: what the viewer is about to see and who it is for.
- Walk one real user journey in the live product, from the start to the moment it works. Use a real transaction if there is one.
- Reach the "aha" moment early. Do not save it for the last ten seconds.
- State what is live today and what is not yet built.
- Go technical. This is the only place a judge watches the thing run, so it is not a second pitch.
- Narration is slower than the pitch because the screen is doing work. Plan for roughly 110 to 120 words a minute, so about 250 to 300 words fills 2:30 to 2:45 and leaves room for silent moments on screen. Do not plan to fill all three minutes with speech. This is a guideline, not a rule.
- One screen cue per step, such as `[Open the app]` and `[Connect wallet]`. A title card at the start or end counts as a slide: skip it and say the line instead.
- Close with: "Play the screen recording and read this aloud over it. How long did it take?"
- The founder's face should be visible in a small bubble. Loom does this by default.
- A repository link is not a demo. If judges need credentials, put the access instructions in the form field for the live product link.

## 5. The deck

Judges are not looking to be impressed. They are looking for a reason to say no, and one red flag closes the deck. They read on a phone with thirty seconds to spare. What survives a day of pitches is a feeling and one takeaway, often only the one-liner. Be extremely basic: plain, clear and normal is enough to land in the top five percent, because a great many submissions are over-engineered or visibly machine-written.

The deck supports the pitch video. It must make sense fast and must not need the founder next to it. Build it from the script, one slide per group of sentences, not the other way round.

### Five rules for every slide

1. **The title is the takeaway.** "Freelancers lose a week to every payment", not "The Problem".
2. **One point per slide.**
3. **Words: aim for about 20 per slide. 40 is the ceiling no slide passes.** Judges stop reading slides over about 20 words after a handful of decks; past 40 they skim for sure.
4. **Cut the superlatives.** Replace revolutionary and fastest with proof: "start to finish in 15 seconds", "$400 saved per user per month".
5. **Readable in 15 seconds**, and legible at phone width.

### Suggested flow (8 to 13 slides)

Put anything beyond that in an appendix after the close and say out loud that it is optional. After slide 1, lead with the strongest asset: exceptional team earlier, real traction earlier. Pick one order and commit; do not merge advice from many people.

| # | Slide | The one thing it says |
|---|---|---|
| 1 | Name and one-liner | Name at medium size, one-liner large, five words or fewer. Nothing else: no logo wall, link, contact, date or watermark. |
| 2 | The world | An interesting, true context, ideally a fact they did not know. |
| 3 | The problem | A specific person, the job they need done, how they cope, what it costs. |
| 4 | The product | A verb and an object in plain words. Narrow, not a platform. |
| 5 to 6 | How it works | One user journey, one screenshot each. What works today versus what is planned. |
| 7 | Why it is better | The single benefit that answers the biggest pain on slide 3. |
| 8 | Proof | Users, interviews, pilots, revenue, speed of shipping. Real numbers only. |
| 9 | The team | Why each person is the right one, in outcomes. |
| 10 | The market | A reachable starting market, bottom-up, with a source. |
| 11 | Business model | Three sentences. Judges score it. |
| 12 | What is next | Concrete next steps. |
| 13 | Close | The one-liner again and where to see the demo. |

### Reviewing an existing deck

Go slide by slide, then across the deck.

- **Eye test.** Name what a stranger looks at first, second and third. If several elements compete, the founder has lost control of where people look.
- **Density.** Count words on every slide. Flag any slide over about 20 words, anything that must be read rather than scanned, and anything illegible at phone width.
- **Story.** Is there one idea per slide and a takeaway title? Cookie-cutter titles are a red flag. Too many slides or features is a flag.
- **Claims.** Generic or "no X" problems; "for everyone" users; buzzwords; vanity or uncited numbers; market size in trillions; a competitor matrix where every rival is bad at everything (and no grasp of competition at all is also a flag); an unclear product or no working demo; anything planned described as if it exists.
- **Team.** Part-time members, a hackathon-only mindset, no contact with users, unclear ownership, outsourced building, a very large team, unequal equity, no one who can build.
- **Craft.** Watermarks, animations beyond a simple appearance, music or memes, unreadable screenshots, text that looks pasted from a language model.

Output of a review: a verdict (would a tired judge on a phone keep reading, and what would they remember tomorrow); at most five fixes, worst first; slide-by-slide notes only where there is a problem; a cut list; missing proof; replacement sentences for at most three slides; and what to leave alone so it does not get broken. Be short.

## 6. The form

Draft every answer in a document first, to the character limits, then paste. Writing to a hard ceiling is a different task from writing freely. Final submission is open; you can save and edit any time before the deadline.

**Public page** (anyone with the link): project name; description up to 500 characters (the one-liner belongs at the start); website, optional; category; team location (set it to Türkiye); logo (JPEG, PNG, WEBP or GIF, up to 20MB); GitHub link, a direct repository link, not an org or profile page; pitch video, up to 2 minutes; X profile.

**Shared with team, judges and Colosseum:**
- What are you building and who is it for: up to 1,000 characters.
- Why this, why now: up to 1,000.
- Technologies and developer or AI tools used.
- Which chains, and how the product uses them: up to 500. A forced integration fails here first.
- Mobile-focused dApp: yes or no.
- Team Telegram contact: someone who actually checks it.
- Did anyone not listed on the team do meaningful work: up to 600. Answer honestly.
- Anything else judges should know: up to 500, optional.
- Demo video, up to 3 minutes, separate upload.
- Live product link and access instructions.

**Private to organisers, and the accelerator screen** (required whether or not you want the accelerator):
- How do you know people need this: up to 1,000.
- How far along are you, do you have users: up to 1,000. Be specific.
- Who else is building here and what are they getting wrong: up to 1,000.
- How do you make money: up to 500. Three sentences.
- How long has each person worked on it, full time or not: up to 500.
- Where each member is based, whether you work in person together.
- Four yes or no questions: legal entity, investment taken, currently fundraising, live token. A pre-idea team answers no to all four, honestly. What reads badly is a thin answer to the open questions above them.

## 7. The rules that disqualify teams

These are not style points. Check them in week one, not on deadline night.

- **Deadline.** 23:59 Pacific on 12 October 2026, which is **09:59 on 13 October in Türkiye**. California is ten hours behind. A team that waits for midnight in Türkiye submits ten hours late. There is no appeal for ten minutes.
- **Every team member registers individually** on colosseum.com before that same moment, or is disqualified. A member missing from the project page is a silent disqualifier.
- **One product per team and one team per person.**
- **Prior work.** You may start before the window and reuse your own code, but only work done inside the window is judged, and you must disclose all prior development on the form. Colosseum's words for teams that do not: they disqualify the team, ban the builders from future hackathons and revoke prizes. Building on other people's open source is fine and encouraged.
- **Permissions.** Private repos and locked documents that judges cannot open are the most common fatal mistake. If the repo stays private, grant access to hackathon@colosseum.com, then have someone outside the team open every link you submitted.
- **Eligibility.** For new startups that have not raised significant outside capital.
- Submit two days early.

## 8. The fastest route

A reviewed first version takes about ninety minutes. The rest is iteration, and the order matters more than the polish.

1. **One-liner, 15 minutes.** Three candidates, tested on three people.
2. **Story, 15 minutes.** Six sentences on the Pixar spine. Email them to a few trusted people and ask: who is the customer and what is the problem, why do current solutions fail, what makes this much better, what is unclear.
3. **Script, 25 minutes.** Two-minute English script, with the arithmetic.
4. **Deck skeleton, 30 minutes.** From the script, takeaway titles, one visual each.
5. **Review, 5 minutes.** Run the deck review above. Fix the first three things.
6. **Share for comments.** Google Slides or a Doc with comment rights, not a gated viewer and not a PDF that forces screenshots. One short, specific ask: "Hi, I'm Aylin from Istanbul, building [one-liner]. Could you look at this deck? Comment access is on. What is the one thing to fix first?"
7. **Record both videos**, rested, several days before the deadline.

Then iterate early. Start from a blank page rather than reusing an old deck. Ask many people to look, but follow one main mentor. If a mentor says the idea is not worth pursuing, take it seriously: pivots days before the deadline have won. If your local Superteam runs a pitch roast session, go.

## 9. Where this comes from

- Official rules: https://colosseum.com/legal/Crypto%20World's%20Fair%20Hackathon%20Rules.pdf
- How to Win a Colosseum Hackathon, Colosseum: https://blog.colosseum.com/how-to-win-a-colosseum-hackathon/
- Perfecting Your Hackathon Submission, Colosseum: https://blog.colosseum.com/perfecting-your-hackathon-submission
- Very pragmatic approach to making a good startup one-liner, Josip Volarević: https://x.com/JosipVolarevic2/status/2096885934532768013
- The first slide of your pitch deck, Josip Volarević: https://x.com/JosipVolarevic2/status/2106374392166973692
- Don't undersell yourself, Josip Volarević: https://x.com/JosipVolarevic2/status/2106075158465089606
- I participated in 3 Colosseum hackathons, Josip Volarević: https://x.com/JosipVolarevic2/status/2038643299221729462
- Pixar's story method for startup pitches: https://startuppitch.substack.com/p/nail-your-startup-pitch-use-pixars
- YC, how to design a better pitch deck: https://www.ycombinator.com/library/4T-how-to-design-a-better-pitch-deck
- Superteam Balkan's count of 139 winning submissions: https://x.com/solanamarko/status/2098084013332210127
- Superteam Türkiye's Colosseum hub, with every guide: https://tr.superteam.fun/colosseum
- Josip's pitch workshop for Crypto World's Fair teams (transcript).