diff --git a/LOCKED_DECISIONS.md b/LOCKED_DECISIONS.md index e044bd0..3383577 100644 --- a/LOCKED_DECISIONS.md +++ b/LOCKED_DECISIONS.md @@ -1,13 +1,13 @@ # CommitLedger — Locked Competition Decisions -_Last updated: 2026-09-27_ +_Last updated: 2026-10-07._ -This file is the source of truth for the HackCanton Season 3 build. Do not silently change these decisions. If an official HackCanton rule conflicts with this file, the official rule wins and this file must be updated. +This file is the source of truth for the **Colosseum Crypto World's Fair 2026** submission. If an official Colosseum rule or live portal requirement conflicts with this file, the official requirement wins and this file must be updated. ## Two locked goals -1. **Competition compliance:** follow every verified HackCanton rule and block final submission until every critical unknown has been checked against the official portal/rulebook. -2. **Winning-quality product:** build a top-tier, judgeable Canton-native product where Canton is technically indispensable, while never fabricating traction, transactions, evidence, or official requirements. +1. **Competition compliance:** satisfy every verified Colosseum requirement before submission. +2. **Winning-quality product:** present a judgeable crypto startup where Canton is technically indispensable, while never fabricating traction, transactions, evidence, or official requirements. Neither goal may be traded away for extra features. @@ -22,40 +22,29 @@ GitHub Issue -> Daml Bounty -> Claim -> Pull Request -> GitHub Merge Verificatio ## Competition objective -Build a judge-ready, reproducible Canton-native MVP where Canton is essential to the product's trust, authorization, provenance, and settlement model. +Build a judge-ready, reproducible MVP that demonstrates why multi-party authorization and verifiable settlement improve open-source bounty workflows. -Do not submit a cosmetic Canton integration. +CommitLedger is a **general-pool Crypto World's Fair entry**. It must not claim a dedicated Canton track. ## Locked constraints -- MergeEarn/Nimiq remains untouched. -- CommitLedger is a separate HackCanton project. -- No paid APIs or paid infrastructure. -- No Vercel. -- No Supabase. +- Keep the current Canton-native product architecture. +- No paid infrastructure is required for the competition proof. - No requirement for the founder to spend real money to demonstrate the product. - No fake users, fake traction, fake transactions, fake testimonials, or fake production claims. -- Real external users are helpful evidence but are not treated as a hard dependency unless an official competition rule explicitly requires them. - Use real GitHub issues / pull requests / merge state as work evidence. - Use Daml smart contracts for the bounty and settlement state machine. - Use Canton Ledger API for real ledger reads/writes in the final demo. - Provide reproducible local/dev-network execution and evidence. - Clearly label demo/test parties and demo/test assets as non-production. -- Any unverified competition requirement must remain marked PENDING, never guessed. +- Any unverified requirement remains PENDING, never guessed. +- Do not add an unrelated chain integration merely to chase a track prize unless it strengthens the actual product. ## Payment / settlement decision -**Canton Coin is NOT a required dependency for the MVP unless official HackCanton rules explicitly require it.** +The competition MVP proves programmable settlement using a clearly labelled demo/test unit, `DEMO_CREDIT`. -The competition build will prove programmable settlement using a clearly labelled demo/test asset or ledger-native settlement representation on Canton. - -This avoids: -- requiring the founder to buy or hold Canton Coin, -- introducing external payment dependencies, -- confusing demo/test value with real money, -- risking the core submission on wallet/mainnet availability. - -The architecture keeps a clean future adapter point for a Canton Coin / Canton Token Standard-compatible payment rail, but this is an optional production extension, not a blocker for the competition MVP. +A production payment rail may be added later. It is not required for the core proof and must not be described as already implemented. ## Required technical proof @@ -63,45 +52,42 @@ The final submission must demonstrate: 1. A bounty is created from a real GitHub issue. 2. Authorization is enforced through Daml parties/choices. -3. A contributor claims or accepts the bounty under the contract model. +3. A contributor claims the bounty under the contract model. 4. A real GitHub pull request is linked. -5. The backend independently verifies repository, branch, relevant identity policy, and merged state. -6. A successful merge enables the settlement transition. +5. The backend independently verifies repository, branch, relevant identity policy, issue binding and merged state. +6. Valid merge evidence enables the settlement transition. 7. Canton records the resulting state/settlement. 8. Unauthorized settlement attempts fail. 9. Duplicate settlement is prevented. 10. The judge can inspect reproducible ledger and GitHub evidence. -## Evidence package - -Required before submission: -- working code -- Daml contracts -- automated contract tests -- GitHub verification tests -- end-to-end deterministic demo script -- architecture diagram -- threat / trust-boundary notes -- failure-case evidence -- ledger transaction / contract evidence -- setup instructions -- concise judge walkthrough -- short demo video script -- submission copy -- final rules checklist +## Required Colosseum presentation package + +Before portal submission, complete: + +- accurate founder/team background and location; +- product logo/graphic; +- GitHub repository access for judges; +- 2–3 minute pitch video; +- <=3 minute technical demo video; +- GTM and distribution strategy; +- truthful demand-validation section; +- disclosure of any development completed before September 14, 2026; +- final runtime evidence capture. ## Scope control -Do not overbuild a marketplace, token, DAO, reputation network, or generalized freelancing platform before the core verified-work settlement flow is excellent. +Do not overbuild a marketplace, token, DAO, reputation network, or generalized freelancing platform before the verified-work settlement flow is excellent. Priority: 1. competition compliance -2. correctness -3. Canton-native value +2. real runtime proof +3. product clarity 4. judge reproducibility 5. security / authorization -6. UX polish -7. optional extensions +6. startup narrative and GTM +7. UX polish +8. optional extensions ## Integrity rules @@ -110,28 +96,8 @@ Priority: - Never fabricate users, transactions, testimonials, adoption, or performance numbers. - Never weaken verification to make the demo easier. - Never present an internal quality target as an official judging criterion. -- Competition-specific official rules and deadlines always override assumptions in this repository. - -## Linked control documents - -- [Competition compliance gate](docs/COMPETITION_COMPLIANCE.md) -- [Winning standard](docs/WINNING_STANDARD.md) -- [Competition build roadmap](docs/BUILD_ROADMAP.md) +- Official Colosseum rules and portal requirements always override assumptions in this repository. ## Submission target -Operational target: feature freeze and evidence complete before the official deadline buffer. Submit early enough to leave time for portal issues and final verification. - - -## Stable toolchain lock - -- Use the latest verified stable open-source DPM 3.5 bundle unless an official HackCanton requirement says otherwise. -- Current locked bundle: DPM SDK 3.5.12. -- Do not use snapshot SDKs for the final competition build without a documented compatibility reason. -- Runtime proof must come from real DPM build/test output and real Canton Ledger API responses; never infer success from source code alone. - -## Competition presentation integrity - -- The repository may use the Canton name descriptively, but must not imply Digital Asset sponsorship or endorsement. -- Do not use Canton branding/logos in a way that suggests affiliation. -- Keep the product identity as CommitLedger; Canton is the underlying network/trust layer. +Feature freeze and real evidence should be complete with a buffer before **October 12, 2026 at 11:59 PM PT**. Submit early enough to recover from portal or video-upload problems. diff --git a/README.md b/README.md index 4d25a02..e6eadb1 100644 --- a/README.md +++ b/README.md @@ -4,11 +4,17 @@ CommitLedger binds a real GitHub bounty issue and merged pull request to role-separated Daml authorization and an auditable Canton settlement receipt. -## Competition thesis +## Crypto World's Fair 2026 + +CommitLedger is being submitted to **Colosseum Crypto World's Fair 2026** as a general-pool entry. Colosseum accepts products across blockchain ecosystems; CommitLedger uses Canton because multi-party authorization and auditable settlement are core to the product, not a cosmetic integration. + +**Competition deadline:** October 12, 2026 at 11:59 PM PT. + +## Product thesis `GitHub Issue -> Bounty -> Claim -> Pull Request -> Merge Evidence -> Canton Settlement -> SettlementReceipt` -Canton is the trust and settlement layer, not a cosmetic integration. Removing Canton removes the product's authorization, provenance, replay protection and final settlement record. +GitHub proves the work event. Daml defines who may move the bounty state. Canton records the authorized settlement state and proof. ## Core guarantees @@ -41,7 +47,7 @@ npm start Open `http://127.0.0.1:4173`. -Because this repository is currently private, set `GITHUB_TOKEN` with read access before using the canonical GitHub verifier. +If this repository is private, set `GITHUB_TOKEN` with read access before using the canonical GitHub verifier. ## Run the full Canton proof @@ -57,7 +63,7 @@ Then: npm run demo:full ``` -The runner automatically captures each Canton `updateId`, `completionOffset` and active `contractId`, executes negative authorization/replay checks, and finishes at the active `SettlementReceipt`. +The runner captures Canton `updateId`, `completionOffset` and active `contractId`, executes negative authorization/replay checks, and finishes at the active `SettlementReceipt`. See [Judge Runbook](docs/JUDGE_RUNBOOK.md) for the exact operator path. @@ -65,19 +71,19 @@ See [Judge Runbook](docs/JUDGE_RUNBOOK.md) for the exact operator path. The Daml project is under `daml/` and is pinned to the stable open-source DPM SDK bundle **3.5.12**. -Verification commands: - ```bash bash scripts/bootstrap-dpm.sh bash scripts/verify-all.sh ``` -## Competition governance +## Colosseum submission package -- [Locked decisions](LOCKED_DECISIONS.md) - [Competition compliance](docs/COMPETITION_COMPLIANCE.md) -- [Winning standard](docs/WINNING_STANDARD.md) -- [Rules snapshot](docs/RULES_SNAPSHOT.md) +- [Verified rules snapshot](docs/RULES_SNAPSHOT.md) +- [Submission copy](docs/COLOSSEUM_SUBMISSION.md) +- [Pitch script](docs/PITCH_SCRIPT.md) +- [Technical demo script](docs/DEMO_SCRIPT.md) +- [Final submission checklist](docs/SUBMISSION_CHECKLIST.md) - [Architecture](docs/ARCHITECTURE.md) - [Threat model](docs/THREAT_MODEL.md) - [Judge runbook](docs/JUDGE_RUNBOOK.md) @@ -88,4 +94,4 @@ bash scripts/verify-all.sh CommitLedger does not claim Canton Coin transfer, fiat settlement, external adoption, mainnet usage, green CI, or runtime Canton success unless that evidence has actually been produced. -Canton is a registered trademark of Digital Asset (Switzerland) GmbH. CommitLedger is an independent project and is not sponsored or endorsed by Digital Asset. +Canton is a registered trademark of Digital Asset (Switzerland) GmbH. CommitLedger is an independent project and is not sponsored or endorsed by Digital Asset or Colosseum. diff --git a/docs/COLOSSEUM_SUBMISSION.md b/docs/COLOSSEUM_SUBMISSION.md new file mode 100644 index 0000000..a62d798 --- /dev/null +++ b/docs/COLOSSEUM_SUBMISSION.md @@ -0,0 +1,127 @@ +# Colosseum Submission Copy — CommitLedger + +_Last updated: 2026-10-07._ + +Use this as the base copy for the Crypto World's Fair portal. Keep every claim consistent with the actual runtime evidence and final videos. + +## Product name + +**CommitLedger** + +## One-line description + +CommitLedger turns verified GitHub work into a role-authorized, auditable settlement lifecycle on Canton. + +## Short description + +Open-source bounty payments still depend on manual trust between maintainers and contributors. CommitLedger connects a real GitHub issue and merged pull request to a Daml state machine on Canton. GitHub proves that the work event occurred; role-separated Daml choices define who can claim, verify and settle; Canton records the final evidence-bound receipt and prevents replay. + +## Blockchains and tools + +- Canton Network / Canton JSON Ledger API +- Daml smart contracts +- GitHub API +- Node.js 22 +- Local-first web UI + +CommitLedger is a general-pool entry and does not claim a dedicated ecosystem track. + +## Problem + +Crypto protocols and open-source projects often use GitHub issues, grants and bounties to coordinate work. The work record is public, but the settlement decision is usually handled off-chain through spreadsheets, multisigs, manual reviews or centralized marketplaces. + +That creates a trust gap: a merged pull request proves that code landed, but it does not itself prove who was authorized to approve the bounty, whether the exact issue was satisfied, or whether the same work was paid twice. + +## Insight + +The useful blockchain primitive is not “put GitHub on-chain.” The useful primitive is **separating evidence from authorization**. + +GitHub remains the source of truth for the software event. A verifier converts canonical provider state into a compact evidence hash. Daml controls which party may advance each state. Canton records the authorized state transitions and final receipt. + +## Product + +The current flow is: + +`GitHub Issue -> Bounty -> Claim -> Pull Request -> Merge Verification -> Verified Bounty -> SettlementReceipt` + +The demo includes: +- a real GitHub issue; +- a real merged PR linked to that issue; +- server-side canonical verification; +- three distinct Canton roles; +- unauthorized-action rejection; +- duplicate-settlement rejection; +- final evidence-bound settlement receipt. + +## Why blockchain is necessary + +Without Canton/Daml, the application server could unilaterally declare a bounty verified or settled. In CommitLedger, the ledger is the authorization and provenance boundary. Removing it removes the multi-party control model, replay-resistant settlement transition and auditable final receipt. + +## Market + +Initial customers are crypto protocols, open-source foundations, grant programs and developer-relations teams that pay contributors for verifiable GitHub work. + +Longer term, the same evidence-to-settlement pattern can support audits, grants, milestone-based contributor programs and other workflows where external work evidence must be converted into controlled payment authorization. + +## Business model + +A production version can charge: +- a per-settlement fee for completed bounties; +- organization subscriptions for policy controls, analytics and integrations; +- enterprise integration fees for custom treasury/payment rails. + +The competition build does **not** claim revenue. + +## Go-to-market + +1. Start with crypto teams already running GitHub bounties or contributor grants. +2. Offer a lightweight GitHub-native workflow that requires minimal process change. +3. Use successful bounty settlement proofs as case studies. +4. Partner with ecosystem grant programs, foundations and developer communities. +5. Expand from individual bounties to organization-level contributor operations. + +## Demand validation + +Current evidence is **technical and workflow validation**, not market traction: CommitLedger uses a real issue/PR fixture and independently verifies canonical GitHub state. + +Before final submission, add only genuine demand evidence such as founder interviews, maintainer feedback, a real pilot, waitlist signups or revenue. If none exists by the deadline, state that clearly instead of inventing traction. + +## Competition execution + +The repository shows substantial implementation activity during the Crypto World's Fair contest period. In the portal, disclose any concept, code or related work that existed before September 14, 2026. + +## Founder + market fit + +**Fill with accurate founder background before submission.** Focus on: +- experience building developer tools, crypto products or automation; +- why open-source work settlement is personally understood; +- evidence of fast product execution during the hackathon. + +Do not invent credentials. + +## Team location + +**Fill accurately in the Colosseum portal.** + +## Repository + +https://github.com/Saidur-droid/CommitLedger + +If the repository remains private, grant review access to `hackathon@colosseum.com` before submission. + +## Demo fixture + +- Issue: https://github.com/Saidur-droid/CommitLedger/issues/5 +- PR: https://github.com/Saidur-droid/CommitLedger/pull/6 + +## Final proof to attach + +Before submission, attach or show: +- current Node test output; +- Daml build/test output; +- real Canton lifecycle output; +- final `SettlementReceipt`; +- authorization failure; +- duplicate-settlement failure; +- pitch video; +- technical demo video. diff --git a/docs/COMPETITION_COMPLIANCE.md b/docs/COMPETITION_COMPLIANCE.md index 963ce99..805d1ff 100644 --- a/docs/COMPETITION_COMPLIANCE.md +++ b/docs/COMPETITION_COMPLIANCE.md @@ -1,80 +1,94 @@ -# HackCanton Season 3 — Competition Compliance Gate +# Colosseum Crypto World's Fair 2026 — Competition Compliance Gate -_Last reviewed: 2026-09-27_ +_Last reviewed: 2026-10-07._ -This file separates **verified public requirements**, **working assumptions**, and **internal quality standards**. Never convert an assumption into a claimed official rule. +This file separates **verified requirements**, **submission actions**, and **internal quality standards**. If the live Colosseum portal conflicts with this file, the portal and official rules win. -## Non-negotiable goal #1 +## Official sources -**Follow every competition rule that can be verified before submission.** +- Competition page: https://colosseum.com/worldsfair +- Hackathon FAQ: https://colosseum.com/hackathon?year=fall2026 +- Official rules PDF: https://colosseum.com/legal/Crypto%20World%27s%20Fair%20Hackathon%20Rules.pdf -If a formal/private portal rule conflicts with any repository decision, the official rule wins immediately. +## Verified eligibility and timing -## Publicly verified competition direction +- Contest period: September 14, 2026 at 6:00 AM PT through **October 12, 2026 at 11:59 PM PT**. +- Each team member must register on Colosseum before the deadline. +- A participant may be on only one team and a team may submit only one project. +- Solo founders are allowed. +- Products may use any blockchain ecosystem; dedicated tracks are separate prize pools. +- Builders may use pre-existing code, but relevant development history must be disclosed. +- All submitted content must be in English. -Current official/public Canton ecosystem material for HackCanton Season 3 emphasizes: -- build something real on Canton; -- the build phase is active; -- Canton/Daml/Ledger integration must be substantive enough to demonstrate an actual Canton application, not branding-only integration. +## Verified submission materials -Official/public sources to re-check before submission: -- https://forum.canton.network/ -- https://appsfactory.cc/ +The Colosseum FAQ says the portal requests or expects: -## Rules audit protocol +- product name and brief description; +- blockchains and tools integrated; +- teammate backgrounds and previous experience; +- team location; +- product logo or graphic; +- GitHub repository link; +- 2–3 minute presentation video; +- technical demo video of no more than 3 minutes; +- go-to-market strategy; +- demand validation and distribution plans; +- any other context needed to understand the product and business. -Every submission-critical requirement must be classified as one of: +Open-source repositories are encouraged. A private repository is allowed only if review access is granted to `hackathon@colosseum.com`. -- **VERIFIED** — confirmed from an official source or the actual submission portal. -- **NOT REQUIRED** — official material explicitly does not require it, or the submission form does not ask for it. -- **PENDING** — not yet confirmed. A PENDING item cannot be represented as an official rule. +## Judging -### Submission blocker +The official rulebook evaluates: +- functionality / code quality; +- potential impact; +- novelty; +- UX; +- open-source / composability; +- business plan and team execution. -Do not submit while any critical item below remains PENDING: +The platform FAQ also emphasizes: +- founder + market fit; +- insight; +- product + execution; +- potential market size; +- founder communication; +- viability; +- traction, when it exists. -- eligibility / participant requirements -- solo vs team eligibility -- required registration state -- submission deadline and timezone -- required repository visibility/license -- required build period / pre-existing-code restrictions -- required Canton technology or network environment -- required demo/video format and duration -- required written fields -- required live URL or deployment -- intellectual-property / open-source requirements -- judging criteria -- prize-track eligibility -- prohibited content / conduct -- any mandatory sponsor technology -- any mandatory identity/KYC step for prize eligibility +CommitLedger must therefore be presented as a **startup**, not only as a technical demo. -## Current working status +## CommitLedger status -| Requirement | Status | Repository action | +| Requirement | Status | Action | |---|---|---| -| Canton must be meaningful to the product | VERIFIED from public HackCanton positioning | Daml + Canton Ledger API are core architecture | -| Paid infrastructure required | NOT FOUND as a requirement | Build remains free/local-first | -| Canton Coin required | NOT FOUND as a requirement | Optional future adapter, not MVP dependency | -| Real-money transaction required | NOT FOUND as a requirement | Demo/test asset only, clearly labelled | -| Real-user traction required | NOT FOUND as a requirement | Genuine feedback is bonus evidence, never fabricated | -| Formal final submission checklist | PENDING until portal/rulebook is accessible | Final submission is blocked until re-check | +| Eligible blockchain ecosystem | VERIFIED | General-pool entry; do not claim a Canton-specific track | +| English content | VERIFIED | Repository and submission docs are English | +| Development during hackathon window | STRONG EVIDENCE | Current Git history shows major implementation work during the contest period; disclose any earlier work truthfully | +| Product GitHub repository | READY | Repository exists and is judgeable | +| Repository review access | ACTION REQUIRED | Make public or grant `hackathon@colosseum.com` access before submission | +| Product description / stack | READY | See `docs/COLOSSEUM_SUBMISSION.md` | +| Pitch script | READY TO RECORD | See `docs/PITCH_SCRIPT.md` | +| Technical demo script | READY TO RECORD | See `docs/DEMO_SCRIPT.md` | +| GTM / business plan | DRAFTED | See `docs/COLOSSEUM_SUBMISSION.md`; add only real validation evidence | +| Logo / graphic | ACTION REQUIRED | Upload an original CommitLedger product graphic | +| Founder background / location | ACTION REQUIRED | Fill with accurate founder information in portal | +| Node tests | MUST RE-RUN | Capture current `npm test` output | +| Daml build/tests | MUST VERIFY | Capture real DPM build/test output | +| Canton lifecycle | MUST VERIFY | Run `npm run demo:full` against a real configured Canton environment | +| Demo video | ACTION REQUIRED | Record from real runtime evidence; do not mock ledger success | +| Presentation video | ACTION REQUIRED | Record from pitch script | +| Final portal submission | ACTION REQUIRED | Submit before October 12, 2026 11:59 PM PT | ## Evidence integrity -- Never fabricate users, testimonials, transactions, adoption, metrics, judging feedback, or production status. -- Never claim MainNet usage unless it happened and can be independently shown. -- Never claim a demo/test asset is real money. -- Never claim an official requirement unless it is actually verified. -- Preserve source links/screenshots/notes for every rule used in the final submission. - -## Final compliance pass - -Immediately before submission: -1. Re-open the official competition portal. -2. Re-read current rules and judging criteria. -3. Compare each requirement with the built repository. -4. Update this file with VERIFIED / NOT REQUIRED status. -5. Run the full technical evidence checklist. -6. Submit only after all critical PENDING items are resolved. +- Never fabricate users, testimonials, transactions, adoption, revenue, or judging feedback. +- Never describe `DEMO_CREDIT` as real money. +- Never claim MainNet use unless independently verifiable. +- Never claim runtime success from source code alone. +- If there is no external traction yet, say so and present a concrete validation plan instead. + +## Final gate + +CommitLedger is **not fully submission-ready** until all ACTION REQUIRED and MUST VERIFY items above are completed with real evidence. diff --git a/docs/DEMO_SCRIPT.md b/docs/DEMO_SCRIPT.md new file mode 100644 index 0000000..14a70d9 --- /dev/null +++ b/docs/DEMO_SCRIPT.md @@ -0,0 +1,81 @@ +# CommitLedger — Technical Demo Script + +Maximum target: 3 minutes. + +Use only a real configured Canton environment. If the runtime is not working, fix it before recording; do not fake green states. + +## 0:00–0:20 — Setup + +Show the CommitLedger home screen. + +Say: +“CommitLedger converts a real GitHub work event into a role-authorized settlement proof on Canton. This demo uses a real issue and merged pull request.” + +## 0:20–0:45 — Verify source issue + +Open or show issue #5. + +In CommitLedger, click **Verify issue & prepare bounty**. + +Point out: +- repository; +- issue number; +- issue state; +- demo reward unit. + +Say: +“The browser does not decide this state. The server reads GitHub directly.” + +## 0:45–1:10 — Verify merged PR + +Show PR #6 and its reference to issue #5. + +Run **Verify canonical merge**. + +Point out: +- PR number; +- base branch; +- head SHA; +- merged timestamp; +- SHA-256 evidence hash. + +## 1:10–2:10 — Run Canton lifecycle + +Click **Run live Canton lifecycle**. + +Show the timeline: +- BOUNTY_ON_LEDGER +- CLAIM_REQUESTED +- CLAIMED +- PR_SUBMITTED +- VERIFIED +- SETTLED + +Point out real contract IDs and update IDs. + +Say: +“Three distinct parties control the workflow: maintainer, contributor and verifier.” + +## 2:10–2:35 — Failure proof + +Show the negative checks from the proof bundle. + +Say: +“The same runtime also proves that wrong issue evidence is rejected, a contributor cannot settle the bounty, and a settled verified contract cannot be settled twice.” + +## 2:35–2:55 — Receipt + +Show the final `SettlementReceipt`. + +Point out: +- bounty ID; +- repository; +- PR; +- reward unit; +- evidence hash; +- settlement reference. + +## 2:55–3:00 — Close + +Say: +“GitHub proves the work event. Daml controls authorization. Canton preserves the settlement proof.” diff --git a/docs/PITCH_SCRIPT.md b/docs/PITCH_SCRIPT.md new file mode 100644 index 0000000..9aced4a --- /dev/null +++ b/docs/PITCH_SCRIPT.md @@ -0,0 +1,43 @@ +# CommitLedger — 2–3 Minute Pitch Script + +Target length: about 2 minutes 30 seconds. + +## 0:00–0:25 — Problem + +Open-source bounties look transparent because the work happens on GitHub, but the payment decision is still mostly manual. A merged pull request proves code landed. It does not prove who was allowed to approve the bounty, whether the exact issue was satisfied, or whether the same work was settled twice. + +## 0:25–0:55 — Product + +CommitLedger turns that workflow into a verifiable settlement lifecycle. + +A maintainer starts from a real GitHub issue. A contributor claims the bounty and submits a pull request. CommitLedger independently reads canonical GitHub state and binds the repository, issue, PR, branch, commit SHA and merge time into evidence. + +That evidence then enters a role-separated Daml workflow on Canton. + +## 0:55–1:25 — Why blockchain + +Canton is not a database added for the hackathon. + +The maintainer, contributor and verifier have different authorities. The application server cannot simply award itself a successful settlement. Unauthorized actions fail at the contract layer, and the verified contract is consumed when settlement occurs, preventing replay. + +The final output is an auditable `SettlementReceipt` bound to the exact GitHub evidence. + +## 1:25–1:55 — Why this matters + +The first market is crypto protocols, foundations and developer programs that already pay contributors for GitHub work. Today they combine issues, spreadsheets, multisigs and manual review. + +CommitLedger gives them a path from public work evidence to controlled settlement without asking them to replace GitHub. + +## 1:55–2:20 — Business and wedge + +The wedge is verified open-source bounties. A production product can monetize through per-settlement fees and organization subscriptions for policy, analytics and treasury integrations. + +The same evidence-to-authorization pattern can later support grants, audits and milestone-based contributor programs. + +## 2:20–2:35 — Close + +The core insight is simple: + +**GitHub proves the work event. Daml defines who may act. Canton records the authorized settlement proof.** + +That is CommitLedger. diff --git a/docs/RULES_SNAPSHOT.md b/docs/RULES_SNAPSHOT.md index fe675ea..5c39009 100644 --- a/docs/RULES_SNAPSHOT.md +++ b/docs/RULES_SNAPSHOT.md @@ -1,40 +1,46 @@ -# HackCanton Season 3 — Verified Rules Snapshot - -_Last verified: 2026-09-27._ - -This file separates currently verified public event facts from CommitLedger's own internal quality gates. - -## Public event facts verified from current AppsFactory / Canton ecosystem materials - -- HackCanton Season 3 is an online Canton build program. -- Builders may participate solo or as a team. -- The build period runs through October 9, 2026. -- Submission deadline: **October 9, 2026 at 23:59 UTC**. -- Judging follows October 10–18, finalists are announced October 19, and the Grand Final is October 21. -- The program is for products built on Canton and includes guided onboarding / shared development environment support. -- Public materials describe up to $50K in cash + credits. -- Builders may start with a new idea or an unfinished project. -- Season 3 has multiple tracks, including an open category. - -## What is NOT treated as a verified mandatory rule - -Unless the organizer's private/formal submission portal explicitly requires it, CommitLedger does **not** assume that the following are mandatory: -- real external users; -- paid hosting; -- Canton Coin purchase; -- mainnet deployment; -- external traction; -- production custody; -- a token launch. - -## Compliance policy - -If the official AppsFactory portal, participant agreement, track rules, or submission form provides requirements that conflict with this repository, those official requirements immediately override this file. - -Before final submission, manually compare the portal/rulebook against: -- `LOCKED_DECISIONS.md`; -- `docs/COMPETITION_COMPLIANCE.md`; -- this file; -- the final demo and submission text. - -No unchecked assumption may be presented as an organizer rule. +# Crypto World's Fair 2026 — Verified Rules Snapshot + +_Last verified: 2026-10-07._ + +## Competition facts + +- Organizer: Colosseum. +- Contest: Crypto World's Fair 2026. +- Contest period: September 14, 2026 at 6:00 AM PT through **October 12, 2026 at 11:59 PM PT**. +- The competition is open to products across blockchain ecosystems. +- Every team member must register before the deadline. +- Solo founders are allowed. +- One participant may join only one team; one team may submit only one project. +- All submitted content must be in English. +- Builders may begin development before the hackathon, but judging focuses on work completed during the contest; relevant pre-existing development must be disclosed. +- Open-source repositories are encouraged. Private repositories are permitted if Colosseum is granted review access. +- The platform expects a product description, team details, GitHub repository, product graphic, 2–3 minute pitch, <=3 minute technical demo, GTM, demand validation and distribution plan. + +## Judging signals + +### Official rules +- Functionality +- Potential impact +- Novelty +- UX +- Open-source / composability +- Business plan / ability to execute + +### Colosseum platform FAQ +- Founder + market fit +- Insight +- Product + execution +- Potential market size +- Founder communication +- Viability +- Traction, when present + +## CommitLedger competition positioning + +CommitLedger uses **Canton + Daml + GitHub** and should be entered as a general-pool product. Do not claim eligibility for a dedicated ecosystem track unless the implementation is actually extended to that ecosystem before submission. + +## Official references + +- https://colosseum.com/worldsfair +- https://colosseum.com/hackathon?year=fall2026 +- https://colosseum.com/legal/Crypto%20World%27s%20Fair%20Hackathon%20Rules.pdf diff --git a/docs/SUBMISSION_CHECKLIST.md b/docs/SUBMISSION_CHECKLIST.md new file mode 100644 index 0000000..de149b0 --- /dev/null +++ b/docs/SUBMISSION_CHECKLIST.md @@ -0,0 +1,61 @@ +# Crypto World's Fair — Final Submission Checklist + +Deadline: **October 12, 2026 at 11:59 PM PT**. + +## Automated / repository work + +- [x] Product code exists and is judgeable. +- [x] Real GitHub issue / merged PR fixture exists. +- [x] Daml role-separated state machine exists. +- [x] Canonical GitHub verifier exists. +- [x] Duplicate settlement and unauthorized-action logic exists. +- [x] Colosseum-specific rules snapshot added. +- [x] Colosseum submission copy drafted. +- [x] 2–3 minute pitch script drafted. +- [x] <=3 minute technical demo script drafted. +- [x] UI competition branding updated. + +## Must verify before submission + +- [ ] Run `npm test` on the final commit and save output. +- [ ] Run `bash scripts/bootstrap-dpm.sh`. +- [ ] Run `bash scripts/verify-all.sh` and save Daml build/test output. +- [ ] Configure a real Canton dev/local environment. +- [ ] Run `npm run demo:full`. +- [ ] Save the evidence bundle using `COMMITLEDGER_EVIDENCE_FILE`. +- [ ] Confirm wrong-issue rejection. +- [ ] Confirm unauthorized-settlement rejection. +- [ ] Confirm duplicate-settlement rejection. +- [ ] Confirm the final active `SettlementReceipt`. + +## Colosseum account / portal + +- [ ] Every team member is registered for Crypto World's Fair. +- [ ] Team leader has the correct team configured. +- [ ] Founder/team background is filled accurately. +- [ ] Team location is filled accurately. +- [ ] Any pre-September-14 development is disclosed. +- [ ] Repository is public **or** `hackathon@colosseum.com` has private-repo review access. +- [ ] Original product logo / graphic is uploaded. +- [ ] Product name and short description are final. +- [ ] Canton / Daml / GitHub stack is listed accurately. +- [ ] GTM and distribution plan are pasted from the submission draft and edited for accuracy. +- [ ] Demand validation includes only real evidence. + +## Videos + +- [ ] Record 2–3 minute presentation video. +- [ ] Record technical demo <=3 minutes. +- [ ] Videos show the final build, not an outdated branch. +- [ ] Technical demo shows real Canton runtime evidence. +- [ ] Audio and screen text are readable. +- [ ] Links are accessible to judges. + +## Final 20-minute check + +- [ ] Open repository link in a logged-out/incognito window if public. +- [ ] If private, confirm Colosseum reviewer access. +- [ ] Re-open the official rules and FAQ for last-minute changes. +- [ ] Confirm every portal field is in English. +- [ ] Confirm no fake traction, production or real-money claims. +- [ ] Submit before the deadline and save the confirmation. diff --git a/web/index.html b/web/index.html index 33415c1..6ff45a8 100644 --- a/web/index.html +++ b/web/index.html @@ -15,7 +15,7 @@
Checking Canton - HackCanton S3 + Crypto World's Fair 2026
@@ -130,7 +130,7 @@

Every important claim leaves an inspectable artifact.

- +