Layer 3 · Economy
Internal Economy Protocol
- Layer: 3 — Economic & Resource System
- Status: Stub — not yet adopted
- RCOS reference: §5.1, §5.2, §5.4, §5.5
Commons vs. Private Classification
RCOS definition5.1.1, 5.1.2, 5.1.3, 5.1.4, 5.1.5, 5.6.2
- 5.1.1 All resources within the declared governed scope MUST be explicitly classified as either **commons** or **private**.
- 5.1.2 The community MUST maintain a single, explicit, and versioned registry of governed resources, including at minimum:
- 5.1.3 Any resource not explicitly classified MUST be treated as **unclassified**, and the community MUST NOT allocate, encumber, monetize, or transfer it until classification is completed through an authorized decision.
- 5.1.4 For commons resources, the community MUST explicitly define:
- 5.1.5 For private resources, the community MUST NOT exercise authority beyond what is explicitly declared in the scope, membership agreements, or other governed artifacts.
- 5.6.2 Resources declared as commons MUST NOT be privatized through informal, implicit, or unilateral action.
Why classify every resource?
Unclassified resources are where quiet privatization happens — someone starts treating a shared asset as personal, or a private asset gets quietly absorbed into community obligations, and by the time anyone notices the norm has shifted. Explicit classification, with stewards and transfer rules named up front, makes any change to that status a visible governance act rather than a creeping fact.
| Resource | Classification | Steward | Access rules | Transfer constraints |
|---|---|---|---|---|
| RCOS specification and artifacts (this repo) | Commons | Blueprint Steward | Public read; Full Members write via governance process | Cannot be privatised; forks permitted |
| Shared treasury (Safe multi-sig) | Commons | Finance Steward | Transparent to all Full Members (real-time via Safe) | Governed by Treasury Ruleset |
| Fruit Haven (fruithaven.land) | Commons | Infrastructure Steward | Full Members; public-facing features open | Cannot be sold or privatised without Constitutional decision |
| Fruit Haven website (fruithaven.land) | Commons | Infrastructure Steward | Public read; Infrastructure Steward and Communications Steward write | Cannot be sold without Constitutional decision |
| RCOS hosted website (blueprint.ecohubs.community) | Commons | Infrastructure Steward / Blueprint Steward | Public read; Blueprint Steward writes; Infrastructure Steward manages | Cannot be sold without Constitutional decision |
| Brand, domain names, social media accounts | Commons | Communications Steward | Communications Steward manages; Full Members may contribute via defined process | Cannot be transferred without Constitutional decision |
Any unclassified resource must not be allocated, encumbered, monetized, or transferred until classification is completed.
Recognized Contribution Categories
RCOS definition5.2.1, 5.2.3, 5.6.3
- 5.2.1 The community MUST explicitly define which contribution categories are recognized. These MAY include, but are not limited to:
- 5.2.3 The community MUST NOT structurally depend on unpaid, invisible, or informal labor for system survival without explicitly defining corresponding obligations, recognition, or compensation mechanisms.
- 5.6.3 Contribution recognition MUST be explicit such that unpaid or invisible labor is not structurally required for system survival.
Why name the kinds of work that count?
If the community never says out loud which kinds of work it depends on, the invisible work — care, facilitation, moderation, stewardship — stays invisible, and the people doing it burn out or leave. Enumerating categories converts “someone just does this” into recognized labour the system has to account for.
| Category | Examples |
|---|---|
| Knowledge & Research | Writing RCOS artifacts, research into community models, documentation, translation |
| Technical Development | Fruit Haven development, website development, tooling, infrastructure maintenance |
| Governance & Coordination | Facilitating and organizing internal meetings, reviewing proposals, onboarding new members, running votes, member coordination (helping members find tasks they’d like to participate in) |
| Community Building | Outreach, welcoming new members, moderating channels, hosting public calls, facilitating meetings to support other communities in applying RCOS |
| Creative & Communication | Content creation, social media, design, writing for public channels |
| Care & Support | Emotional support, conflict facilitation, wellbeing check-ins |
| Stewardship | Maintaining shared resources, monitoring platforms, managing external services |
| Informal Participation | Active Discord/forum engagement, attending calls, feedback on proposals |
Contribution Recognition Mechanism
RCOS definition5.2.2, 5.2.5
- 5.2.2 The community MUST define a contribution recognition mechanism specifying:
- 5.2.5 Contribution recognition MUST NOT create implicit decision authority, veto power, or governance influence beyond what is defined in Layer 2.
Why pin down how recognition actually works?
Without a defined mechanism, “who gets credit” becomes a matter of who is loudest or closest to whoever decides. Specifying what qualifies, how it’s recorded, who validates, and how to dispute it turns recognition into something a member can actually rely on — and blocks recognition from silently mutating into governance influence.
- What qualifies: Any activity falling into one of the recognized categories above; informal participation counts at the member’s own declaration
- How contributions are recorded:
- Structured: automatically via Puckstack task completion ? XP/ECO credited via Offcoin
- Informal/other: self-reported by the member in Fruit Haven or Discord; no validation required for informal participation
- Who validates: Structured contributions validated automatically by Puckstack/Offcoin; significant contributions (e.g. major artifacts, facilitation work) may be nominated by any member for additional XP via the Membership Admin
- Effect on access/privileges: Contribution recognition affects XP and ECO balance only — it does not grant additional governance rights beyond what the membership state defines
- Dispute: Any member may contest a contribution record within 30 days; disputes resolved by Membership Admin with right of appeal to Full Members
Internal Units
RCOS definition5.2.4, 5.2.5
- 5.2.4 If internal economic units are used (e.g. time credits, points, tokens), the Internal Economy Protocol MUST define:
- 5.2.5 Contribution recognition MUST NOT create implicit decision authority, veto power, or governance influence beyond what is defined in Layer 2.
Why define XP and ECO this precisely?
Internal units tend to grow powers no one voted for — decay, caps, transferability, governance weight — unless each property is nailed down in writing. Listing issuance, transfer rules, privacy, and explicit non-governance status makes the units tools of recognition rather than quiet shadow currencies.
Two internal units are in use: XP (experience points) and ECO (community currency). Both are tracked via Offcoin / Fruit Haven.
| Property | XP | ECO |
|---|---|---|
| Purpose | Activity and progress indicator | Contribution recognition; may unlock certain Puckstack permissions |
| Issuance | Automatic via Puckstack task completion; manual via Membership Admin for nominated informal contributions | Same as XP |
| Transferability | Non-transferable between members | Non-transferable between members; not traded on external markets |
| Expiration / decay | None currently | None currently — see Missing Technical Implementations |
| Hard cap | None currently | None currently |
| Future utility | N/A | TBD — further utility to be defined via future proposals |
| Fraud prevention | Self-reported contributions subject to community review; dispute mechanism as defined in Contribution Recognition Mechanism | Same as XP |
| Privacy | Balances visible to all Full Members in Fruit Haven | Balances visible to all Full Members in Fruit Haven |
ECO and XP do not grant governance rights beyond what the membership state defines (see §5.2.5).
Accumulation Constraints
RCOS definition5.4.1, 5.4.2, 5.4.3, 5.4.4, 5.6.4
- 5.4.1 Internal economic systems MUST prevent unbounded concentration of internal influence or control through resources, credits, or financial obligations.
- 5.4.2 If internal units exist, the community MUST define one or more accumulation-limiting mechanisms, which MAY include:
- 5.4.3 Economic mechanisms MUST NOT allow members to bypass governance authority boundaries defined in Layer 2, including through purchasing influence, creating dependency, or converting economic power into informal decision authority.
- 5.4.4 The community MUST define reviewable indicators of economic concentration risk and an explicit mechanism to adjust constraints when such risks are detected.
- 5.6.4 Economic mechanisms MUST prevent indefinite concentration of internal influence.
Why constrain accumulation at all?
Any internal unit that can pile up without limit eventually becomes leverage — a few members with large balances gain informal sway the governance system never granted them. Stating accumulation rules explicitly, even when the current rule is “none yet,” keeps the question open and forces a visible decision before concentration becomes a structural problem.
- No hard cap on XP or ECO currently — accumulation is unlimited
- Neither unit can be converted into governance authority or used to bypass the Decision Matrix
- Accumulation limits and decay mechanisms are deferred as a future proposal; see Future Proposals
External Income Interfaces
RCOS definition5.3.2
- 5.3.2 Income sources and any external income interfaces MUST be explicitly defined.
Why require approval before money arrives?
Once funds are in hand, the conversation shifts from “should we accept this?” to “what do we do with it?” — and the conditions attached to the income (grant terms, partnership obligations, service commitments) are often already locked in. Requiring a Strategic decision before any new income channel opens keeps the community in control of what it takes on.
- Current: No external income; all operational costs are covered by the founding member as personal contributions
- Potential future interfaces: Grants and foundations, Web3 ecosystem funding, partnerships, paid services (tooling, onboarding support, educational programs)
- Rule: Any new external income interface must be declared and approved via a Strategic decision before funds are received or commitments made
Dispute Resolution for Economic Records
Why time-box economic disputes?
Contribution and balance records accumulate fast; if disputes could be raised indefinitely, the ledger would never settle and every historical credit would stay contestable. A 30-day window with a named resolver and an appeal path gives members a real chance to correct errors without leaving the whole economic history perpetually unstable.
Any member may contest a contribution record or internal unit balance within 30 days of the record being created. See Contribution Recognition Mechanism above for the full dispute process. Appeals beyond Admin resolution are handled by Full Members via the governance process (Layer 2).
Ratification Record
- Adopted:
- Decision type: Strategic
- Version:
- Decision record: