> For the complete documentation index, see [llms.txt](https://spire-docs.gitbook.io/spire/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://spire-docs.gitbook.io/spire/pylon/architecture-overview.md).

# Architecture Overview

The following details Pylon specific concepts. For details regarding regular chain architecture and components see [here](https://docs.optimism.io/operators/chain-operators/architecture).

### Sync Zones

Spire enables synchronous composability across chains that sit under the same parent chain. This is done through coordinated sequencing. Our current design leverages a single large node that acts as the coordinating sequencer across all appchains in a sync zone.

* A sync zone dictates which chains can interact as if they were all on the same chain.
* Which chains are within your sync zone is determined by which other chains are running under the same [coordinator](#coordinator) (ultimately limited by the settlement chain they operate within).

<figure><img src="/files/PkEDCQwOu52mQd0IMClj" alt="" width="563"><figcaption></figcaption></figure>

### Coordinator

A Pylon node that fulfills the role of an RPC node and the coordinating sequencer across appchains and the settlement layer to create a [Sync Zone](#sync-zones).

### Appchain Nodes

These are nodes that can be used for following the chain, indexing the chain, etc. but they are read only. Writes must pass through the Coordinator or through the Settlement chain in order to be properly simulated, sequenced, and/or executed.

### Port Contracts

Port contracts are smart contracts that serve as the interface for cross-chain communication. They receive and store the results of cross-chain calls, allowing transactions to access data from other chains as if they were executing on the same chain. The transactions that populate these contracts are called [Priming Transactions](#priming-transactions). This enables synchronous composability between chains within a [sync zone](#sync-zones).

The name "Port Contract" reflects their role as the landing point for data "shipped" across chains. They work in conjunction with [forwarding proxy contracts](#forwarding-proxy-contracts), which provide a developer-friendly abstraction layer. This abstraction allows developers to interact with contracts on other chains using the same interface they would use for local contracts, making cross-chain development feel like single-chain development. See [here](/spire/pylon/features.md#synchronously-composable-transactions) for details on how this works.

### Priming Transactions

Cross-chain calls are dynamically detected by Pylon and their results are injected into the Port Contract to pre-populate the required data to fulfill the call. The system transaction used to pre-populate the required data is called a Priming Transaction.

### Forwarding Proxy Contracts

A forwarding proxy contract is really just a regular proxy contract that you can call into as if it were your target contract on your target chain. It forwards all the necessary data to the [Port Contract](#port-contracts) to retrieve the results of your cross-chain call.

### Example Cross-Chain Transaction

<figure><img src="/files/CniJTOJoa5xu0kNp7UDM" alt=""><figcaption></figcaption></figure>


---

# 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://spire-docs.gitbook.io/spire/pylon/architecture-overview.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.