> 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/execution-model-and-throughput/execution-model-and-throughput.md).

# Execution Model & Throughput

#### Overview

PlayBlock is built as a purpose-engineered execution layer for games.\
Unlike general-purpose blockchains that optimize for arbitrary smart-contract flexibility, PlayBlock optimizes for high-frequency, deterministic, and bursty execution patterns common in gaming, predictions, and real-time reward systems.

At its core, PlayBlock separates *execution*, *ordering*, and *settlement* to achieve high throughput without sacrificing correctness or auditability.

### Execution Philosophy

PlayBlock follows three guiding principles:

1. **Determinism first**\
   Game outcomes, settlements, and balances must always converge to a single, verifiable state.
2. **Throughput over generality**\
   The chain is optimized for known execution patterns (bets, spins, payouts, rewards), not arbitrary DeFi experimentation.
3. **Burst-friendly by design**\
   Traffic spikes (game rounds ending, tournaments, reward drops) are expected and handled natively.

### The Execution Model

#### 1. Ordered, Single-State Execution

PlayBlock operates on a single global state shared across all products:

* Casino & arcade games
* Prediction games
* Reward systems
* Partner portals and white labels

This means:

* No fragmented liquidity
* No per-app reconciliation
* One canonical balance per user

Transactions are strictly ordered, eliminating race conditions common in multi-chain or multi-shard gaming setups.

#### 2. Executor-Driven Transactions

Instead of relying on end-user wallets to submit transactions:

* Execution is handled by authorized executor wallets
* Executors are whitelisted at the protocol level
* Users interact via signed intents, not raw transactions

This enables:

* Gasless user experience
* Predictable nonce management
* Controlled parallelism

#### 3. Parallel Intent Intake, Serialized Settlement

PlayBlock separates intent ingestion from state mutation:

| Stage         | Behavior                              |
| ------------- | ------------------------------------- |
| Intent intake | Fully parallel (API, queues, streams) |
| Validation    | Deterministic & stateless             |
| Execution     | Serialized per contract / executor    |
| Settlement    | Atomic and final                      |

This allows tens of thousands of concurrent user actions while maintaining strict correctness at settlement time.

### Throughput Characteristics

#### Practical Throughput (Not Theoretical TPS)

PlayBlock does not market raw TPS numbers in isolation.\
Instead, throughput is measured in real game actions per second:

* Bets placed
* Spins executed
* Wins settled
* Rewards distributed

In production conditions, PlayBlock comfortably sustains:

* **High hundreds to low thousands of executions per second**
* **Sub-second confirmation latency** for user-facing actions
* **Zero mempool contention** under normal operation

#### Why Throughput Stays Predictable

Traditional chains degrade under load due to:

* Public mempools
* Fee auctions
* Wallet nonce contention
* Unbounded contract execution paths

PlayBlock avoids all four by design:

* No public mempool
* Fixed execution paths
* Known contract surfaces
* Controlled executor count

The result is flat latency curves, even during peak traffic.

### Execution Under Load

#### Burst Scenarios (Examples)

* End of a prediction round (thousands of settlements)
* Reward campaign distribution
* Tournament payout finalization
* Partner portal traffic spikes

PlayBlock handles bursts by:

* Queue-backed intent buffering
* Executor round-robin distribution
* Deterministic replay safety (idempotent execution)

No user action is dropped; excess load is **absorbed**, not rejected.

### Settlement & Finality

PlayBlock uses fast finality inherited from its underlying rollup stack:

* Execution finality is near-instant for users
* Settlement finality is cryptographically anchored upstream
* All actions remain fully auditable

For game logic, execution finality matters more than L1 finality, and PlayBlock optimizes exactly for that.

***

### Why This Model Works for Games

| Requirement            | Traditional Chains | PlayBlock |
| ---------------------- | ------------------ | --------- |
| Gasless UX             | ❌                  | ✅         |
| Deterministic outcomes | ⚠️                 | ✅         |
| Burst handling         | ❌                  | ✅         |
| Predictable latency    | ❌                  | ✅         |
| Unified balance state  | ❌                  | ✅         |


---

# 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/execution-model-and-throughput/execution-model-and-throughput.md?ask=<question>&goal=<endgoal>
```

`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.