Skip to main content

CLUE Moderation and Arbitration Mechanics

Moderation and arbitration in CLUE are implemented as a formal on-chain contour of market quality: who votes, with what weight, when a case is escalated, how consensus is calculated, and how rewards/penalties are distributed — everything is fixed by contracts, not by manual decisions.

Moderation​

  • Moderation circuit: Moderation + ModerationRegistry + CommitteeCore. Moderators form the primary quality signal of the market through bit flags (see also market moderation rail).
  • Link to markets: MarketsLifecycle and MarketsAppeals open cases, move market states in the lifecycle, and transmit data to the moderation/arbitration contour.
  • Committee source: ModeratorsPool (top candidates + weights) and ModeratorsManager (committee sizes, score/slashing steps, rounds parameters), aligned with the moderator/arbitrator staking model.
  • What does a moderator do: participates in moderation-cases, votes by flags, receives rewards for participation and penalties for omissions/discrepancies from final result (see slashing mechanics).

How to open a moderation case​

  1. Market creation: in MarketsLifecycle.addMarket the market is created with status Approved (see market lifecycle).
  2. Case funding: marketFee is transferred to moderationRegistry as moderation reward pool (see market listing fee).
  3. Creating a case: createCaseFromRegistry(...) is called in Moderation, then case is linked to market (setModerationCase) via contract binding.
  4. Seed fixation: base seed of case is stored in market (setMarketBaseSeed) and is used to deterministically build round committees (see state-machine determinism).

Mechanics of case moderation​

A moderation case in CLUE is a separate on-chain entity tied to a specific marketId. Its task is not “manual censorship,” but a formal fixation of market risk profile through deterministic committee logic and the flags bit model.

  1. Case init: when creating a market, moderation case opens, reward pool is added (from marketFee), and service parameters are recorded (creation time, seed, case type) in sync with market creation flow.
  2. Round context: active round is calculated by roundIndex = (now - createdAt) / roundSeconds; this makes round transitions predictable and testable under on-chain state transitions.
  3. Committee build: from moderator roster-slice, a round working committee is formed with weight cap (maxWeightBps) so no address dominates beyond permissible limit (see effective weight model and anti-concentration policy).
  4. Voting: each committee member submits one vote in uint8 flags format; vote data is written to case registry and used in final bit count (see data flows).
  5. Finalize: after full committee quorum is reached, case is finalized, final moderationFlags are written to MarketsRegistry, and reward/penalty is applied by contract logic (see fee/reward execution rail).

Practical meaning: moderation does not directly change AMM pricing, but adds an on-chain quality layer that transparently affects moderator reputation and role incentives.

Formation of committee and weight​

  • Roster snapshot: when creating a case, a top-slice of moderators is taken from pool by activeModeratorsLimit, then weighted candidate order is formed (see moderator pool model).
  • Round mechanics: for each round roundIndex = (now - createdAt) / roundSeconds.
  • Rolling committee: round composition is assembled from already-voted participants plus roster-chunk candidates, with deterministic continuity across case rounds.
  • Weight normalization: final committee weights are normalized with maxWeightBps, so one address cannot monopolize round influence (aligned with anti-whale safeguards).

“Ticks” (flags) and the bit model​

In moderation, the vote payload is uint8 flags (bit mask). The contract stores only bits, while human-readable labels are specified by frontend/indexer conventions (see contract-level moderation path).

  • Flag limit: moderationFlagsCount (default 5, maximum 8), configurable via governance controls.
  • Current working profile (5 flags): bit0=adult, bit1=violence, bit2=restricted_sensitive, bit3=scam_risk, bit4=low_quality.
  • Masks: 1, 2, 4, 8, 16 (in hex: 0x01, 0x02, 0x04, 0x08, 0x10), used as protocol-level risk-marking layer.

How is consensus on flags calculated?​

  • Condition for finalizing the round: case closes when votes == committeeSize (same quorum closure logic as in arbitration voting).
  • For each bit: the weighted support for the flag is summed, then the strict majority rule is applied:
flagi={1,weighti×2>totalWeight0,otherwise\mathrm{flag}_i = \begin{cases} 1, & \mathrm{weight}_i \times 2 > \mathrm{totalWeight} \\ 0, & \text{otherwise} \end{cases}

Important: the threshold is strict (>50%), not ≥50%.

Rewards and penalties in moderation​

  • Reward pool: taken from funded marketFee and distributed among final committee proportionally to weights (see publication fee economics).
  • If there are no weights: reward is returned to case creator address.
  • Activity-score: voter receives activity-based reward; missing round votes are automatically penalized (see activity discipline).
  • Slashing-score: after finalization, each moderator’s bits are compared with final bits. Matches give recovery step, mismatches give penalty step (scaled by correct/incorrect bit share), aligned with token slashing policy.

Moderators work diagram​

Moderation flow
Opening a moderation caseThe market opens a funded review case on-chain.
→
Moderators committeeA deterministic committee is formed from the moderator roster and weights.
→
Total for each flagWeighted votes determine the final bitmask for each moderation flag.
→
Rewards and penaltiesCase rewards and score adjustments are applied according to final outcomes.

Arbitration​

Arbitrators are involved when an outcome dispute is not resolved at regular outcome-submission level. Their task is to provide a final on-chain decision with measurable consensus and economic accountability (see resolution branches).

When an appeal opens the way to arbitration​

  • The market is in AwaitingAppeals, outcome has already been submitted, and mode is Standard only (see Standard vs Self resolve).
  • The appellant selects desiredOutcome (0 = cancel, 1..N = specific outcome), which must differ from current outcome (outcome-space follows market type model).
  • One address - one appeal for the current era (appealEpoch).
  • Default escalation threshold: appealEscalationThresholdBps = 30_000 (that is 30% in bpsDenom=100_000 scale), parameterized under governance mechanics.
  • What is stakeAgainst: this is the amount of stake for all outcomes, opposite selected desiredOutcome. In a binary market, this is literally the stake of the “other/losing” side; in multi-outcome, it is the sum of all alternative outcomes.
  • Escalation condition: appeal stake must cover at least 30% of stakeAgainst (by default), then an arbitration case is created.
  • Bonds and deposits: with makeAppeal, an appeal fee deposit is placed into rewardPool; with sendToResolve/reopenArbitration, a separate auto-resolve bond is posted (minimum minAppealBond, default 100 CLUE) (see edge/fail-safe branch).

Formally:

appealedStake×100000≥stakeAgainst×thresholdBps\mathrm{appealedStake} \times 100000 \ge \mathrm{stakeAgainst} \times \mathrm{thresholdBps}

In case of default thresholdBps=30000 this is “30% of the side against”.

Fee, stake and escalation threshold​

  • Appeal fee: is taken as maximum of stake-based fee and floor component (manager parameters: appealFeeBps, appealFeeFloorBps) in the appeals flow.
  • Target outcome: fixed by the first appeal; subsequent appeals must maintain the same target.
  • Escalation: occurs when the total appeal stake passes the threshold:
appealedStake×100000≥stakeAgainst×appealEscalationThresholdBps\mathrm{appealedStake} \times 100000 \ge \mathrm{stakeAgainst} \times \mathrm{appealEscalationThresholdBps}

During escalation, an arbitration case is created, appeal rewardPool is transferred to bondPool, and market is linked to arbitrationCaseId (see market dispute state machine).

Auto-resolve, escalation and opening of an arbitration case​

  • If the creator did not submit outcome on time: after resolveAt + outcomeSubmissionGrace, any participant can call sendToResolve with a bond (see overdue outcome branch).
  • If arbitration consensus is weak: market remains in AwaitingAppeals, appeal fee parameters increase (appealBondEscalationStepBps), and process can repeat with a new arbitration round (see economic risk control loop).

Mechanics of an arbitration case​

An arbitration case opens when a dispute goes beyond normal appeal: through escalation threshold, auto-resolve, or re-escalation after weak consensus. This is a separate cycle with its own caseId, committee, and accumulation of consensus metrics within lifecycle state transitions.

  1. Case open: arbitration case is created, market is linked with arbitrationCaseId, and appeal funds are transferred to case bond circuit (see appeals/escalation binding).
  2. Committee selection: registry builds arbitrator committee from moderator pool using seed/roster logic with weight normalization and arbitrationMaxWeightBps cap (see moderator weight model).
  3. Outcome voting: arbitrators vote on outcomeIndex (including 0 = cancel); the round closes when the votes of the entire committee have been collected.
  4. Round result: the winning outcome is determined, the round consensusBps is fixed, and then lifecycle updates the aggregates consensusSumBps and arbitrationRounds.
  5. Execution gate: if average consensus reaches threshold, market is finalized; if not, market remains in AwaitingAppeals and new cycle starts (new appealEpoch and potentially new arbitration case), per edge/fail-safe policy.

Arbitrators' voting​

  • Valid options: outcomeIndex in range 0..N, where 0 is market cancellation (consistent with market outcome model).
  • Finalization: at votes == committeeSize.
  • Winner: outcome with maximum weight; in tie, deterministic tie-break from case seed is used (see contract determinism).

Aggregate Consensus and Replication Case​

For each arbitration round, consensusBps = winningWeight / sumWeights in bps is calculated. Next, lifecycle takes into account the average consensus across rounds:

avgConsensus=consensusSumBpsarbitrationRounds\mathrm{avgConsensus} = \frac{\mathrm{consensusSumBps}}{\mathrm{arbitrationRounds}}

Final execution is allowed when avgConsensus ≥ arbitrationFinalConsensusBps (threshold is set by ModeratorsManager through governance-controlled parameters).

If threshold is not reached, protocol does not “force” controversial finalization: market remains in AwaitingAppeals, next appeal round accumulates, and at new escalation threshold opens a repeated arbitration case (new caseId in new appealEpoch), aligned with risk mitigation for disputes.

  1. The arbitrators' round is closed and the local consensusBps is recorded.
  2. Lifecycle updates consensusSumBps and arbitrationRounds.
  3. It is considered avgConsensus = consensusSumBps / arbitrationRounds.
  4. If avgConsensus is below the threshold, the market returns to AwaitingAppeals, appeal parameters are strengthened.
  5. After repeated escalation, a new arbitration case is opened and the cycle continues until the final consensus threshold is reached.

Reward, creator-share and sanctions​

  • Committee rewards: distributed proportionally to final committee weights (if case has reward pool), consistent with role incentive design.
  • Creator share redirect: if appeal is confirmed, creator fee share can be redirected in favor of arbitrators (see fee-flow redirect path).
  • Slashing-score in arbitration: participants who voted for final winner receive recovery-step; those against receive penalty-step (aligned with moderator/arbitrator slashing model).
  • Fail-safe: if transfer of a share fails, pending/stuck accounting is applied with rescue/retry path (see fail-safe payouts).

Arbitration cycle diagram (with repeated case)​

Arbitration cycle
Threshold metAppealed stake reaches 30% of stakeAgainst by default.
→
Arbitrators voteCommittee members vote on outcome index 0..N.
→
Compute avgConsensusLifecycle aggregates consensus across arbitration rounds.
Execution gateIs average consensus at least 70%?
YesFinalize market through resolve/cancel and finalizeFees.
NoReturn to AwaitingAppeals, increase fee/floor by 25%, and open a new caseId.

Arbitration payout flows (without ambiguity)​

  • What forms the arbitration pool: appeal deposits (rewardPool) upon escalation move to bondPool; auto-resolve adds separate caller bond (see appeals-open flow).
  • Branch 1 - appeal confirmed (targetOutcome coincided with final one): redirectCreatorShare = true, creator fee from AMM fee circuit is sent to arbitration and divided by committee weights; appeal pool goes to appellant refund mechanics, not arbitrator payout.
  • Branch 2 - appeal rejected (targetOutcome did not match): creator share remains with creator recipient, and bondPool is distributed among “correct” arbitrators proportionally to weight; claim-window applies, after which unclaimed remainder can be swept to feeTreasury (claim-window = appealPeriod, default 30 minutes).
  • Low consensus (<70% avg): market is not finalized, payouts are not closed, and repeat cycle starts with increased fee/floor appeal parameters and a new arbitration case (see repeat arbitration loop).
  • Auto-resolve bond caller: refunds follow corresponding branches; if temporary balance shortfall occurs, pending balance is recorded with separate claim path so amount is not lost (see operational safeguards).

Transparency and stability invariants​

  • There is no manual “override” of outcomes: status and outcome transitions are performed only through valid contract lifecycle branches (see security invariants).
  • Committees are determined by seed logic: composition can be reproduced using on-chain data (baseSeed, roundIndex, roster snapshot), consistent with technical architecture.
  • Weight is not only stake: score/slashing profile directly affects quality of future participation of moderator/arbitrator (see effective weight model).
  • Economic responsibility: rewards, bond pools, redirects and penalties create symmetrical incentives against passivity and dishonest decisions (see economic principles).

For full context around moderation, appeals, and arbitration mechanics, use these canonical sections across docs/protocol: