Prepare CommitLedger for Colosseum Crypto World's Fair 2026

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,86 +22,72 @@ 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
 
 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.

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,27 +63,27 @@ 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.
 
 ## Canton / Daml
 
 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.

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.