$10,000 USDC on Lux mainnet · paid retroactively for merged contributions to five named tier-1 repos · four-week submission window · three judges, three-of-three attestation · funded by kcolbchain to seed the ecosystem dev-payouts rail.
What this is
A $10,000 retroactive grant pool to recognize contributors who land substantive work — merged PRs, accepted specs, reference implementations, high-quality docs — in five named open-source repos at the intersection of the Hanzo and Lux ecosystems.
This is the inaugural ("Round Zero") in a planned series. Future rounds may add Hanzo and Lux matching, on-chain attestation, and a recurring cadence. Round Zero is self-funded by kcolbchain to seed the rail and produce public on-chain receipt of an ecosystem dev-payouts program working end-to-end.
Timeline
| Milestone | Date (UTC) |
|---|---|
| Eligibility window for the contribution itself | 2026-04-01 → 2026-07-08 |
| Submissions open | 2026-06-15 |
| Submissions close | 2026-07-08 23:59 |
| Independent judge scoring complete | 2026-07-12 |
| Judge convergence session | 2026-07-13 |
| Attestations published | 2026-07-15 |
| KYC requests sent (≥$600 winners only) | 2026-07-16 |
| Payouts (USDC, Lux mainnet) | 2026-07-22 |
The eligibility window covers contributions merged or accepted between 2026-04-01 and 2026-07-08. Work landing after the close rolls into Round One.
Eligible repos
Submissions must reference a contribution to one of these five repos (or
any sub-repo under hanzonet/*):
hanzoai/HIPs— Hanzo Improvement Proposals (governance + spec)hanzoai/cloud— unified Hanzo Cloud binary (HIP-0106)hanzoai/mcp— Hanzo MCP server registryhanzonet/*— any repo in the hanzonet orgluxfi/{LPs, lattice, threshold}— Lux Proposals + lattice primitives + threshold MPC
Eligible work
- Merged pull requests of any size (one substantive PR > many trivial ones)
- Accepted HIPs or LPs (filed and merged into the corpus)
- Reference implementations cited from a HIP / LP
- Documentation that materially enables others to ship
- Audit reports + security fixes (also eligible separately under the upcoming bounty program)
Tiers
| Rank | Award | Winners | Pool |
|---|---|---|---|
| 1st | $2,000 | 1 | $2,000 |
| 2nd | $1,000 | 2 | $2,000 |
| 3rd | $500 | 4 | $2,000 |
| Honorable | $250 | 8 | $2,000 |
| Operations + Caddy | $2,000 | — | $2,000 |
| Total | — | 15+ | $10,000 |
$2,000 reserved for operational costs: on-chain transaction fees, judges' time (split equally), and any contributor support that surfaces during the window. Unspent operations budget rolls into the next round.
Judges
Three judges. Each tier assignment requires three-of-three attestation (unanimous on tier, not on every score axis). Attestations published publicly with the payout transactions.
- Abhishek Krishna — kcolbchain
- 1 from Hanzo — invite outstanding
- 1 from Lux — invite outstanding
Judges may not submit their own contributions for the round they are judging. Conflicts of interest are surfaced publicly with the attestation, not used to recuse a judge from the round.
Rubric
Each submission is scored 0–5 on five axes by each judge. Total possible: 25 points per judge × 3 judges = 75 points.
| Axis | What we look for |
|---|---|
| Quality | Code clarity, test coverage, idiomatic style for the target repo |
| Impact | Does this unblock others, fix a real bug, or open a contribution surface? |
| Rigor | Design thinking, edge cases, threat modeling where relevant |
| Sustained engagement | One-shot drive-by vs. follow-through over multiple weeks |
| Maintainer signal | Review velocity, follow-up issues filed, maintainer feedback in PR |
| Total score | Tier | Award |
|---|---|---|
| 60+ / 75 | 1st | $2,000 |
| 50–59 / 75 | 2nd | $1,000 |
| 40–49 / 75 | 3rd | $500 |
| 30–39 / 75 | Honorable | $250 |
| < 30 / 75 | — | No award |
Ties broken by the sustained-engagement
axis, then by judge discussion (logged in the published attestation).
Full rubric at JUDGING.md.
How to submit
One submission per contribution. Open an issue on the round repository:
Submit a contribution → (repo opens 2026-06-15)
Required fields in the submission:
- GitHub handle of the contributor
- Contribution URL — PR, HIP, LP, or doc
- One-line impact claim — what does this unblock or enable?
- Receiving wallet — USDC-receiving address on Lux mainnet
- Email for KYC if the award exceeds $599 (only the top three tiers; honorable mentions stay wallet-only)
What we will pay attention to
- Quality — code clarity, test coverage, design rigor
- Strategic value — does this unblock others or open a new contribution surface?
- Sustained engagement — building over time prioritized over one-shot drive-bys
- Maintainer signal — review comments, merge speed, follow-up issues
What we will not pay for
- Self-promotional content (blog posts about yourself, hype threads)
- AI-generated bulk PRs that don't add substance
- Closed-without-merge work that wasn't substantive (process churn doesn't qualify)
- Contributions from the named judges' own history during the round window
- Work for which the contributor has already been paid by another program covering the same scope
Tax + KYC
Awards under $600 per recipient are paid as direct USDC transfers on Lux mainnet, wallet-only, no KYC. This covers all honorable mentions and most third-place winners.
Awards $600 or above per recipient require the standard W-9 (US) or W-8BEN (non-US) before payout — handled by the kcolbchain accounts team. This typically applies to first place, second place, and some third-place recipients.
FAQ
Why retroactive instead of forward bounties?
Cash for work already done beats promised revshare on future revenue. Most platforms in this space pay a percentage of future inference / settlement / app revenue — fine when the platform has real GMV, theatre when it doesn't. Retroactive grants recognize the contributors who already showed up.
Why these five repos?
They are the closest to the kcolbchain × Hanzo + Lux contribution surface today: hanzoai/HIPs for spec authorship, hanzoai/cloud for the unified-binary platform, hanzoai/mcp for tool registry, hanzonet/* for the agent / DID / wire layer, and luxfi/{LPs, lattice, threshold} for the consensus and post-quantum primitive stack. Future rounds may expand scope.
Will there be future rounds?
Yes, contingent on Round Zero learnings. The on-chain rail at kcolbchain/dev-distributor is built for recurring rounds; Round Zero uses direct USDC transfers because 15 winners is small enough that the distributor adds overhead. Round One onward uses the distributor.
Can Hanzo / Lux team contributors submit?
Yes, with one exception: the named judges may not submit their own contributions for the round they are judging. Other Hanzo / Lux maintainers are eligible.
Will the judges' attestations be public?
Yes. All attestations are published with the payout transactions on 2026-07-22. We want the judging signal to be visible, including disagreements where they occurred.
What if I'm not sure my contribution qualifies?
Submit it anyway. The judges are the ones who decide what qualifies; the form does not filter. If your contribution is borderline, the worst that happens is your submission doesn't make a tier — no penalty.
What if I co-authored the contribution with someone else?
Submit jointly with the co-author's explicit consent, and declare the split (e.g., 60/40) in the submission. We pay the full award amount distributed according to the declared split. Co-authors without consent on a joint submission can flag it as a conflict — the submission gets disqualified.
Can a contribution count if I was paid by another program for it?
Partial overlap is judged case-by-case — e.g., a Hanzo OSS Fund grant covered the contribution's research time but not the merge work. Full overlap (same scope, fully reimbursed elsewhere) disqualifies. The submission form asks you to confirm this explicitly.
What if I send my wallet on the wrong chain?
The submission form asks explicitly for a Lux mainnet address. We follow up before disqualifying. Don't submit an Ethereum, Solana, or other-chain address expecting a bridge — we don't bridge for the round.
What happens to the operations budget if it's not fully used?
Unspent operations budget rolls forward into Round One. The $2,000 ops earmark on Round Zero is intentionally conservative; we expect ~$1,000 to roll forward and seed Round One's ops float.
Is this related to the Hanzo Open Source Fund (the 20% revshare)?
Not directly. Hanzo's pricing-policy.json describes a 20% revenue-share to an Open Source Fund proportional to OSS dependency usage. We have filed a public issue asking about the distribution mechanism. Round Zero is funded entirely by kcolbchain and is independent of that program. If the OSS Fund is real, future rounds may align with it.
What if my contribution lands after 2026-07-08?
It rolls into Round One. Round Zero scopes to merges + filings completed in the window 2026-04-01 → 2026-07-08 to anchor against existing visible work.
Contact
Questions about eligibility, scope, or process: research@kcolbchain.com. Public-facing comments + suggestions can be raised as issues on the kcolbchain/retro-round-0 repo once it opens.