NODERS

Posted on May 29

HackCanton Season 1: Canton Builders, Demos, Winners

#hackathon #web3 #blockchain #startup

Some hackathons are built like fireworks.

Bright launch. Loud countdown. Forty-eight hours of chaos. A few demos. A few prizes. Then the repo goes quiet, the group chat slowly dies, and everyone moves on.

HackCanton Season 1 was built for a different kind of flame.

Less flash. More heat.

For 21 days, builders, founders, developers, product people, mentors, judges, and ecosystem partners moved through one focused experiment:

Can a hackathon become something more serious than a weekend sprint?

Could it become a structured path from a rough idea to a real Canton MVP?

Could it help teams not only write code, but also understand their users, sharpen their business case, test their assumptions, and explain why their product needed Canton in the first place?

That was the bet.

HackCanton Season 1 ran from April 15 to May 15, 2026. It started with a platform demo and a private builder hub. It ended with a live Grand Final, shipped MVPs, judge feedback, winners, and a much clearer map of what the Canton builder ecosystem can become.

And for a first season, that is exactly the kind of signal you want.

HackCanton Season 1 in Numbers

The numbers tell one part of the story.

Metric	Result
Builders who entered the flow	300+
Registered teams	81
Teams that opened project journals	53
Teams with real stage progress	26
Teams submitted for judging	21
Teams that appeared in the live Grand Final	9
Live streams and workshops	6
Build phase duration	21 days

But numbers are only the surface.

The real story is what happened in the middle.

People formed teams in public. Projects pivoted. Teams got stuck on ICP, validation, DevNet, demo links, DAR uploads, Mana, onboarding, and the uncomfortable question every builder eventually hits:

“Is this actually a product, or just a cool idea?”

That messy middle is where HackCanton Season 1 found its shape.

Because building is not clean.

It is not a straight line from idea to demo. It is more like walking through fog with a compass that only starts working after you write down what you learned yesterday.

Some ideas got sharper.

Some got smaller.

Some got killed.

Some became real only after one honest conversation with a user, mentor, or teammate.

HackCanton was designed for that exact zone: the place where most hackathon projects usually disappear.

And Season 1 proved the format has teeth.

What Made HackCanton Different

HackCanton was not a classic weekend sprint with a Canton logo slapped on top.

It was closer to a lightweight startup pressure chamber.

The format combined three layers

Layer	What it meant in practice
Hackathon	Teams still had to ship a working product or credible MVP.
Incubator	Teams had to think through the user, market, problem, and validation.
Accelerator	Strong teams were pushed toward post-hackathon support, ecosystem access, infrastructure, and future seasons.

That structure mattered.

Every team moved through the same core path:

Problem → ICP → Validation → GTM → MVP → Pitch

Simple on paper.

Brutal in practice.

Because it forced teams to answer the questions most builders prefer to delay.

The questions every team had to face

Who exactly is this for?
What pain does that user actually feel?
Why now?
Why Canton?
What is the smallest version that proves the product works?
How do you reach the first ten users?
What evidence says this thing deserves to exist?

The AppsFactory platform turned that process into a daily build loop. Teams maintained AI-powered project journals, recorded progress, answered prompts, burned Mana, updated stage documents, and gradually turned vague product energy into something judges could evaluate.

The AI journal was not just a notes field.

It became the black box recorder of the build process.

Mentors and judges could see more than the final pitch. They could see pivots, false starts, rough assumptions, user thinking, technical decisions, and how teams responded when reality pushed back.

That changed the incentives.

The goal was not to look perfect on the final day.

The goal was to keep showing up, keep documenting, keep narrowing, keep building.

In other words: not vibes, but progress.

For developers, this is important.

Most hackathons reward the last-minute demo effect. A nice UI, a clever pitch, a few working screens, and suddenly the project looks stronger than it really is.

HackCanton Season 1 pushed in the opposite direction.

It rewarded the path:

What did you learn?
What changed?
What did you validate?
What did you cut?
What did you actually ship?
Why does Canton matter here?

That made the builder journey visible.

And in an ecosystem as technically specific as Canton, that visibility matters.

Why Canton Made the Hackathon More Interesting

HackCanton Season 1 was focused on Canton Network because Canton creates a very different builder playground from a typical public-chain hackathon.

Most crypto hackathons orbit familiar territory: tokens, swaps, dashboards, staking, NFTs, governance wrappers, DeFi variations, and some AI agent magic sprinkled on top.

Canton asks a harder question:

What can you build when privacy is not a patch, but part of the architecture?

Canton is a privacy-first blockchain architecture built for institutional finance, multi-party workflows, DAML smart contracts, selective disclosure, and applications where different parties should not see the same data by default.

That one design choice changes the product space.

A prediction market can become private by design.

A block-trade venue can settle atomic swaps without exposing sensitive intent to the whole market.

A treasury workflow can let institutions collaborate without leaking internal state.

A real-world asset system can model issuers, holders, observers, approvals, audit trails, and settlement logic with more nuance than “everyone sees everything forever.”

That is why HackCanton was never just “build a crypto app.”

The challenge was more specific:

Build something that makes sense because Canton exists.

For a developer, that is the real test.

Not “can I connect a wallet?”

Not “can I write a contract?”

Not “can I show a dashboard?”

But:

Would this product be weaker if Canton did not exist?

If the answer is yes, you are probably in the right design space.

HackCanton Season 1 Tracks

The tracks were built around real ecosystem gaps, not abstract categories.

Track	Focus
Real-World Assets and Business Workflows	Issuance, state changes, transfers, fulfillment, audit, and pilot-ready workflows.
Financial Applications, DeFi, Exchanges, and Prediction Markets	Trading, lending, prediction markets, yield tools, and real economic activity.
Investment Infrastructure, Funds, DAOs, and Governance Tools	Capital coordination, fund workflows, governance, and role-based decision systems.
Data, Analytics, and Ecosystem Dashboards	Network visibility, analytics, metrics, validators, and ecosystem intelligence.
Open Track	Any Canton-native MVP that did not fit neatly into another category.

The strongest teams understood this quickly.

Canton could not be decoration. It had to be structural.

If a project could run just as well on any generic chain, the Canton story was weak. But if privacy, role-based visibility, multi-party workflows, institutional-grade settlement, or DAML-based business logic were central to the product, the pitch became much stronger.

That distinction shaped the entire season.

Timeline: 21 Days of Pressure

HackCanton Season 1 opened on April 15 with the Opening Ceremony and platform demo.

The opening session introduced the rules of the game: the platform, AI journal, Mana mechanic, tracks, judging criteria, materials, submission flow, and the full path from problem to pitch.

Then the build phase began.

Week 1: Orientation, Team Formation, and Problem Pressure

The first days were onboarding, orientation, and controlled chaos.

Some participants were already deep in product ideas. Others arrived solo and started looking for teammates. Some were learning Canton from scratch. Some were debugging access.

Some were asking whether solo submissions were allowed, whether local sandbox was enough, whether projects could be private, whether multiple submissions were possible, whether judges cared about GitHub links, and what exactly “Canton fit” meant.

That was the point.

The hackathon was not only a competition. It was a live learning environment.

By Day 3, the platform already had dozens of active teams, public projects, journals, and early signs of momentum.

The organizer message at that stage was important:

Pressure-test the problem, not the idea.

Not the feature list.

Not the pitch deck.

The problem.

Is it real? Is it specific? Does the user actually feel it?

That became one of the season’s recurring themes. A good Canton MVP was not just about using DAML or touching DevNet. It needed a real user, a clear pain, a sharp workflow, and a reason the product belonged in this ecosystem.

For devs, this can be uncomfortable.

Many of us like starting with architecture. Or tooling. Or “what can I technically make work by Sunday night?”

But Season 1 kept pushing teams back to a more useful starting point:

Who has the problem, and why would they care?

That is where better software starts.

Week 2: Validation, GTM, MVP Scope, and Technical Reality

By the second week, the tone shifted.

The early excitement gave way to the harder work: validation, GTM, MVP scope, user flows, demo prep, and the constant reminder that adding more features was often less useful than making one workflow understandable.

This is where the hackathon started to feel less like a sprint and more like a product discipline test.

Teams had to decide what not to build.

They had to narrow their pitch.

They had to turn “Canton is cool” into:

“This specific product needs Canton because…”

That sentence is harder than it looks.

And it is exactly the kind of sentence serious builders need to answer.

A good MVP is not a smaller version of a huge product.

A good MVP is a sharp proof of one important workflow.

That distinction became more obvious as the season moved forward.

Final Week: Submission Pressure

By the final week, the energy changed again.

Submission pressure kicked in.

Teams were cleaning up docs, compressing PDFs, fixing demo URLs, burning Mana, asking about repo privacy, preparing videos, pushing DAR files, and trying to make their product pages readable enough for async judging.

On May 6, submissions closed.
From May 7 to May 13, judges reviewed projects asynchronously on the platform.
On May 13, finalists were announced.
On May 15, the Grand Final went live.

Grand Final recording:
https://youtu.be/6zjnGw9l4Ng

That final stream was not just a showcase. It was the moment the Season 1 experiment became visible: real teams, real products, real demos, and a real sense that Canton now had more builders than it did a month earlier.

Judging: Async Review and Live Grand Final

HackCanton Season 1 used a two-stage judging process.

First came async judging, where judges reviewed submitted projects on the platform. That review covered project files, stage documents, journals, demos, and submitted materials.

The async judging panel included representatives from:

Decasonic
Bing Ventures
Contribution Capital
DWF Ventures
Quantstamp
NODERS LLC
Canton Foundation

The strongest teams then moved into the Grand Final, where they pitched live in front of a judging panel made up of analysts, engineers, principals, and developer relations leads from top funds and ecosystem partners.

The Grand Final judging panel included representatives from:

DWF Ventures
LongHash Ventures
Scytale Digital
Panther Hollow Ventures
Contribution Capital
Chainlink
JSquare
Quantstamp
Canton Foundation
NODERS LLC

The live format was simple and strict: each team had 5 minutes to pitch, followed by 2 minutes of Q&A.

Winners were announced live at the end.

That structure gave teams two different tests.

Async judging tested the depth of the work.
The Grand Final tested the clarity of the story.

Both mattered.

A project page can show the journey.

A live pitch shows whether the team can make other people believe in it.

For developers, this is a useful lesson.

A strong project is not only what runs locally. It is also what other people can understand, evaluate, test, and believe in.

Workshop Track: Turning Canton From “Interesting” Into Buildable

Canton is powerful, but it is not always obvious on day one.

The architecture is different. DAML is different. The mental model is different.

Parties, signatories, observers, choices, validators, synchronizers, activity markers, Featured Apps, DAR uploads, ledger APIs — this is not a beginner-friendly word cloud.

So Season 1 needed more than hype.

It needed a learning track.

Full HackCanton playlist:
https://www.youtube.com/playlist?list=PLj4LwPb3JvuSqNXry2Hle8RqbJ5qTLVul

Opening Ceremony: The Builder Map

The Opening Ceremony gave participants the map: how the platform worked, what judges would review, how projects should be submitted, and why the AI journal mattered.

It also set the tone for the whole season:

This would not be a “submit and disappear” hackathon.
This would be a documented build journey.

Canton 101: DAML, Featured dApps & Tokenomics

This was the “okay, what are we actually building on?” session.

Jatin Pandya from Canton Foundation broke down Canton’s privacy-first architecture, DAML smart contracts, parties, signatories, observers, choices, Featured Apps, activity markers, Canton Coin, and the tokenomics logic around network activity.

For builders coming from Solidity, Rust, Go, or traditional backend development, this mattered.

DAML was not presented as just another smart contract language. It was framed as a workflow language where access control, stakeholders, and multi-party logic are first-class concerns.

That is a big mental shift.

In Solidity, developers often think in functions and state transitions.

In DAML, they need to think in parties, rights, visibility, authorization, and who is allowed to see or exercise what.

That shift unlocked a lot of Season 1 product thinking.

If you are used to EVM-style mental models, Canton can feel unusual at first. But that is also where its product potential comes from.

You are not only asking:

What does this function do?

You are asking:

Who can see this?
Who can act on this?
Who needs to consent?
What should remain private?
What should be shared?
What should be auditable?

That is a more enterprise-shaped way to think about smart contracts.

Canton Node + NaaS Workshop

This session answered the practical infrastructure question:

How do teams actually get something running?

Kiryl from NODERS walked through the local sandbox, the shared HackCanton DevNet node, party provisioning, API access, DAR deployment, logs, debugging, and the trade-offs between running your own node and using managed infrastructure.

This was not abstract DevRel content.

It directly addressed the things teams were hitting during the hackathon: OAuth, JSON Ledger API, DevNet access, package deployment, logs, and when a separate node is overkill for an MVP demo.

For many teams, this was the difference between “we are stuck” and “we can keep moving.”

That kind of infrastructure support matters.

A developer can have a strong product idea and still lose days to environment setup, auth issues, deployment confusion, or missing logs.

Season 1 made those problems visible and started building the support layer around them.

Go-DAML & Go-Wallet Workshop

For Go teams, this was one of the most practical sessions of the season.

Go-DAML gives developers a Go client for DAML ledger integration, including bindings, command submission, query flows, package and user management, and gRPC Ledger API support.

Go-Wallet builds on top of that for wallet flows, token operations, balances, transfers, and external party workflows.

That matters because many Canton products will not live only in a smart contract IDE. They need real backends, real APIs, real services, and integration with existing software stacks.

A good MVP is rarely just a contract.

It is usually a contract, an app, a backend, a user flow, a demo, and a story that ties all of it together.

Discover Modo

Modo joined with a workshop focused on data infrastructure.

The session helped teams understand how to work with Canton data: explorer views, APIs, structured activity, transfer tracking, portfolio context, and network signals.

For builders racing toward submission, this was valuable because it reduced guesswork.

A product is stronger when it can use real ecosystem data instead of vague assumptions.

That is especially true for dashboards, analytics products, trading tools, validator tooling, and apps where usage data becomes part of the product experience.

Closing Ceremony

The Closing Ceremony wrapped the build phase and explained the next steps: async judging, finalist selection, Grand Final flow, pitch format, feedback, and what could happen after HackCanton.

By the end of the workshop track, Season 1 had given builders more than encouragement.

It gave them a technical runway.

Tools Builders Used During HackCanton

HackCanton did not send teams into the Canton jungle with a motivational quote and a deadline.

The platform collected materials, docs, SDKs, APIs, explorers, DevNet details, partner tools, and workshop recordings in one place.

Builders had access to Canton documentation, DAML resources, CN Quickstart, DAML Studio, DevNet node materials, JSON Ledger API details, SDKs, explorers, and ecosystem tooling.

Key tools and resources

Tool / Resource	Role in the season
Go-DAML SDK	Go client for DAML ledger integration.
Go-Wallet DAML SDK	Wallet flows, token operations, balances, transfers, and external party workflows.
Canton Loop Wallet	Wallet access and ecosystem onboarding via Five North.
Lighthouse Explorer	Canton explorer tooling from Five North.
Seaport	DAML development platform from Five North.
Modo	Canton explorer, API access, structured data, and network context.
Silvana	Private orderbooks, DvP settlement, RWA workflows, APIs, and institutional privacy patterns.

NODERS provided two open-source Go SDKs:

Modo docs:

https://docs.modo.link

Silvana docs:

https://docs.silvana.one

These tools were not side quests.

They were part of how teams moved from “Canton sounds interesting” to “we can actually build with this.”

A strong hackathon ecosystem is not only about prize money. It is about reducing the distance between curiosity and execution.

Season 1 did that well.

Sponsors and Ecosystem Partners

HackCanton Season 1 was not built by one team in isolation.

A strong builder program needs more than a platform and a deadline. It needs tools, infrastructure, data, ecosystem context, and people who are willing to show up before everything is polished.

That is why the support from Season 1 partners mattered.

Modo

Modo helped teams work with Canton data in a more practical way.

During the season, Modo supported builders with ecosystem data access, explorer context, API resources, and a dedicated workshop focused on how teams can use real Canton network signals instead of guessing.

For builders working on analytics, dashboards, trading tools, ecosystem intelligence, or user-facing products, that kind of data layer is important.

A product gets stronger when it can understand what is actually happening on the network.

Links:

Modo Website: https://modo.link/
Modo X: https://x.com/modoapps
Modo Discord: https://discord.com/invite/8eTJ5XRdxC
Modo Canton Explorer: https://cc.modo.link/

Silvana

Silvana brought a strong financial infrastructure angle to the season.

Its work around private orderbooks, DvP settlement, RWA workflows, APIs, and institutional privacy patterns gave builders a useful reference point for what Canton-native financial applications can look like.

That mattered because many HackCanton teams were exploring products where privacy, counterparties, settlement, and asset movement are not side details.

They are the core of the product.

Links:

Silvana Website: https://silvana.one/
Silvana X: https://x.com/silvana_book

Five North

Five North supported Season 1 with practical ecosystem tools for Canton builders.

Teams interacted with products and resources such as Canton Loop, Lighthouse Explorer, and Seaport - tools that helped with wallet access, ecosystem exploration, and DAML development workflows.

For a new builder entering Canton, this kind of tooling lowers the entry barrier.

It turns "where do I even start?" into "I can try this now."

Links:

Five North Website: https://www.fivenorthdigital.com/
Five North X: https://x.com/FiveNorthHQ
Lighthouse - Canton Blockchain Explorer: https://lighthouse.xyz/
CantonLoop: https://cantonloop.com/
Seaport: https://seaport.to/

Grand Final: The Live Test

After async judging, the strongest projects moved to the Grand Final.

The live final took place on May 15 from 14:00 to 16:00 UTC on Zoom and YouTube stream.

Each team had 5 minutes to pitch and 2 minutes for Q&A.

Nine teams appeared in the live Grand Final.

The format was intense by design.

Five minutes is not enough time to hide behind complexity. Teams had to make the problem clear, explain the product, show the Canton fit, and give judges enough confidence that the project was more than a demo.

That is a very different skill from simply submitting a project page.

The async stage rewarded depth.

The live stage rewarded clarity under pressure.

Together, they made the final feel like a real product test.

HackCanton Season 1 Winners

At the end of the Grand Final, the judges selected three winners.

1st Place — Confimarket

Confimarket built a privacy-first prediction market on Canton.

It won because the full package landed.

The problem was understandable. The category was real. The Canton fit was strong. The narrative was clean. The user-facing experience made sense.

Privacy was not pasted onto the pitch as a buzzword; it was part of the product’s reason to exist.

Prediction markets are already a powerful category. On Canton, the question becomes more interesting:

What happens when market participation, positions, settlement, and sensitive information can be modeled with privacy-aware infrastructure?

Confimarket made that question feel tangible.

That is why it took first place.

2nd Place — Swap.Monster

Swap.Monster built a large block-trade venue for atomic swaps on Canton.

The idea was sharp because it spoke directly to an institutional pain point: large trades can move markets, leak intent, and create execution risk.

A Canton-native block-trade venue makes intuitive sense. Atomic settlement, privacy-aware workflows, and reduced information leakage are not decorative features here.

They are the product.

Swap.Monster did what strong hackathon projects do: it connected a real market problem to a technical architecture in a way judges could immediately understand.

The vision was clear.

The Canton fit was undeniable.

3rd Place — IRSForge

IRSForge built interest rate hedging infrastructure on Canton.

This was one of the most technically and financially serious projects in the cohort.

The project targeted a clear gap: if Canton is becoming infrastructure for serious financial settlement, then tools for interest rate exposure, credit risk, swaps, and hedging workflows become increasingly relevant.

IRSForge did not chase a lightweight consumer narrative.

It went straight into the deep end of financial infrastructure.

One judge described it as filling a much-needed niche.

That is exactly the kind of project HackCanton wanted to surface: not just something fun, but something the ecosystem may actually need.

Prize Pool and Post-Hackathon Support

HackCanton Season 1 was not only about cash prizes.

The prize structure also included infrastructure and growth support from NODERS.

Placement	Prize
1st place	$5,000 + 3 months NaaS by NODERS at $1,000/month + 3 months Ambassador Program
2nd place	$3,000 + 2 months NaaS by NODERS at $1,000/month + 2 months Ambassador Program
3rd place	$2,000 + 1 month NaaS by NODERS at $1,000/month + 1 month Ambassador Program
All finalists	2 months NaaS by NODERS at $2,700/month

That support mattered because a strong Canton project does not end at a pitch.

Teams need infrastructure, feedback, users, ecosystem context, and a path toward real deployment.

The best hackathon outcome is not a trophy.

It is a product that keeps moving.

Honourable Mentions

Not every strong team made the top three.

Several teams came close and built products with real potential:

RWA Collateral Review
Agora
HumanPass
SyncdicAI Vault
Yapper Agent
Canton Cortex Explorer
ChainFreight
OpenFluid

The message to those teams was simple:

Keep building.

HackCanton Season 1 was never meant to be a one-time contest where everyone who misses the podium disappears into the archive.

Judge feedback, Season 2, platform improvements, ecosystem access, and continued community support are part of the continuation.

Some projects need more time.

Some need a sharper user.

Some need a narrower MVP.

Some need better GTM.

Some are one strong iteration away from becoming genuinely competitive.

That is normal.

That is not failure.

That is building.

What Season 1 Proved

Season 1 proved that Canton builders exist — but they need a clear doorway.

Canton is technically deep. The ecosystem is still early from a developer-experience perspective. The concepts are powerful, but not always obvious.

But when teams get a structured path, live workshops, docs, DevNet access, mentors, examples, partner tools, and a community that answers questions in real time, they start building.

1. Clear onboarding creates builders

Canton is not hard because it lacks potential.

It is hard because the mental model is different.

HackCanton helped reduce that gap by giving builders one place to start, one path to follow, and one community to ask.

2. AI-guided journals can become more than a gimmick

The journals made progress visible.

That matters because most hackathons overvalue the final five minutes and undervalue the three weeks that came before them.

The journal flipped that.

It let mentors and judges see the arc: the assumptions, the pivots, the momentum, the doubts, the evidence, and the actual work.

For developers, that is a useful pattern.

A project log is not bureaucracy when it helps you debug your own thinking.

3. Hackathons can be more founder-oriented

The strongest teams were not only the teams with code.

They were the teams that understood the problem, the user, the GTM, the validation path, and why Canton mattered.

That is a healthier benchmark than “who hacked the most features together before the deadline?”

Because a real product needs more than features.

It needs a reason to exist.

4. Canton has a broad application surface

The cohort produced ideas across prediction markets, OTC trading, credit, treasury, staking, event infrastructure, analytics, real estate, governance, developer tooling, and workflow automation.

That range is important.

It means Canton is not waiting for one killer app narrative.

It can support many.

What Comes Next for HackCanton

HackCanton Season 1 was the first chapter.

Not a polished final product.

Not the finished model.

A strong beta with real signal.

The next season will be sharper:

better onboarding;
stronger mid-season engagement;
more mentors;
more partners;
better workshop timing;
a more polished platform experience from day one.

But the foundation is already there.

AppsFactory is becoming a home base for Canton builders: a place to learn, test ideas, find teammates, use real tools, ship MVPs, get feedback, and move from “I have an idea” to “we built something real.”

Season 1 started with raw ideas.

It ended with shipped products, public demos, judge feedback, live pitches, winners, and a stronger community around Canton.

That is a good start.

Actually, more than good.

It is exactly the kind of start an ecosystem needs.

The first season gave builders a path.

The next one will raise the bar.

Season 2 is next.

FAQ

What was HackCanton Season 1?

HackCanton Season 1 was a 21-day online hackathon and build program for Canton Network developers, founders, and teams. It combined AI-guided journals, structured product stages, technical workshops, mentorship, async judging, and a live Grand Final.

When did HackCanton Season 1 run?

The season ran from April 15 to May 15, 2026. The build phase ended on May 6, async judging ran from May 7 to May 13, and the Grand Final took place on May 15.

Who won HackCanton Season 1?

The top three winners were Confimarket in first place, Swap.Monster in second place, and IRSForge in third place.

What did teams build during HackCanton?

Teams built Canton-native products across prediction markets, OTC trading, interest rate swaps, staking, escrow, real-world assets, event ticketing, analytics, treasury intelligence, developer tooling, and governance infrastructure.

Why was Canton important for the hackathon?

Canton’s privacy-first architecture, DAML smart contracts, multi-party workflows, and selective disclosure model gave builders a different product design space from typical public-chain hackathons.

Who judged HackCanton Season 1?

Async judging included representatives from Decasonic, Bing Ventures, Contribution Capital, DWF Ventures, Quantstamp, NODERS LLC, and Canton Foundation.

The Grand Final judging panel included representatives from DWF Ventures, LongHash Ventures, Scytale Digital, Panther Hollow Ventures, Contribution Capital, Chainlink, JSquare, Quantstamp, Canton Foundation, and NODERS LLC.