> For the complete documentation index, see [llms.txt](https://docs.playnance.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.playnance.com/rewards-pipeline/rewards-pipeline.md). # Rewards Pipeline ## PlayBlock Rewards Flow PlayBlock rewards are designed as a deterministic, on-chain–settled incentive system that aligns user activity, platform growth, and token economics. Rewards are not cosmetic, not delayed, and not centrally editable.\ Every reward originates from verifiable activity, is calculated off-chain, and is settled on-chain. ### Core Principles of the Rewards System PlayBlock rewards are built around four core principles: 1. Activity-Driven – rewards are earned only through real actions 2. Deterministic – same input always produces the same reward 3. On-Chain Finality – settlement happens on PlayBlock 4. Composable – rewards can be reused across products This ensures rewards scale safely across casino, arcade, predictions, and future products. ### What Generates Rewards Rewards are triggered by validated user actions, including: * Bets placed * Games played * Volume contributed * Liquidity participation * Campaign participation * Partner or affiliate activity * System-level incentives (seasonal, boosts, quests) Each action produces a reward-eligible event. ### Step-by-Step Rewards Flow #### 1. User Action A user performs an action inside any PlayBlock-powered product: * Casino * Arcade * Prediction games * Future integrations Examples: * Place a bet * Complete a game round * Participate in a promotion At this stage, no rewards are granted yet. #### 2. Action Validation & Settlement The action is: * Validated by backend services * Executed on-chain (bets, wins, transfers) * Finalized by PlayBlock smart contracts Only successfully finalized actions are eligible for rewards. If settlement fails → no reward. #### 3. Reward Eligibility Detection Once the settlement is confirmed: * The system detects eligible events * Context is attached: * User * Game * Amount * Outcome * Timestamp * Campaign rules (if any) This creates a reward candidate, not a payout. #### 4. Reward Calculation Engine Rewards are calculated off-chain using deterministic rules: * Fixed ratios * Tier multipliers * Volume thresholds * Time-based boosts * Campaign modifiers Key characteristics: * No randomness * No manual overrides * Fully reproducible calculations The result is a reward instruction. #### 5. Reward Queuing & Scheduling Reward instructions are: * Queued * Rate-limited * Batched when needed * Ordered for execution This prevents: * Spikes * Double rewards * Chain congestion Rewards can be: * Instant * Delayed * Accumulated (depending on campaign rules) #### 6. On-Chain Reward Distribution Final reward execution happens on PlayBlock: * GCoin is transferred * Treasury balances are updated * Events are emitted on-chain Once executed: * Rewards are final * Publicly verifiable * Immutable #### 7. Post-Settlement Visibility After distribution: * User balances update immediately * Rewards appear in UI * Events are indexed for analytics * Monitoring systems verify execution Any discrepancy is detectable via: * On-chain events * Internal logs * Analytics pipelines ### GCoin’s Role in the Rewards System GCoin is the native incentive asset of PlayBlock. It is used to: * Reward activity * Align user incentives with platform growth * Create long-term engagement loops * Power cross-product rewards GCoin rewards are: * Gasless for users * Settled on-chain * Transferable * Reusable across products ### Anti-Abuse & Safety Mechanisms The rewards flow includes built-in protection: * Reward eligibility only after settlement * Idempotent reward execution * Per-action uniqueness * Rate limiting * Treasury caps * Campaign-scoped rules This prevents: * Double rewards * Replay attacks * Reward farming * Manual manipulation --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.playnance.com/rewards-pipeline/rewards-pipeline.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.