docs: PoA open questions triage with priorities and resolution recommendations#59
docs: PoA open questions triage with priorities and resolution recommendations#59brawlaphant wants to merge 2 commits intoregen-network:mainfrom
Conversation
…endations Structured triage of all 31 formally numbered open questions plus 4 bioregional framework questions and 8 newly identified implicit gaps. Assigns P0/P1/P2 priority, resolution owner, concrete recommended answer, implementation dependencies, and blocking analysis for each. Key findings: - 8 P0 items block implementation (fee distribution model is the root) - 8 implicit questions were not asked in any spec (zero-revenue contingency, SDK v0.54 readiness, IBC safety, stability locks + voting power) - Critical path: OQ-M013-1 -> OQ-M013-5 -> OQ-M012-1 -> OQ-M014-3 - 9 NEEDS_GOVERNANCE items packaged into 3 proposal groups Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Summary of ChangesHello, 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 a detailed analysis and prioritization of all outstanding questions concerning the Proof-of-Authority (PoA) migration and Economic Reboot. It aims to provide clarity on implementation dependencies, identify critical path items, and propose concrete resolutions, including those requiring community governance, to ensure a smooth and well-planned transition for the network. Highlights
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. 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 new document, docs/governance/poa-open-questions-triage.md, which comprehensively triages open questions for the Proof-of-Authority (PoA) migration and Economic Reboot. The document categorizes questions by priority, resolution owner, recommended answers, and dependencies, and identifies additional implicit questions. The review comments highlight several critical inconsistencies within the document, including conflicting descriptions of the OQ-M012-5 multiplier phase progression, discrepancies in deadlines for OQ-IMPL-1, numerical inaccuracies in P0 item counts and status categories, logical contradictions in the priority and status of OQ-M001-1 and OQ-GOV-POA-1, an incomplete critical path analysis for P0 items, and multiple discrepancies in the packaging of NEEDS_GOVERNANCE items for governance proposals. These issues require resolution to ensure document clarity, accuracy, and effective project planning.
|
|
||
| **Rationale:** Each phase addresses the network's most pressing need at that stage. The `max()` selection during TRANSITION prevents a regrowth cliff as staked tokens unbond while stability commitments ramp up. | ||
|
|
||
| **Status:** RESOLVED -- The OQ resolution doc and M012 spec both describe this phase-gated approach. |
There was a problem hiding this comment.
The status claims that The OQ resolution doc and M012 spec both describe this phase-gated approach. While the M012 spec does align with the recommendation here, the open-questions-resolution.md document describes a different progression for OQ-M012-5:
Recommendation: Phase-gated progression: staking multiplier at launch, maximum deflation multiplier when staking ratio exceeds 60%, stability multiplier when supply reaches governance-defined target. Transitions triggered by on-chain conditions.
This is inconsistent with the M014 state-based progression recommended in this document. Please clarify which approach is correct and update the documents for consistency.
References
- To improve document clarity, co-locate all state definitions and transitions within the primary state machine documentation, including definitions for edge-case flows like escalations, or ensure consistency across referenced documents if they are not co-located.
- When specifying transition logic between different mechanisms (e.g., multipliers), explicitly define the function and the state-based conditions (phase-gating) that govern the transition to prevent implementation ambiguity. Inconsistencies across documents lead to ambiguity.
|
|
||
| | Gap | Risk if Unresolved | Recommended Next Step | | ||
| |-----|--------------------|-----------------------| | ||
| | OQ-IMPL-1: Zero fee revenue | Validator exodus during downturn | Tokenomics WG designs contingency mechanism by April 2026 | |
There was a problem hiding this comment.
There are conflicting deadlines for resolving OQ-IMPL-1: Zero fee revenue:
- This table suggests a deadline of April 2026.
- The 'Timeline Mapping' section (line 1195) lists it as due by August 2026.
- The 'P0 Resolution Order' section (line 1175) states it must be resolved before M014 activates, which is part of the Stage 3 mainnet deployment in Q4 2026.
Please reconcile these different timelines to provide a single, clear deadline for this P0 item.
References
- To improve document clarity, ensure all related information, such as critical deadlines for P0 items, are consistent throughout the document. Conflicting timelines can lead to significant project management issues and misinterpretations.
|
|
||
| | Priority | Count | Description | | ||
| |----------|-------|-------------| | ||
| | P0 (blocks implementation) | 8 | Must be resolved before any code is written | |
There was a problem hiding this comment.
The count of P0 items is stated as 8, but the summary table at the end of the document (lines 1081-1127) lists 10 items with P0 priority. This discrepancy should be resolved for clarity.
References
- To improve document clarity, ensure all related information, such as counts and summaries, are consistent throughout the document. Inconsistencies can hinder understanding and lead to misinterpretations.
| | NEEDS_GOVERNANCE (requires community vote) | 9 | | ||
| | NOT_ADDRESSED (gaps identified in this triage) | 8 | |
There was a problem hiding this comment.
There are inconsistencies in the counts of items by status. The 'Counts by Status' table lists 9 NEEDS_GOVERNANCE items and 8 NOT_ADDRESSED items. However, the summary table at the end of the document shows 7 NEEDS_GOVERNANCE items and 12 NOT_ADDRESSED items. Please reconcile these counts for consistency.
References
- To improve document clarity, ensure all related information, such as counts and summaries, are consistent throughout the document. Inconsistencies can hinder understanding and lead to misinterpretations.
|
|
||
| **Question (from spec):** Should the default governance tally weight be fixed at 60% validator / 40% token holder, or should it vary by proposal type? | ||
|
|
||
| **Priority:** P2 -- deferrable. The base 60/40 split is sufficient for v0. Per-process variation (addressed in OQ-GOV-POA-1) is the more detailed treatment of this question. |
There was a problem hiding this comment.
There seems to be an inconsistency in the priority and status between OQ-M001-1 and OQ-GOV-POA-1.
OQ-M001-1is marked asP2 -- deferrableandRESOLVED, with the rationale that it 'Subsumes into OQ-GOV-POA-1'.OQ-GOV-POA-1is marked asP1 -- blocks mainnetandNEEDS_GOVERNANCE.
If the decision to vary weights by proposal type (OQ-M001-1) is a prerequisite for defining those weights (OQ-GOV-POA-1), then OQ-M001-1 should likely have a priority of P1 as well, and its resolution should be tied to the governance decision in OQ-GOV-POA-1. Marking it as P2 -- deferrable and RESOLVED seems contradictory.
Please consider aligning the priorities and statuses of these two related open questions.
References
- To improve document clarity, ensure all related information, such as priorities and statuses of interconnected items, are consistent throughout the document. Inconsistencies can hinder understanding and lead to misinterpretations of project timelines and dependencies.
|
|
||
| ### P0 Resolution Order | ||
|
|
||
| The 8 P0 items must be resolved in approximately the following order: |
There was a problem hiding this comment.
This section's title states, 'The 8 P0 items must be resolved...', but as noted elsewhere, there appear to be 10 P0 items identified in the document's summary table. This section only provides a numbered resolution order for 8 of them, with OQ-IMPL-3 and OQ-IMPL-8 listed without numbers at the end.
For completeness and to avoid confusion, this analysis should be updated to include all 10 P0 items in the resolution order, clarifying their dependencies.
References
- To improve document clarity, ensure all related information, such as counts and resolution orders, are consistent and complete throughout the document. Inconsistencies can hinder understanding and lead to misinterpretations.
|
|
||
| ## Recommended Governance Proposal Packaging | ||
|
|
||
| The 9 NEEDS_GOVERNANCE items should be packaged into three governance proposals (consistent with the OQ resolution doc's recommendation): |
There was a problem hiding this comment.
This section states it is packaging 9 NEEDS_GOVERNANCE items, but there are several inconsistencies:
- The summary table (lines 1081-1127) only lists 7 items with
NEEDS_GOVERNANCEstatus. - The 'Counts by Status' table (line 37) states there are 9
NEEDS_GOVERNANCEitems. - This packaging section includes
OQ-BIO-2andOQ-IMPL-4, which are marked asNOT_ADDRESSEDin the summary table, notNEEDS_GOVERNANCE.
Please reconcile these discrepancies. If OQ-BIO-2 and OQ-IMPL-4 should indeed go to governance, their status should be updated throughout the document. The total counts should also be corrected for consistency.
References
- To improve document clarity, ensure all related information, such as counts and statuses, are consistent throughout the document. Inconsistencies can hinder understanding and lead to misinterpretations of governance needs.
Address gemini-code-assist review feedback on PR regen-network#59: - Fix OQ-M012-5 multiplier phase progression to match OQ resolution doc's three-phase model (staking -> max deflation -> stability) while noting M012 spec's complementary transition bridging logic - Resolve conflicting OQ-IMPL-1 deadlines (August 2026 for testnet) - Correct P0 count from 8 to 10 (was missing IMPL-2, IMPL-3, IMPL-8 and double-counting); update P1 to 18 and all summary counts - Fix status counts to reflect all 45 items: 26 RESOLVED, 9 NEEDS_GOVERNANCE, 10 NOT_ADDRESSED - Clarify OQ-M001-1/OQ-GOV-POA-1 relationship: M001-1 resolves the principle (should weights vary?), GOV-POA-1 resolves the specifics (what weights?) -- no contradiction - Expand critical path to include all 10 P0 items with numbered resolution order and phase dependencies - Reclassify OQ-BIO-2 and OQ-IMPL-4 from NOT_ADDRESSED to NEEDS_GOVERNANCE since both are included in governance proposal packaging (Proposals B and C respectively) - Update owner counts to match actual table data Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
1 participant
Summary
docs/governance/open-questions-resolution.md— this triage adds priority ordering, dependency mapping, critical path analysis, and gap identification that the resolution doc does not provideKey Findings
Test plan
🤖 Generated with Claude Code