Part of the P3 mechanism-design push (#36).
Summary
Reward deposits are recorded today (DINTaskAuditor.totalDepositedRewards) but there is no distribution or claim logic at all — the largest DevNet 2.0 gap. Build the per-GI reward engine: pool funding, role splits, settlement, and a pull-payment claim flow.
- Per-GI pool funded by the model-owner reward deposit (made a precondition of
startGI; market-set pool size) plus a decaying protocol-emission top-up during bootstrap (steady state: fees fund everything, emission → 0)
- Role split, DAO-settable — initial proposal 60% clients (proportional to BlockFLow marginal-gain score among accepted models) / 20% auditors (equal per completed assignment; correctness enforced by slashing, not reward weighting) / 15% aggregators (per finalized T1/T2 batch) / 5% treasury
- Settlement at
endGI credits claimable[address]; pull-payment claimRewards(), never push transfers in loops; median + proportional split computed on-chain so payouts are verifiable
- Client-side design: admission scoring gates participation, contribution scoring weights rewards, reward accounting settles claims from a bounded pool (issues/client-reward-mechanism.md)
- Validator-side design: pool + fee revenue split across GIs, roles, and individual validators (issues/validator-reward-mechanism.md)
- Anti-gaming: fold-in duplicate discounting, median-bounded score inflation, zero reward below pass score
Open decisions
- Exact split percentages — simulate in P3-5.2 at 10–50 validators / 100–500 clients per model
- Aggregator reward scaling with batch size (recommendation: yes, linear)
- Pool minimums denominated in DIN vs fiat-oracle terms (recommendation: plain DIN, no oracle dependency)
Design sources
MECHANISM_DESIGN §5 · issues/client-reward-mechanism.md · issues/validator-reward-mechanism.md · whitepaper-summary §4.4
Roadmap anchors: WP 3.1 (participant reward logic), WP 3.2 (validator incentive mechanism), P3-5.1/5.2
Part of the P3 mechanism-design push (#36).
Summary
Reward deposits are recorded today (
DINTaskAuditor.totalDepositedRewards) but there is no distribution or claim logic at all — the largest DevNet 2.0 gap. Build the per-GI reward engine: pool funding, role splits, settlement, and a pull-payment claim flow.Scope (from MECHANISM_DESIGN §5)
startGI; market-set pool size) plus a decaying protocol-emission top-up during bootstrap (steady state: fees fund everything, emission → 0)endGIcreditsclaimable[address]; pull-paymentclaimRewards(), never push transfers in loops; median + proportional split computed on-chain so payouts are verifiableOpen decisions
Design sources
MECHANISM_DESIGN §5 · issues/client-reward-mechanism.md · issues/validator-reward-mechanism.md · whitepaper-summary §4.4
Roadmap anchors: WP 3.1 (participant reward logic), WP 3.2 (validator incentive mechanism), P3-5.1/5.2