On this page

Docs

Crowdfunded builds

When nobody sells what you need, many backers can fund it together. Developers are hired for the deliverables, backers vote to release each milestone, and everyone holds revenue units. Every later paid sale of the finished item is split across the unit holders.

Test mode, and a legal warning. Crowdfunded builds run on the simulated rail only, so no real money moves. Revenue units that people can trade are likely to be regulated securities in many countries. Get legal advice before any real money or public promotion is involved. Nothing on this page is legal, tax or investment advice.

Node only for now. Funded builds are coming soon on the hosted app. Its funded-build screens and "start a funded build" links are placeholders today. The commands and endpoints on this page are for a self-hosted node. The on-chain design for builds is in docs/PAYMENTS.md and is not deployed.

Who is involved

RoleWhat they do
ProposerCreates the project with its goal, deliverables, developers and milestones. Later attaches the finished item.
BackersPledge USD toward the goal. They receive revenue units in proportion to what they funded, and vote on milestones.
DevelopersAre named in advance with a share of the budget and a share of the units. Deliver milestones with evidence.
Escrow agentConfirms that pledged money arrived. On a self-hosted node, the node operator.

Lifecycle

StateMeaningNext
OPENCollecting pledges until the goal or the deadline (30 days by default).FUNDED when confirmed money reaches the goal. FAILED if the deadline passes first.
FUNDEDGoal reached and units issued. Developers deliver, backers vote.COMPLETED when every milestone is approved.
COMPLETEDAll milestones approved. The proposer can attach the product item.Final. Sales keep paying dividends.
FAILEDThe deadline passed before the goal was reached.Final. See If a goal is missed.

A pledge counts only after the escrow agent confirms the deposit. A pledge that would push the total above the goal is ignored, so you can only back up to the remaining amount.

Create a project

Shares are written in basis points (bps): 10,000 bps is 100%.

FieldRule
title, specTitle up to 200 characters; spec up to 4,000.
deliverablesList of what will be built. At least one.
goal_usdGreater than zero.
deadline_daysDays to reach the goal. Default 30.
developersList of {id, budget_bps, equity_bps}. Each id is a developer's public key and must be unique. budget_bps values must total exactly 10,000, each above zero. equity_bps values must total at most 5,000.
milestonesList of {name, bps}. Each above zero, totalling exactly 10,000.
bash
curl -s -X POST http://127.0.0.1:8420/api/projects -d '{
  "identity": "acme",
  "title": "Invoice PDF skill",
  "spec": "A skill that turns invoice PDFs into structured JSON.",
  "deliverables": ["invoice-extractor skill"],
  "goal_usd": 1000,
  "deadline_days": 30,
  "developers": [
    {"id": "rb1...dev-one", "budget_bps": 7000, "equity_bps": 1500},
    {"id": "rb1...dev-two", "budget_bps": 3000, "equity_bps": 500}
  ],
  "milestones": [{"name": "Prototype", "bps": 4000}, {"name": "Release", "bps": 6000}]
}'

If a share rule is broken, the node answers with an error and nothing is created. List projects with python -m repoblock projects.

Units and the 50% cap

Every project has exactly 1,000,000 revenue units, issued once, at the moment the goal is reached.

  • Developers receive units equal to their equity_bps. All developers together can hold at most 50%. This cap is enforced when the project is created, so a project that breaks it never exists.
  • The rest go to backers in proportion to the money each had confirmed. Rounding leftovers go to the largest backer.

Example, with the project above: developers hold 15% + 5% = 200,000 units. Backers share 800,000. If Ana pledged $600 and Bo $400:

HolderPledgedUnitsShare
Dev onen/a150,00015.0%
Dev twon/a50,0005.0%
Ana$600480,00048.0%
Bo$400320,00032.0%

Back a project with POST /api/projects/PROJECT_ID/back and {"identity":"ana","amount_usd":600}, or with the MCP tool back_project.

Milestones and votes

  1. A developer posts a delivery for a milestone with a short piece of evidence (up to 500 characters), such as a link to a release and a test run.
  2. Backers vote yes or no, with a weight equal to the units they held when the milestone was delivered. Units moved afterwards cannot vote twice. Developers do not vote.
  3. The milestone is approved when yes votes hold more than half of all backer units at that snapshot, not just of those who voted. Silence counts against approval.
  4. On approval, the log records what each developer is owed: goal x the milestone's share x the developer's budget share.

With a $1,000 goal, the Prototype milestone is worth $400. Dev one's budget share of 70% gives $280 and dev two's 30% gives $120. In this example Ana holds 480,000 of the 800,000 backer units, which is 60%, so she alone can approve a milestone. A concentrated cap table means concentrated control. A new delivery for the same milestone clears its earlier votes. When every milestone is approved, the project is COMPLETED.

bash
curl -s -X POST $NODE/api/projects/$PID/deliver -d '{"identity":"dev-one","milestone":0,"evidence":"v0.1 release and CI run"}'
curl -s -X POST $NODE/api/projects/$PID/vote    -d '{"identity":"ana","milestone":0,"approve":true}'

Dividends from sales

When the project is finished, the proposer publishes the product as an ordinary listing with project_id set to the project, and records it on the project (POST /api/projects/PROJECT_ID/product with block_id). From then on, a released order for that item does not pay one seller. After the network fee, the money is split across the current unit holders, in cents, with the leftover cent to the largest holder.

A $25 sale at the 1% default fee leaves $24.75:

HolderUnitsDividend
Dev one150,000$3.71
Dev two50,000$1.23
Ana480,000$11.89
Bo320,000$7.92

Each share is rounded down to the cent first: $3.7125 becomes $3.71, $1.2375 becomes $1.23, and Ana's exact $11.88 stays. The one cent left over goes to Ana, the largest holder. Each project's dividends accumulate in its record.

Transferring units

Once a project is FUNDED or COMPLETED, a holder can send some of their units to another identity with POST /api/projects/PROJECT_ID/transfer and {"to":"rb1...","units":50000}. Dividends follow the units at the moment an order is settled. Two rules protect the developer cap: units granted to developers stay with developers until the project is COMPLETED, and a transfer that would take the developers' total above 50% is ignored. This transferability is what makes units likely to count as securities. Read the legal warning above.

Your portfolio

python -m repoblock portfolio --as ana prints, per project: what you invested, your units and ownership percentage, the dividends received and your net result. The same view is at GET /api/portfolio/YOUR_PUBLIC_ID and in the MCP tool portfolio.

If a goal is missed

When the deadline passes before the goal is reached, the project becomes FAILED and issues no units. Confirmed pledges are owed back to backers. The escrow agent returns them and records each one as a project.refund event in the log. A node has no HTTP route or command for it yet, so the operator does it from Python (ProjectService.refund); on the simulated rail nothing real moves. After a project is funded there is also no mechanism today to return unspent money if developers stop delivering. Backers' only lever is to withhold approval. Back only what you can afford to lose.

Last updated: