# Glossary of Key Terms

## Core concepts

The terms most relevant to understanding what Espresso is, how it integrates with chains and applications, and what guarantees it provides.

**Batch Poster** The component responsible for collecting ordered transactions, assembling them into batches, and submitting those batches to the parent chain (e.g., Ethereum). In Espresso-integrated chains, the batch poster [runs inside a TEE](/network/developer/rollup-developers/nitro/using-tee-with-nitro.md) to ensure it only posts batches that have been confirmed by Espresso's HotShot consensus.

**Caff Node (Caffeinated Node)** A node for a chain or application integrated with Espresso that [reads finalized blocks directly from the Espresso Network](/network/developer/dapp/read-from-network.md) and derives local state from them. Caff Nodes expose standard EVM-compatible JSON-RPC endpoints, the same interface your application already uses. Users see confirmed transaction state within seconds of Espresso finalization, without waiting for any downstream settlement step (such as an L1 batch for rollup-based deployments). For teams building latency-sensitive applications (trading, bridging, intent settlement), a Caff Node is how you close the gap between what Espresso has finalized and what your users can actually see and act on.

**Confirmation** The point at which the Espresso Network considers a transaction settled and irreversible. An Espresso confirmation is produced by decentralized Proof of Stake consensus across the Espresso validator set, secured by the [HotShot](/network/developer/the-espresso-network/properties-of-hotshot.md) consensus protocol. Reversing a confirmed transaction would require compromising a supermajority of staked $ESP, the same class of security guarantee that backs other major Proof of Stake networks, delivered within seconds rather than minutes or hours. For institutions, an Espresso confirmation is the moment a transaction can be acted on: a risk system can update margin and release positions across counterparties, a stablecoin issuer can treat a redemption as final and update reserves, and a payment network can release funds to a counterparty. None of these workflows have to wait for downstream settlement, which would otherwise add latency and expose them to stale-data risk.

**Data Availability (DA)** The guarantee that transaction data has been published and can be retrieved by any party who needs it. DA is distinct from execution: a network can confirm that data is available without executing the transactions it contains. Espresso provides an optional [DA layer (EspressoDA)](/network/developer/the-espresso-network/properties-of-hotshot/espresso-data-availability-layer.md) for integrated chains; integrations may also use Ethereum, Celestia, EigenDA, or Avail.

**Delegated Proof of Stake** A variant of Proof of Stake in which token holders who do not operate validator nodes can assign ("delegate") their tokens to a validator of their choice. The validator stakes the combined tokens on behalf of delegators and shares block rewards proportionally, minus a commission. Espresso's Mainnet 1 uses delegated Proof of Stake. See [Delegate $ESP](/network/network/delegation-ui.md) to participate, and [Staking Rewards Calculation](/network/developer/the-espresso-network/stake-table/staking-rewards-calculation.md) for how rewards are distributed.

**Epoch** A fixed interval of blocks after which the stake table is updated. Changes to validator registrations, delegations, and undelegations take effect at epoch boundaries, not immediately. In Espresso, delegations become active two epochs after being finalized on Ethereum. See [Staking Rewards Calculation](/network/developer/the-espresso-network/stake-table/staking-rewards-calculation.md) for epoch timing details.

**ESP Token** The native token of the Espresso Network, used for staking and delegation. Validators and their delegators earn ESP rewards for participating in HotShot consensus and securing the network. The minimum delegation is 1 ESP. See [Delegate $ESP](/network/network/delegation-ui.md) to get started.

**Finality** The point at which a transaction's position in the ledger is considered irreversible. How quickly and securely finality is reached depends on the system:

* **L1 chains (e.g. Ethereum):** Finality is backed by a large decentralized validator set but takes time. Ethereum's Casper FFG reaches economic finality in roughly 12–15 minutes.
* **Rollups:** Finality depends on a batch being posted to and accepted by the parent chain, inheriting the L1's delay on top of the rollup's own sequencing time.
* **Permissioned or app-specific chains:** Finality is often delegated to a trusted operator or a small committee, which is fast but introduces a centralization dependency.

Espresso provides another option: HotShot, Espresso's BFT consensus protocol, delivers decentralized Proof of Stake finality within seconds on Mainnet 1. Unlike L1 finality, it doesn't require waiting through epoch cycles. Unlike rollup finality, it doesn't require an L1 batch to be posted and accepted. And unlike permissioned chains, it doesn't rely on a trusted operator: finality is backed by a decentralized validator set where corrupting the result would require controlling at least two-thirds of staked $ESP. See [Security model at a glance](/network/learn/rollup-architecture.md#security-model-at-a-glance) for how this applies across integration types.

**HotShot** Espresso's BFT (Byzantine Fault Tolerant) consensus protocol, running in production on Mainnet 1. [HotShot](/network/developer/the-espresso-network/properties-of-hotshot.md) finalizes blocks submitted by integrated chains and applications, providing settlement guarantees across a decentralized validator set without executing the transactions themselves. It is based on HotStuff and HotStuff-2, designed to scale to thousands of nodes while maintaining fast, optimistically responsive finality, currently settling blocks in under three seconds on Mainnet 1, with a roadmap target of sub-second finality.

**Interoperability** The ability for separate chains or applications to exchange state and coordinate activity in a trust-minimized way. Espresso enables interoperability by providing a shared finality layer that any connected system can read trustlessly via [light client contracts](/network/developer/the-espresso-network/light-client.md) on Ethereum and Arbitrum One. See [Interfaces](/network/developer/the-espresso-network/interfaces.md) for the technical integration points.

**L1 / L2** **L1 (Layer 1)** refers to a base blockchain that provides security and settlement, most commonly Ethereum. **L2 (Layer 2)** refers to a chain that executes transactions off-chain and anchors them to an L1 for security. Rollups are the most common L2 design. Espresso sits above the L1 as a decentralized settlement and finality layer for L2s and application-specific environments. See [Configurable Execution Environments](/network/learn/rollup-architecture.md).

**Namespace** A unique identifier that associates a chain or application's transactions with a specific slot inside an Espresso block. Multiple chains can use Espresso simultaneously, each submitting to its own namespace. The namespace allows each chain's transactions to be independently verified and retrieved without processing the full block. See [EspressoDA](/network/developer/the-espresso-network/properties-of-hotshot/espresso-data-availability-layer.md) for how namespaces work at the data availability layer.

**Orbit Chain** An Arbitrum Nitro chain deployed using the [Orbit](https://arbitrum.io/orbit) framework. Orbit chains can be permissioned or permissionless and settle to Arbitrum One or Ethereum. Espresso's [Nitro integration](/network/developer/rollup-developers/nitro.md) allows Orbit chains to use Espresso for fast, decentralized confirmations by running the batch poster in an SGX TEE.

**Proof of Stake** A consensus mechanism in which validators are chosen to propose and attest to blocks in proportion to the amount of tokens they have staked as collateral. Honest behavior is incentivized by rewards; dishonest behavior can result in slashing. Espresso uses Proof of Stake (specifically delegated Proof of Stake) to secure HotShot consensus on Mainnet 1. See [Stake Table Contract](/network/developer/the-espresso-network/stake-table.md) for the onchain implementation.

**RaaS (Rollup-as-a-Service)** A category of infrastructure providers that deploy and operate rollup chains on behalf of other teams, handling node operation, monitoring, and upgrades. Caldera is the primary RaaS provider for Espresso-integrated chains. Orbit chains can integrate with Espresso directly or through a RaaS provider. See [Live on Espresso](/network/learn/chains-reference.md) for the current list of integrated chains.

**Rollup** A blockchain that executes transactions off-chain and posts a compressed record of those transactions to a parent chain (L1) for security anchoring. Rollups inherit the parent chain's security while achieving higher throughput. Optimistic rollups assume batches are valid and allow fraud challenges; ZK rollups attach cryptographic validity proofs to each batch. See [Configurable Execution Environments](/network/learn/rollup-architecture.md).

**Sequencer** The component responsible for collecting user transactions, ordering them, and producing blocks. In most rollups today, the sequencer is a single centralized operator, which introduces a trust dependency on that operator's ordering decisions. Espresso does not replace the sequencer. Instead, it provides [decentralized settlement and finality](/network/learn/rollup-architecture.md) for the blocks a chain's own sequencer produces, ensuring those blocks cannot be retroactively reordered without consensus-level corruption.

**Settlement** The point at which a chain's state is recorded with finality and made readable by other systems, so that counterparties, auditors, and downstream applications can rely on it. The strength of settlement depends on what backs it: a single sequencer's soft confirmation can be revoked by that operator and is not auditable as final, while a decentralized validator network's confirmation cannot be revoked without compromising a supermajority of stake. Espresso acts as a decentralized settlement layer for integrated chains and applications: their finalized blocks are anchored to Espresso's Proof of Stake consensus, and the resulting state is verifiable from [light client contracts](/network/developer/the-espresso-network/light-client.md) deployed on Ethereum and Arbitrum One. Chains that also anchor to an L1 such as Ethereum can continue to do so; Espresso adds fast, decentralized finality on top.

**TEE (Trusted Execution Environment)** A secure hardware enclave (such as Intel SGX or AMD SEV) that provides three guarantees: code integrity (only the expected code runs inside the enclave), data confidentiality (the enclave's state cannot be inspected or tampered with, even by the machine's operator), and remote attestation (anyone can verify the enclave is running the correct code). Espresso uses TEEs in batch posters to ensure that only Espresso-confirmed transactions are posted to the parent chain. See [Using TEE with Nitro](/network/developer/rollup-developers/nitro/using-tee-with-nitro.md).

**ZK Proof (Zero-Knowledge Proof)** A cryptographic method that allows one party to prove to another that a statement is true without revealing any underlying information beyond the truth of the statement itself. In the rollup context, ZK proofs are used to prove that a batch of transactions was executed correctly, enabling immediate finality on the parent chain without a fraud-proof window. See [ZK Rollup Integration](/network/developer/rollup-developers/integrating-a-zk-rollup.md).

## HotShot consensus internals

Lower-level protocol vocabulary used inside HotShot consensus and EspressoDA. Most readers won't need these; they're documented here for protocol engineers, auditors, and node operators reading the [Properties of HotShot](/network/developer/the-espresso-network/properties-of-hotshot.md) reference.

**Commitment Proposal** A proposal on a block commitment. A block can only be applied to the chain if consensus on the commitment proposal is reached. A commitment proposal is used as follows:

* A (consensus) leader, upon receiving a DAC for this view or sufficient quorum votes for the previous view, will construct a commitment proposal and multicast it to replicas. The commitment proposal will contain the block commitment, view number, height, justify QC, and the proposer ID.
* A node, after receiving the commitment proposal, if also gets either the DAC or the DA proposal, will validate the set and send the quorum vote back to the leader.

See [Properties of HotShot](/network/developer/the-espresso-network/properties-of-hotshot.md) for the full consensus flow.

**Data Availability Certificate (DAC)** A certificate that the proposed data is available to a quorum of distinct parties in the random small data availability (DA) committee. A DA leader, after receiving a sufficient number of votes on its DA proposal, assembles the votes into an optimistic DAC. See [EspressoDA](/network/developer/the-espresso-network/properties-of-hotshot/espresso-data-availability-layer.md).

**Data Availability Layer** Storage nodes that guarantee the availability and retrievability of transaction raw data and are in charge of the eventual dissemination of the full data across the network. See [EspressoDA](/network/developer/the-espresso-network/properties-of-hotshot/espresso-data-availability-layer.md).

**Data Availability Proposal** A proposal on a block for data availability. Consensus on a data availability proposal ensures that enough parties have the block data. The DA proposal consists of the block and the corresponding view number. See [EspressoDA](/network/developer/the-espresso-network/properties-of-hotshot/espresso-data-availability-layer.md).

**Data Availability Vote (DA Vote)** A node vote on the data commitment, indicating the receipt of either a DA proposal or a valid VID share. The vote contains the justify QC commitment, view number, block commitment, signature, and vote token. See [EspressoDA](/network/developer/the-espresso-network/properties-of-hotshot/espresso-data-availability-layer.md).

**Data Retrievability Certificate** A certificate that valid VID shares are available to a quorum of replicas. This ensures the liveness and data availability of the HotShot protocol even if the random small DA committee is bribed by an adversary. A DA leader assembles the retrievability certificate after receiving enough votes from the entire node/replica set. See [EspressoDA](/network/developer/the-espresso-network/properties-of-hotshot/espresso-data-availability-layer.md).

**Quorum Vote** A vote on the commitment proposal representing the status of the node/replica's decision on the proposal.

*`Yes Vote`:* is sent if the replica successfully verifies the commitment proposal. It consists of the justify QC commitment, view number, leaf commitment, signature, and vote token.

*`No Vote`:* indicates the replica's rejection. A no vote has the same contents as a yes vote.

*`Timeout Vote`*: means the replica cannot decide due to timeout. Therefore, it does not include the leaf commitment as the yes or no vote does, but has all the other fields.

The node is not only signing on the data that is voted on but also the vote type, preventing a dishonest node from altering the vote. E.g., it is impossible to use the signature associated with a no vote to create a yes vote. See [Properties of HotShot](/network/developer/the-espresso-network/properties-of-hotshot.md).

{% hint style="info" %}
**Want to learn more?** [Get in touch with the Espresso team →](mailto:hello@espressosys.com?subject=Documentation%20question)
{% endhint %}


---

# 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/glossary/glossary.md?ask=<question>
```

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.