Core Contracts

Overview

The Governance contract’s documentation highlights “support for multiple proposal types.” As seen in the code snippet:

The proposalType is captured and stored in each ProposalCore but never used in:

• Voting Thresholds: No different or specialized thresholds for “parameter changes” vs. “generic.”

• State Transitions: The code does not treat different proposal types differently in state(...).

• Execution Paths: The _executeProposal function does not branch on proposalType to handle treasury actions or parameter changes in a distinct manner.

Meanwhile, the contract documentation explicitly states it “supports multiple proposal types” as a key feature. One would expect distinct logic to handle each type (e.g. different required quorums, distinct timelock paths), but there is none.

Contradiction & Impact

1. Contradicts “Multiple Proposal Types”
   The code base signals multi-type governance yet lumps all proposals into the same routine. This mismatch between code and doc confuses integrators who might rely on specialized rules for certain types.

2. Misleading or Incomplete Governance
   Stakeholders or developers reading the docs may assume they can create a “treasury” or “param change” proposal with specialized flow, only to find the system handles them exactly the same as any other proposal.

3. Potential Incomplete Feature
   If the team intended to eventually expand logic for each type (like different quorums or approval processes), that is not implemented. The project may inadvertently run governance with a narrower feature set than publicly documented.

Proof

A cursory search in the code snippet for any usage of proposalType reveals no references after the initial assignment. The public state(...), castVote(...), _executeProposal(...), _queueProposal(...), etc. ignore it entirely, functionally making it a “dead” field in ProposalCore.

Recommendation

1. Remove proposalType
   If no specialized logic is planned, removing this parameter (and its references in the docs) eliminates confusion.

2. Implement Type-Specific Logic
   If multiple proposal types are indeed a design goal, incorporate them:

   • Different thresholds for each type (e.g., “financial proposals require 2x the normal threshold”).

   • Distinct execution flows in _executeProposal (treasury proposals call certain modules, parameter proposals do on-chain parameter changes, etc.).

   • Separate doc describing how each proposalType modifies the governance flow.

3. Document Real Behavior
   If proposalType is purely informational for UI or off-chain references, clarify that it has no effect on on-chain execution so integrators aren’t misled.