Are you an LLM? Read llms.txt for a summary of the docs, or llms-full.txt for the full context.
Skip to content

DAO

Our take on a decentralized autonomous organization

We've built a decentralized, credibly-neutral, and largely autonomous system on Ethereum that enables Cobuilds to pursue arbitrary goals - making decisions, spending capital, and hiring humans and AIs to do work.

Stakers stake $COBUILD on budgets to direct how the Goal's treasury gets spent — and earn rewards when their allocations succeed.

Treasury Graph

A Cobuild’s Treasury Graph is a hierarchical treasury streaming money to accomplish goals.

Treasury Graph
Funds stream pro-rata by stake weight
Total staked
0 $CO
Current rewards
0 $CO
funders depositGoal TreasuryReward Poolunlocks on successBudget A50%Budget B30%Budget C20%Grants / ContestsGrants / ContestsGrants / Conteststo contributors
Your $CO to stake:
Budget A0
Budget B0
Budget C0
Actions

It routes funds through a tree:

Goal → Budgets → Allocation Mechanisms (Flows / Rounds)

The mechanism is designed around a single question:

What is the current weight vector over spending paths that best accomplishes the goal?

Cobuild answers that question continuously using stake. Stakers stake $COBUILD on budgets to direct where funds flow. Only budgets with stake receive funds, and stakers earn rewards only if their allocations help the Goal succeed.

Core properties

1) Streaming is simple, real-time, and pro‑rata

At every node, outgoing funds are streamed to children in proportion to instantaneous stake share.

  • If a child has no stake (or is below a threshold), it gets 0 stream
  • Weights update immediately when stake weight changes

2) Rewards accrue on stake-time, not used for routing

Routing weights come from instant stake share.

Staker rewards are computed from stake-time — how long your stake has been allocated to a budget:

  • rewards early + persistent stakers
  • reduces last‑minute "sniping"
  • you can move stake between budgets, but points only accrue while stake is there
  • does not affect stream weights

3) Rewards are gated by goal success

Cobuild uses a final claim gate:

  • Budget success finalizes reward entitlements
  • but rewards become claimable only if the Goal succeeds before its deadline

This ties “doing well inside the system” to “the goal actually being achieved”.

4) Listing is optimistic and non-subjective (TCRs)

Budgets and allocation mechanisms enter registries via TCR mechanics:

  • proposer posts a bond in $COBUILD
  • anyone can challenge within a window Registries verify schema + safety, not “quality”. Staking determines quality.

High-level flow

  1. A Goal is created with:

    • an oracleable success condition
    • a deadline
    • a minimum raise target and raise deadline
    • a treasury that receives funds
  2. Budgets are proposed into the Budget_TCR. Once listed, they can receive stake and stream.

  3. Stakers direct their weight to budgets.

    • Streaming from the Goal treasury routes to budget treasuries pro-rata by stake weight.
    • Budgets cannot spend until they reach their activation threshold (aka minBudget).
  4. Inside a budget, allocation mechanisms are proposed via Allocation_TCR. Stakers route budget outflow to these mechanisms pro-rata as well.

  5. When a budget succeeds:

    • its stream stops
    • unspent funds are returned upward
    • staker reward entitlements for that budget are finalized
  6. When the Goal succeeds:

    • the global reward pool unlocks
    • finalized reward entitlements become claimable

Who this spec is for

  • Stakers: how to stake on a Goal, direct allocation, and earn rewards
  • Builders / integrators: the state machine and accounting you implement
  • Researchers: incentive model and anti-sniping separation (routing vs rewards)