> For the complete documentation index, see [llms.txt](https://axon-finance.gitbook.io/axon-finance-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://axon-finance.gitbook.io/axon-finance-docs/yellowpaper-g-networking-and-performance/g2-performance.md).

# G.2 Performance Model & Design Targets

Throughput/latency analysis and target derivation

> **Design status**: performance metrics are `Design Targets`, **not implemented measured values**; final values will be set by testnet benchmarks. This section gives the derivation logic behind the targets, not a promise.

## G.2.1 Three Performance Dimensions

A payment-grade SLA (whitepaper [3.3](/axon-finance-docs/part-iii-technical-architecture/part3-architecture/3-3-consensus-finality.md)) is characterized by three quantities:

$$\text{throughput } \Theta\ (\mathrm{TPS}), \qquad \text{finality latency } T\_{\text{final}}\ (\mathrm{s}), \qquad \text{per-transaction fee } \text{fee}\ ($)$$

Design Targets: $\Theta > 10{,}000$, $T\_{\text{final}} < 1\mathrm{s}$, $\text{fee} < $0.001$. Below we give the derivation and bottleneck analysis for each.

## G.2.2 Finality Latency

From [B.1.7](/axon-finance-docs/yellowpaper-b-consensus-and-ledger/b1-consensus.md), finality latency is the number of consecutive QCs required to commit, $k$, times the per-round overhead:

$$T\_{\text{final}} \approx k \cdot (\delta\_{\text{net}} + \delta\_{\text{agg}} + \delta\_{\text{exec}})$$

With pipeline depth $k = 3$, a block-interval target $\Delta\_{\text{block}} \in \[250, 500],\mathrm{ms}$, and with $\delta\_{\text{agg}}$ (BLS aggregate verification) and $\delta\_{\text{exec}}$ (execution) absorbed by the pipeline within the block interval, then

$$T\_{\text{final}} \approx k \cdot \Delta\_{\text{block}} \in \[0.75, 1.5],\mathrm{s} \ \Rightarrow\ \text{sub-second target}$$

Optimization directions: reduce $k$ (a more aggressive commit rule), shorten $\Delta\_{\text{block}}$ (faster aggregation / a closer validator topology). BLS aggregation makes QC verification independent of $n$ ([A.2.3](/axon-finance-docs/yellowpaper-a-system-model-and-cryptography/a2-cryptography.md)), the key to latency not degrading as validators grow.

## G.2.3 Throughput

Throughput per unit time = transactions per block / block interval:

$$\Theta = \frac{N\_{\text{block}}}{\Delta\_{\text{block}}}, \qquad N\_{\text{block}} = \min!\left(\frac{B\_{\text{net}}}{\bar{s}*{\text{tx}}},\ \frac{C*{\text{exec}}\cdot\Delta\_{\text{block}}}{\bar{g}\_{\text{tx}}}\right)$$

Transactions per block $N\_{\text{block}}$ is constrained by two upper bounds (take the smaller):

* **Network bound**: bandwidth $B\_{\text{net}}$ / average transaction size $\bar{s}\_{\text{tx}}$ — relaxed by the compact blocks / erasure coding of [G.1.3](/axon-finance-docs/yellowpaper-g-networking-and-performance/g1-networking.md).
* **Execution bound**: execution throughput $C\_{\text{exec}}$ (gas/s) × block interval / average transaction gas $\bar{g}\_{\text{tx}}$.

To reach $\Theta > 10{,}000,\mathrm{TPS}$, both bounds must be ample. Three levers:

1. **Parallel execution**: payment transactions are mostly disjoint account pairs (no state conflict), so they can be optimistically executed in parallel + conflict-detection retry — raising $C\_{\text{exec}}$ to nearly the core-count multiple.
2. **Short block interval**: the smaller $\Delta\_{\text{block}}$, the more throughput and latency improve together (bounded by the network lower bound).
3. **Lean execution**: stablecoin settlement is a chain-layer primitive ([D.1](/axon-finance-docs/yellowpaper-d-settlement-oracle-compliance/d1-settlement.md)), so the payment path is short and $\bar{g}\_{\text{tx}}$ is small, fitting more transactions under the same bandwidth/compute.

## G.2.4 Fee

From [F.1.2](/axon-finance-docs/yellowpaper-f-protocol-economics-and-security/f1-gas-fees.md), a payment transaction fee $= \bar{g}*{\text{tx}} \times price*{\text{fixed}}$. Because the settlement primitive makes $\bar{g}\_{\text{tx}}$ low and stable, and steady state uses a fixed rate (no auction premium), the fee can be compressed to the **sub-cent range** and made **predictable** — the premise for M2M micropayments ([C.2.7](/axon-finance-docs/yellowpaper-c-account-abstraction-and-ai-authorization/c2-session-keys.md)) to be economically viable. **Predictability itself is the feature**, not merely a low number.

## G.2.5 Bottleneck & Trade-off Summary

| Dimension        | Main bottleneck                            | Main levers                                           |
| ---------------- | ------------------------------------------ | ----------------------------------------------------- |
| Finality latency | $k \cdot \Delta\_{\text{block}}$           | BLS aggregation, validator topology, commit rule      |
| Throughput       | min(network bound, execution bound)        | parallel execution, compact blocks, lean payment path |
| Fee              | $\bar{g}\_{\text{tx}}$, fee-rate mechanism | primitized settlement, fixed rate                     |

## G.2.6 Honest Disclosure

> The figures in this section are all **`Design Targets`**, representing the target range engineering aims to achieve and its derivation logic, **not currently implemented measured values**. Actual performance is affected by many factors — hardware, network topology, load characteristics, parallelization effectiveness — and final measured values will be published after **testnet benchmarking**. We do not state Design Targets as if they were already-achieved results. See the parameter summary in [Appendix II](/axon-finance-docs/yellowpaper-appendices/appendix-parameters.md).

***

*Next:* [*Appendix I · Notation*](/axon-finance-docs/yellowpaper-appendices/appendix-notation.md)


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://axon-finance.gitbook.io/axon-finance-docs/yellowpaper-g-networking-and-performance/g2-performance.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.