> 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/use-cases.md). # Use Cases 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. Across the use cases below, Espresso provides the same foundation: * **Dedicated execution environments:** each application can define its own rules for fees, ordering, compliance, asset support, privacy, and application logic. * **Settlement through Espresso:** each environment keeps its own sequencer or block proposer, while Espresso finalizes that output through decentralized Proof of Stake consensus. * **Cross-system verifiability:** state finalized by Espresso can be verified by chains and applications that need to rely on that settlement. * **Connectivity without giving up control:** dedicated environments can stay connected to broader onchain markets, including Ethereum liquidity where supported, without inheriting a general-purpose chain's execution rules. Each use case below focuses on what is distinct about that workflow. For a network overview, see [What is Espresso?](/network/learn/what-is-espresso.md). ### Tokenized Assets and Stablecoin Issuance **Who it's for.** Institutions issuing tokenized bonds, securities, structured products, stablecoins, deposit tokens, or other regulated digital assets. **The tradeoff.** Issuers need control over issuance, redemption, transfer eligibility, compliance rules, and asset lifecycle events. Public general-purpose chains provide market access but force issuers to inherit chain-wide fees, ordering assumptions, and public execution. Fully private systems preserve issuer control but can isolate tokenized assets and stablecoins from wallets, counterparties, liquidity, and DeFi integrations. **How Espresso fits.** Issuers can run a dedicated environment for issuance, redemption, eligibility checks, freeze and blocklist controls, NAV updates, and transfer restrictions. Espresso is a good fit because it separates execution from settlement: the issuer keeps control over asset logic, while Espresso provides a finalized settlement record that Ethereum and other connected chains can verify. That helps issued assets maintain connectivity to onchain liquidity without requiring the issuer to inherit a general-purpose chain's rules. ### Payment networks **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. Fully private networks also cut off access to major onchain liquidity sources like USDC and USDT, which limits utility for real-world payment flows. **How Espresso fits.** Payment applications can define their own fee logic e.g. no fees for certain amounts, counterparty rules, supported assets, and compliance checks in an application-specific environment. Espresso is useful here because fast Proof of Stake finality gives payment systems a stronger settlement basis than a single operator's confirmation, while the execution environment keeps payment-specific rules separate from network-wide congestion and fee dynamics. ### Tokenized money market funds and collateral management **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.** Fund issuers and collateral managers can keep redemption rules, NAV update logic, collateral eligibility, and margin policy inside a dedicated environment. Espresso is useful because collateral and margin workflows need a shared source of finality across systems. Espresso finality gives counterparties, auditors, and risk systems a common record to verify when they need evidence of finalized positions or collateral movements. ### Privacy-preserving settlement workflows **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: transactions can be encrypted before submission, execution can be limited to authorized participants, and proofs can let counterparties verify validity without exposing the underlying private data. Espresso is a good fit because it can finalize encrypted transaction streams without executing or decrypting them, preserving public settlement while keeping sensitive workflow data out of the settlement layer. ### 24/7 financial workflows **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.** Espresso operates continuously through a decentralized validator network, so applications are not designed around market-hour settlement windows or a single operator's business hours. That matters for treasury, collateral, and payment workflows where counterparties need a settlement system that can keep producing finality across regions and time zones. ### Application-specific financial systems **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 can define the rules that matter for its market structure. An RFQ venue, for example, can define its own auction logic, participant rules, timing windows, and asset support. Espresso is a good fit because the venue's own sequencer can order activity according to those market rules, while Espresso finalizes the sequencer's output so counterparties have a common finality source. ### Gasless application experiences **Who it's for.** Financial applications and payment networks where charging end users a variable network fee is incompatible with the product design, for example fixed-fee payment products, enterprise treasury tools, or consumer-facing financial applications. **The tradeoff.** On public general-purpose chains, gas fees are set by network-wide demand and paid by the end user or application in the chain's native token. This makes fee predictability difficult and forces product decisions around gas mechanics that have nothing to do with the application's financial logic. **How Espresso fits.** Because each application controls its own execution environment, fees can be a product decision instead of a network-level constraint. Espresso does not force every application into one shared fee market, so the application operator can absorb fees, denominate them in a supported asset, or remove them from the end-user experience where the product design supports it. ### Secure crosschain settlement **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.** Messaging protocols can move messages, but they do not by themselves create the settlement guarantee behind those messages. Espresso is complementary because its consensus answers whether source activity is final, while zero-knowledge proofs can help a destination environment verify what that finalized activity means for a state update or message without re-executing the source environment. ### Institutional liquidity workflows **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.** Institutional liquidity workflows often need multiple parties to rely on the same record of trades, collateral movements, and financing legs. Espresso is a good fit because it gives those workflows a shared finality layer without forcing all participants onto one execution environment. An institution can keep its own compliance, privacy, and workflow rules while making the finalized outcome verifiable to counterparties that need to rely on it. ## Where to go next * For the full network overview: [What is Espresso?](/network/learn/what-is-espresso.md). * 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). --- # 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/learn/use-cases.md?ask=&goal= ``` `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.