HackCanton S2 gives builders five weeks to ship a Canton-native MVP. Here’s the roadmap, bounty lanes, tools, dates, and build ideas for Canton teams.
A hackathon repo can die surprisingly fast.
The landing page looks polished. The еудупкфь is loud. Somebody creates a monorepo, another person adds a dashboard, and three weeks later the team is still arguing about architecture while the submission form is already open.
HackCanton Season 2 is built to avoid that pattern.
The goal is not to deploy “something on Canton.” The goal is to prove a workflow that becomes better because Canton exists: a trade where counterparties should not expose their full order details, a lending flow with controlled collateral visibility, an invoice that moves between a supplier, buyer, and financier, or a treasury action that requires several approvals before settlement.
This article is the map: where the season stands, what happens next, which tracks and bounty lanes are open, which tools can save you time, and how to scope an MVP that judges can understand in minutes.
HackCanton S2 in 60 Seconds
HackCanton Season 2 is a five-week online builder program organized by NODERS and AppsFactory for teams building on Canton Network.
The Opening Ceremony took place on July 3. The build phase is now live.
| Milestone | Date |
|---|---|
| Opening Ceremony | July 3, 2026, 15:00 UTC |
| Build phase | July 4–26 |
| Closing Ceremony | July 25, 15:00 UTC |
| Submission deadline | July 25, 23:59 UTC |
| Async judging | July 27–August 2 |
| Finalists announced | August 2 |
| Grand Final | August 5, 14:00 UTC |
The main pool includes $25K in cash and $25K in credits and perks, with additional CBTC and cETH challenges worth 50,000 CC each.
Deadline rule: although the delivery phase is listed through July 26, submissions close on July 25 at 23:59 UTC. Build your schedule around the submission deadline, not the phase label.
Missed the kickoff? Watch the Opening Ceremony replay.
Why Canton Changes the Way You Design an App
Canton’s most useful feature for a builder is not a headline TPS number. It is sub-transaction privacy.
A single atomic transaction can contain different views for different stakeholder groups. Each party receives the part of the workflow it is authorized to see rather than the full transaction tree.
That changes the first engineering question.
On a typical public chain, a team may start with:
What contract should we deploy?
A stronger Canton team starts with:
Who participates, what can each party see, who can act, and what must settle together?
This is the mental model behind Daml and Canton-native application design. Contracts represent agreements between parties; choices define who may move the workflow forward; signatories and observers define authorization and visibility.
Use this lightweight spec before touching the code:
User:
Problem:
Parties:
- Party A:
- Party B:
- Optional auditor / operator:
Visibility:
- Party A can see:
- Party B can see:
- Nobody else should see:
Actions:
- Who creates the agreement?
- Who approves or rejects it?
- Who can cancel or amend it?
Atomic state change:
- What assets, rights, or obligations move together?
Demo proof:
- What must work end to end for the MVP to be credible?
If your team cannot complete this page, the idea is probably not ready for implementation.
Your Route Through the Hackathon
Treat HackCanton as a product sprint rather than an open-ended research project.
1. Pick one workflow
Do not start with “a DeFi platform,” “an RWA marketplace,” or “an AI financial ecosystem.” Those are categories, not products.
Start with one concrete flow:
- a trading desk requests a private CBTC quote;
- a supplier submits an invoice and a buyer confirms it;
- a treasury agent proposes a payment that requires human approval;
- a borrower posts cETH collateral and opens a credit position;
- an issuer updates one stage of an asset lifecycle.
A useful project statement is:
We help
[user]complete[workflow]on Canton because[privacy, permissions, settlement, or auditability]matters.
Example:
We help trading desks settle private CBTC block trades without exposing size and terms to the wider market.
2. Choose the track after the workflow
HackCanton has five main tracks.
| Track | Good fit for |
|---|---|
| RWA and Business Workflows | Asset issuance, lifecycle management, invoice flows, delivery-versus-payment |
| Financial Apps | Trading, lending, collateral, prediction markets, liquidity and settlement |
| Investment Infrastructure | Funds, treasury operations, governance and investor approvals |
| Data and Analytics | Portfolio tools, liquidity views, validator analytics and app monitoring |
| Open Track | Wallet UX, developer tooling, agents, identity and new primitives |
The track should describe what you are already building. Do not distort the product to fit a category.
3. Select only the tooling you need
You do not receive extra points for integrating every sponsor.
Pick the shortest route to a working flow:
- use CBTC if Bitcoin is collateral, settlement, liquidity, or the traded asset;
- use cETH if ETH drives an actual application state change;
- use Console Wallet when signing and asset movement are central to the UX;
- use CC View when your product depends on real Canton activity or analytics;
- use Ginie to accelerate an already-defined Daml workflow;
- use the official Canton Quickstart when you need a full local reference stack.
The winning integration is the one the application actually needs.
The Two Asset Bounty Lanes
CBTC: Build Bitcoin Products That Keep Running
CBTC is a 1:1 Bitcoin-backed token on Canton. The BitSafe challenge is aimed at products that create recurring CBTC activity and could continue as live applications after the hackathon.
The challenge pool is 50,000 CC:
| Place | Prize |
|---|---|
| 1st | 30,000 CC |
| 2nd | 15,000 CC |
| 3rd | 5,000 CC |
Useful directions include:
- prediction markets settled in CBTC;
- market-making and routing tools;
- private RFQ and OTC settlement;
- lending and multi-asset collateral vaults;
- position, liquidity, and venue analytics;
- liquidation keepers or risk-monitoring agents.
The hard requirement is meaningful integration. CBTC should move, settle, secure a position, route liquidity, or otherwise affect the application state. A balance widget with a CBTC logo is not a bounty submission.
Eligible projects need a working prototype, public GitHub repository, integration documentation in the README, and a demo video of up to three minutes. Teams may contain one to five builders.
cETH: Give ETH a Job on Canton
cETH is a 1:1 representation of ETH on Canton and follows the Canton Token Standard, CIP-0056. It can be integrated into Canton wallets, exchanges, and applications as an asset for trading, collateral, lending, liquidity, or settlement.
The cETH challenge also offers 50,000 CC:
| Place | Prize |
|---|---|
| 1st | 25,000 CC |
| 2nd | 15,000 CC |
| 3rd | 10,000 CC |
Strong directions include:
- cETH order books, AMMs, or RFQ systems;
- liquidity routing across Canton venues;
- lending markets and credit lines;
- multi-asset vaults;
- cross-margin workflows;
- treasury and collateral-monitoring tools.
The key qualification is simple:
cETH must drive a state change.
Displaying a balance is not enough. The asset should be transferred, locked, borrowed, settled, routed, or used as collateral.
Teams also need a public repository, incremental commit history, a concise README, a working prototype, and a demo video of no more than three minutes.
Tools That Can Save a Week
Official Canton Quickstart
The Canton Network Quickstart is the most complete starting point for teams that want a working full-stack reference application.
It includes:
- Daml contracts;
- a Java backend;
- a React frontend;
- LocalNet for multi-party testing;
- wallet and Canton Coin flows;
- tooling for running and debugging the application locally.
Do not replace the example app line by line. Use it to understand how Daml, the backend, the frontend, wallets, and the ledger connect, then cut away everything your MVP does not need.
The official Canton developer documentation also covers Daml, application architecture, APIs, SDKs, privacy patterns, testing, and DevNet deployment.
Ginie
Ginie is an AI-assisted development layer for Canton. Builders can describe a workflow in plain English, generate Daml, compile it with the SDK, run automated checks, and deploy the result.
This is useful when the workflow is already specific:
Create an agreement between a borrower, lender, and auditor.
The lender and auditor can view the collateral terms.
Only the borrower and lender can view the interest rate.
The lender can approve or reject the loan.
Settlement transfers the asset only after approval.
It is less useful when the input is:
Build a private DeFi platform.
AI can accelerate implementation. It cannot rescue an undefined product.
PixelPlex Tools
PixelPlex contributes several practical Canton tools:
- Console Wallet for signing, balances, asset transfers, and dApp interaction;
- CC View for Canton explorer data, analytics, monitoring, and network context;
- CC Tag for human-readable names across wallets, applications, teams, and invoices.
These tools matter because a correct contract can still produce a terrible demo. Judges need to see who is acting, what is being signed, what changed, and where the asset moved.
A Seven-Day Build Plan
Day 1: Freeze the problem
Write the user, workflow, parties, visibility rules, and final state change. Remove features until the flow fits on one page.
Day 2: Prove Canton fit
Explain why the product becomes weaker on a fully transparent network. If privacy, authorization, or atomic settlement is not essential, reconsider the idea.
Day 3: Choose the stack
Decide whether you need Daml directly, Quickstart, Ginie, an asset integration, wallet UX, or analytics. Avoid adding tools “just in case.”
Day 4: Build the ledger flow first
Get the agreement lifecycle working before polishing the frontend. Create the contract, exercise the choice, and verify visibility between parties.
Day 5: Connect one usable interface
Build only the screens required to demonstrate the workflow. A three-screen product with a complete flow is better than a twelve-screen dashboard with fake buttons.
Day 6: Run the demo end to end
Record the flow once. Every point where you have to explain “this part is mocked” becomes the next engineering task.
Day 7: Start the submission package
Write the README and record a rough demo early. Do not discover on submission day that nobody outside the team understands the architecture.
What Judges Need to Understand Quickly
A judge should be able to answer these questions after watching your demo:
- Who has the problem?
- What happens today without the product?
- Which parties participate?
- What can each party see?
- What action changes the state?
- Where does Canton create an advantage?
- Does the core flow actually work?
- Could this become a live application?
Your demo should follow the same order.
Do not begin with a market-size slide or a long Canton explanation. Show the user, the problem, and the transaction.
Submission Checklist
Prepare these items while you build:
- [ ] Working MVP or prototype
- [ ] Public GitHub repository
- [ ] Incremental commit history
- [ ] README with setup instructions
- [ ] Architecture and party model
- [ ] Explanation of the Canton advantage
- [ ] Clear CBTC or cETH integration, when applicable
- [ ] Demo video within the required limit
- [ ] Product screenshots
- [ ] Track and bounty selection
- [ ] Next-step plan after the hackathon
A clean README should explain:
1. The problem
2. The users and parties
3. The workflow
4. Visibility and authorization
5. Architecture
6. How to run the project
7. How CBTC or cETH is used
8. What is working today
9. What comes next
Common Ways to Lose Time
- Building the platform before the workflow A full lending protocol is too broad. One collateral agreement is testable.
- Copying a public-chain app Canton should affect the architecture, not only the deployment target.
- Treating privacy as marketing copy Visibility must appear in the party model and demo.
- Adding CBTC or cETH at the end An asset integration should change the core flow, not decorate the UI.
- Waiting until submission week to write the README Documentation often exposes architectural confusion earlier than code review does.
- Shipping a beautiful frontend with no state transition Judges need to see the ledger workflow complete.
Sponsor and Builder Links
BitSafe / CBTC
onRails / cETH
PixelPlex
Ginie
HackCanton and Canton Network
- HackCanton Season 2
- AppsFactory
- Canton Network
- Developer documentation
- Quickstart
- AppsFactory Telegram
- AppsFactory Discord
Build the Smallest Thing That Proves the Point
HackCanton S2 gives teams enough time to build a credible MVP, but not enough time to hide a fuzzy idea behind a large codebase.
Start with one user and one broken workflow. Map the parties. Decide who sees what. Make one meaningful state transition work from beginning to end. Then add the asset, interface, analytics, or automation that makes the product useful.
A narrow CBTC settlement flow can become a trading product. A cETH collateral prototype can become a lending market. A three-party invoice workflow can become financing infrastructure.
The first version does not need to be large.
It needs to make Canton necessary.
Top comments (0)