> For the complete documentation index, see [llms.txt](https://rh-project.gitbook.io/red-horse-rh/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://rh-project.gitbook.io/red-horse-rh/governance/5.3-parameters.md).

# 5.3 Parameters

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.