ESP é o token de utilidade nativo da Espresso Network (ESP), integrando de forma fluida a segurança da rede e os pagamentos de serviços num sistema unificado. Validadores e delegadores utilizam ESP para participar no Proof of Stake (PoS) delegado, enquanto cadeias e aplicações conectadas pagam taxas de protocolo para aceder a serviços como Finality e Data Availability (DA). Para compreender o staking e as taxas de protocolo, é necessário focar na divisão de funções, pontos de entrada dos contratos e no modo como os incentivos sustentam o consenso.
Em ambientes multichain, a ordenação e confirmação dependem frequentemente de uma camada fundacional partilhada. A Espresso Network utiliza HotShot para liquidação descentralizada, sendo ESP o elemento que determina a composição do conjunto de validadores e a forma como os serviços são pagos e acedidos. Os mecanismos de staking e taxas devem ser acompanhados de forma independente para evitar confundir “detenção de tokens” com “acesso a serviços da rede”.
ESP é a base das estruturas de garantia de staking e pagamento de serviços para a segurança da rede. O endereço do token ESP na mainnet Ethereum é 0x031De51F3E8016514Bd0963d0B2AB825A591Db9A, designado tanto para staking como para taxas de protocolo. Validadores têm de fazer staking de ESP através da Stake Table para serem elegíveis ao conjunto de consenso ativo, sendo classificados pelo montante de staking; delegadores atribuem ESP aos validadores, reforçando de forma indireta a segurança da rede.
ESP não processa transações das cadeias conectadas nem substitui os seus mecanismos de ordenação. Pelo contrário, ESP sustenta o orçamento de segurança PoS: alterar resultados confirmados implica comprometer uma parte significativa dos ESP em staking no conjunto de validadores. Este modelo está fortemente ligado ao consenso HotShot e finality rápida—HotShot fornece confirmação BFT, enquanto o staking de ESP determina o peso económico por detrás de cada confirmação.
| Componente | Contrato / Ponto de entrada (Ethereum) | Funcionalidade |
|---|---|---|
| ESP Token | 0x031De51F3E8016514Bd0963d0B2AB825A591Db9A |
Token de utilidade para garantia de staking e taxas de protocolo |
| Stake Table | 0xCeF474D372B5b09dEfe2aF187bf17338Dc704451 |
Gere o registo de validadores, delegações e staking |
| Fee Contract | 0x7f15ff3f783acd4d09c6a79d098ed5069a2bd39a |
Detém depósitos ETH para pagamentos de taxas da rede Espresso |
| Reward Claim | 0x67c966a0ecdd5c33608be7810414e5b54da878d8 |
Distribui recompensas de staking a validadores e delegadores |
Esta tabela distingue entre as camadas de segurança e pagamento: a Stake Table supervisiona a participação no consenso, o Fee Contract gere pré-pagamentos e consumo de serviços, e o contrato Reward Claim trata da distribuição de recompensas. A verificação cruzada de endereços e funções proporciona uma visão mais rigorosa do sistema do que apenas conhecer o nome do token.
Validadores devem registar os seus nodos na Stake Table na Ethereum e garantir ESP delegado suficiente para integrar o conjunto ativo, sendo ordenados por staking em cada epoch. A mainnet utiliza PoS delegado sem permissão: validadores podem operar os seus próprios nodos ou receber delegações de ESP. A delegação mínima é 1 ESP, e o conjunto ativo inclui normalmente os 100 principais validadores por staking.
As alterações de staking não são instantâneas. As atualizações na Stake Table ocorrem nos limites de epoch, e as delegações tornam-se ativas após dois epochs adicionais após a finalidade Ethereum. A desdelegação requer uma janela de saída, sendo geralmente permitida apenas uma desdelegação por validador de cada vez. Validadores podem definir uma taxa de comissão, deduzida das recompensas antes da distribuição aos delegadores conforme a sua participação.
Os titulares de tokens que não operam nodos podem delegar, desdelegar e reivindicar recompensas através de interfaces públicas como stake.espresso.network. Estas interfaces são apenas frontends; a Stake Table, Reward Claim e outros contratos aplicam as regras. Ao escolher validadores, é necessário verificar o estado no conjunto ativo, a taxa de comissão e a fiabilidade do nodo.
| Método de participação | Executor | Resultado |
|---|---|---|
| Validador auto-operado | Regista nodo e atrai delegação | Integra conjunto ativo, participa em HotShot, recebe comissão |
| Delegar ESP | Titular designa validador | Aumenta o peso de staking do validador, partilha recompensas após comissão |
| Desdelegar | Delegador inicia saída | Levanta após janela de saída; atualização de staking efetivo no limite de epoch |
Esta tabela evidencia que a participação no consenso se baseia em “registo + peso de staking efetivo”, e não apenas no saldo da carteira. A delegação reduz barreiras operacionais e transfere algum risco para a escolha do validador.

Figura 1. Caminho duplo de staking ESP e taxas de protocolo: titulares delegam/fazem staking → validadores e Stake Table → segurança HotShot; integradores pagam serviços Finality/DA via Fee Contract.
Integradores pagam taxas de protocolo pré-depositando e consumindo saldos para liquidação, confirmação e serviços DA opcionais. O Fee Contract (0x7f15ff3f783acd4d09c6a79d098ed5069a2bd39a) detém depósitos ETH para taxas da rede Espresso; construtores ou integradores depositam ETH no endereço especificado para deduções. Como ESP cobre tanto staking como taxas de protocolo, é fundamental distinguir entre “entrada de pagamento de serviço” e “função do token”—não são a mesma operação.
As taxas de protocolo estão ligadas à utilização da rede, não à “compra de lugares de validador”. Integradores consomem taxas para aceder a Finality ou DA; validadores entram no consenso com base no peso de staking. Ambos os caminhos convergem na mesma rede: um é o conjunto de validadores incentivados, o outro é o utilizador que paga taxas.
Esta estrutura diferencia a Espresso dos sequenciadores centralizados de cadeia única: sequenciadores centralizados dependem de um único operador, enquanto a Espresso vincula a confirmação a um conjunto de validadores PoS, com integradores a pagar pela utilização. Espresso vs. Centralized Sequencer and Astria contrasta “camadas de confirmação partilhada pagas” com “confiança num único sequenciador”. As taxas não afetam se as cadeias operam os seus próprios sequenciadores, apenas como a confirmação e DA são medidos e liquidados.
Os incentivos garantem que validadores participam continuamente nas confirmações HotShot e verificação relacionada, permitindo que blocos de cadeias conectadas alcancem finality num conjunto descentralizado. As recompensas são reivindicadas via Reward Claim e mecanismos similares; a verificação on-chain determina as distribuições a validadores e delegadores. Os incentivos dependem de “participação no conjunto ativo e cumprimento de funções”.
A ordenação e DA estão claramente separadas: as cadeias operam normalmente os seus próprios sequenciadores, enquanto a Espresso fornece liquidação descentralizada, finality rápida e EspressoDA opcional para compromissos de blocos. Fluxo de confirmação rápida da Espresso liga transação, ordenação, confirmação HotShot e liquidação verificável. Os incentivos de validador recompensam a participação honesta na confirmação partilhada e verificação DA, não a execução nas cadeias conectadas.
A comissão e o estado no conjunto ativo funcionam como filtros: a comissão divide recompensas entre validadores e delegadores; os 100 principais determinam elegibilidade para funções e recompensas. Delegar a nodos fora do conjunto ativo pode não gerar recompensas. É necessário verificar sempre o estado no conjunto ativo do validador antes de considerar a distribuição de recompensas.
Os riscos envolvem sobretudo slashing e restrições comportamentais. O PoS incentiva ações honestas através de recompensas e penaliza má conduta grave via slashing, conforme regras públicas—“potencial perda de ativos em staking” é um risco inerente. Existem também riscos de contrato inteligente: Stake Table, Fee Contract, Reward Claim e ESP Token residem na Ethereum, pelo que vulnerabilidades, atualizações ou permissões podem afetar fundos e estado do sistema.
Os riscos operacionais centram-se nos validadores: downtime, funções não cumpridas ou saída do conjunto ativo podem reduzir recompensas dos delegadores. A desdelegação tem uma janela de tempo. No lado das taxas, os riscos incluem saldos insuficientes, erros de endereço ou deduções mal compreendidas. Integradores devem distinguir entre “depositar no Fee Contract” e “completar integração e garantir confirmação”.
Os equívocos comuns incluem: tratar ESP apenas como um ativo negociável e ignorar as funções de staking e taxas; assumir que delegar equivale a operar um validador ou que todas as delegações geram recompensas; interpretar taxas de protocolo como ofertas promocionais. As taxas de protocolo destinam-se a serviços Finality/DA, enquanto o staking suporta segurança e distribuição de incentivos.
ESP unifica segurança e pagamentos de serviços: validadores e delegadores fazem staking ou delegam ESP via Stake Table para apoiar o conjunto ativo HotShot; integradores pagam taxas de protocolo para serviços de confirmação e DA. Os incentivos estão ligados à ordenação, confirmação e verificação DA, sendo a comissão e o estado no conjunto ativo determinantes para elegibilidade. Os participantes devem compreender os riscos de slashing, contratos inteligentes, operação de nodos e janelas de saída, e acompanhar separadamente os caminhos de staking e taxas.
ESP é o token de utilidade nativo da Espresso Network, utilizado principalmente para staking de validadores, participação em PoS delegado e funções de taxas de protocolo. Os titulares podem tornar-se validadores ou delegar ESP a validadores para garantir o consenso HotShot; integradores pagam por serviços da rede como Finality e DA. ESP não processa transações dentro das cadeias conectadas.
Para ser validador, é necessário registar um nodo na Stake Table na Ethereum, configurar chaves de consenso e parâmetros de comissão, e garantir ESP delegado suficiente para integrar o conjunto ativo, ordenado por staking. Os titulares que não operam nodos podem delegar ESP. As interfaces públicas incluem stake.espresso.network; a eficácia do registo e delegação é regulada por contratos on-chain e regras de epoch.
Espresso Network é uma infraestrutura multichain para confirmação e liquidação partilhada, oferecendo finality descentralizada e rápida para cadeias e aplicações conectadas via consenso HotShot, com serviços de disponibilidade de dados opcionais. ESP proporciona segurança de staking e funcionalidade de taxas de protocolo, permitindo participação de validadores e utilização de serviços num sistema unificado.
HotShot é o protocolo de consenso BFT da Espresso Network, fornecendo finality descentralizada para compromissos de blocos de cadeias conectadas, sem executar essas transações. A sua segurança baseia-se num conjunto de validadores PoS delegado: reverter resultados confirmados exige comprometer uma grande parte dos ESP em staking. HotShot combina finality rápida com segurança económica PoS numa única camada de confirmação.
A participação na Espresso envolve diversos riscos: slashing PoS e restrições comportamentais, vulnerabilidades de contratos inteligentes na Stake Table / Fee Contract / Reward Claim, downtime de validadores ou perda de estado no conjunto ativo, janelas de desdelegação e operações de depósito de taxas. Integradores devem distinguir entre capacidade de pagamento e integração total. O acima exposto destina-se apenas a fins informativos.





