# Zones

## Introduction to IronWeave Zones

You can think of Zones as the IronWeave equivalent to zip codes; the post office uses zip codes to organize the mail activity (such as pickup and delivery), but zip codes are really just convenient areas of organization to enable mail activity service for the entire globe. And there are no real boundaries associated with zip codes, just a convenient addressing system to scale out the addressing and organization of areas in a country or region. And you can cross zip codes easily enough in real life - in other words, you don't have to worry about which zip code you're in when you travel from one city to another - you just get in your car and drive there. The same applies in IronWeave and its Zones.

To get more technical, in IronWeave a Zone is a section of the fabric where validators service IronWeave chains that also reside in that Zone (based on their Chain ID). IronWeave Zones operate at an operational level as boundaries for a collection of validators and IronWeave blockchains, where the shared-block architecture operates on a private, shared-block level. This parallel operation and horizontal scalability allows for a massive distribution of the computational load. 

This approach is comparable to DNS (domain name system) zones, where there is no technical limit to the number of zones and they can all interact as a whole, even though the work is distributed and decentralized. This design enables the horizontal partitioning of the fabric, spreading the computational load and allowing for the simultaneous and independent processing of transactions and interactions. This compartmentalization allows for greater efficiency and speed, and allows the network fabric capacity to expand by simply adding more Zones rather than centralizing power or creating performance bottlenecks.

## How Zones Operate

In DNS, a name lookup is sent to a DNS server to translate a human-readable name (like [www.ironweave.io](http://www.ironweave.io)) into a computer-readable IP address. In IronWeave, the fabric uses a Chain ID (like 10000000000042959294959...) to translate an IronWeave chain identifier into its Zone location, by reading the first few bytes of the Chain ID (initially, the first 12 bits). 

When a shared block is created, for whatever purpose, the Chain IDs of each participating IronWeave chain are provided, and thereby identify the Zone in which each participating chain resides. It's no big deal to cross Zones during a given block creation interaction (it's expected to be the case in most occasions, and is actually good for decentralization), just like it's no big deal to live in Boise and send a letter to someone in Phoenix, or no big deal to live in Seattle and call someone who lives in Dallas. The interconnectedness of Zones, of zip codes, and of the global telephone network have been designed and built for such interactions. 

A Validator (or group of Validators, depending on the interaction) from each Zone is tasked with determining the validity of the block, including ownership and permissions, and whether sufficient value exists for gas fee and (if present) value transfer. If all such required validation steps pass, the shared block is created and placed on the chains (by virtue of being placed on storage nodes in said Zones, encrypted and opaque to the validators of course) in each participant's IronWeave Zone. 

## Count of Zones

Initially, IronWeave uses 12 bits of the Chain ID to identify a specific IronWeave Zone, which provides for up to 2<sup>12</sup> = 4,096 interacting IronWeave Zones. This deterministic assignment allows the fabric to efficiently route transactions and identify the correct operational Zone for a given chain. The architecture is designed to scale to accommodate up to 16 bits for the Chain ID (more can be added later if necessary, but..), which would enable a staggering 2<sup>16</sup> = 65,536 Zones.

The clear mathematical progression provides a direct link between the number of Zones and the network's capacity, serving as the basis for IronWeave’s massive horizontal scalability and unmatched througput.

Initial Bits for IronWeave Zones: 12 bits — 4,096 IronWeave Zones

Future Bit Capacity for IronWeave Zones: 16 bits - 65,536 IronWeave Zones

## Capacity of Zones

Now getting to scalability, recall that IronWeave uses BFT consensus mechanism for its underlying consensus protocol, which is what will dictate its latency and performance mechanics.

Also recall that each IronWeave Zone implements a separate instance of the BFT protocol, enabling each IronWeave Zone to be its own validator boundary and thus, each Zone is its own performance boundary. The performance benchmark for Mysticeti reached a sustained 300,000 TPS in lab conditions, with sub-second finality. Other BFT consensus mechanisms under consideration are capable of 16,000 TPS, which can be tuned to align with IronWeave's unique implementation of block creation for each independent interaction.

With such approximate performance metrics, to illustrate the potential for scalability in IronWeave, a more conservative estimate can be used for the throughput of each IronWeave Zone.&#x20;

<figure><img src="/files/4HLYu6zT6MLHAeeLxEO9" alt=""><figcaption><p>For IronWeave performance and capacity, we'll use a more conservative estimate for TPS/IPS</p></figcaption></figure>

Assuming each Zone has the capacity to handle 16,000 transactions per second (TPS), the total network throughput for IronWeave can be calculated based on the number of active zones:

| Number of Zones | Total Transaction Throughput (TPS) |
| --------------- | ---------------------------------- |
| 4,096           | 65,536,000                         |
| 65,536          | 1,048,576,000                      |

That's a lot of activity, and a lot of Transactions / Interactions Per Second (TPS/IPS). While AI Agents and other activities will likely ramp up in the near future and can use IronWeave for whatever flexibly use they require, deploying that many IronWeave Zones right away is not necessary. Doing so would be like creating 10,000 datacenters at once for the Internet, just in case that amount of compute or storage capacity someday becomes necessary. That might happen, but not right away.&#x20;

There are other considerations as well, such as larger block sizes (which would likely affect performance), less performant validators (though a certain level of performance will be necessary for any validator to get meaningful rewards, based on performance-based voting mechanisms), or bandwidth constraints that may affect that throughput. But initially, that's still over a sixty million TPS capacity with 12 bits, and an extremely large number of interactions with the bits used for Zone identification expanded to sixteen.

{% hint style="info" %}
**Note:** During Testnet phase we will continually innovate for opportunities to improve scalability, throughput, performance and flexibility. We're currently exploring engineering approaches that may improve block creation time and time to transaction finality, also potentially increasing overall throughput capacity (TPS/IPS). Our iterative engineering process may create an improved alternative to Zones, an improved consensus mechanism, and other robust innovations that would benefit overall fabric operations. That's the goal of any Testnet: explore, iterate, innovate, improve, and move forward.&#x20;
{% endhint %}

## Initial Performance Capacity for IronWeave

So to begin with, we anticipate deploying approximately 126 Zones, which looks like the following as its initial performance profile:&#x20;

| Number of Zones at initial Mainnet release | Total Transaction Throughput (TPS) |
| ------------------------------------------ | ---------------------------------- |
| 126                                        | 2,016,000                          |

So in the early days of the IronWeave fabric release, the capacity of 126 Zones will provide for approximately 2,016,000 (two million, sixteen thousand) transactions (interactions) per second, or TPS/IPS. Even that is a lot of capacity, when you compare it to 4 TPS for Bitcoin or 20 TPS for Ethereum, or 42,000 for Visa.&#x20;


---

# 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://docs.ironweave.io/scalability/zones.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.