Skip to content
ETH Canal
Menu

Hackathons

A builder sprint designed for teams that want to ship real work.

The 2026 hackathon is built around real output, hands-on support, and momentum that continues after demo day.

Build Window
April 2026
Focus
Useful technical output with credible follow-through
Output
Repo, demo, scope statement, and next steps
Community illustration representing collaborative builder work.

Core Tracks

Public tracks should be broad enough to stay useful and specific enough to shape submissions.

These tracks give teams a clear sense of what ETH Canal wants to encourage without boxing the program into short-lived categories.

Protocol and infrastructure tooling

Reliability, core primitives, and upgrades that improve the Ethereum builder stack.

Security and resilience

Auditable improvements, better guardrails, and operational quality that holds up after the demo.

Developer experience and onboarding

Tools, workflows, and teaching surfaces that make the ecosystem easier to enter and contribute to.

Real-world use cases for LATAM

Projects that connect Ethereum infrastructure to practical local needs without collapsing into generic fintech theater.

Participation Model

A build sprint needs clear checkpoints.

The more clearly the process is framed, the easier it is for teams, mentors, and judges to move with confidence.

  1. Kickoff

    Program framing

    Teams align on tracks, judge expectations, and the difference between a concept deck and a credible submission.

  2. During the sprint

    Mentor checkpoints

    Mentors provide architecture feedback and technical unblock support. Sponsors can back tracks, but public rules stay uniform.

  3. Submission

    Structured demo output

    Each team submits a repository, short demo, scope summary, dependency list, and a candid implementation status.

  4. After judging

    Follow-on paths

    Promising teams move into incubator support, partner intros, grants, or contributor pipelines.

Submission Expectations

Demo day should never feel like a black box.

Teams should know what to submit and how quality will be judged before they write the first line of code.

Required outputs

  • Public repository link and commit history
  • Short product or technical demo
  • Clear scope statement and implementation status
  • Explicit dependencies, assumptions, and next steps

Judge principles

  • Technical quality and maintainability
  • Clarity of execution
  • Usefulness to builders or operators
  • Alignment to the chosen track and stated constraints