5.3 Parameters

The initial parameter set and how updates are constrained

This section defines the initial governance-controlled parameters for RH and the constraints that prevent arbitrary changes. The intent is to keep governance predictable and bounded: parameters can evolve, but only within clearly disclosed rules and with transparent notice.

RH parameters are versioned. Any change must include an effective date (or epoch), the before/after values, and a rationale.

Parameter Registry (Initial)

A) Membership Parameters

• Tier thresholds (MP): Initial tier thresholds as defined in Section 2.1

• Lock options: 7 / 30 / 90 / 180 days

• Duration multipliers: Initial multipliers as defined in Section 2.1

• Snapshot rule: Tier and eligibility are evaluated at epoch boundary snapshots

B) Rewards Parameters

• Epoch length: Weekly (7 days) by default

• Epoch budget cap: A maximum RH amount distributed per epoch (set by governance)

• Weighting basis: Membership Points (MP) as the primary weighting signal

• Campaign caps: Each campaign must have a disclosed maximum budget and a defined start/end window

• Unclaimed rewards policy: Roll over to the next epoch by default (unless a campaign specifies otherwise)

C) Treasury Parameters

• Budget cycle: Monthly budgeting (baseline)

• Spending categories: Operations / Ecosystem / Security / Community / Reserve

• Approval thresholds: Tiered approvals based on spend size (e.g., small/medium/large)

• Reporting cadence: Monthly public summaries (baseline)

D) Safety Parameters

• Emergency pause scope: Limited to specific functions (e.g., reward claims and/or new locks)

• Emergency trigger policy: Defined conditions for activation and disclosure requirements

• Migration policy: Procedures for contract replacement if required, including user notices and transition windows

Constraints (What Prevents Arbitrary Changes)

To prevent governance from becoming discretionary or unpredictable, RH applies constraints:

• Bounded change limits: Critical parameters have maximum change rates per cycle (e.g., budget caps cannot jump beyond a disclosed percentage within a single month).

• No retroactive changes: Completed epochs cannot be modified retroactively.

• Notice and versioning: Changes require advance notice and a new parameter version.

• Checkpoint execution: Changes take effect at defined checkpoints (typically epoch boundaries).

• Transparency: Before/after values, rationale, and execution transactions are publicly referenced.

Example Change Rules (Baseline)

The following baseline rules illustrate how constraints can be applied:

• Epoch budget caps may be adjusted no more than once per month (unless emergency governance is invoked).

• Tier thresholds may be updated only with advance notice and cannot reduce to zero or remove tiers without a replacement framework.

• Campaign budgets must always be capped and time-bounded.

These constraints are designed to preserve trust: RH can evolve as needed, but changes remain legible, limited, and verifiable.