Governance
LREP governance controls protocol settings, upgrades, treasury routing, and optional identity policy.
Mainnet Beta
RateLoop's Base mainnet contracts are live production infrastructure. The beta label covers operational maturity around governance participation, off-chain services, indexer reliability, operator tooling, and public documentation while the deployed contract stack remains the system of record.
Routine configuration, indexing, UI, keeper, and operator issues should be resolved against the existing deployment. If a significant contract-level incident cannot be handled through governance, admin actions, or service rewiring, the community should publish a separate migration runbook that explains why the existing deployment cannot safely continue.
As the protocol leaves beta, evolution continues through the normal governance process: proposals, voting, timelock review, and execution through the deployed governance system.
What Governance Does
LREP is a capped, non-financial reputation token with no protocol token sale and no treasury backing. Governance power comes from held, self-delegated LREP, and proposals execute through the governor and timelock. The current token auto-delegates voting power to the holder and rejects third-party LREP vote delegation.
Proposal Lifecycle
| State | Meaning |
|---|---|
| Pending | Created and waiting for the voting delay. |
| Active | Voting is open: For, Against, or Abstain. |
| Queued | Passed and waiting in the timelock. |
| Executed | The change is live. |
Core Parameters
| Proposal threshold | 1,000 LREP hard floor |
| Proposal threshold range | 1,000-100,000 LREP |
| Voting delay | ~1 day |
| Voting period | ~1 week |
| Quorum | 4% of circulating supply (min 100,000 LREP) |
| Timelock delay | 2 days |
| Governance lock | 7 days after proposing or voting |
| Voting delegation | self-delegated LREP only |
Transferable LREP is an explicit launch choice, not an accidental cash-vote shortcut. Rating and payout influence are mitigated by prediction-accuracy scoring, effective-unit weighting, verified-human launch anchors, correlation payout snapshots, calibration and reveal reliability, while governance uses timelocks, voting locks, a quorum floor, and a proposal-threshold floor.
Cluster Payout Oracle
The ClusterPayoutOracle is a governance-managed target for payout and public-rating correlation accounting. It stores challengeable correlation epoch roots and per-round roots for LREP or USDC bounty claims, launch LREP credits, and public-rating effective weights. Settlement records pending raw rating evidence first; the visible rating moves after the matching public-rating snapshot finalizes and the veto window elapses.
Payout roots are proposed by registered frontend operators that have bonded 1,000 LREP in the FrontendRegistry. Operators publish the deterministic artifact URI and root from their registered wallet or a delegated snapshot keeper that approved them first, then wait through the challenge window. Artifact v3 includes pinned settlement-time input snapshot references in the epoch parameter hash, so other operators or auditors recompute against the same identity, history, and ban-state boundary and can challenge bad roots with the configured USDC challenge bond, which defaults to 5 USDC.
ClusterPayoutOracle Challenge Flow
Bonded frontend operator
Deterministic payout artifact
Challenge window
Finalize payout weights
The challenge bond is an anti-spam bond, not payout-value coverage.
Claim paths use the finalized correlation payout weights.
Governance arbitrates with a reason hash and can slash the proposing frontend.
Governance controls oracle configuration, including the challenge window, finalization veto window, challenger bond, frontend registry, and fallback bond recipient. It can also arbitrate challenged roots through proposals that either finalize a correct challenged root or reject an invalid one with a public reason hash, and can slash the proposing frontend through the FrontendRegistry if the on-chain-data computation was wrong. When rejection is expected to lead to a slash, the governance batch should include the matching slash action where appropriate; parent-epoch rejection batches should also explicitly reject any challenged child round snapshots that need their fee-withdrawal freeze cleared immediately. Governance can use slashFrontendWithBounty to route a fixed 50% of everything confiscated — the stake cut, accrued fees, and any pending fee withdrawal — to the recorded challenger, so a correct challenge is directly profitable rather than just bond-neutral. Finalized payout roots remain rejectable during the veto period even after configured consumers first consume them; after the veto window, consumed roots are final for that consumer path. Longer challenge and veto windows increase public review time but slow healthy payout finality, while shorter windows improve claim speed and narrow the review period.
The intended security model is optimistic rather than fully per-snapshot economically secured on-chain. Public artifacts, challenge windows, governance arbitration, and the globally bonded frontend-operator set are meant to make incorrect payout roots observable and punishable through frontend slashing, reputation loss, and future-fee loss. Frontend fee withdrawals wait out a 1-hour slashable review window and remain frozen during active challenged payout snapshots, so fees back accountability only while they are still accrued, pending, or challenge-frozen. The 1,000 LREP bond and separate 14-day stake unbonding period preserve operator-exit accountability for fresh offenses that governance resolves after the short fee review window.
Round Settings Bounds
Question creators can choose round settings, but only inside governance-approved ranges. That lets urgent asks settle faster while broader questions can wait for more raters.
| Setting | Default | Creator bounds |
|---|---|---|
| Question duration | 20 minutes | 20 seconds to 30 days |
| Settlement raters | 3 | 3 to 100; Governance can raise the default settlement voter count and the allowed minimum for new rounds as rater supply, bounty value, and attack pressure grow; the minimum remains at least 3 because RBTS settlement needs three participants. Already-created questions and already-open rounds keep their snapshotted configuration. |
| Voter cap | 100 | 3 to 200 |
Treasury
The treasury starts with 25M LREP under governor/timelock control. Ongoing inflows include the treasury share of contested losing pools, withdrawal fees, and forfeited unrevealed reports. Spending follows the same proposal and timelock path as upgrades.
Treasury grants can support work that grows the RateLoop feedback network: partner activation, integrations, research and data projects, community growth, protocol development, verification acceleration, appeals, and security or whistleblower rewards. These uses are treasury responsibilities rather than Launch Distribution Pool rewards. Because LREP also carries governance power, grant proposals should explain the recipient, purpose, amount, expected impact, and any milestone or reporting expectations.
Safety Powers
Governance can use public on-chain evidence to respond to collusion, repeated unrevealed commitments, clearly false self-reported context, or other behavior that damages the feedback signal. The main enforcement tools are parameter changes, payout snapshot challenge windows and bonds, oracle challenge arbitration, frontend stake slashing, calibration changes, optional credential policies, and treasury or pool routing through normal proposals.
Confidential context adds a narrower safety path: raters accept per-question confidentiality terms before hosted context is served, access logs can be anchored as public evidence artifacts, and breach reports can route to governance for bond slashing or surplus-earnings sanctions. Sanctions are meant to protect gated-context access and future earning power, not to confiscate returned stake or cancelled-round refunds.
Protocol Evolution
RateLoop is expected to evolve over time, especially as AI systems become more capable and as new smart-contract, wallet, identity, and coordination vulnerabilities are discovered. Governance was integrated from the start so the community can adapt protocol parameters, treasury routing, and safety rules without relying on informal operator discretion.
During and after beta, protocol changes should use the deployed governance path wherever possible. Material changes should be documented, reviewable, and aligned with the same proposal, voting, and timelock principles that control upgrades and configuration changes.