> For the complete documentation index, see [llms.txt](https://polarischain-1.gitbook.io/polarischain/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://polarischain-1.gitbook.io/polarischain/11.-payment-infrastructure/11.4-l1-only-throughput-scaling-strategy.md).

# 11.4 - L1-Only Throughput Scaling Strategy

Polarischain deliberately avoids off-chain payment channels, rollups, or L2 scaling layers. Off-chain constructs inherently bypass native compliance validation, undermining the protocol’s core regulatory value proposition. Instead, throughput is maximized through native execution optimization and network-level capacity expansion.

**Execution-Level Scaling (Phase 2+)**

* **Parallel Transaction Processing:** Non-conflicting transfers (touching distinct account pairs) execute concurrently across available CPU cores. Payment workloads are inherently parallelizable, enabling linear throughput gains with hardware scaling.
* **Block Pipelining:** Validators produce blocks for round `N+1` while round `N` finalizes. The Mysticeti engine’s pipelined committer sustains continuous throughput without consensus idle gaps.
* **Adaptive Block Sizing:** Block capacity dynamically scales with network load—expanding during peak demand, contracting during low utilization to minimize bandwidth waste.
* **Batch Signature Verification:** Dilithium verification costs are amortized across transaction batches, significantly reducing per-transaction CPU overhead.
* **Batch Settlement API:** High-frequency workflows (micropayments, IoT streams, merchant settlements) accumulate off-chain and submit periodic net-settlement transactions. Final settlement undergoes full native compliance validation on-chain.

**Validator & Network Scaling (Phase 5+)**

* **Tiered Validator Roles:** Staked capital determines node function. Top-staked operators (`30–100` nodes) serve as **Full Validators** (consensus + block production). Additional nodes operate as **Execution Validators** (parallel verification), **Archive Validators** (historical data + API serving), or **Light Validators** (header sync). New nodes add capacity without bloating the BFT committee.
* **Parallel Consensus Committees:** When single-committee throughput peaks, the network partitions into independent committees (`30–100` validators each). Each runs a parallel Mysticeti DAG on a disjoint account subset. Four committees of 30 yield \~4x throughput while maintaining strict BFT safety within each partition. Cross-committee transfers are coordinated via a root consensus layer.
* **Proposer-Builder Separation:** Permissionless builders collect, pre-validate, and bundle transactions into candidate payloads. Committee proposers select optimal bundles and wrap them in signed DAG blocks. This decouples transaction intake scaling from fixed-size consensus participation.
* **Geographic Proximity Routing:** Clients automatically route submissions to the nearest validator cluster, minimizing submission latency while finality remains bound by deterministic consensus rounds.


---

# 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://polarischain-1.gitbook.io/polarischain/11.-payment-infrastructure/11.4-l1-only-throughput-scaling-strategy.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.