# Performance

INTMAX is designed to asymptotically minimize on-chain data requirements while supporting high-throughput off-chain activity. Its performance characteristics stem directly from its stateless, proof-based design, where **only aggregate commitments** are stored on-chain, and all computation and transaction details remain off-chain and user-controlled.

***

### On-Chain Data Efficiency

Each transaction batch requires approximately:

* **5 bytes per sender**, comprising:
  * 32 bytes: Merkle root commitment
  * 48 bytes: Aggregated BLS signature
  * \~96 bytes × *n*: List of BLS public keys (1 per sender)

Since transaction content is excluded from the chain, **block size scales with the number of participating senders**, not the number of transactions or recipients. A single sender can batch thousands of payments with no additional on-chain cost.

**Key asymmetry**:

> On-chain size ∝ O(number of *senders*)\
> Off-chain cost ∝ O(number of *transactions*)

***

### Current Throughput (Ethereum Today)

Assuming:

* 0.375 MB Ethereum block size (post-Calldata gas cost reduction)
* Average sender overhead ≈ 5 bytes

We achieve a theoretical throughput of:

* **\~7,500 senders per second**
* **Unlimited recipients per sender** (handled off-chain)

This already exceeds the throughput of existing rollups under realistic constraints, especially for payment use cases.

***

### Future Scaling (EIP-4844 and Beyond)

With EIP-4844 (Proto-Danksharding), Ethereum aims to increase data bandwidth to:

* **\~16 MB per block** (via blob space)

Under these conditions, INTMAX could support:

* **320,000+ senders per second**
* Again, with no increase in on-chain cost per recipient or transaction volume

This positions INTMAX as a **future-proof scalability layer**, where increasing L1 bandwidth immediately benefits L2 throughput—without redesign.

***

### Comparative Efficiency

| Metric                        | INTMAX                               | Traditional ZK-Rollups       |
| ----------------------------- | ------------------------------------ | ---------------------------- |
| On-chain data per transaction | \~5 bytes                            | \~200–300 bytes              |
| Transaction batching model    | Sender-centric, unlimited recipients | Flat per-transaction cost    |
| Sequencer bottleneck          | None (permissionless)                | Centralized or single leader |
| Withdraw proof size           | Constant (ZK-SNARK)                  | Similar                      |


---

# Agent Instructions: 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:

```
GET https://intmax-general.gitbook.io/intmax-developers-hub/intmax-network/performance.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.