ESP is the native utility token of Espresso Network (ESP), seamlessly integrating network security and service payments within a unified system. Validators and delegators use ESP to participate in delegated Proof of Stake (PoS), while connected chains and applications pay protocol fees to access services like Finality and Data Availability (DA). To understand staking and protocol fees, focus on the division of roles, contract entry points, and how incentives underpin consensus.
In multichain environments, sequencing and confirmation often depend on a shared foundational layer. Espresso Network leverages HotShot for decentralized settlement, with ESP determining validator set membership and how services are paid for and accessed. Staking and fee mechanisms should be tracked independently to avoid conflating “holding tokens” with “having access to network services.”
ESP is the backbone of staking collateral and service payment structures for network security. The Ethereum mainnet ESP Token address is 0x031De51F3E8016514Bd0963d0B2AB825A591Db9A, designated for both staking and protocol fees. Validators must stake ESP via the Stake Table to be eligible for the active consensus set, ranked by stake amount; delegators assign ESP to validators, indirectly enhancing network security.
ESP does not process transactions for connected chains or replace their sequencing mechanisms. Instead, ESP underpins the PoS security budget: altering confirmed outcomes requires compromising a significant portion of staked ESP within the validator set. This model is tightly coupled to HotShot consensus and rapid finality—HotShot provides BFT confirmation, while ESP staking determines the economic weight behind each confirmation.
| Component | Contract / Entry Point (Ethereum) | Functionality |
|---|---|---|
| ESP Token | 0x031De51F3E8016514Bd0963d0B2AB825A591Db9A |
Utility token for staking collateral and protocol fees |
| Stake Table | 0xCeF474D372B5b09dEfe2aF187bf17338Dc704451 |
Manages validator registration, delegation, and staking |
| Fee Contract | 0x7f15ff3f783acd4d09c6a79d098ed5069a2bd39a |
Holds ETH deposits for Espresso network fee payments |
| Reward Claim | 0x67c966a0ecdd5c33608be7810414e5b54da878d8 |
Distributes staking rewards to validators and delegators |
This table distinguishes between the security and payment layers: the Stake Table oversees consensus participation, the Fee Contract manages service prepayments and consumption, and the Reward Claim contract handles reward distribution. Cross-verifying addresses and functions provides a more accurate view of the system than simply knowing the token’s name.
Validators must register their nodes in the Stake Table on Ethereum and secure enough delegated ESP to join the active set, ranked by stake each epoch. Mainnet uses permissionless delegated PoS: validators can operate their own nodes or receive ESP delegations. The minimum delegation is 1 ESP, and the active set typically includes the top 100 validators by stake.
Staking changes are not instant. Updates to the Stake Table occur at epoch boundaries, and delegations become active after two additional epochs following Ethereum finality. Undelegation requires an exit window, and only one undelegation per validator is usually allowed at a time. Validators may set a commission rate, deducted from rewards before distribution to delegators based on their share.
Token holders who do not run nodes can delegate, undelegate, and claim rewards through public interfaces like stake.espresso.network. These interfaces are simply frontends; the Stake Table, Reward Claim, and other contracts enforce the rules. When choosing validators, check their active set status, commission rate, and node reliability.
| Participation Method | Executor | Outcome |
|---|---|---|
| Self-Operated Validator | Registers node and attracts delegation | Joins active set, participates in HotShot, earns commission |
| Delegate ESP | Holder designates validator | Increases validator’s stake weight, shares rewards after commission |
| Undelegate | Delegator initiates exit | Withdraws after exit window; effective stake updates at epoch boundary |
This table highlights that consensus participation is based on “registration + effective stake weight,” not merely wallet balance. Delegation lowers operational barriers and shifts some risk to validator selection.

Figure 1. Dual path of ESP staking and protocol fees: holders delegate/stake → validators and Stake Table → HotShot security; integrators pay for Finality/DA services via Fee Contract.
Integrators pay protocol fees by predepositing and consuming balances for settlement, confirmation, and optional DA services. The Fee Contract (0x7f15ff3f783acd4d09c6a79d098ed5069a2bd39a) holds ETH deposits for Espresso network fees; builders or integrators deposit ETH to the specified address for deductions. Since ESP covers both staking and protocol fees, it’s important to distinguish between “service payment entry” and “token function”—these are not the same operation.
Protocol fees are tied to network usage, not “purchasing validator seats.” Integrators consume fees to access Finality or DA; validators enter consensus based on staked weight. Both paths converge on the same network: one is the incentivized validator set, the other is the fee-paying user.
This structure differentiates Espresso from single-chain centralized sequencers: centralized sequencers rely on a single operator, while Espresso anchors confirmation to a PoS validator set, with integrators paying for usage. Espresso vs. Centralized Sequencer and Astria contrasts “paid shared confirmation layers” with “trust in a single sequencer.” Fees do not affect whether chains operate their own sequencers, only how confirmation and DA are measured and settled.
Incentives ensure validators continuously participate in HotShot confirmations and related verification, allowing connected chain blocks to reach finality on a decentralized set. Rewards are claimed via Reward Claim and similar mechanisms; on-chain verification determines distributions to validators and delegators. Incentives are tied to “active set participation and duty fulfillment.”
Sequencing and DA are clearly separated: chains usually run their own sequencers, while Espresso provides decentralized settlement, fast finality, and optional EspressoDA for block commitments. Espresso’s rapid confirmation flow links transaction, sequencing, HotShot confirmation, and verifiable settlement. Validator incentives reward honest participation in shared confirmation and DA verification, not execution on connected chains.
Commission and active set status act as filters: commission splits rewards between validators and delegators; the top 100 determine eligibility for duties and rewards. Delegating to nodes outside the active set may not yield rewards. Always verify a validator’s active set status before considering reward distribution.
Risks primarily involve slashing and behavioral constraints. PoS incentivizes honest actions through rewards and penalizes severe misconduct via slashing, as defined by public rules—“potential loss of staked assets” is an inherent risk. Smart contract risks also exist: Stake Table, Fee Contract, Reward Claim, and ESP Token all reside on Ethereum, so vulnerabilities, upgrades, or permissions can affect funds and system state.
Operational risks are centered on validators: downtime, missed duties, or leaving the active set can reduce delegator rewards. Undelegation has a time window. On the fee side, risks include insufficient balances, address errors, or misunderstanding deductions. Integrators must distinguish between “depositing to the Fee Contract” and “completing integration and achieving confirmation guarantees.”
Common misunderstandings include: treating ESP solely as a tradable asset and ignoring its staking and fee functions; assuming delegation is equivalent to running a validator or that all delegations earn rewards; misunderstanding protocol fees as promotional giveaways. Protocol fees are for Finality/DA services, while staking supports security and incentive distribution.
ESP unifies security and service payments: validators and delegators stake or delegate ESP via the Stake Table to support the HotShot active set; integrators pay protocol fees for confirmation and DA services. Incentives are tied to sequencing, confirmation, and DA verification, with commission and active set status determining eligibility. Participants must understand the risks of slashing, smart contracts, node operation, and exit windows, and track staking and fee paths separately.
ESP is the native utility token of Espresso Network, primarily used for validator staking, delegated PoS participation, and protocol fee functions. Holders can become validators or delegate ESP to validators to secure HotShot consensus; integrators pay for network services like Finality and DA. ESP does not process transactions within connected chains.
To become a validator, register a node in the Stake Table on Ethereum, configure consensus keys and commission parameters, and secure enough delegated ESP to join the active set, ranked by stake. Non-node holders can delegate ESP instead. Public interfaces include stake.espresso.network; effectiveness of registration and delegation is governed by on-chain contracts and epoch rules.
Espresso Network is a multichain infrastructure for shared confirmation and settlement, offering decentralized, rapid finality for connected chains and applications via HotShot consensus, with optional data availability services. ESP provides staking security and protocol fee functionality, enabling validator participation and service usage under a unified system.
HotShot is the BFT consensus protocol of Espresso Network, providing decentralized finality for block commitments from connected chains, without executing those transactions. Its security is based on a delegated PoS validator set: overturning confirmed results requires compromising a large share of staked ESP. HotShot merges rapid finality with PoS economic security in a single confirmation layer.
Participation in Espresso involves several risks: PoS slashing and behavioral constraints, smart contract vulnerabilities in Stake Table / Fee Contract / Reward Claim, validator downtime or loss of active set status, undelegation time windows, and fee deposit operations. Integrators should distinguish between payment capability and full integration. The above is for informational purposes only.





