[Feature]: GoodDAO MVP Governance Contract

[L03TJ3]

Summary

We need a planning pass for the MVP GoodDAO governance contract.

This is not an implementation task yet.
The goal is to inspect the existing repository and produce a clear implementation plan for a single smart contract that handles GoodDAO house membership, staking, House of Alignment eligibility, approval, and quarterly allocation voting.
The end goal should be a concise execution plan that outlines the contract interface and considerations for the different roles/read/write methods.
Keep it simple!

Confirmed Direction

Build one MVP contract, tentatively named:

GoodDaoHouses.sol

The contract should handle:

1. House of Alignment and House of Citizens membership
2. staking-based registration using G$
3. single-transaction register + stake flow, using transferAndCall from the G$ token contract or ERC777-style receive hooks if appropriate
4. GovernanceCommittee-managed House of Alignment whitelist / registry
   --- GovernanceCommitttee should be a ROLE assigned that governs: (post registration) House Of Alignment approvals and (pre-registration) member whitelist registration
5. HoA approval and revocation
6. fixed voting weights by house
7. quarterly Alignment Vote creation, voting, finalization, and execution
8. frontend-readable member, whitelist, vote, and result state
9. optional FlowSplitter integration for finalized allocation results

Scope of This Planning Task

Inspect the repository and produce an implementation plan as sub-issue of these instructions.

Do not implement the contract yet.
The plan should identify:

• where the contract should live
• existing contract patterns to reuse
• existing token interfaces available for G$
• whether transferAndCall, ERC777 hooks, or another existing pattern should be used for single-transaction register + stake
• existing access-control patterns
  -- and defining which roles are required and can be assigned
• existing proxy / upgradeability patterns
• existing FlowSplitter interfaces or references (do a websearch on the contract definition: https://docs.flowstate.network/developers/IFlowSplitter)
• existing deployment and test conventions

Required Contract Behavior

Houses

The MVP has two houses:

• House of Alignment
• House of Citizens

Both houses require staking G$ to become members.

House of Alignment members represent approved aligned projects, organizations, or wallets.

House of Citizens members represent regular participating members.

Metadata per house:

• HoA: Name, Project webpage, mission statement, redistribution strategy
• HoC: Name, (optional) social links

House of Alignment eligibility registry

The contract must include an on-chain registry of addresses eligible to register as House of Alignment members.

Requirements:

• GovernanceCommittee or an authorized role can add/remove eligible HoA addresses
• anyone can read whether an address is HoA-eligible
• HoA registration must be restricted to eligible addresses
• HoA eligibility is separate from active membership
• registry updates must emit events
• registry updates, member registration should besides events also track sign-up/update dates with timestamps as part of the registry.

Registration and staking

Registration and staking should be handled as one user transaction.

Preferred direction:

• use transferAndCall from the GoodDollar token contract if available and appropriate
• otherwise evaluate ERC777-style hooks or the closest existing repo-compatible pattern

The plan should confirm the best implementation path after inspecting existing contracts and token interfaces.

Membership lifecycle

House of Alignment:

• address must be HoA-eligible before registering
• user registers with metadata and stakes the required G$ amount
• member enters Pending status
• GovernanceCommittee or authorized role approves the member
• approved member becomes Active
• only active HoA members can receive Alignment Vote allocations

House of Citizens:

• user registers with metadata and stakes the required G$ amount
• member becomes Active immediately after successful registration/staking
• active HoC members can vote
• HoC members cannot receive Alignment Vote allocations

Unstaking should remove future eligibility but preserve historical participation through events.

GovernanceCommittee / permissions

Use role-based access control.

The plan should propose the cleanest role model for (admin vs GovernanceCommitee):

• managing the HoA eligibility registry (GovCo)
• approving HoA members (GovCo)
• revoking HoA members (GovCo)
• creating quarterly Alignment Votes (GovCo)
• finalizing votes (GovCo)
• executing finalized results (GovCo)
• pausing sensitive actions if needed (Admin)

The plan should say whether to use one broad GOVERNANCE_COMMITTEE_ROLE or split permissions into more granular roles.

Alignment Votes

The MVP only needs one vote type:

AlignmentVote

Purpose:

Allocate the GoodDAO Impact Pool / Community UBI Pool across active House of Alignment members.

Voting rules:

• active HoA members can vote
• active HoC members can vote
• only active HoA members can receive allocations
• HoA voting weight: 40
• HoC voting weight: 4
• each voter allocates their full weight across eligible HoA recipients
• voters can update their vote while the vote is open
• voting window is expected to be 7 days
• eligible voters and recipients should be snapshotted at vote creation
• finalization stores canonical results
• execution into FlowSplitter is separate from finalization
• finalized results must remain available even if execution fails

Quarterly vote creation

Alignment Votes are expected to happen on a quarterly cycle.
The plan should recommend how this should be represented in the MVP contract:

• fully manual creation by authorized role
• semi-automated creation by authorized automation/keeper wallet
• or another repo-compatible pattern

The contract does not need to autonomously create votes without an external transaction.

FlowSplitter integration

Contract Reference: https://docs.flowstate.network/developers/IFlowSplitter
FlowSplitter execution is desired but should be isolated from vote finalization.
Requirements:

• finalized vote results are stored before execution
• execution can only happen after finalization
• execution is permissioned
• a vote cannot be executed twice
• if FlowSplitter execution fails, finalized vote results remain stored
• FlowSplitter support should be configurable or disableable

The plan should identify the correct FlowSplitter interface and result-unit format from the existing codebase, if available.

Expected Output

Return a concise execution plan covering:

• proposed contract shape
• interface for read/write/events
• repo patterns to reuse
• main implementation steps
• key tests
• unresolved questions / risks

Do not write the contract yet. Do not produce a full technical specification.

Acceptance Criteria

The plan should be short enough for a maintainer to review quickly and clear enough to approve or adjust before assigning implementation.