Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

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

Last updated

Was this helpful?