ESP es el token de utilidad nativo de Espresso Network (ESP), que integra de manera eficiente la seguridad de la red y los pagos de servicios en un sistema único. Los validadores y delegadores utilizan ESP para participar en la prueba de participación delegada (PoS), mientras que las cadenas y aplicaciones conectadas pagan tarifas de protocolo para acceder a servicios como Finality y Data Availability (DA). Para comprender el staking y las tarifas de protocolo, céntrate en la división de roles, los puntos de entrada a los contratos y la función de los incentivos en el consenso.
En entornos multicadena, la secuenciación y la confirmación suelen depender de una capa fundamental compartida. Espresso Network emplea HotShot para la liquidación descentralizada, y ESP determina la composición del conjunto de validadores y la forma de pago y acceso a los servicios. Es fundamental rastrear por separado los mecanismos de staking y de tarifas para no confundir “tener tokens” con “acceso a los servicios de la red”.
ESP es la base del colateral de staking y de la estructura de pagos de servicios para la seguridad de la red. La dirección del token ESP en la red principal de Ethereum es 0x031De51F3E8016514Bd0963d0B2AB825A591Db9A, utilizada tanto para staking como para tarifas de protocolo. Los validadores deben poner en staking ESP mediante la Stake Table para ser elegibles en el conjunto activo de consenso, ordenados por cantidad en staking; los delegadores asignan ESP a los validadores, reforzando así la seguridad de la red.
ESP no procesa transacciones de las cadenas conectadas ni sustituye sus mecanismos de secuenciación. Su función es sustentar el presupuesto de seguridad PoS: modificar resultados confirmados requiere comprometer una parte significativa del ESP en staking dentro del conjunto de validadores. Este modelo está estrechamente ligado al consenso HotShot y la finalización rápida: HotShot aporta confirmación BFT, mientras que el staking de ESP determina el peso económico de cada confirmación.
| Componente | Contrato / Punto de entrada (Ethereum) | Funcionalidad |
|---|---|---|
| Token ESP | 0x031De51F3E8016514Bd0963d0B2AB825A591Db9A |
Token de utilidad para colateral de staking y tarifas de protocolo |
| Stake Table | 0xCeF474D372B5b09dEfe2aF187bf17338Dc704451 |
Gestiona el registro de validadores, delegación y staking |
| Fee Contract | 0x7f15ff3f783acd4d09c6a79d098ed5069a2bd39a |
Almacena depósitos de ETH para el pago de tarifas de la red Espresso |
| Reward Claim | 0x67c966a0ecdd5c33608be7810414e5b54da878d8 |
Distribuye recompensas de staking a validadores y delegadores |
Esta tabla diferencia las capas de seguridad y de pago: la Stake Table regula la participación en el consenso, el Fee Contract gestiona los pagos anticipados y el consumo de servicios, y el contrato Reward Claim distribuye las recompensas. Verificar direcciones y funciones ofrece una visión más precisa del sistema que limitarse al nombre del token.
Los validadores deben registrar sus nodos en la Stake Table de Ethereum y obtener suficiente ESP delegado para entrar al conjunto activo, ordenado por staking en cada época. La red principal utiliza PoS delegado sin permisos: los validadores pueden operar sus propios nodos o recibir delegaciones de ESP. La delegación mínima es de 1 ESP y el conjunto activo suele estar compuesto por los 100 validadores con mayor staking.
Los cambios de staking no son inmediatos. Las actualizaciones en la Stake Table se efectúan al final de cada época, y las delegaciones se activan tras dos épocas adicionales luego de la finalización en Ethereum. La undelegación requiere una ventana de salida, y normalmente solo se permite una undelegación por validador a la vez. Los validadores pueden fijar una comisión, que se deduce de las recompensas antes de distribuirlas a los delegadores según su participación.
Los holders que no gestionan nodos pueden delegar, undelegar y obtener recompensas a través de interfaces públicas como stake.espresso.network. Estas interfaces son solo frontends; la Stake Table, Reward Claim y otros contratos ejecutan las reglas. Al elegir validadores, revisa su estado en el conjunto activo, la comisión y la fiabilidad del nodo.
| Método de participación | Ejecutor | Resultado |
|---|---|---|
| Validador autogestionado | Registra nodo y atrae delegaciones | Ingresa al conjunto activo, participa en HotShot, gana comisión |
| Delegar ESP | Holder designa validador | Aumenta el peso del staking del validador, recibe recompensas tras comisión |
| Undelegar | Delegador inicia salida | Retiro tras la ventana de salida; el staking efectivo se actualiza al final de la época |
Esta tabla muestra que la participación en el consenso depende del “registro + peso efectivo en staking”, no solo del saldo en la billetera. La delegación reduce barreras operativas y traslada parte del riesgo a la elección del validador.

Figura 1. Doble ruta de staking de ESP y tarifas de protocolo: los holders delegan/ponen en staking → validadores y Stake Table → seguridad HotShot; los integradores pagan servicios de Finality/DA a través del Fee Contract.
Los integradores pagan tarifas de protocolo predepositando y consumiendo saldos para liquidación, confirmación y servicios opcionales de DA. El Fee Contract (0x7f15ff3f783acd4d09c6a79d098ed5069a2bd39a) almacena depósitos de ETH para las tarifas de Espresso Network; los desarrolladores o integradores depositan ETH en la dirección indicada para las deducciones. Dado que ESP cubre tanto el staking como las tarifas de protocolo, es esencial distinguir entre “punto de entrada de pago de servicios” y “función del token”; no son la misma operación.
Las tarifas de protocolo están vinculadas al uso de la red, no a la “compra de plazas de validador”. Los integradores consumen tarifas para acceder a Finality o DA; los validadores entran en consenso según el peso en staking. Ambas rutas convergen en la misma red: una es el conjunto de validadores incentivado, la otra es el usuario que paga tarifas.
Esta estructura distingue a Espresso de los secuenciadores centralizados de una sola cadena: los secuenciadores centralizados dependen de un solo operador, mientras que Espresso vincula la confirmación a un conjunto de validadores PoS y los integradores pagan por el uso. Espresso vs. Secuenciador centralizado y Astria compara “capas de confirmación compartidas de pago” con “confianza en un solo secuenciador”. Las tarifas no afectan si las cadenas gestionan sus propios secuenciadores, solo la forma en que se mide y liquida la confirmación y la DA.
Los incentivos garantizan la participación continua de los validadores en las confirmaciones HotShot y la verificación asociada, permitiendo que los bloques de las cadenas conectadas alcancen la finalización en un conjunto descentralizado. Las recompensas se obtienen a través de Reward Claim y mecanismos similares; la verificación on-chain determina la distribución a validadores y delegadores. Los incentivos dependen de la “participación en el conjunto activo y el cumplimiento de tareas”.
La secuenciación y la DA están claramente separadas: las cadenas suelen operar sus propios secuenciadores, mientras que Espresso proporciona liquidación descentralizada, finalización rápida y EspressoDA opcional para compromisos de bloques. El flujo de confirmación rápida de Espresso conecta transacción, secuenciación, confirmación HotShot y liquidación verificable. Los incentivos a validadores recompensan la participación honesta en la confirmación compartida y la verificación de DA, no la ejecución en cadenas conectadas.
La comisión y el estado en el conjunto activo funcionan como filtros: la comisión reparte recompensas entre validadores y delegadores; los 100 primeros determinan la elegibilidad para tareas y recompensas. Delegar a nodos fuera del conjunto activo puede no generar recompensas. Verifica siempre el estado en el conjunto activo de un validador antes de considerar la distribución de recompensas.
Los riesgos se centran principalmente en el slashing y las restricciones de comportamiento. PoS incentiva acciones honestas mediante recompensas y penaliza conductas graves mediante slashing, según reglas públicas: “pérdida potencial de activos en staking” es un riesgo inherente. Existen riesgos asociados a contratos inteligentes: Stake Table, Fee Contract, Reward Claim y el token ESP residen en Ethereum, por lo que vulnerabilidades, actualizaciones o permisos pueden afectar los fondos y el estado del sistema.
Los riesgos operativos recaen en los validadores: inactividad, tareas no cumplidas o salir del conjunto activo pueden reducir las recompensas a delegadores. La undelegación tiene una ventana temporal. Por el lado de las tarifas, los riesgos incluyen saldos insuficientes, errores de dirección o confusión sobre las deducciones. Los integradores deben distinguir entre “depositar en el Fee Contract” y “completar la integración y lograr garantías de confirmación”.
Entre los malentendidos frecuentes se encuentran: tratar ESP solo como un activo negociable y no considerar sus funciones de staking y tarifas; asumir que delegar equivale a operar como validador o que todas las delegaciones generan recompensas; confundir las tarifas de protocolo con incentivos promocionales. Las tarifas de protocolo son para servicios de Finality/DA, mientras que el staking respalda la seguridad y la distribución de incentivos.
ESP unifica la seguridad y los pagos de servicios: validadores y delegadores ponen en staking o delegan ESP a través de la Stake Table para respaldar el conjunto activo de HotShot; los integradores pagan tarifas de protocolo por servicios de confirmación y DA. Los incentivos están ligados a la secuenciación, confirmación y verificación de DA, con la comisión y el estado en el conjunto activo determinando la elegibilidad. Es fundamental que los participantes comprendan los riesgos de slashing, contratos inteligentes, operación de nodos y ventanas de salida, y gestionen por separado las rutas de staking y tarifas.
ESP es el token de utilidad nativo de Espresso Network, utilizado principalmente para el staking de validadores, la participación en PoS delegado y las funciones de tarifas de protocolo. Los holders pueden convertirse en validadores o delegar ESP a validadores para asegurar el consenso HotShot; los integradores pagan por servicios de red como Finality y DA. ESP no procesa transacciones dentro de las cadenas conectadas.
Para ser validador, registra un nodo en la Stake Table en Ethereum, configura las claves de consenso y los parámetros de comisión, y asegura suficiente ESP delegado para ingresar al conjunto activo, ordenado por staking. Los holders que no gestionan nodos pueden delegar ESP. Las interfaces públicas incluyen stake.espresso.network; la efectividad del registro y la delegación la determinan los contratos on-chain y las reglas por época.
Espresso Network es una infraestructura multicadena para confirmación y liquidación compartidas, que ofrece finalización descentralizada y rápida para cadenas y aplicaciones conectadas mediante el consenso HotShot, con servicios opcionales de disponibilidad de datos. ESP proporciona la seguridad del staking y la funcionalidad de tarifas de protocolo, permitiendo la participación de validadores y el uso de servicios en un sistema unificado.
HotShot es el protocolo de consenso BFT de Espresso Network, que proporciona finalización descentralizada para compromisos de bloques de cadenas conectadas, sin ejecutar esas transacciones. Su seguridad se basa en un conjunto de validadores PoS delegado: revertir resultados confirmados requiere comprometer una gran parte del ESP en staking. HotShot combina finalización rápida y seguridad económica PoS en una sola capa de confirmación.
La participación en Espresso implica diversos riesgos: slashing y restricciones de comportamiento propias de PoS, vulnerabilidades en contratos inteligentes como Stake Table / Fee Contract / Reward Claim, inactividad del validador o pérdida de estado en el conjunto activo, ventanas temporales para undelegación y operaciones de depósito de tarifas. Los integradores deben distinguir entre capacidad de pago e integración total. Lo anterior es solo para fines informativos.





