Skip to content

rchain dbr retro

Jump to bottom
Dan Connolly edited this page Jul 19, 2026 · 1 revision

RChain Distributed Budgeting and Rewards — Lessons from a Failed Experiment in Decentralized Governance

The RChain Cooperative ran a bounty program from 2017–2020 where RAMs (RChain Active Members) voted on budgets for GitHub issues and on reward splits among contributors. A trust metric weighted votes by reputation tier (apprentice/journeyer/master). The program was archived in 2020. Seven years later, the paper trail preserved in GitHub issues — hundreds of discussions about fairness, metrics, slashing, translation work, and process design — constitutes one of the most detailed public records of a distributed governance experiment in the blockchain era.

What Was Built

The rchain-dbr web application was a LAMP-stack (Linux, Apache, MySQL, PHP) CRUD interface built on Xataface. It let members:

  • Browse issues and vote on budgets (dollar amounts per issue)
  • Vote on reward percentages for each contributor on an issue
  • Track trust ratings that determined voting weight
  • "Slash" a member's entire monthly rewards as a last-resort sanction

The system evolved from Google Sheets into a dedicated web app (per issue #260, budget $3000, 2–4 weeks estimated). It was deployed at rewards.rchain.coop. An explainer video and wiki documentation covered the workflow.

Lessons Learned

1. Low-quality work can capture a bounty program

Issue #483 raised alarms that translation work had grown to 28% of all open issues (50 of ~180). Concerns included: no strategy for which documents to translate, difficulty evaluating translation quality, and the work being dominated by a small number of individuals per language. The author explicitly said they felt "uncomfortable participating in the budgeting process" because they couldn't evaluate the work. The proposed solutions — delegation of votes, budget caps, a dedicated sub-program — were never implemented.

2. Trust metrics effectively counter fraud

The trust metric system — where voting weight depended on reputation tier — was a defense against gaming. Complaints that certified voters lacked firsthand knowledge of the work or that ~80% of rewards went to trusted members came from participants attempting to extract rewards without earning trust. The requirement to get certified by existing trusted members was the feature, not the bug: it prevented the Sybil attacks and vote-manipulation that plagued permissionless systems.

3. No objectives, no metrics

Issue #783 was opened specifically to establish goals, objectives, and metrics for the bounty program — a "reboot" after RCon3. The deficiency was noted during a board meeting. The issue proposed a $1200 budget and 6-month timeline but was never resolved. The program operated for over a year without articulated success criteria.

4. Slashing was added as a backstop

Issue #261 asked what "slashing conditions" the system should have, drawing inspiration from Casper's consensus protocol. The trust metric already prevented Sybil attacks and vote-manipulation; slashing was conceived as an additional backstop against misconduct within the trusted cohort. A slashing mechanism was eventually documented in the wiki: a quorum (10x weight) of slashing votes against a participant on any issue would zero out their entire monthly rewards.

5. Time-of-contribution vs time-of-payment exchange rates

Issue #969 surfaced a subtle but corrosive problem: whether rewards should be valued at the RHOC exchange rate when the work was done or when it was paid. With a volatile token, this could mean a 10x difference in real compensation. The issue was never cleanly resolved.

6. Software rot and deployment complexity

The rchain-dbr codebase was a PHP/Xataface application with OAuth integration, a PostgreSQL schema, Discord verification, and deployment via Ansible. The INSTALL.md and README document a multi-step setup with database configuration, OAuth provisioning, and Discord verification. The repo was forked from rchain-community/rchain-dbr and had 297 commits across a LAMP stack that was already dated by the time it was built.

7. The paper trail is the enduring artifact

The most durable output of the experiment is not the software but the record. The GitHub issues, wiki pages, and discussion threads constitute a detailed ethnographic record of a real distributed governance attempt. Every design tension — trust concentration, measurement, quality control, slashing, delegation, exchange rate risk — was surfaced in public. None were resolved.

What Didn't Happen

The following were proposed but never implemented or completed:

Proposal Issue Status
Goals, objectives, metrics for the bounty program #783 Opened, not resolved
Delegation of votes #483 (comment) Proposed, not implemented
Budget caps on translation work #483 Proposed, not implemented
Story points for development work #273 Discussed, not adopted
Apprentice/journeyman/master ratios #785 Asked, never answered
OAuth authentication for GitHub + Discord #414, #413 Deferred, never completed

References

Navigation

Clone this wiki locally