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 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. Other operators or auditors can recompute the artifact and 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, 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 a slash follows a rejected root, 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.
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 21-day slashable review window, so an operator's undelivered earnings act as collateral that grows with their usage — a misbehaving proposer forfeits the bond, weeks of fee income, and the future fee stream together.
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 |
|---|---|---|
| Blind phase | 20 minutes | 20 seconds to 30 days |
| Max duration | 20 minutes | 20 seconds to 60 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; 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.
