> For the complete documentation index, see [llms.txt](https://docs.espressosys.com/network/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.espressosys.com/network/developer/rollup-developers/nitro.md).

# Nitro / Orbit

This guide is for teams integrating an **existing Arbitrum Nitro / Orbit chain** with Espresso. Espresso provides settlement and finality on the chain's blocks. L1 batch posting (where applicable) is a property of the chain framework, not Espresso settlement itself.

Espresso has developed an integration with the Arbitrum Nitro tech stack that allows [Arbitrum Orbit](https://arbitrum.io/orbit) chains to integrate with Espresso. The integration gives each Orbit chain decentralized Proof of Stake settlement and finality from Espresso: the chain continues to run its own Nitro sequencer and execution stack, and Espresso finalizes the blocks it produces. Roadmap items include enhanced cross-chain interoperability and support for Espresso DA.

The first production integration launched on January 29, 2025 at block 1486407. Orbit chains can integrate by running Espresso's Docker image directly or through a RaaS provider.

{% hint style="info" %}
If you just want to see the steps for getting up and running, you can [skip to the guide](/network/developer/rollup-developers/nitro/migrate-orbit-chains-to-espresso.md).
{% endhint %}

## Integration overview

This integration makes minimal changes to the Arbitrum Nitro stack, and ensures that each batch processed by the rollup is consistent with HotShot-finalized blocks within its namespace.

To ensure that the batch has been finalized by HotShot, the following checks are performed:

1. **Namespace validation:** Ensure that the set of transactions in a rollup's batch corresponds to the correct namespace. Namespacing allows multiple chains to share Espresso's settlement layer simultaneously by associating each chain's transactions with a unique namespace within HotShot blocks.
2. **Espresso block Merkle proof check:** Confirm that the rollup's batch maps to a valid HotShot block. Specifically, verify that the HotShot block associated with a rollup batch is a valid leaf in the Merkle tree maintained by Espresso's onchain state contract.
3. The sequencer calls `WriteSequencerMsg` on the transaction streamer.
4. The batcher fetches the message from the transaction streamer and submits the transaction to HotShot via the transaction streamer.
5. The batcher then calls the query API to check if the transaction has been finalized by HotShot.
6. Once the transaction is finalized, the batcher performs batch consistency checks.
7. The batcher signs the transaction calldata that would be sent to the `Sequencer Inbox` contract.
8. The `Sequencer Inbox` contract is modified to verify the batcher’s signature.

This approach involves running a Nitro node with only the batcher enabled, operating in a TEE environment (such as Intel SGX). The batcher will sign the transaction calldata. In case the TEE is broken, the batch poster can't impact the safety of the Orbit chain. It could, however, temporarily halt the chain's progress, thereby breaking liveness. Bridges relying on Espresso confirmations for faster settlement need to trust the TEE as well in this integration. In a future update, the dependency on TEEs will be removed entirely.


---

# 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://docs.espressosys.com/network/developer/rollup-developers/nitro.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.