# What is the Espresso Network? The Espresso Network, built by Espresso Systems, is a decentralized settlement layer for institutions and application developers building onchain financial systems. It provides fast finality, scalable throughput, configurable execution environments, and secure interoperability across blockchain ecosystems. Espresso reduces reliance on trusted intermediaries by using decentralized Proof of Stake consensus as the basis for settlement and cross-system coordination. Dedicated execution environments let applications define their own rules for fees, ordering, compliance, asset support, and application logic while settling through Espresso. ## At a glance **Available today on Mainnet 1** | Capability | State | | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Settlement | Decentralized Proof of Stake (BFT) consensus | | Validator set | Permissionless, top 100 by delegated stake | | Token | $ESP (ERC-20, Ethereum) | | Cross-chain readability | Light client contracts on Ethereum and Arbitrum One | | Live chain integrations | ApeChain (Yuga Labs), Rari Chain (Rarible), Rufus, Molten, T3rn, NodeOps, Huddle01, and AppChain, all on Arbitrum Nitro. See [Live on Espresso](/network/learn/chains-reference.md). | | Staking and delegation | Available via the [staking UI](/network/network/delegation-ui.md) and `staking-cli` | **On the roadmap (in active development)** | Capability | Target | | ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | | Finality | Sub-second | | Throughput | Scaling to 1M+ transactions per second | | Privacy-preserving execution environments | In active development | | Cross-chain readability | Additional chains | | Chain integrations | Celo on OP Stack; LitVM (Litecoin) on Arbitrum Nitro; Morph (Bitget) on its Optimistic zkEVM; plus Katana and Gate Layer | | Tooling for institutional issuance and settlement | Use-case-specific | {% hint style="info" %} **Who this page is for** * **Heads of digital assets and product leads:** Start with [What you can build](#what-you-can-build-on-espresso) and [How Espresso compares](#how-espresso-compares-to-other-systems). * **Technical evaluators:** Start with [What makes this possible](#what-makes-this-possible), then read [How Espresso Fits](/network/learn/espresso-in-the-modular-stack.md) and [Configurable Execution Environments](/network/learn/rollup-architecture.md). * **Diligence and risk teams:** [Networks](/network/network/networks.md) lists contract addresses, validator information, and operator material. {% endhint %} *** ## What you can build on Espresso Institutions moving financial assets onchain face the same tradeoff: public general-purpose chains offer liquidity and interoperability but limit control and predictability; private systems preserve control but fragment the application from broader onchain markets. Espresso is designed to bridge that gap. Each use case below follows the same structure: who it's for, the tradeoff it addresses, how Espresso fits, and its current status. ### Tokenized assets {% hint style="info" %} **Status:** Designed to support. Specific issuer integrations are use-case-specific. {% endhint %} **Who it's for.** Institutions tokenizing bonds, securities, structured products, and other real-world assets. **The tradeoff.** On a public general-purpose chain, the issuer inherits the chain's fees, throughput, and ordering rules. On a private chain, the asset is isolated from market activity. **How Espresso fits.** Issuers define their own execution environment (eligibility logic, compliance hooks, ordering policy) while settlement and finality come from a decentralized Proof of Stake validator set. Counterparties on Ethereum or Arbitrum One can verify finalized state trust-minimally from the [light client contracts](/network/developer/the-espresso-network/light-client.md), without depending on a single operator. ### Stablecoin issuance {% hint style="info" %} **Status:** Designed to support. Active product direction; no managed issuance product today. Specific issuer integrations are use-case-specific. {% endhint %} **Who it's for.** Institutional stablecoin issuers needing predictable settlement of mint, burn, and transfer activity; control over compliance and eligibility logic; and finality strong enough to coordinate redemptions across counterparties and chains. **The tradeoff.** Issuing on a general-purpose chain means inheriting that chain's ordering and governance. Issuing on a private system avoids that but isolates the stablecoin from open liquidity. **How Espresso fits.** Issuers run their own execution environment, defining mint and burn rules, eligibility logic, freeze and blocklist controls, and ordering policy. Settlement and finality come from a decentralized validator network. ### Payment networks {% hint style="success" %} **Status:** Live capability on Mainnet 1. Payment applications can integrate today. {% endhint %} **Who it's for.** Payment networks needing fast finality, predictable cost, and continuous 24/7 operation across counterparties and chains. **The tradeoff.** General-purpose chains can deliver throughput but with variable fees and ordering risk. Bilateral or closed networks offer control but limited reach. **How Espresso fits.** Payment applications define their own fee logic, ordering policy, and counterparty rules in an application-specific environment while inheriting Espresso's settlement guarantees. Transactions settle in under three seconds on Mainnet 1 today; the roadmap targets sub-second. ### Tokenized money market funds and collateral management {% hint style="info" %} **Status:** Designed to support. Specific issuer integrations are use-case-specific. {% endhint %} **Who it's for.** MMF issuers and collateral managers moving fund interests, NAV updates, and collateral movements onchain. **The tradeoff.** Public general-purpose chains expose every NAV update and redemption to chain-wide fee and governance dynamics. Private deployments preserve control but make audit and cross-counterparty workflows harder to evidence. **How Espresso fits.** Issuers run dedicated environments with their own redemption rules, NAV update logic, and compliance controls. Settlement finality comes from a decentralized validator network and is verifiable from Ethereum and Arbitrum One via the light client contracts. ### Privacy-preserving settlement workflows {% hint style="warning" %} **Status:** In active development. Settlement is live on Mainnet 1; privacy-preserving execution environments are being developed. {% endhint %} **Who it's for.** Institutional financial workflows that need to keep execution data (counterparty identity, balances, trade size, position state) private from third parties while still settling on a system other parties can verify. **The tradeoff.** Public general-purpose chains expose execution data by default. Private deployments preserve privacy but lose the cross-system verifiability that comes from a public settlement layer. **How Espresso fits.** Privacy lives at the application and execution layer (encrypted blocks, confidential computation, privacy-preserving cryptographic proofs). Espresso provides settlement and finality at the consensus layer, so state or validity can be proven to the network (and to verifiers on other chains) without revealing the underlying private information. ### 24/7 financial workflows {% hint style="success" %} **Status:** Live on Mainnet 1. Espresso operates continuously across a decentralized validator network, with no batch windows or operator availability constraints. {% endhint %} **Who it's for.** Institutional workflows that need to clear across counterparties and time zones without scheduling around a single operator. **The tradeoff.** Traditional settlement is constrained by market hours, settlement cycles, and operating windows. Public chains operate 24/7 but expose application-level scheduling to network-level congestion. Closed settlement networks avoid that congestion but inherit operator availability constraints. **How Espresso fits.** Applications building on Espresso get a settlement layer that does not have batch windows, market hours, or single-operator downtime as design constraints. ### Application-specific financial systems {% hint style="success" %} **Status:** Live capability on Mainnet 1. Applications can build on existing chain integrations (Arbitrum Nitro, OP Stack) today. {% endhint %} **Who it's for.** Exchanges, RFQ venues, clearing systems, and other financial applications with specific requirements around ordering, fees, asset support, or compliance. **The tradeoff.** Building on a public chain forces the application to adapt to that chain's economics. Building a fully private system avoids that but loses interoperability with broader onchain markets. **How Espresso fits.** Each application runs its own execution environment (defining the rules that matter for the application) while sharing Espresso's settlement guarantees. An RFQ venue, for example, can define its own auction logic and timing rules, settle results through Espresso, and have counterparties verify the finalized result from Ethereum or Arbitrum One. ### Secure cross-chain settlement {% hint style="success" %} **Status:** Live on Mainnet 1. Light client contracts deployed on Ethereum and Arbitrum One. {% endhint %} **Who it's for.** Applications coordinating activity across multiple chains (moving an asset, executing a multi-leg trade, syncing application state) where the settlement guarantee matters. **The tradeoff.** Messaging protocols and bridge systems rely on their own trust models (relayer sets, multisigs, oracle networks) for message delivery. Those trust models are often acceptable for low-value flows but harder to justify for institutional workflows where the settlement guarantee matters. **How Espresso fits.** Espresso provides decentralized Proof of Stake finality as the basis for cross-system coordination. Other systems can verify Espresso state trustlessly from the light client contracts on Ethereum and Arbitrum One. Espresso is complementary to messaging protocols where applications need both message delivery and finality guarantees. ### Institutional liquidity workflows {% hint style="info" %} **Status:** Designed to support. Specific institutional integrations are use-case-specific. {% endhint %} **Who it's for.** Repo, securities lending, prime brokerage, and intraday treasury workflows needing fast settlement of multi-leg transactions and the ability to coordinate across systems without giving up control of compliance and audit. **The tradeoff.** The mismatch between traditional settlement cycles and onchain continuous operation is one of the main reasons these workflows have not moved onchain. **How Espresso fits.** Espresso combines fast Proof of Stake finality, configurable execution environments, and secure cross-chain readability. An institution can keep the rules of its workflow private to its execution environment while making the settled state of each transaction verifiable to its counterparties. *** ## What makes this possible The use cases above rest on a small, deliberate set of capabilities: * **Decentralized Proof of Stake consensus.** Permissionless validator set; stake delegated via the $ESP token. No single sequencer, multisig, or operator can reorder or censor finalized blocks. * **Fast finality.** Sub-second on the roadmap. * **Scalable throughput.** Designed to support institutional settlement volumes without depending on a single sequencer; the roadmap targets 1M+ transactions per second. * **Configurable execution environments.** Each integrated chain or application defines its own execution rules (fees, ordering, compliance, asset support) while sharing Espresso's settlement guarantees. * **Secure interoperability.** Finalized state is verifiable trust-minimally from [light client contracts](/network/developer/the-espresso-network/light-client.md) on Ethereum and Arbitrum One, so applications, bridges, and counterparties on those chains can confirm Espresso finality without relying on intermediaries. * **Optional data availability.** Espresso DA for the data its environments finalize, or external DA (Celestia, EigenDA, Ethereum, Avail) depending on the deployment. * **Privacy at the application layer.** Public settlement layer; private execution environments can prove validity without revealing the underlying data. *** ## How Espresso compares to other systems | System category | Settlement model | Control over execution | Cross-system verifiability | Typical fit | | ----------------------------------- | -------------------------------- | -------------------------------- | --------------------------------------------------------- | -------------------------------------------------- | | Public general-purpose chains | Chain's own consensus | Limited; inherits chain rules | Native within ecosystem | Open developer reach, broad liquidity | | Private / permissioned chains | Operator-controlled | Full | Limited; via bridges | Compliance-heavy, isolated workflows | | Messaging / oracle networks | None (delivery only) | N/A | Their own trust models | Cross-chain messaging; complementary to settlement | | Multisig-based bridges | Signer set | N/A | Trust-bounded by signer set | Lower-value cross-chain transfer | | Canton-style institutional networks | Coordinator-led | Application-level | Limited public verifiability | Privacy-first institutional consortia | | **Espresso Network** | **Decentralized Proof of Stake** | **Configurable per environment** | **Light client commitments on Ethereum and Arbitrum One** | **Institution-grade onchain finance** | Espresso does not require institutions to commit to a single ecosystem; its interoperability is designed to keep dedicated environments connected to broader onchain liquidity. Where applications need both message delivery and decentralized finality, Espresso is complementary to messaging and oracle networks, not a substitute. *** ## Roadmap disclosure {% hint style="warning" %} Where this page describes a use case as something Espresso "is designed to support," the capability is validated by the network's architecture but specific institutional integrations are use-case-specific. Roadmap items (sub-second finality, throughput scaling to 1M+ tx/s, privacy-preserving execution environments, managed institutional issuance tooling) are in active development and are not delivered capabilities today. {% endhint %} *** ## Where to go next * For chains and application teams evaluating dedicated environments: [Configurable Execution Environments](/network/learn/rollup-architecture.md). * For an architectural view of how Espresso fits into existing stacks: [How Espresso Fits](/network/learn/espresso-in-the-modular-stack.md). * For integrators reading state from Espresso: [Reading from Espresso](/network/developer/dapp/read-from-network.md). * For network contracts, endpoints, and validator information: [Networks](/network/network/networks.md). * For ESP token holders: [Delegate $ESP](/network/network/delegation-ui.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/use-cases.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.