> 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/learn/rollup-architecture.md). # Configurable Execution Environments Espresso 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 **completely generalized execution environment**. 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 verify trust-minimally. ## 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.** Real-time settlement on Mainnet across a decentralized validator set. * **Scalable throughput.** The ability to scale to millions of transactions per second. * **Trust-minimized readability.** State finalized by Espresso can be verified by chains and applications that need to rely on that settlement, so integrated applications can coordinate across systems 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 such as Besu or another EVM client, 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. * Verifiable settlement commitments that let other systems verify Espresso state. ## 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 verifiable Espresso state. The model is trust-minimizing, not trust-removing. Applications and bridges still need to verify Espresso state on their target system. For deeper protocol detail, see [Protocol documentation](/network/network/networks.md#protocol-documentation). ## Where to go next * For technical integration paths, see [Integrate a Chain](/network/developer/rollup-developers.md) in the Developer section. * For applications and clients that read finalized state, see [Reading from Espresso](https://github.com/EspressoSystems/gitbook/blob/main/concepts/read-from-network.md). * For network contracts, endpoints, and validator information, see [Networks](/network/network/networks.md). --- # 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: ``` 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.