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

Incentives & threat model

This page explains what Cobuild is trying to make incentive-compatible, and what it does not try to guarantee.

Actors and incentives

  • Stakers: stake $COBUILD on budgets to direct allocation, earn rewards on successful budgets.
  • Budget proposers: submit budgets with success conditions and invariants.
  • Builders / recipients: receive budget outflows.
  • Challengers / reporters: challenge invalid listings or invariant breaches.
  • Oracles / disputers: resolve success and disputes (default: UMA OO).

Why split routing from rewards?

Routing needs to be responsive

If new information arrives (“this budget is going off the rails”), you want:

  • stake weight to move immediately
  • funding to re-route immediately

So routing uses instantaneous stake share.

Rewards need to be anti-sniping

If rewards also followed instantaneous weights, you’d get:

  • last-minute contributions right before success
  • underpayment to early stakers

So rewards use stake-time (time-weighted stake allocation).

Why gate rewards on Goal success?

Without a final gate, people can:

  • optimize for “easy budget wins”
  • farm rewards on budgets that don’t move the goal-level needle

By gating claims on Goal success:

  • stakers only get paid if the overall goal succeeds
  • “local wins” only matter if they add up

Staker expected value (mental model)

A staker's expected value is roughly:

Pr(Goal succeeds) * reward share minus capital cost of locked stake minus expected slashing (if misconduct occurs)

This incentivizes funding budgets that actually raise the probability of Goal success, not just local activity.

Economic security condition (simple statement)

Goal: extracting value from the treasury should be bounded by the cost of staking $COBUILD (and/or by slashing risk).

Cobuild enforces this via:

  • no baseline flow (no stake → no stream)
  • minStake thresholds (reduces trivial drips)
  • runwayCap (limits idle hoards)
  • maxRatePerStakeUnit (limits how fast any stake can pull funds)
  • invariants + TCR validity checks (block invalid payout paths)
  • Goal success gate (local farming doesn’t pay if the Goal fails)

Core threats and mitigations

1) Bribery / kickbacks for routing weight

Attack: a recipient pays stakers to route funds to them.

Mitigations:
  • allocation power is proportional to $COBUILD staked (bribes must exceed their own loss from bad allocation)
  • rewards are time-weighted (sniping is weak)
  • maxRatePerStakeUnit limits how much can be pulled per stake
  • Goal success gate makes pure local farming unprofitable if it hurts the Goal

Residual risk: bribery can still exist if external incentives dominate.

2) Self-dealing budgets ("I stake to fund myself")

Attack: proposer lists a valid budget that routes to themselves and stakes to direct funds to it.

Mitigations:
  • allocation power is proportional to $COBUILD staked — self-dealing is bounded by how much you stake
  • allowlisted invariants can prohibit obvious self-dealing
  • other stakers can counter-allocate if they have enough stake
  • goal-level success and disputes can reject low-value “successes”

Residual risk: wealthy actors can extract if the system allows “bad but valid” budgets and slashing is off.

3) Spent-based reward farming (if spent is the weight)

Attack: maximize spent to mint more reward points.

Mitigations:
  • success gating prevents rewards if the Goal fails
  • runwayCap and maxRatePerStakeUnit limit damage
  • optional alternative weights (capped/concave/insured stake-time)

4) Dragging out execution to farm points

Attack: keep a budget alive to accrue more stake-time points.

Mitigations:
  • executionDuration limits the window
  • rewards only finalize on success
  • locked stake has opportunity cost inside the Goal

5) Registry griefing / censorship via challenges

Attack: challenge spam to delay listings.

Mitigations:
  • challenge bonds sized to deter frivolous challenges
  • loser-pays-winner
  • optional rate limits / cooldowns

6) Oracle griefing / subjective success

Attack: disputes over vague success conditions.

Mitigations:
  • success conditions must be oracleable and evidence-backed
  • TCRs check schema/safety only; quality is handled by staking

What Cobuild does NOT guarantee

  • optimal allocation (only an allocation market)
  • protection from all bribery or collusion
  • success if success conditions are subjective or poorly defined

Cobuild aims to make bad outcomes costly and to align rewards with real Goal success.