Community Voting, Influence Score, and reward sync

Overview#

This article describes the current canonical pipeline between Community Voting result calculation, Influence Score updates, and Pawn-Coin reward synchronization.

The key runtime rule is that reward issuance must follow the latest canonical business result and the latest canonical Influence Score, not an earlier snapshot.

Why this pipeline matters#

If prediction correctness, Influence Score, and reward credits drift apart, the platform shows a contradictory economy.

• the user may see a reward that no longer matches the final prediction result
• the multiplier shown in UI may not match the credited amount
• rollback scenarios become opaque if only one layer updates

Main runtime nodes#

• private/community_pool/prediction_result_calc.php determines the business result candidate and resets stale state when needed
• private/community_pool/score_calc.php recalculates and writes the canonical current_influence_score
• private/community_pool/CommunityPool.php handles user submission flow and first-forecast daily bonus entry points
• private/pawn_coin/PawnCoinService.php performs reward credit, rollback, multiplier application, and wallet history linkage
• auth/index.php and resources/react/init.jsx expose the result through wallet and history UI

Canonical order of operations#

1. calculate or refresh the prediction result
2. recompute the affected user's Influence Score
3. call the reward synchronization layer using the updated score
4. write wallet and ledger trace
5. show the same explanation in UI history

This order is intentionally different from the older pattern where a reward could be credited directly from the prediction-result step before the latest Influence Score was written.

Influence Score rule#

Influence Score changes reward size, but it does not decide whether a prediction is factually correct.

• the business result decides eligibility
• the current canonical score decides the multiplier
• the reward service writes base amount, multiplier, and scaled amount into reward metadata

Rollback and adjustment safety#

The reward layer must be able to do more than one-time credit.

• if a previously correct prediction becomes excluded or otherwise invalid, the related reward must be revertible
• if Influence Score changed before the final sync, the credited amount must use the updated multiplier
• UI history must explain both positive reward credits and negative adjustment or rollback entries

Daily bonus and quality gates#

The first forecast of the day bonus is still part of the economy, but it no longer means every short action is reward-eligible.

• minimum normalized comment length is enforced for daily Community Voting bonus eligibility
• reward issuance is isolated from the primary social write path so a reward failure does not corrupt the comment transaction
• central reward rate limits in the Pawn-Coin layer still apply on top of source-module checks

Common drift risks#

• the backend credits reward before the latest score is written
• UI shows multiplier details that do not match the ledger amount
• daily bonus quality gates diverge between source modules and shared economy config
• direct wallet history access skips wallet bootstrap and hides the full finance trace

Minimum regression checklist#

1. a correct prediction credits exactly one reward event
2. the first qualifying forecast of the day credits at most once per period and only after quality gates pass
3. multiplier shown in wallet or reward summary matches the actual credited amount
4. reverting or excluding a previously rewarded prediction produces a consistent rollback or adjustment trace
5. opening wallet history directly still shows starter grant and recent finance context

Related articles#

• Mpawns Coin: architecture of the player economy
• Mpawns Coin: reward engine and anti-abuse layers
• Prediction Markets, Pawn-Coin settlement, ledger, and schema guards