> 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/performance-benchmarks-1/performance-benchmark.md).

# Performance Benchmark

### Why performance benchmarks matter

In gaming and prediction systems, performance is not an abstract metric.\
It directly impacts:

* Player experience (latency, responsiveness)
* Fairness and determinism (state updates, settlement order)
* Operational cost (fees, batching, retries)
* System scalability under real load

For this reason, PlayBlock benchmarks itself not only against other Layer-2 and Layer-3 chains, but against the actual requirements of high-frequency, real-money gaming settlement.

Traditional benchmarks that focus only on peak TPS or theoretical throughput are insufficient. What matters is sustained performance under load, with deterministic execution and predictable costs.

### What we measure

PlayBlock evaluates performance using metrics that reflect real production behavior:

#### Core metrics

* **Block time**\
  How frequently blocks are produced.
* **Transaction inclusion latency**\
  Time from submission to block inclusion (p50 / p95).
* **Sustained throughput**\
  Transactions per second under continuous load, not short bursts.
* **Cost per action**\
  Measured for:
  * Native transfers
  * ERC-20 transfers
  * Game actions (contract calls with state changes + events)
* **Finality model**
  * Local finality (on PlayBlock itself)
  * Upstream settlement finality (parent chain / Ethereum)
* **Data availability (DA) model**\
  Ethereum DA vs AnyTrust / DAC-based DA and its impact on cost and latency.

### Benchmarking philosophy

PlayBlock does not attempt to “win” benchmarks by tuning for synthetic workloads.\
Instead, benchmarks are designed to reflect real Playnance production flows, including:

* Gasless user transactions
* High-frequency game actions
* Deterministic ordering requirements
* Continuous execution over long periods

This makes comparisons more honest and directly relevant to developers and operators.

### High-level comparison overview

| Network Type                      | Typical Block Time            | Throughput Characteristics                               | Finality Model                             | Gaming Suitability                              |
| --------------------------------- | ----------------------------- | -------------------------------------------------------- | ------------------------------------------ | ----------------------------------------------- |
| **PlayBlock (L3, AnyTrust RAAS)** | **Sub-second (configurable)** | **Optimized for sustained, high-frequency game actions** | **Fast local finality, Ethereum-anchored** | **Purpose-built for gaming settlement**         |
| General-purpose L2s               | \~2–4 seconds                 | High, but shared across many applications                | Rollup-based L1 finality                   | Good for general DeFi, less optimized for games |
| ZK-based L2s                      | \~2–4 seconds                 | High theoretical throughput, proof-bound                 | Proof-dependent finality                   | Strong security, higher latency for settlement  |
| App-specific L3s                  | Sub-second to 1s              | Configurable per application                             | Parent-chain dependent                     | Good when tightly scoped                        |

> **Key takeaway:**\
> PlayBlock optimizes for **predictable latency and deterministic execution**, not just maximum TPS.

### Why PlayBlock performs differently

#### 1. Purpose-built execution model

PlayBlock is not a shared execution environment for unrelated applications.\
It is designed specifically for:

* Games
* Predictions
* Casino-style interactions
* Settlement-heavy workflows

This allows aggressive tuning of:

* Block intervals
* Gas limits
* Sequencer behavior
* State access patterns

#### 2. Layer-3 architecture on Arbitrum + AnyTrust

PlayBlock operates as a Layer-3 application chain using:

* Arbitrum Orbit stack
* AnyTrust data availability

This enables:

* Significantly lower data costs
* Faster block production
* Higher sustained throughput for small, frequent transactions

The tradeoff is explicit and intentional:\
PlayBlock prioritizes performance and cost efficiency while maintaining Ethereum-anchored security guarantees.

#### 3. Gasless execution for users

End users do not pay gas directly.

This removes several performance bottlenecks present on public L2s:

* No user-side gas estimation delays
* No mempool competition
* No priority fee bidding wars

From a benchmark perspective, this results in:

* More stable inclusion times
* Predictable cost per action
* Cleaner latency distributions

#### 4. Deterministic settlement first

In gaming, determinism beats raw speed.

PlayBlock enforces:

* Strict ordering of actions
* Deterministic settlement logic
* Clear separation between:
  * User-visible confirmation
  * Upstream settlement finality

This makes benchmarks more meaningful for real money systems.

### Benchmark methodology (recommended)

To ensure fair comparison, PlayBlock benchmarks follow a consistent structure:

#### Workloads tested

1. Native token transfer
2. ERC-20 transfer
3. Game action (state update + event emission)

#### Load profile

* Gradual ramp-up (e.g. 50 → 500 → 2,000 tx/s)
* Sustained load per level (10–20 minutes)
* Measurement of:
  * p50 / p95 latency
  * Error / revert rate
  * Effective throughput
  * Cost per transaction

#### Reporting principles

* Separate local confirmation from L1 finality
* Report sustained numbers, not peaks
* Publish configuration parameters alongside results

### Interpreting benchmark results correctly

When comparing PlayBlock to other chains, it is critical to understand:

* A 2s block time on a general L2 does not imply worse UX if pre-confirmation is used
* A sub-second block time does not guarantee deterministic settlement
* “Finality” can mean different things depending on the rollup or proof system

PlayBlock benchmarks are designed to answer one question:

> **Can this system reliably settle high-frequency, real-money game actions at scale?**

### Summary

PlayBlock’s performance profile is the result of deliberate architectural choices:

* Layer-3 app-chain design
* AnyTrust data availability
* Gasless execution
* Deterministic settlement focus

Rather than competing on marketing TPS numbers, PlayBlock optimizes for what actually matters in production gaming systems:\
low latency, predictable costs, and reliable settlement under sustained load.


---

# 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/performance-benchmarks-1/performance-benchmark.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.