Rewards

Cobuild uses a single global reward pool per Goal.

• 20% of Goal inflows are reserved into RewardEscrow
• rewards are not used for routing weights
• rewards are gated: only claimable if Goal succeeds

Why stake-time

The staker's job is judgment and commitment. They decide which budgets to back and when to back them. The reward formula should compensate the full lifecycle of that decision — not just the moments when weight is actively pointed somewhere.

You stake $COBUILD on a Goal and allocate it to budgets. Weight controls routing (where funds flow). Your $COBUILD is locked at the Goal level until the Goal resolves, but you can move stake between budgets freely.

Rewards accrue on stake-time — how long your stake is allocated to a budget:

points_u,i = ∫ stake_u,i(t) dt

When a budget fails, all its stakers earn zero — doesn't matter how long they had stake there.

Why stake-time works

Zeroing weight isn't "doing nothing" — it's a deliberate allocation decision. The staker committed capital early (good), backed a budget during its critical funding phase (good), then freed up stream capacity for other budgets (good). Every step was a useful contribution. They should keep earning on the budgets where their stake remains allocated.

The free-rider concern — someone stakes, ignores everything, and earns passively — is real in theory but self-correcting in practice. Inattentive stakers leave stake on failing budgets and earn nothing on those. Attentive stakers reallocate to winners. Over the life of a Goal, the attentive staker's portfolio outperforms. The success gate is already the filter for attention.

When rewards accrue

Rewards accrue while:

• your stake is allocated to the budget
• no success/failure assertion is pending (frozen during dispute windows)

If a budget fails, all stake-time on it earns zero.

How the reward pool is distributed

Step 1: At budget success, compute reward points per staker

When budget i succeeds, each staker u gets:

• points_u,i = ∫ stake_u,i(t) dt (stake-days on that budget)

If a budget fails, all its stakers earn zero rewards.

Step 2: Global claim at Goal success

• R_total = Σ points_u,i across all successful budgets
• RewardPool = balance(RewardEscrow) (20% of inflows)

At Goal success, each unit redeems for:

• rewardPerUnit = RewardPool / R_total

User claim:

• claim_u = (Σ_i points_u,i) * rewardPerUnit

Concrete example

Three budgets under a Goal. Reward pool is $200K.

Budget A succeeds (100 day execution):

• Alice: staked 10K for all 100 days (weight active the whole time)
  • Points: 10,000 × 100 = 1,000,000
• Bob: staked 5K on A for all 100 days (zeroed weight on A after day 80)
  • Points: 5,000 × 100 = 500,000

Budget B succeeds (50 day execution):

• Carol: staked 20K for all 50 days
  • Points: 20,000 × 50 = 1,000,000
• Bob: allocated 5K to B for the last 20 days
  • Points: 5,000 × 20 = 100,000

Budget C fails. Dave staked 15K for 90 days. Zero rewards.

Total points: 2,600,000

• Alice earns: $76,923
• Bob earns: $46,154 (rewarded for both A and B)
• Carol earns: $76,923

Note what happens to Bob: he kept stake on A the whole time (earning points) while also allocating stake to B. Under stake-time, he earns on both — points accrued for the time his stake was on each budget.

What this rewards and what it doesn't

It rewards: committing capital early, picking budgets that succeed, and bearing risk for the duration.

It doesn't reward: how much money flowed through the budget, how much was spent, or how big the budget was. And it doesn't punish zeroing weight — your stake keeps earning as long as it's allocated.

Common objections

"What if a budget barely spends anything but technically succeeds?" This is where success condition design becomes critical. If the success condition is meaningful — "ship this feature and it has 1000 users" or "produce this research output and it passes peer review" — then a budget that "barely spends" but succeeds is a great outcome. The stakers correctly identified something that could succeed without massive resources. The failure mode is if success conditions are too easy to satisfy — but that's a success condition quality problem, not a reward formula problem.

"Can't you just diversify across every budget?" Capital is finite. Staking 10K on Budget A means that 10K isn't available for Budget B at the same time. Over-diversification means thinner stakes everywhere — less influence on routing, less stake-time per budget. You're forced to make actual bets.

"Doesn't this reward passive stakers who aren't paying attention?" Over the life of a Goal, inattentive stakers will leave stake on failing budgets while attentive ones reallocate to winners. The success gate is the real quality filter — not the reward formula. An inattentive staker who happens to pick a winner earned it by keeping stake there. An inattentive staker who never moves off losers earns nothing. The system is self-correcting.

Tokenized reward claims

Reward entitlements can be implemented as transferable claim tokens (ERC20-style) per Goal.

Because rewards are gated until Goal success, tokenized claims let stakers:

• sell future upside for liquidity now
• exit time risk without breaking alignment

A reward claim token is a claim on the reward pool conditional on Goal success — a binary-outcome claim.

What if a budget hasn't resolved when the Goal succeeds?

If the Goal succeeds but Budget D is still in execution — it hasn't succeeded or failed yet — stakers on Budget D earn zero rewards for that budget. Only budgets that have successfully resolved before (or at) Goal success generate reward entitlements. Unresolved budgets are treated the same as failed budgets for reward purposes.

This means timing matters: a budget that's on track but resolves after the Goal deadline contributes nothing to its stakers' rewards. Stakers are incentivized to back budgets that will resolve within the Goal's timeframe.

What if the Goal fails?

• reward claims become non-redeemable (zero value)
• staked $COBUILD becomes withdrawable at Goal resolution
• reward escrow follows the Goal's treasury disposition policy (see resolution)