# Configurable Execution Environments The Espresso Network is a decentralized settlement layer. Applications and chains that integrate with Espresso define their own **execution environment** (the rules for how transactions are executed, fees are paid, ordering decisions are made, and which assets are supported) and rely on Espresso for settlement and finality. A configurable execution environment can be: * A **dedicated execution environment** for a single application or product team. * An **application-specific environment** (for example, an exchange, payment network, RFQ venue, or clearing system) built around one financial use case. * A **full chain** when broader functionality is needed. In each case, the design choice is the same: the application defines its own operating environment, while settlement finality comes from Espresso's decentralized Proof of Stake consensus. ## Why use a configurable execution environment? Institutions building onchain financial systems often face a tradeoff between **control** and **connectivity**. * Public general-purpose chains offer broad liquidity and interoperability, but require accepting that chain's fees, throughput, and governance. * Private and permissioned chains preserve operational control, but fragment the application from broader onchain liquidity. A configurable execution environment on Espresso lets a team define its own execution rules (fees, ordering, compliance, supported assets, application logic) while still settling through a decentralized validator network that other onchain systems can read trustlessly. ## What Espresso provides Espresso provides **decentralized settlement and finality** for the blocks proposed by integrated chains and applications. Each application's execution ordering rules (how transactions are sequenced inside a block) are set by the application itself, not by Espresso, and Espresso does not execute the transactions inside those blocks. * **Decentralized consensus finality.** Once Espresso finalizes a block, that block cannot be retroactively reordered or removed without consensus-level corruption (at least two-thirds of staked $ESP would need to be controlled by dishonest parties). * **Fast finality.** Transactions settle in under three seconds on the production Mainnet 1 network. The roadmap targets sub-second finality. * **Data availability.** Espresso can provide DA for the data its chains finalize, removing the need for a separate DA layer in many deployments. Integrations may also continue to use Celestia, EigenDA, Avail, or Ethereum for DA. * **Trust-minimized readability.** Finalized state is verifiable from light client contracts on Ethereum and Arbitrum One, so integrated applications can coordinate cross-system without relying solely on trusted intermediaries. Espresso does **not** execute application transactions. Each execution environment runs the application's own state transition function. This separation lets each environment evolve independently while still inheriting Espresso's settlement guarantees. ## Where the application logic lives Each execution environment is responsible for: * The application's state transition function (an EVM, a custom VM, or a single application's state machine). * Local execution and block proposal. * Application-specific rules: fees, ordering policy, compliance checks, asset support. Espresso is responsible for: * Decentralized settlement and finality for the blocks produced by each environment. * Optional data availability. * Light client commitments that let any other system verify Espresso state. ## How Espresso integrates with existing rollup stacks Many of Espresso's integrations today are with rollup frameworks (Arbitrum Nitro, OP Stack). For those integrations: 1. The rollup's sequencer or builder produces blocks for the execution environment. 2. The Espresso Network finalizes those blocks under Proof of Stake consensus. 3. If the rollup also settles to an L1 (e.g. Ethereum), batches are posted to that L1 along with proofs that the batch is consistent with the blocks Espresso has finalized. The L1 verifies the proof before accepting the batch. 4. End users can read finalized state through a [caff node](/network/developer/dapp/read-from-network.md) without waiting for the L1 batch. This pattern is one way to integrate. Configurable execution environments are not limited to rollups, and not every Espresso environment settles to Ethereum. ## Security model at a glance * **Settlement finality** is backed by Espresso's decentralized Proof of Stake consensus. Espresso provides consistent, irreversible finality on the blocks it finalizes as long as at least two-thirds of staked $ESP is controlled by honest parties. * **Application correctness** is the responsibility of each execution environment. Espresso does not verify application state transitions. * **Cross-system coordination** relies on Espresso's light client commitments. The model is trust-minimizing, not trust-removing. Applications and bridges still need to verify light client state on their target system. For deeper protocol detail, see [HotShot Consensus](/network/developer/the-espresso-network/properties-of-hotshot.md) and the [Light Client Contract](/network/developer/the-espresso-network/light-client.md). ## Where to go next * For chains integrating Espresso into an existing stack, see the chain integration guides: [Nitro / Orbit](/network/developer/rollup-developers/nitro.md), [OP Stack](/network/developer/rollup-developers/op.md). * For applications and clients that read finalized state, see [Reading from Espresso](/network/developer/dapp/read-from-network.md). * For network contracts, endpoints, and validator information, see [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/rollup-architecture.md?ask= ``` 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.