> 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/what-is-espresso.md).

# What is Espresso?

Espresso is a blockchain that serves as a decentralized settlement layer that enables institutions and developers to build payment networks, stablecoins, tokenized assets, and other financial applications with real-time settlement, configurable execution, and secure interoperability.

Espresso combines decentralized Proof of Stake consensus with zero-knowledge proof systems: consensus establishes a canonical, final record of transactions across all connected environments, and zero-knowledge proofs make that finality efficiently verifiable across environments without re-executing source logic or exposing private data.

Built for a future where onchain finance spans many independent networks, Espresso lets integrated systems build on their own stack, keep their architecture, and rely on fast settlement backed by a decentralized validator network.

Integrated systems can use Besu or other EVM clients, define their own rules, and make state finalized by Espresso verifiable by other chains and applications that need to interoperate with them. For institution-grade use cases in detail, see [Use Cases](/network/learn/use-cases.md).

***

{% hint style="info" %}
**Who this page is for**

* **Heads of digital assets and product leads:** Start with [Use Cases](/network/learn/use-cases.md) 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 %}

***

## At a Glance

**Available today on Mainnet**

* **Settlement**: Real-time settlement backed by a decentralized validator network
* **Finality**: Fast finality on Mainnet
* **Throughput**: Can scale to millions of transactions per second
* **Validator set**: Permissionless, top 100 by delegated stake
* **Token**: $ESP (ERC-20, Ethereum)
* **Crosschain readability**: State finalized by Espresso can be verified by Ethereum and other connected chains, keeping dedicated environments connected to onchain liquidity including USDC, USDT, and other Ethereum-issued assets
* **Privacy architecture**: the Espresso design supports private execution through encrypted block submission and authorized client decryption; only participants holding the appropriate access keys can derive application state
* **Live chain integrations**: See [Live on Espresso](/network/network/chains-reference.md) for current integrated chains and applications
* **Staking and delegation**: Available via the [staking UI](/network/developer/operators/run-a-node/delegation-ui.md) and `staking-cli`

***

## What Makes This Possible

The use cases in [Use Cases](/network/learn/use-cases.md) 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.** Real-time settlement on Mainnet today.
* **Scalable throughput.** The ability to scale to millions of transactions per second. Because Espresso does not execute transactions, each environment runs its own execution logic and Espresso is not the throughput bottleneck. Multiple environments run in parallel, each scaling independently, while Espresso finalizes their output.
* **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.** State finalized by Espresso can be verified by chains and applications that need to rely on that settlement, so applications, bridges, and counterparties can confirm Espresso finality without relying on intermediaries.
* **Privacy at the application layer.** Public settlement layer; private execution environments can prove validity without revealing the underlying data.

***

## Technical Architecture

The consensus protocol underlying Espresso's Proof of Stake finality is called **HotShot**, based on the HotStuff family of BFT consensus protocols. Compromising Espresso-finalized ordering would require an adversary to control at least one-third of staked $ESP. Data availability uses erasure coding, known as Verifiable Information Dispersal (VID), so individual nodes only need to store a fraction of each block rather than the full data, and a block is only finalized once enough chunks are confirmed recoverable across the network. See [Properties of HotShot](https://github.com/EspressoSystems/gitbook/tree/main/concepts/the-espresso-network/properties-of-hotshot/README.md) for protocol-level detail.

### Why the design works for private financial applications

Espresso separates consensus from execution. Each application environment has its own sequencer that orders transactions and streams them to Espresso. Espresso finalizes that stream through decentralized Proof of Stake consensus, establishing a definitive record of what happened. Each application then executes its own logic against that finalized transaction stream. This separation is what makes privacy possible on a public settlement layer.

For private applications, transaction data can be encrypted before it reaches Espresso. Espresso finalizes the encrypted transaction sequence without decrypting it. Only authorized participants, those holding the appropriate access keys, can decrypt and execute the application logic to derive state such as account balances, positions, or ownership records. Because all authorized participants observe the same finalized sequence and run the same deterministic logic, they all derive identical state, without any participant needing to reveal private data to the settlement layer.

### Why consensus and zero-knowledge proofs are both necessary

Consensus and zero-knowledge proofs solve two different problems.

**Consensus answers: what happened, and is it final?**

Each application environment has its own sequencer that orders transactions. Espresso's Proof of Stake consensus finalizes the sequencer's output, giving every participant a single, agreed-upon record of what happened. Without consensus, there is no guarantee of finality. Anyone could present a conflicting version of events, and no one could prove which was correct. Consensus is what makes settlement real: a finalized transaction cannot be reversed or censored by any single party.

**Zero-knowledge proofs answer: how do I act on state from another environment without re-executing it or seeing private data?**

Once consensus has established what happened, separate environments still need to coordinate. A destination environment cannot always reconstruct the full state of a source environment. Doing so could be expensive, and for private applications it would require access to encrypted data the destination is not authorized to see.

Zero-knowledge proofs solve this. A coordination server for the source environment attaches a succinct proof to a crosschain message. The destination environment verifies the proof, confirming that the state or message is correct, without re-executing the source logic and without decrypting private data.

**Why you need both:**

Consensus alone tells you a transaction is final but gives you no efficient way to verify what that means for state on a separate environment. Zero-knowledge proofs alone let you prove state transitions efficiently, but without consensus there is no authoritative record of which state is canonical. A proof could be constructed against a disputed or non-final sequence. Together, consensus establishes finality and zero-knowledge proofs make that finality efficiently verifiable across environments, including private ones.

### Zero-knowledge proofs and multiple proof systems

When applications on separate environments need to coordinate, they cannot always reconstruct full source state. Espresso supports zero-knowledge proof systems to make crosschain coordination efficient and privacy-preserving.

Coordination servers for a source application attach succinct proofs to crosschain messages. A destination application can verify message correctness using the proof alone, without re-executing the source logic or accessing private data. Multiple proof systems are supported, including ZK SNARKs and trusted execution environment (TEE) attestations, so teams are not required to adopt a single proving stack. This is how Espresso removes the need for trusted intermediaries in crosschain settlement while preserving the privacy of each application's internal state.

***

## Where to Go Next

* For institution-grade use cases: [Use Cases](/network/learn/use-cases.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).
* For integrators reading state from Espresso: [Reading from Espresso](https://github.com/EspressoSystems/gitbook/tree/main/concepts/read-from-network.md).
* For network contracts, endpoints, and validator information: [Networks](/network/network/networks.md).
* For protocol implementation details: [espresso-network](https://github.com/EspressoSystems/espresso-network).
* For ESP token holders: [Delegate $ESP](/network/developer/operators/run-a-node/delegation-ui.md).