5.2 Process

How proposals are made, reviewed, and executed

RH governance is designed to be lightweight, transparent, and execution-focused. The process defines how proposals are introduced, how feedback is collected, and how approved changes are implemented—while keeping discretionary power limited and ensuring users can verify what changed.

Governance operates in phases. Early governance prioritizes clear operational discipline and limited parameter changes. As the ecosystem matures, the process may expand to include broader participation mechanisms.

Governance Lifecycle

Step 1) Proposal Draft

A proposal begins as a draft that clearly states:

• What will change (parameters, budgets, policies)

• Why it should change (rationale and intended outcomes)

• Scope and limits (what is affected, what is not)

• Implementation plan (timing, execution steps, and rollback/migration plan if applicable)

• Risk assessment (security, operational, and community impact)

Proposals should use versioned parameter references and include specific values.

Step 2) Public Review & Feedback

Draft proposals are shared through official RH channels for community review. Feedback is collected for a defined review window.

• Review windows are time-bound (e.g., 48–72 hours for routine changes; longer for major changes).

• Questions, objections, and alternative suggestions are recorded publicly where feasible.

Step 3) Decision / Approval

Approval mechanisms may vary by phase:

• Phase 1 (Operational Governance): Decisions are approved by a designated governance committee or multisig signers under disclosed policy constraints.

• Phase 2 (Hybrid Governance): Community signaling (polls) may be introduced alongside operational approval.

• Phase 3 (On-chain Governance): Formal on-chain voting may be introduced for eligible parameters when readiness allows.

Regardless of phase, governance must remain within the scope defined in Section 5.1.

Step 4) Execution

Approved changes are executed according to the implementation plan:

• Parameter updates are applied at defined checkpoints (often at epoch boundaries).

• Changes are announced with effective dates and the updated parameter set.

• On-chain transactions used for execution are referenced for verification.

Step 5) Reporting & Retrospective

After execution, RH publishes a brief retrospective:

• What was changed (before/after values)

• When it became effective

• Whether any incidents occurred

• Any follow-up actions required

Emergency Governance (Exceptional Cases)

In emergencies (e.g., security incidents), RH may use an accelerated process:

• Immediate containment actions (e.g., pausing specific functions)

• Rapid public disclosure of the incident and actions taken

• Follow-up governance proposal for any longer-term changes

• Retrospective reporting after stabilization

Emergency actions must be narrowly scoped and used only for risk containment.

Governance Artifacts (Documentation)

To keep governance auditable, RH maintains:

• A proposal archive (IDs, versions, and outcomes)

• Parameter registry (current values and change history)

• Treasury reporting (budgets and spend summaries)

• Security notices (if applicable)

This process is intended to keep RH governance predictable: changes are proposed openly, reviewed, approved within scope, executed transparently, and documented for verification.