CLUE Staking and Incentive Mechanisms

Staking in CLUE is a multi-level on-chain system where the same CLUE token is distributed between three functional circuits: moderation/arbitration, fee-discount, and governance. Each circuit has its own rules for entry, rotation, reward/penalty, and exit, but all of them are connected by one protocol economic cycle and a shared fee-flow + incentives layer.

Key principle: dynamic competition for seats. If active spots are filled, a new participant enters the active roster only if they exceed the weakest participant’s threshold (by stake or effective weight, depending on the pool). This keeps the system anti-static: influence cannot be “bought once and forever”; it must be continuously confirmed by stake, activity discipline, and participation quality.

This page covers CLUE staking in a search-friendly structure: 3 staking pools (Moderator/Arbitrator staking pool, Fee Discount staking pool, DAO Governance staking pool), plus staking rewards, slashing mechanics, and cliff/vesting exit models.

Moderator/Arbitrator Staking PoolFee Discount Staking PoolDAO Governance Staking PoolInterplay of 3 Staking PoolsStaking Cliff & Vesting

Economic DiscountsFee FlowDispute FlowGovernance FlowToken Utility

3 staking pools
Moderation/Arbitration, Fee Discount, DAO Governance.

Dynamic rotation
Active seats are continuously contested by stronger stake/weight.

Controlled exits
Cliff, unbonding, and vesting smooth token release over time.

Moderator and Arbitrator Staking Pool

The quality-role circuit operates through ModeratorsPool and ModeratorsManager in the broader moderation/arbitration contour. Stake determines committee access, selection probability, reward share, and sanction depth for mistakes.

Moderator/Arbitrator staking pool model

• Double circuit structure: the pool maintains top (active) and reserve lists.
• Roster limits (current profile):
  • active participants: 50
  • reserve participants: 10
• Committees:
  • moderation committee: 3 (see moderation committee mechanics)
  • arbitration committee: 5 (see arbitration voting)
• Per-participant weight cap (anti-concentration):
  • moderation: up to 49%
  • arbitration: up to 40%

Effective weight, activity and slashing-score

• Participant effective weight:

$$\mathrm{effectiveWeight} = \mathrm{activeStake} \times \frac{\mathrm{activityBps} + \mathrm{slashingBps}}{2 \times 100000}$$

Weight depends not only on stake size, but also on decision quality.

• Activity-score contour: reward/penalty steps are configured by manager; current typical steps:

  • moderation: +5% / -10%
  • arbitration: +1% / -15%

• Slashing-score contour: reflects decision quality and affects final effectiveWeight; current typical steps:

  • moderation: -15% penalty / +5% recovery
  • arbitration: -30% penalty / +1% recovery

• Result: even with equal stake, a participant with better moderation consistency and arbitration quality receives more weight, enters active circuit more often, and keeps the seat more consistently.

Token Slashing (Stake Confiscation)

In addition to score penalties, severe cases use direct DAO-governed slashing via slashStake(...). Penalties can be applied in batch to multiple addresses with individual shares.

• Calculation base: slashable balance includes active stake and pending unbond queue.
• Formula:

$$\mathrm{slashAmount} = \mathrm{slashableBalance} \times \frac{\mathrm{shareBps}}{100000}$$

• Penalty destination: confiscated amount is transferred to recipient approved by governance decision.
• Consequence: lower stake automatically reduces effectiveWeight and accelerates displacement from active set, reinforcing the anti-concentration model.

Moderator/Arbitrator Participation Cycle

1. Stake: participant locks CLUE and receives initial score profile.
2. Membership: address enters active or reserve contour by current effectiveWeight (same top/reserve logic used across governance rotation).
3. Round work: moderation / arbitration actions update activity/slashing scores.
4. Reward / penalty: rewards strengthen position; mistakes reduce weight and increase rotation risk.
5. Unstake/exit: requestUnstake → unbonding → claimUnbonded (no instant withdrawal; compare with market lifecycle safety delays).

How participants crowd each other out

• Entry threshold when active is full: newcomer must exceed weakest active threshold.
• Reserve promotion: best reserve candidate is promoted when its effectiveWeight is above weakest active participant.
• Score degradation: passivity/errors can keep address in reserve even without stake withdrawal.
• Slash effect: stake reduction directly accelerates seat loss and lowers chance of influence reconcentration (aligned with risk controls vs collusion).

Trading Fee Discount Staking Pool

The discount circuit is implemented by FeeDiscountPool + FeeDiscountRegistry + FeeDiscountManager. User stakes CLUE and competes for seats in limited discount slots tied to trading-fee execution and economic model discounts.

Fee discount staking pool model

• Discount ladder: 10 slots with DAO-controlled discountBps and capacity.
• Total seat capacity (current profile): 25 active seats.
• Reserve: 5 reserve seats for instant rotation on stake changes.
• Default slot matrix:
  • discounts: 99%, 90%, 80%, 70%, 60%, 50%, 40%, 30%, 20%, 10%
  • capacities: 1,1,1,2,2,2,3,3,5,5

Entry, threshold and seat allocation

• If seats are available: participant enters active-seat circuit directly.
• If limit is full: entry only under strict rule:

$$\mathrm{newStake} > \mathrm{weakestSeatStake}$$

• Real-time recalculation: each stake change calls notifyStakeChanged and triggers top/reserve rebalance.
• Maximum discount (current profile): up to 99% (not 100%).
• Effective fee:

$$\mathrm{fee}_{eff} = \mathrm{fee}_{base} \times \left(1 - \frac{\mathrm{discountBps}}{100000}\right)$$

Formula is applied directly in AMM fee logic, while split proportions stay unchanged.

Member fee-discount cycle

1. Stake in FeeDiscountPool.
2. Threshold check: when seat-limit is full, participant must outbid weakest seat.
3. Slot assignment: after rebalance, participant gets slotId + corresponding discountBps.
4. AMM trading: effective fee is reduced; saved volume is recorded in account metrics.
5. Unstake/exit: requestUnstake → unbonding → claimUnbonded; seat can then be occupied by another address (same competitive pattern as DAO rotation).

How does “beating” happen in slots?

• With occupied active slots, newcomer must provide stake strictly above weakest active threshold (>).
• As stake grows, participant can move into higher slot (larger discount), automatically shifting lower-priority address.
• On stake drop/partial withdrawal, participant may be demoted to lower slot or pushed into reserve by larger stakers.
• If trader has no active slot seat, their discount becomes zero until re-entering active-seat contour; this links directly to trader unit economics.

Cliff/Vesting in the discount pool

FeeDiscountPool supports the same lock mechanics as other staking pools: minWithdrawTimestamp (cliff) and vestingPeriod. This allows discount benefits in active phase while keeping stake release gradual and market-predictable.

DAO Governance Staking Pool

Governance circuit is built on DAOPool + DAORegistry + DAOManager. Stake in DAOPool gives voting weight, but final influence is adjusted by real voting activity and proposal lifecycle rules.

DAO governance staking pool model

• Active composition (current profile): 15 participants.
• Reserve: 5 participants.
• Effective weight:

$$\mathrm{effectiveWeight} = \mathrm{activeStake} \times \frac{\mathrm{activityBps}}{100000}$$

Passive stake loses influence faster than active stake.

• Proposal snapshot: at proposal creation time, composition and weights are fixed, preventing post-factum restart manipulation (see snapshot model).
• DAO Rewards: distributed proportionally by effective weights in active set, not only by raw stake size (see distribution flow).

Activity discipline and impact on weight

• Participation reward: +25 p.p. to activity (up to max).
• Miss penalty: -50 p.p. (not below min).
• Economic outcome: declining activity reduces effectiveWeight and share in DAO Rewards distribution, matching governance discipline mechanics.

Participant governance cycle

1. Stake in DAOPool and enter active/reserve contour by thresholds.
2. Proposal snapshot: available weight is fixed at voting start.
3. Voting: participation increases activity-score; misses reduce it and thus future effective weight.
4. Finalize/execute: past decisions are executed in governance window; participation discipline feeds score model.
5. Unstake: exit uses unbonding + delay to reduce “instant exit after vote” risk (aligned with operational safety constraints).

How positions are “shifted” in DAO

• If active-limit is full, new address becomes active only after exceeding current entry threshold.
• Reserve participant can push weakest active to reserve when their effectiveWeight becomes higher.
• Systematic vote skipping lowers activityBps and weakens influence without forced stake withdrawal, consistent with anti-passive governance design.

Cliff/Vesting in the governance pool

DAOPool supports cliff and vesting lock configurations for phased exits. This enables long-horizon governance participation while reducing risk of abrupt “weight drain” after key votes (compare with team governance allocation lock profile).

Interplay of 3 Staking Pools: A Unified Competitive Model

The three CLUE staking pools form shared capital dynamics: the same token competes for different utility rights — role (moderation/arbitration), savings (fee discount), and influence (governance). Participants constantly rebalance stake between pools based on expected yield and strategic goals.

• Pools outbid each other via utility/profitability: moderation reward growth can pull capital from discount slots; turnover/fee growth increases demand for discount seats (see ecosystem flywheel).
• DAO controls loop parameters: top/reserve limits, activity steps, unbonding, and slot configurations are changed by governance decision, not manual operations.
• Rotation over static dominance: with filled limits, influence persists only while stake + activity are maintained; passive addresses are replaced by active ones (same principle appears in risk mitigation for role collusion).
• Anti-oligopoly: each subsystem has threshold entry, reserve rotation, and discipline coefficients, so control remains dynamic instead of permanently fixed (aligned with anti-concentration policy).

Final section logic: staking in CLUE is a continuous loop:

stake → participation → score/weight update → roster rotation → reward/penalty → restake,

where each pool has its own competition contour, but all three operate as one protocol economic system.

Staking lock types: cliff and vesting

In all three CLUE staking pools (ModeratorsPool, FeeDiscountPool, DAOPool), lock profile is configured per stake record (StakeRecord: amount, minWithdrawAt, vestingPeriod, withdrawn). Core contract point: cliff and vesting are applied not only at entry, but also at exit through requestUnstake, where volume is split using FIFO stake history. This is consistent with token distribution vesting logic and governance-controlled unlock discipline.

Resulting minWithdrawAt (cliff) is computed as max between user parameter and global pool-manager delay (now + minWithdrawDelay / minWithdrawTimestamp). So even a “basic” stake is subject to system minimum withdrawal window (important for liquidity and volatility risk control).

Basic Stake (Without Individual Vesting)

• Entry: stake without individual vestingPeriod (vestingPeriod = 0).
• Cliff: custom timestamp is optional; global manager delay still applies.
• Exit: after unlock, requestUnstake moves volume to unbond queue (without vesting schedule).
• Claim: after unbonding period, tokens are collected via claimUnbonded.
• When to use: classic lock → unbond → claim without prolonged release schedule (best for participants focused on shorter market-cycle liquidity).

Cliff-Based Stake (Delayed Withdrawal)

• Entry: stake with minWithdrawTimestamp (cliff date).
• Cliff normalization: contract uses

$$\mathrm{effectiveCliff} = \max\left(\mathrm{userTimestamp},\ \mathrm{now} + \mathrm{globalDelay}\right)$$

• Before cliff: exit request is limited by lock period (LockedBalance).
• After cliff: standard requestUnstake → unbonding → claim flow works.
• Important: in DAOPool / FeeDiscountPool, timestamp must be strictly in future; in ModeratorsPool, boundary value is auto-shifted by at least +1 second.
• Effect: protection from instant in-and-out behavior and more predictable active composition (supports governance stability).

Stake with Cliff + Linear Vesting

• Entry: stake with two params: minWithdrawTimestamp (cliff) and vestingPeriod.
• Where vesting is created: not in stake, but in requestUnstake when processing records with vestingPeriod > 0.
• Schedule params: for each such portion, VestingSchedule(total, claimed, cliff, start, end) is formed, where:
  • start = max(now_at_request, cliff)
  • end = start + vestingPeriod
• Coexistence with unbonding: one requestUnstake may produce both:
  • toUnbond (records without vesting)
  • toReserve (records with vesting)
• Reserve mechanics: vesting volume is tracked as vestingReserved and cannot be withdrawn a second time by another request.
• Active stake decrease: for vesting portions, debit from active stake happens at actual claim time (claimUnbonded), not at schedule creation moment.
• Effect: smooth position exit without abrupt pressure on pool composition and role/discount/governance economics, reducing operational and liquidity shocks.

How it works step by step (general life cycle)

1. Stake: participant deposits CLUE to selected pool.
2. Record: amount / minWithdrawAt / vestingPeriod are stored in stakeHistory.
3. Active phase: stake participates in rankings, discount slots, or governance weight (depending on pool role in token utility).
4. Withdrawable check: requestUnstake allows output only inside active - lockedActive - vestingReserved (for moderators, slashed part is additionally considered).
5. FIFO split: system iterates stake history in order and splits requested amount into unbond and vesting portions.
6. Claim: claimUnbonded(maxItems) processes both queues (unbond + vesting) up to maxItems per call, keeping exits deterministic similarly to state-machine constraints.

Linear vesting formula

Contracts implement piecewise logic:

$$\text{if } t \le start:\quad claimable = 0$$ $$\text{if } t \ge end:\quad claimable = total - claimed$$ $$\text{otherwise}:\quad claimable = \left\lfloor total \times \frac{t - start}{end - start} \right\rfloor - claimed$$

Where:

$$start = \max(\mathrm{now\_at\_requestUnstake},\ cliff)$$

Before start, claimable amount is 0; then release is linear, and full amount becomes available by end.

Practical contract summary: cliff defines earliest exit time, unbond enforces minimum delay for regular chunks, and vesting stretches release for selected portions. This three-layer combination makes stake exits predictable and lowers the risk of abrupt drawdowns in active pool composition.

Related Protocol References

For full context around staking mechanics, use these canonical sections across docs/protocol:

• Overview and ecosystem context: CLUE Overview, Ecosystem flywheel, User journey
• Economic integration: Economic model, Roles and incentives, Staking discounts
• Trading and execution rails: Market mechanics core, AMM pricing, Fee flow
• Quality and dispute contour: Moderation model, Appeals open, Arbitration payouts
• Governance and treasury: DAO model, Governance flow, DAO mechanics
• Token layer and distribution: Token utility, Deflation model, Distribution architecture
• Risk and legal perimeter: Risk framework, Technical risks, Regulatory principles