# How Espresso Fits

Espresso is a decentralized settlement layer. Chains and applications integrate with Espresso to get decentralized Proof of Stake settlement and finality on the blocks they produce, optional data availability, and cross-chain readability through [light client contracts](/network/developer/the-espresso-network/light-client.md) on Ethereum and Arbitrum One.

Espresso plays the same role in every integration. What differs is the deployment shape.

## Pattern 1: A dedicated execution environment built around Espresso

A team builds an application or chain that runs its own execution environment (defining its own rules for fees, ordering, compliance, and asset support) and settles through Espresso. Espresso's decentralized Proof of Stake finality on the chain's blocks is the chain's settlement guarantee; counterparties on Ethereum or Arbitrum One verify finalized state from the light client contracts.

This pattern fits institutions and application teams that need:

* Control over their operating environment (fees, ordering policy, compliance, asset support).
* Predictable performance independent of general-purpose chain congestion.
* Decentralized settlement and finality without operating their own validator set.
* Connectivity to broader onchain markets through Espresso's interoperability.

See [Configurable Execution Environments](/network/learn/rollup-architecture.md) for more detail.

## Pattern 2: An existing chain that adds Espresso for fast decentralized finality

A chain that already has its own execution environment (for example, a rollup based on Arbitrum Nitro or the OP Stack) integrates Espresso. The chain continues to run its own execution stack; Espresso finalizes the chain's blocks under decentralized Proof of Stake consensus. Some chains in this pattern also continue to anchor batches to an L1 such as Ethereum; others do not. In both cases, Espresso provides the same settlement guarantee on the chain's finalized blocks.

This pattern fits teams that:

* Want Espresso's fast decentralized finality without changing their core execution stack.
* Want their finalized state to be verifiable trustlessly from other onchain systems.
* Want their chain's blocks finalized by a decentralized validator set rather than a single sequencer.

Many of Espresso's current integrations sit in this pattern; see the chain integration guides for details.

## What both patterns share

Regardless of deployment shape, integrated systems share:

* **Decentralized Proof of Stake finality.** Settlement guarantees come from Espresso's validator set, not from any single operator.
* **Secure interoperability.** Finalized state is readable trust-minimally from other chains via light client commitments.
* **Fast settlement.** Sub-three-second finality on Mainnet 1 today, with the roadmap targeting sub-second.
* **Optional data availability.** Espresso can provide DA for the data its chains finalize, complementing or replacing separate DA layers (Celestia, EigenDA, Ethereum, Avail) depending on the deployment.

## What Espresso does not do

* Espresso does not execute application transactions. Execution always happens in the application's own environment.
* Espresso does not act as a shared sequencer and does not control each application's transaction ordering rules. Each integrated chain runs its own sequencer or builders; Espresso provides decentralized settlement and finality for the blocks they propose.
* Espresso does not require any chain to settle to Ethereum. Some integrations do, others do not.

## Where to go next

* For institutional readers evaluating which pattern fits: [What is the Espresso Network?](/network/learn/use-cases.md)
* For chains and applications building a dedicated execution environment: [Configurable Execution Environments](/network/learn/rollup-architecture.md).
* For teams integrating an existing chain into Espresso, see the chain integration guides under the Developer track.
* For network contracts and endpoints: [Networks](/network/network/networks.md).


---

# 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.espressosys.com/network/learn/espresso-in-the-modular-stack.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.