The bet
Centralized, closed-source software has a structural advantage: it can capture value and pay the people who build it. Open source has an execution advantage: parallel collaboration at global scale, with no one able to lock it down. ContribNet is a bet that if you solve the compensation problem for open source — actually pay contributors in a verifiable, trust-minimized way — collaborative development can create more total value than any closed alternative.
That’s the thesis. Here’s how the system works.
—
What ContribNet is
ContribNet is a platform that lets you run a project as a self-governing on-chain entity. A project has a task board, a contributor registry, a treasury, and a governance system. Contributors earn Contribution Points (CP) by completing tasks that are reviewed and scored by peers. At the end of each epoch (default: 14 days), the treasury distributes funds proportional to CP — compensating contributors for work already done.
CP is permanent. Your record of contribution never disappears. Governance weight decays — only recent activity counts toward voting power, so the people making decisions are the people actively working on the project, not long-retired early contributors.
—
Project lifecycle
A project starts when a founder deploys it on-chain via the factory. They set an initial configuration: epoch length, review parameters, quorum thresholds, minimum payout, and so on — all adjustable later through governance.
The founder mints some initial CP to anchor the scale (e.g. 400 CP to themselves for the work that got the project to launch). From there, new CP is created only by completing tasks that pass peer review.
The lifecycle of a task:
-
Anyone — contributor or not — can propose a task: title, description, difficulty, suggested CP range. The proposal is stored on IPFS; its hash is registered on-chain.
-
Registered contributors vote it into the backlog (50% threshold, no timelock).
-
A contributor claims the task and has an assignment window to deliver. New to the project? Tasks flagged as “Good First Issue” are open to anyone — no existing CP required. Completing one is how you become a registered contributor.
-
The contributor submits their work as a git bundle pinned to IPFS.
-
Reviewers commit a hidden score using a commit-reveal scheme (to prevent anchoring bias), then reveal after the commit window closes.
-
Once enough reviews are in, the task finalizes: CP is minted to the contributor, and — if reviewers voted to merge — the on-chain project HEAD advances to the new bundle CID.
The treasury fills from any source — grants, donations, product revenue. Every epoch, 80% of available funds (configurable) flow out to contributors proportional to their CP share.
Founder mode and the governance handover. When a project is first deployed, the founder’s wallet is the project’s owner. In this state the founder has direct admin access: they can mint CP, update config, and force-finalize stalled tasks — all without a governance vote. This is intentional: a new project with one person and no contributors can’t govern itself yet.
Once the project has enough contributors with distributed CP to sustain governance, the founder should hand over. This is a single transaction — transferOwnership(address(this)) — which makes the project self-owning. From that point:
-
Minting CP requires an executed governance proposal
-
Config changes require a governance proposal
-
The founder retains their CP and governance weight like any other contributor, but has no special admin access
The frontend surfaces this as a “Make this project contributor-owned” panel, visible only to the founder while they still hold direct ownership. The recommended sequence is: seed the task board with good-first-issue tasks → get a few contributors through the task flow so CP is meaningfully distributed → apply production config settings → hand over.
Handing over early (before CP is distributed) is possible but leaves governance fragile — if the founder holds 95% of CP, they control all votes anyway, which defeats the point.
—
What kind of projects this suits
Open source relying on grants and donations. This is the clearest fit. A project with public code and a treasury can receive grants directly on-chain. Contributors earn CP through work; the treasury distributes proportionally. The grant givers can verify exactly what was built and who built it before funds are released, or they can trust the governance process and fund upfront.
For-profit projects with decentralized ownership. A startup-like project where the “equity” is CP. Founders set the initial CP to anchor their stake, then contributors dilute in over time through work. When the product generates revenue it flows to the treasury and distributes every epoch. The platform takes a 3% fee (governance adjustable via ContribNet project) on epoch payouts; everything else stays in the project.
Digital products — software, content, datasets, research outputs — map naturally because deliverables are verifiable and deliverable via IPFS. Physical products are potentially a bit more tricky but still possible.
—
How you interact with the project
Three surfaces:
Web frontend. An application served from an IPFS hash controlled by a .dot domain (currently .dot domains only work on Paseo as DotNS contracts have only be deployed there). Live at ipfs.io/ipfs/bafybeibffjo6vp3bd6heyrv4vtao74yxl6zx6oovk5zokjhlzzv5e62o7y. You connect a wallet (MetaMask, Talisman, SubWallet — anything that injects as window.ethereum on the Kusama Asset Hub EVM). From there: browse projects, see your tasks, vote, review, raise governance proposals, withdraw payout.
The cn CLI. A full command-line interface for every on-chain action — profiles, tasks, governance, treasury, comments, event streaming. Designed for scripting and agent loops. Example:
cn task list 0xProjectAddr --state votedin --json
cn task assign 0xProjectAddr 0xTaskId
cn task submit 0xProjectAddr 0xTaskId main --notes "implemented X"
cn task review commit 0xProjectAddr 0xOtherTaskId --score 85 --merge yes
The cn-git CLI. Git-specific workflow. You work in a normal local git repo. cn-git push bundles your branch and uploads it to IPFS. cn-git rebase syncs your local HEAD with the on-chain canonical HEAD. cn-git review --checkout pulls down a submission as a local branch so you can inspect the diff in VS Code before scoring.
AI agents can use the cn CLI directly. The event-streaming command (cn watch) outputs one JSON object per line to stdout — straightforward to consume in an agent loop.
—
Tools a project gets
CP issuance. The founder can mint initial CP to seed the scale. After that, CP is created only through the task review process. You can configure the min and max CP range per task difficulty to calibrate what work is worth.
Task board / Kanban. Tasks move through states: Proposed → Voted In → Assigned → In Review → Done (or Dropped). The UI shows this as a kanban. Task metadata — description, acceptance criteria, attachments — lives on IPFS. On-chain stores only the hash, state, and CP values.
Governance. Every consequential decision is a proposal: settings changes, treasury transfers, project upgrades, contributor suspension, fork heritage. Proposals have configurable thresholds (standard vs supermajority) and timelocks, so contributors have time to react before anything irreversible happens.
Domains. Projects can control a `.dot` domain (Polkadot’s native naming system). The domain points to an IPFS hash — so a governance proposal can update what users see when they navigate to the project’s domain. No centralized hosting, no admin key. Note that this currently only works on Paseo (see example here) since the DotNS contracts have only been deployed there.
Governance-controlled artifacts. Any project artifact — a CLI binary, a desktop app, a dataset, a model weight — can be published via governance. The artifact is uploaded to IPFS and the CID is registered on-chain through a proposal. When users run `cn update` (or equivalent), they pull the governance-approved CID, not a URL controlled by a developer. This means a project can ship software to its users with the same trust guarantees as everything else: no single admin key, community-approved, tamper-evident. The ContribNet CLI itself is distributed this way.
—
Git versioning
This is one of the more unusual parts. There is no GitHub. Code lives on IPFS. The project maintains an on-chain headCommit — a CID pointer to the current canonical git bundle. When a contributor submits work, their bundle’s CID and the project’s HEAD at submission time are both recorded on-chain. This allows merge-conflict detection and provides a tamper-evident audit trail of every accepted contribution.
cn-git push bundles your git branch (not a full pack — just the objects needed to reconstruct your branch from the known HEAD) and pins it to IPFS via Pinata. The bundle CID goes into the task submission. After the review finalizes and the contribution is merged, the project HEAD advances to the new CID.
Anyone can reconstruct the full project history by chasing the chain of CIDs backward. Nothing is on a server that can be deleted.
—
Incentives
Contributor angle. You get paid proportional to your contribution history. CP doesn’t decay — a large contribution three years ago still earns treasury share. You also get governance power proportional to recent CP, so active contributors run the project.
Founder angle. You define the initial CP scale and mint your founding stake. As contributors earn CP through work, they dilute you — but the project grows. You keep governance control as long as you stay active. If you go quiet, the community takes over.
Forking. If a project’s governance goes in a direction you disagree with, you can fork. The fork starts as a new on-chain project. At creation time, the founder carries a snapshot of the parent project’s CP ledger over — so contributors who built the original get founding stake in the fork. Currently forks always start with clean governance regardless of CP inheritance; a configurable heritage policy (allowing the original project’s governance to influence fork terms) is planned for a future version. This is a hard limit on governance capture: contributors can always leave and take a snapshot of the history with them. It’s also the escape hatch for platform-level changes — any project that disagrees with a beacon upgrade can fork before the timelock expires and continue on the old implementation indefinitely.
Platform fee. 3% (this number is adjustable via ContribNet’s project governance) of every epoch payout goes to the ContribNet project’s treasury . This is the platform’s revenue model — the platform sustains itself through the same mechanism it provides to others.
—
The platform is itself a project on the platform
The ContribNet project is a regular project deployed on ContribNet. It has been handed ownership of the platform contracts: the ProjectFactory, the ProjectBeacon (which controls the implementation all projects run on), and the .dot domain (which controls what the frontend points to).
This means:
-
A smart contract upgrade to every project on the platform requires a governance proposal, a supermajority vote, and a 72-hour timelock
-
A frontend update requires a governance proposal
-
A CLI release requires a governance proposal — the CLI tarball is uploaded to IPFS and the CID is registered on-chain via governance. Installing from IPFS means you get exactly the version contributors voted to approve.
cn-git updatefetches the latest governance-approved CID automatically
Until ownership has been formally transferred from the deployer EOA (still in progress — waiting for the ContribNet project to have enough contributors to sustain governance), the deployer retains admin access. The design is complete; the key ceremony has not happened yet.
—
Security
The review system uses commit-reveal to prevent score anchoring: reviewers submit a hash of their score before the scores are visible, then reveal after the commit window closes. Reviewers who commit but fail to reveal are penalized (configurable ghost strike limit, configurable deposit forfeited). Consensus is required (configurable minimum number of reveals) before a task is finalized.
Governance actions have timelocks. The emergency pause is the only instant action, and it can only freeze a project — it cannot move funds or change governance rules. Treasury transfers require a supermajority and 72 hours.
The platform beacon upgrade pattern gives every project advance notice and a fork escape hatch. No upgrade can take effect without the community seeing it coming.
—
Current state and honest caveats
This is not a finished product. It is entirely vibe-coded. The contracts are on Paseo (Polkadot’s canary testnet) and Kusama Asset Hub. The codebase has not been formally audited. The ownership transfer to on-chain governance has not happened yet.
What exists: a smart contract system, a functional web frontend, a CLI, and git versioning via IPFS. What doesn’t exist yet: a robust community, formal audits, and the full governance handover.
The project in its current state is a proof of concept to be built upon. Bugs are expected and contributions are necessary for the longevity and decentralisation of the project (read next section on how to get involved).
—
How to get involved
Get KSM into your wallet. ContribNet on Kusama Asset Hub runs on an EVM-compatible chain, so you use a standard Ethereum wallet (MetaMask, Talisman, SubWallet). To fund it with KSM, you need to convert your Ethereum address to its Kusama SS58 equivalent: go to the Address Format Converter on the Polkadot docs, select Kusama Hub as the network, and paste your Ethereum address. Copy the SS58 address that appears and send KSM to it from any exchange or wallet. The funds will show up in your Ethereum wallet on Kusama Asset Hub.
Browse open tasks. Go to the ContribNet project on the frontend and open the task board. Tasks marked “Good First Issue” are unassigned and open to anyone — no existing CP required. These are the entry point for new contributors.
Assign yourself a good first issue. Any unregistered address can claim a good first issue. Pick one from the board, hit assign, and you have the assignment window to deliver. Good first issues are scoped to be completable without deep context: documentation improvements, test coverage, small UI fixes, tooling. Once you complete one and it passes review, you’re a registered contributor and can claim any task.
Propose a task. If you see something missing — a bug, a feature, a doc gap — propose it. A task proposal needs a title, description, and a difficulty level. Good task proposals include concrete acceptance criteria (what does “done” look like?) and, if relevant, suggest “Good First Issue” so it’s accessible to newcomers. Once submitted, contributors vote it into the backlog.
What makes a good task proposal:
-
Scoped to a single deliverable — not “improve the CLI” but “add `–json` flag to `cn profile get`”
-
Acceptance criteria that a reviewer can verify from the IPFS bundle alone
-
Realistic CP range for the difficulty (look at comparable finalized tasks for calibration)
-
“Good First Issue” tag if it doesn’t require project context to complete
Contribute to the platform itself. The ContribNet project manages its own development on ContribNet. If you want to work on the smart contracts, the CLI, or the frontend, propose or claim a task there — same flow as any other project.
—
Possibilities
An open source protocol that pays its own contributors. A DAO where ownership is earned through work. A decentralized studio where contributors share revenue. A research collective that distributes grant funding proportionally to contribution. An AI agent collective where the agents themselves earn CP and draw treasury distributions.
—
*Deployed on Paseo testnet and Kusama Asset Hub. Feedback welcome — the ContribNet project itself is the right place to raise issues via task proposals.*