Crypto Hackathon Entry Checklist: From Track Choice to Final Demo

How do you choose a Web3 hackathon track?

Choose the track whose published prompt best matches what your project already demonstrates. A persuasive track fit is specific: you can point to a feature, user flow or technical choice that answers the prompt, rather than relying on a broad claim that the project belongs in Web3.

Before committing, put the track description beside your current build and answer these questions:

• Which user problem named or implied by the prompt does the project address?
• What can a reviewer actually see working today?
• Which blockchain or Web3 element is essential to that user flow?
• Does the project meet the track’s stated eligibility and submission requirements?

Then compare the fit with your remaining build time. A narrower track with a demonstrable feature is often easier to explain than a broad track that would require major unfinished work. Do not infer judging criteria from a track name; use the organizer’s published description and ask for clarification if it leaves a material question open.

Write a one-sentence fit statement before you lock the choice: “For [user], this project does [job], using [Web3 element], which addresses [track prompt].” If you cannot complete that sentence with evidence from the build, revisit the track or reduce the claim. For context on contest formats, see crypto, NFT and Web3 contests.

What to include in a blockchain hackathon project

A complete project entry connects the problem, solution and working evidence without asking the reviewer to fill in missing context. Present a concise explanation first, then make the code, deployed experience and supporting materials easy to inspect.

Use this submission checklist as you assemble the entry:

• Project summary: name the intended user, the problem and the specific solution.
• Web3 role: explain what the blockchain component enables in the product, in plain language.
• Current status: distinguish implemented features from planned work. Label prototypes and mock data clearly.
• Technical evidence: provide the repository, deployment or test-network details required by the event. Confirm each link opens and does not require private access.
• Team and acknowledgements: identify contributors and disclose third-party tools, assets or code where the rules ask for it.
• Setup instructions: give a reviewer a short route to run or inspect the project, including prerequisites and known limitations.

Keep the written claims aligned with the actual build. If a feature is represented by a mock, say so; if a wallet connection is required, state that before the reviewer reaches the demo. Check the event’s exact field list instead of assuming every hackathon wants the same materials. A useful final test is to hand the entry to someone unfamiliar with the project and ask them to explain what it does after reading the summary.

Web3 hackathon demo tips for a clear walkthrough

A useful demo shows one complete user journey and makes the project’s central claim visible. Start with the user’s problem, move through the working flow, and finish by explaining which part uses Web3 and why that choice matters to the product.

Plan a short walkthrough around actions rather than slides:

• Open on the product state the reviewer needs to understand, not a long introduction.
• Show the key action from start to finish, including wallet or network steps when they are part of the experience.
• Narrate what the user sees and what the system does; do not rely on unexplained technical labels.
• If the flow uses a test environment, identify it and clarify what is or is not persistent.
• Close with the current build boundary and one credible next development step.

Before recording or presenting, test the demo using the same access path a reviewer will receive. Check the correct network, permissions, sample data, loading states and any external service the walkthrough depends on. Keep a recording available as a fallback if live access is interrupted, and ensure it shows the real interface rather than a concept-only mockup. A backup supports the presentation; it should not conceal a feature that is unavailable in the submitted build.

Make the code and evidence easy to verify

A reviewer should be able to move from your claims to the relevant evidence without guessing where to look. Organize the repository and supporting links around the project’s core flow, and make the state of each component clear.

Review the package from a fresh session:

• Confirm the repository, demo, documentation and any contract or explorer links are public or have the access settings required by the event.
• Check that the README explains prerequisites, setup and the route to the main feature.
• Remove secrets and private credentials from shared files; use the project’s safe configuration approach instead.
• Label test-network addresses, sample transactions and mock data so they cannot be mistaken for production behavior.
• Verify that the submitted links point to the final version, not an earlier branch or draft.

For blockchain evidence, provide the exact network and address needed to inspect the relevant deployment, if the event requests it. Do not imply an audit, production readiness or security property that your team has not established. If there is a known limitation, state it briefly alongside the affected feature and explain how to reproduce it. This kind of precision helps reviewers assess what exists without inflating claims or leaving them to infer the project’s status.

Check the hackathon rules before sharing your entry

The organizer’s rules determine which materials, collaborations and forms of promotion are allowed. Read the current rules before publishing a demo or inviting an audience, and resolve any uncertainty with the organizer rather than assuming a common practice applies to this event.

Check the rules for eligibility, team composition, permitted tools, intellectual property, open-source requirements, submission edits and any restrictions on outside promotion. Also verify whether a public vote is part of the format, how it works and whether promotional requests are permitted. If the rules prohibit outside promotion, do not run it. When sharing is allowed, invite people to review or try the project honestly and give them the official instructions; never offer incentives that the rules do not permit.

We do not sell votes, followers or engagement, and we do not use bots, scripts, fake accounts or click farms. We take on contest work only when promotion can follow white-hat methods and stay in line with platform rules and contest rules. For a rules-first review, use the contest rules and risk check; for an overview of the work available, see contest marketing.

Run a final crypto hackathon submission checklist

A final review checks consistency across the track, written entry, repository and demo. Read the submission as a reviewer would: follow its links, test its instructions and confirm that each claim matches the current build.

Use this last pass before you submit:

• The chosen track fits the visible project and its published prompt.
• Every required form field is complete, and the project summary matches the demo.
• Each link opens with the expected access, and the repository points to the final version.
• The demo has been tested from the reviewer’s perspective, with a fallback ready.
• Limitations, test environments, mock data and third-party contributions are clearly disclosed where relevant.
• Any planned outreach complies with both the contest’s rules and the platform’s rules.

If the entry is ready but you want help planning permitted outreach, prepare the organizer’s rules, your draft submission, demo link and the audience you want to reach. DigitalMedia1 can review those materials and outline suitable next steps; the work and reporting are agreed before it starts. Request a free contest analysis and send us your materials to begin.