feat: Specification gaps — Economic Reboot, M010 challenges, OPAL scoring, M009/M011 expansion, PoA annotations #12
Conversation
Formalize the Tokenomics WG's Economic Reboot proposals into four protocol-level mechanism specifications, grounded in forum discussions, the Comprehensive Governance Proposal, and KOI knowledge graph context. New specs: - M012: Fixed Cap Dynamic Supply (hard cap ~221M, algorithmic mint/burn) - M013: Value-Based Fee Routing (%-of-value fees, 4-pool distribution) - M014: Authority Validator Governance (PoA transition, 15-21 curated set) - M015: Contribution-Weighted Rewards (activity-based distribution) Each spec includes: purpose, participants, token flows, state transitions, governance parameters, security invariants, implementation notes, and open questions for WG resolution (15 total across 4 mechanisms). Cross-references updated in README, phase-1/1.2, phase-2/README, and docs/economics/token-economics-synthesis.md. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Summary of ChangesHello @CShear, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request introduces comprehensive specifications for the Regen Network's Economic Reboot, transitioning its tokenomics from an inflationary Proof-of-Stake model to a revenue-based governance utility model. It defines new mechanisms for dynamic token supply, value-based fee routing, authority validator governance, and contribution-weighted rewards, aiming to align protocol revenue with ecological value and foster a more sustainable and mission-aligned network. The changes also integrate these new mechanisms into existing documentation and identify key decisions requiring further Working Group input. Highlights
Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a comprehensive and well-structured set of specifications for four new 'Economic Reboot' mechanisms. The documentation is detailed, covering the design, philosophy, and open questions for each protocol. My review focuses on ensuring the internal consistency and clarity of these complex systems. I have identified a few key areas for improvement, including a potential design conflict between the new Proof-of-Authority model and a parameter in the supply algorithm, an inconsistency in a proposed fee distribution model, and several ambiguities in reward and penalty mechanisms that could be clarified to prevent unintended consequences. Additionally, I found a minor calculation error in a summary table. Addressing these points will enhance the robustness and precision of these important specifications.
| staking_multiplier = 1 + (S_staked / S_total) | ||
| range: [1.0, 2.0] | ||
| effect: higher staking participation → faster regrowth |
There was a problem hiding this comment.
There appears to be a design inconsistency regarding the staking_multiplier. The formula uses S_staked, which is a Proof-of-Stake (PoS) concept. However, mechanism M014 transitions the network to Proof-of-Authority (PoA) and explicitly supersedes PoS staking. If PoS is disabled, S_staked would presumably be zero, making the multiplier always 1. Please clarify how staking_multiplier is intended to function in a PoA world, or if the formula should be adjusted. The "stability tier" in M015 might be a replacement for staking, but this connection is not clear.
| **Model B** (from Gregory's Network Coordination Architecture, forum/19#67): | ||
| | Pool | Share | Purpose | | ||
| |------|-------|---------| | ||
| | Burn Pool | 25-35% | Supply reduction via M012 | | ||
| | Validator Fund | 15-25% | Authority validator compensation | | ||
| | Community Pool | 50-60% | Contributor distribution via M015 | | ||
| | Agent Infrastructure | (included in Community Pool) | Not separated | |
There was a problem hiding this comment.
The share ranges provided for Model B are mathematically incompatible. The sum of the maximum shares (35% + 25% + 60%) is 120%, and the sum of minimums is 90%. This violates the 'Share Sum Unity' invariant defined on line 278, which states the shares must sum to 1.0. The ranges need to be adjusted so that it's always possible to select values from each range that sum to 100%.
There was a problem hiding this comment.
The logic in this review is faulty. The ranges are already set so that it's always possible to select values from each range that sum to 100%, but we wouldn't do that this AI bot did, which is to choose the lowest from each category or the highest from each category.
I suggest resolving this one.
| "avg_automation_score": 0.66 | ||
| "proposed_ecosystem": 3, | ||
| "proposed_economic_reboot": 4, | ||
| "avg_automation_score": 0.71 |
There was a problem hiding this comment.
The avg_automation_score appears to be miscalculated. Based on the scores of the 14 mechanisms listed in the JSON registry (a total score of 9.6), the correct average is approximately 0.686. The current value of 0.71 is inaccurate. Please update the value to reflect the correct calculation.
| "avg_automation_score": 0.71 | |
| "avg_automation_score": 0.69 |
| ecological_multiplier = 1 - (ΔCO₂ / reference_value) | ||
| reference_value = 50 ppm (configurable) | ||
| effect: improving ecological metrics → faster regrowth |
There was a problem hiding this comment.
The formula for ecological_multiplier (1 - (ΔCO₂ / reference_value)) can result in a negative value if ΔCO₂ is positive and larger than reference_value. This would cause the overall regrowth rate r to become negative, effectively turning token minting into additional burning. While this could be an intended punitive measure for worsening ecological metrics, it's a significant behavior that should be explicitly stated. Consider adding bounds to the multiplier (e.g., max(0, 1 - (ΔCO₂ / reference_value))) to prevent negative regrowth, unless this behavior is desired.
| | Credit Retirement | 0.30 | Terminal impact event; strongest ecological commitment | | ||
| | Platform Facilitation | 0.20 | Enables ecosystem growth; rewards infrastructure builders | | ||
| | Governance Voting | 0.10 | Maintains governance participation incentive | | ||
| | Proposal Submission | 0.10 | Rewards initiative and leadership | |
There was a problem hiding this comment.
Awarding an activity score for Proposal Submission could be gamed by submitting numerous low-quality or spam proposals. While OQ-M015-4 addresses gaming via small transactions, this specific vector is not mentioned. Consider adding a note about mitigations, such as requiring proposals to meet a minimum quorum or pass to be eligible for rewards, or leveraging the existing x/gov deposit mechanism to disincentivize spam.
| 2. **Stability Cap**: Stability tier allocation ≤ 30% of Community Pool inflow | ||
| 3. **Activity Integrity**: Activity scores derived from on-chain transactions only; no self-reported activity | ||
| 4. **Sybil Resistance**: Activity weights prevent wash trading from being profitable (fees paid > rewards earned for circular transactions due to M013 fee extraction) | ||
| 5. **No Double-Counting**: Each transaction counted once for reward scoring; marketplace trades count for buyer OR seller, not both |
There was a problem hiding this comment.
The 'No Double-Counting' security invariant states that marketplace trades count for the 'buyer OR seller, not both'. This is ambiguous. To ensure predictable and fair reward distribution, the specification should clarify which party receives the activity score credit, or define the mechanism for determining it (e.g., always the buyer, or configurable by governance).
| Phase 1 (Q1-Q2 2026): M013 (Fee Routing) — can be deployed independently | ||
| ↓ | ||
| Phase 2 (Q3-Q4 2026): M014 (PoA) — requires M013 for validator compensation | ||
| ↓ M012 (Dynamic Supply) — requires M013 for burn input |
There was a problem hiding this comment.
The ASCII diagram for the implementation sequence is confusing due to a stray arrow on this line. It visually implies that M012 depends on an arrow. This appears to be a formatting error. Suggest removing the arrow to clarify that M012 and M014 are parallel activities in Phase 2.
Expand the M010 Reputation Signal spec with a complete challenge/dispute workflow — the primary gap identified in the v0 advisory spec. SPEC.md (143 → 380 lines): - Full 7-state signal lifecycle state machine with guards and actions - v0 resolution (admin with safeguards, auto-escalation on timeout) - v1 resolution (Arbiter DAO reusing M008 infrastructure, with appeal) - Challenge parameters, submission requirements, rejection conditions - Score impact table per signal state - Signaler accuracy tracking (v1) - 6 challenge KPIs for digest monitoring - 20 acceptance tests (up from 6) New files: - schemas/m010_challenge.schema.json (challenge event schema) - datasets/fixtures/v0_challenge_sample.json (replay fixture with varied signal statuses + 3 challenge resolutions) Updated files: - schemas/m010_signal.schema.json (added status enum field) - schemas/m010_kpi.schema.json (added challenge_kpis object) - phase-2/2.1-token-utility-mechanisms.md (M010 section expanded with challenge state machine, participants, parameters, 3 new invariants) Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Bridge the gap between OPAL's qualitative checklist questions and the quantitative 0.0-1.0 scores in the work-order schema. Adds to docs/governance/pacto-opal-alignment.md: - Rubric-based scoring model with 4-5 weighted criteria per dimension - Per-dimension formulas: Ontology (entity alignment, schema compat, concept integration, terminology), Philosophy (ecological regen, human sovereignty, equitable distribution, PACTO triadic), Architecture (system compat, dependencies, tech debt, security), Language (clarity, accessibility, terminology, multilingual), Action (agent capability bounds, human impact, reversibility, layer) - Composite score with category-specific weight overrides - Governance routing thresholds (expedited/standard/enhanced/blocked) - Scoring workflow: context gathering → per-dimension eval → routing - Score persistence and versioning model - 4 open questions for WG resolution Updates: - schemas/work-order.schema.json: opal_scores description references algorithm - docs/governance/agentic-governance-roadmap.md: Phase B deliverable B.6 and OPAL scoring capability added Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…ions M009 (Service Provision Escrow): Added complete dispute resolution flow via M008 Arbiter DAO, cancellation workflow, milestone lifecycle state machine, agent integration (WF-RR-04), governance parameters, 8 security invariants, 4 open questions, and token flow breakdowns for all resolution types. M011 (Marketplace Curation): Added 5-state collection lifecycle, curator bond/slash/reward token flows, quality scoring algorithm with input sources and price fairness calculation, AGENT-003 integration (WF-MM-04), collection challenge mechanism, featured batch system, governance parameters, 8 security invariants, and 5 open questions. Also adds WF-RR-04 and WF-MM-04 agentic workflows and updates mechanism dependency graph in phase-1 inventory. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…esses M001-ENH: Added dual participant tables (pre/post-PoA), dual-track voting model specification (60% validator track + 40% holder track), transition phases, and 2 new open questions (OQ-M001-1, OQ-M001-2). Phase-1 inventory: Updated M001, M002, M003, M005 with PoA status annotations explaining supersession/modification by M014/M013/M015. Added M003 and M005 to dependency table. Updated M009 and M011 dependencies. Governance processes (2.3): Added PoA impact annotations to all 5 governance processes (GOV-001 through GOV-005), expanded parameter categories with new authority_validators/fee_routing/rewards categories, added post-PoA governance layer decision matrix, PoA governance transition plan with 4 phases, and 3 transition open questions (OQ-GOV-POA-1 through OQ-GOV-POA-3). Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
CShear
changed the title
…to M013 Adds OQ-M013-5 documenting the community debate over whether buy-back-and-burn encourages speculation vs. the capital formation argument for maintaining burn. Presents four positions from zero burn to dynamic burn share. Expands OQ-M013-3 from a one-liner into a full treatment of fee collection and distribution denomination (REGEN vs stablecoins), covering collection-side options (REGEN-only, native denom, hybrid) and distribution-side options (stablecoin, convert-to-REGEN, recipient choice with REGEN premium). Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
1 participant
Summary
This PR addresses 5 of 6 identified specification gaps in the agentic-tokenomics repo, adding ~2,500 lines across 19 files. Gap 6 (contributor guides) is deferred pending review feedback on spec patterns.
Commits
1. Economic Reboot Mechanism Specifications (M012-M015)
New file:
phase-2/2.6-economic-reboot-mechanisms.md(674 lines)Formalizes the Tokenomics WG's Economic Reboot proposals into protocol-level specs:
S[t+1] = S[t] + r(C-S[t]) - B[t]Sources: Fixed Cap (forum/34), PoA RFC (forum/70), Economic Reboot Roadmap (forum/567), Network Coordination Architecture (forum/19#67)
2. M010 Challenge/Dispute Workflow
Expanded:
mechanisms/m010-reputation-signal/SPEC.md(143 to 380+ lines)m010_challenge.schema.json, updated signal/KPI schemasv0_challenge_sample.jsonwith 8 signals + 3 challenges3. OPAL Coherence Scoring Algorithm
Expanded:
docs/governance/pacto-opal-alignment.md(233 to 473 lines)4. M009/M011 Skeleton Expansion
Expanded:
phase-2/2.1-token-utility-mechanisms.md— M009 (~90 to ~250 lines), M011 (~50 to ~290 lines)M009 (Service Provision Escrow): Complete dispute resolution via M008 Arbiter DAO, cancellation workflow, milestone lifecycle sub-machine, agent integration (AGENT-001 WF-RR-04, AGENT-003), 9 governance parameters, 8 security invariants, 4 open questions.
M011 (Marketplace Curation): 5-state collection lifecycle, curator bond/slash/reward flows, quality scoring algorithm with input sources, AGENT-003 integration (WF-MM-04), collection challenge mechanism, featured batch system, 12 governance parameters, 8 security invariants, 5 open questions.
Also adds WF-RR-04 and WF-MM-04 agentic workflows to
phase-2/2.2-agentic-workflows.md(12 to 14 workflows).5. PoA Transition Annotations
Updates M001-ENH, M001/M002/M003/M005 inventory, and governance processes for M014 implications:
6. M013 Burn Debate and Fee Denomination Questions
Adds two substantive open questions surfaced from community discussion:
Open Questions Summary (36 total)
Files Changed (19)
New files (3):
phase-2/2.6-economic-reboot-mechanisms.md,m010_challenge.schema.json,v0_challenge_sample.jsonSubstantially expanded (5):
2.1-token-utility-mechanisms.md(+637),m010 SPEC.md(+284),pacto-opal-alignment.md(+240),2.3-governance-processes.md(+142),2.2-agentic-workflows.md(+96)Cross-reference updates (11):
1.2-tokenomic-mechanisms.md,phase-2/README.md,README.md,token-economics-synthesis.md,agentic-governance-roadmap.md,work-order.schema.json, and 5 m010 supporting filesTest plan
Generated with Claude Code