> 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/cross-platform-orchestration/cross-platform-orchestration.md). # Cross-Platform Orchestration PlayBlock is not just a chain. It’s the coordination layer that makes multiple Playnance products behave like one platform. Users interact with different surfaces (PlayW3, PlayQuack, Predictions, partner portals), but behind the scenes, we orchestrate the same core actions: * identity + wallet ownership * balances and settlement (gasless) * rewards and incentives (GCOIN) * game lifecycle automation (open → run → finalize) * real-time events and notifications * provider integrations (casino aggregators, sports/odds feeds, etc.) The outcome: a user can move between products without “starting over”, while the system stays deterministic, auditable, and scalable. ### Why Orchestration Exists Gaming platforms fail when each product becomes its own island: * duplicated balances and inconsistent “source of truth” * separate reward logic per app * different risk rules per game type * impossible analytics * manual operations Cross-platform orchestration solves this by enforcing a single execution pattern: Every user action becomes a verified intent → executed by controllers/executors → settled on PlayBlock → emitted as events → reflected across all apps. ### Core Orchestration Principles #### 1) One state for all platforms Regardless of UI entry point, all value flows converge to the same core settlement model: * balances and payouts settle through PlayBlock contracts * rewards are sent in GCOIN directly to the user wallet * users can verify results on PlayBlock explorer #### 2) Deterministic where it matters Game outcomes, payouts, and user balances must be consistent and replayable: * game controllers execute the exact lifecycle steps * executors are whitelisted and controlled * retries are idempotent (no double credits) #### 3) Product-specific UX, shared execution Casino, arcade, and predictions can feel different — but execution stays uniform: * same wallet identity layer * same rewards mechanism * same logging, monitoring, and event streaming model ### The Orchestration Layers #### User Identity & Session Users authenticate through wallets (including social wallets where relevant).\ Orchestration ties every activity back to a **single wallet address** as the durable identity. This enables: * unified reward eligibility * unified limits / risk controls * unified analytics attribution #### Controllers Controllers are services responsible for turning “intent” into validated execution: Examples: * **Games Controller**: starts/finalizes prediction games, triggers payouts, handles cancellations/refunds * **Reward Orchestrator**: validates reward eligibility (registration + activity), triggers reward payout * **Session Controllers**: manage deposit/play sessions with external providers The controllers apply policy, timing rules, and idempotency. #### Executors Executors are the operational wallets/services that actually submit on-chain transactions. Why executors exist: * keep user experience gasless * centralize nonce management, fee strategy, and retries * isolate execution from web/API request latency Executors are: * whitelisted on the relevant contracts * rotated / sharded (round-robin, partitioning, queues) * monitored like production critical infra #### Messaging and Coordination Cross-platform orchestration is event-driven. A typical flow: 1. API receives request (bet, spin, finalize, reward claim) 2. Controller validates policy + idempotency 3. Job is created (queue / scheduler) 4. Executor submits transaction 5. On-chain event is emitted 6. Event stream updates: * UI state (real-time) * logs (MySQL) * analytics (ClickHouse) * notifications (channels) This is how multiple products can stay synchronized without coupling everything together. ### Example Orchestrated Flows #### A) New User Reward Flow (cross-platform) A user can register in one product and claim rewards in another, because orchestration is wallet-based. Typical orchestration: * user connects wallet * user links Telegram/Twitter (eligibility layer) * user spins the spinner (feature trigger) * reward service validates: * has this wallet already claimed? * are required links present? * is the request signed + valid? * executor sends GCOIN reward on-chain * user sees tx in explorer / wallet * events propagate to all UIs and analytics #### B) Activity-Based Rewards (cross-platform) User can earn rewards through activity across multiple features: * casino play * arcade play * predictions bets * streaks / milestones / campaigns Orchestration ensures: * “activity” events are normalized (one schema) * campaign logic runs consistently * payout is always a GCOIN transfer to the user wallet #### C) Game Lifecycle Orchestration (Predictions) Predictions games are a lifecycle, not a single action: * create game * open for bets * close betting * finalize outcome * payout winners * cleanup + indexing Orchestration is responsible for: * timing windows and safety buffers * handling postponed/cancelled games * payout batching * ensuring the on-chain state and the DB state stay aligned ### Operational Guarantees Cross-platform orchestration is designed around a few hard guarantees: * **Idempotency:** retries never cause duplicate payouts * **Consistency:** UI and databases reflect on-chain truth * **Backpressure:** queues protect the chain from burst load * **Observability:** every action is traceable from request → txHash → event → UI update * **Isolation:** casino issues don’t break predictions; orchestration decouples via events/queues --- # 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/cross-platform-orchestration/cross-platform-orchestration.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.