Community rewards
Community rewards are intended to recognize useful participation in online.casino, such as accepted corrections or evidence-backed experiences. Gamification is confirmed future direction, with implementation deferred. The engine, reward mechanics and practical value of points remain open.
The July 2026 discovery contains a detailed candidate design. Its names, amounts, levels and timings are hypotheses for discussion, not an approved reward economy.
Keep four measures separate
| Measure | What it concerns |
|---|---|
| OC Score | The Casino's assessment |
| Community Points | A person's non-monetary participation rewards |
| Contributor reputation | The person's contribution history and progression |
| Period contribution score | Contribution performance within a competition period |
Commercial relationships do not enter trust or organic ranking. Reward balance does not automatically increase contributor trust. Gambling volume is not a reward source. An external Casino's VIP tier or programme points are separate from every measure above.
An example of the intended loop
A contributor submits a correction to a withdrawal limit. The product checks it, and an authorized decision accepts the supported correction. Only then would a selected reward rule assess whether it qualifies. The contributor could see the reason for a pending, accepted or rejected action and any resulting reward.
Submitting the same action twice must not double its reward. If a later review reverses the accepted action, the reward and dependent progress need an explained correction in history. This example does not select a points amount or approve data-check contributions for the current release.
Candidate ways to recognize contributions
The historical design explored several connected features:
- Points for approved actions, with separate caps for base rewards and campaign bonuses. Possible uses included profile status, cosmetics, streak protection and selected community perks. Giveaways and other uses need their own policy.
- Contributor tiers earned from accepted or verified contributions. The draft proposed five levels with provisional names and thresholds. A tier would not bypass moderation, purchase trust or automatically multiply points.
- Achievements for milestones such as a first contribution, verified review, accepted data checks, a material terms correction or a withdrawal report. Progress and rewards would need reversal rules when a contribution is revoked.
- A small daily check-in streak, with milestones, history and limited shields. A daily contribution streak was questioned because moderation can finish after the day ends. Weekly challenges offer a different timing tradeoff.
- Separate all-time reputation and weekly contribution leaderboards. A weekly competition would need eligibility, minimum participation, tie rules, caps, privacy choices and prize policy rather than rank the oldest points balances.
- Onboarding, data-check and terms-review challenges, plus themed campaigns. Each needs a goal, period, attribution rule, reward and claim deadline.
- Conditional bonuses and later personal research assignments, such as checking stale payment facts. Repeated and stacked rewards need explicit limits.
These are a menu to select from. The historical counts, thresholds and schedules are not current release commitments.
Claims and the reward history
The candidate design distinguishes automatic awards from rewards a user actively claims. A reward inbox would explain the source, contents, when a claim opens, when it expires and whether it was claimed, expired or reversed. A claim must not be fulfilled twice. Expired rewards remain in history rather than disappear.
Staff controls in the proposal include pause, resume or cancellation of campaigns, limits and budgets, reasoned grants and reversals, and visibility into issued and reversed rewards. Monitoring would help distinguish useful contribution from reward farming. The exact controls and moderation policies remain unselected.
Limits on incentives
Accepted direction excludes gambling volume as a reward source. The historical proposal also rejects rewarding deposits, wagering, wins, losses or spins, and uses Casino registration only as a verification signal. It treats points as non-cash and makes no token-conversion promise.
The historical proposal gives age, market and self-exclusion restrictions precedence over reward eligibility. A qualifying contribution would not override those restrictions. Which rules apply, and when they prevent participation or a claim, still need an explicit decision; no thresholds or policy are agreed here.
Privacy, period attribution after delayed moderation and permitted perks also need decisions. A challenge should not require a person to gamble or encourage them to recover losses. Point values and multipliers cannot be chosen responsibly without knowing the useful actions and limits they support.
Choosing an engine
One proposal uses an external managed service. If selected, that engine owns reward, progression and claim state; the product displays confirmed results and keeps delivery history rather than inventing a second balance. A delayed reply remains pending or uncertain, not a successful claim. Core browsing and contribution work must remain usable during a reward-service outage.
Engine selection is still open. Service commitments, data handling, export and exit arrangements would need separate agreement for that option. Detailed commercial terms remain private. The gamification review brief asks for the product choices first, without starting deferred implementation.