ESP est le token d’utilité natif d’Espresso Network, intégrant la sécurité du réseau et le paiement des services dans un système unifié. Les validateurs et les délégateurs utilisent ESP pour participer à la Preuve d’enjeu déléguée (PoS), tandis que les chaînes et applications connectées paient des frais de protocole pour accéder à des services tels que la Finalité et la Disponibilité des données (DA). Pour comprendre le staking et les frais de protocole, il faut distinguer les rôles, les points d’entrée des contrats et la façon dont les incitations structurent le consensus.
Dans les environnements multi-chain, le séquencement et la confirmation reposent sur une couche fondamentale partagée. Espresso Network s’appuie sur HotShot pour le règlement décentralisé, avec ESP déterminant l’appartenance au groupe de validateurs et la manière dont les services sont payés et utilisés. Il est essentiel de suivre séparément les mécanismes de staking et de frais pour ne pas confondre « détenir des tokens » et « accéder aux services du réseau ».
ESP sert de base au collatéral de staking et aux paiements de services pour la sécurité du réseau. L’adresse du token ESP sur le mainnet Ethereum est 0x031De51F3E8016514Bd0963d0B2AB825A591Db9A, utilisée pour le staking et les frais de protocole. Les validateurs doivent staker ESP via la Stake Table pour être éligibles au groupe de consensus actif, classés selon le montant staké ; les délégateurs attribuent ESP aux validateurs, renforçant ainsi la sécurité du réseau.
ESP ne traite pas les transactions des chaînes connectées ni ne remplace leurs mécanismes de séquencement. Il soutient le budget de sécurité PoS : modifier des résultats confirmés nécessite de compromettre une part importante d’ESP staké dans le groupe de validateurs. Ce modèle est étroitement lié au consensus HotShot et à la finalité rapide—HotShot assure la confirmation BFT, tandis que le staking ESP détermine le poids économique de chaque confirmation.
| Composant | Contrat / Point d’entrée (Ethereum) | Fonctionnalité |
|---|---|---|
| ESP Token | 0x031De51F3E8016514Bd0963d0B2AB825A591Db9A |
Token d’utilité pour le collatéral de staking et les frais de protocole |
| Stake Table | 0xCeF474D372B5b09dEfe2aF187bf17338Dc704451 |
Gère l’enregistrement des validateurs, la délégation et le staking |
| Fee Contract | 0x7f15ff3f783acd4d09c6a79d098ed5069a2bd39a |
Héberge les dépôts ETH pour les paiements des frais du réseau Espresso |
| Reward Claim | 0x67c966a0ecdd5c33608be7810414e5b54da878d8 |
Distribue les récompenses de staking aux validateurs et délégateurs |
Ce tableau distingue les couches de sécurité et de paiement : la Stake Table supervise la participation au consensus, le Fee Contract gère les prépaiements et la consommation de services, et le contrat Reward Claim assure la distribution des récompenses. La vérification croisée des adresses et fonctions offre une vision plus précise du système que la simple connaissance du nom du token.
Les validateurs doivent enregistrer leurs nœuds dans la Stake Table sur Ethereum et obtenir suffisamment d’ESP délégué pour rejoindre le groupe actif, classé par staking à chaque epoch. Le mainnet utilise une Preuve d’enjeu déléguée sans permission : les validateurs peuvent exploiter leurs propres nœuds ou recevoir des délégations ESP. La délégation minimale est de 1 ESP, et le groupe actif inclut généralement les 100 premiers validateurs par staking.
Les modifications de staking ne sont pas instantanées. Les mises à jour de la Stake Table interviennent à chaque epoch, et les délégations deviennent actives après deux epochs supplémentaires suivant la finalité sur Ethereum. L’undélégation nécessite une fenêtre de sortie, et généralement une seule undélégation par validateur est autorisée à la fois. Les validateurs peuvent fixer un taux de commission, prélevé sur les récompenses avant distribution aux délégateurs selon leur part.
Les détenteurs de tokens qui n’exploitent pas de nœuds peuvent déléguer, undéléguer et récupérer des récompenses via des interfaces publiques telles que stake.espresso.network. Ces interfaces ne sont que des frontends ; la Stake Table, Reward Claim et autres contrats appliquent les règles. Lors du choix d’un validateur, vérifiez son statut dans le groupe actif, son taux de commission et la fiabilité de son nœud.
| Méthode de participation | Exécuteur | Résultat |
|---|---|---|
| Validateur auto-opéré | Enregistre le nœud et attire la délégation | Rejoint le groupe actif, participe à HotShot, perçoit une commission |
| Déléguer ESP | Détenteur désigne un validateur | Augmente le poids du staking du validateur, partage des récompenses après commission |
| Undéléguer | Délégateur initie la sortie | Retrait après la fenêtre de sortie ; mise à jour du staking effectif à l’epoch |
Ce tableau montre que la participation au consensus repose sur « l’enregistrement + le poids effectif du staking », et non simplement sur le solde du portefeuille. La délégation réduit les obstacles opérationnels et transfère une partie du risque au choix du validateur.

Figure 1. Double chemin du staking et des frais de protocole ESP : les détenteurs délèguent/stake → validateurs et Stake Table → sécurité HotShot ; les intégrateurs paient les services Finality/DA via le Fee Contract.
Les intégrateurs paient les frais de protocole en pré-déposant et consommant des soldes pour le règlement, la confirmation et les services DA optionnels. Le Fee Contract (0x7f15ff3f783acd4d09c6a79d098ed5069a2bd39a) héberge les dépôts ETH pour les frais du réseau Espresso ; les builders ou intégrateurs déposent de l’ETH à l’adresse indiquée pour les déductions. Puisque ESP couvre à la fois le staking et les frais de protocole, il est important de distinguer « point d’entrée de paiement de service » et « fonction du token »—ce ne sont pas les mêmes opérations.
Les frais de protocole sont liés à l’utilisation du réseau, pas à « l’achat de sièges de validateur ». Les intégrateurs consomment des frais pour accéder à Finality ou DA ; les validateurs participent au consensus selon le poids du staking. Les deux chemins convergent sur le même réseau : l’un correspond au groupe de validateurs incentivés, l’autre à l’utilisateur payant des frais.
Cette structure distingue Espresso des séquenceurs centralisés sur une seule chaîne : les séquenceurs centralisés reposent sur un seul opérateur, tandis qu’Espresso ancre la confirmation sur un groupe de validateurs PoS, avec des intégrateurs payant pour l’usage. Espresso vs. Centralized Sequencer et Astria oppose « couches de confirmation partagées payantes » à « la confiance dans un seul séquenceur ». Les frais n’influencent pas le fait que les chaînes exploitent leurs propres séquenceurs, mais seulement la façon dont la confirmation et la DA sont mesurées et réglées.
Les incitations garantissent la participation continue des validateurs aux confirmations HotShot et à la vérification associée, permettant aux blocs des chaînes connectées d’atteindre la finalité sur un groupe décentralisé. Les récompenses sont récupérées via Reward Claim et des mécanismes similaires ; la vérification on-chain détermine la distribution aux validateurs et délégateurs. Les incitations sont liées à la « participation au groupe actif et à l’accomplissement des tâches ».
Le séquencement et la DA sont clairement séparés : les chaînes exploitent généralement leurs propres séquenceurs, tandis qu’Espresso assure le règlement décentralisé, la finalité rapide et EspressoDA optionnel pour l’engagement des blocs. Le flux de confirmation rapide d’Espresso relie transaction, séquencement, confirmation HotShot et règlement vérifiable. Les incitations aux validateurs récompensent la participation honnête à la confirmation partagée et à la vérification DA, non l’exécution sur les chaînes connectées.
La commission et le statut dans le groupe actif servent de filtres : la commission répartit les récompenses entre validateurs et délégateurs ; les 100 premiers déterminent l’éligibilité aux tâches et récompenses. Déléguer à des nœuds hors du groupe actif peut ne pas générer de récompenses. Vérifiez toujours le statut du validateur dans le groupe actif avant d’envisager la distribution des récompenses.
Les risques concernent principalement le slashing et les contraintes comportementales. Le PoS incite à des actions honnêtes via des récompenses et pénalise les comportements graves par le slashing, selon des règles publiques—« perte potentielle des actifs stakés » est un risque inhérent. Les risques liés aux Smart Contracts existent également : Stake Table, Fee Contract, Reward Claim et ESP Token résident tous sur Ethereum, donc les vulnérabilités, mises à jour ou permissions peuvent affecter les fonds et l’état du système.
Les risques opérationnels sont centrés sur les validateurs : les interruptions, tâches manquées ou la sortie du groupe actif peuvent réduire les récompenses des délégateurs. L’undélégation possède une fenêtre temporelle. Côté frais, les risques incluent les soldes insuffisants, les erreurs d’adresse ou la mauvaise compréhension des déductions. Les intégrateurs doivent distinguer « dépôt au Fee Contract » et « intégration complète et garantie de confirmation ».
Les incompréhensions courantes incluent : considérer ESP uniquement comme un actif négociable et ignorer ses fonctions de staking et de frais ; supposer que la délégation équivaut à exploiter un validateur ou que toutes les délégations génèrent des récompenses ; confondre les frais de protocole avec des promotions. Les frais de protocole servent aux services Finality/DA, tandis que le staking soutient la sécurité et la distribution des incitations.
ESP unifie la sécurité et les paiements de services : les validateurs et délégateurs stakent ou délèguent ESP via la Stake Table pour soutenir le groupe actif HotShot ; les intégrateurs paient des frais de protocole pour la confirmation et les services DA. Les incitations sont liées au séquencement, à la confirmation et à la vérification DA, avec la commission et le statut dans le groupe actif déterminant l’éligibilité. Les participants doivent comprendre les risques de slashing, de Smart Contracts, d’exploitation de nœud et de fenêtres de sortie, et suivre séparément les chemins du staking et des frais.
ESP est le token d’utilité natif d’Espresso Network, principalement utilisé pour le staking des validateurs, la participation à la PoS déléguée et les fonctions de frais de protocole. Les détenteurs peuvent devenir validateurs ou déléguer ESP à des validateurs pour sécuriser le consensus HotShot ; les intégrateurs paient pour des services réseau tels que Finality et DA. ESP ne traite pas les transactions au sein des chaînes connectées.
Pour devenir validateur, enregistrez un nœud dans la Stake Table sur Ethereum, configurez les clés de consensus et les paramètres de commission, et obtenez suffisamment d’ESP délégué pour rejoindre le groupe actif, classé par staking. Les détenteurs ne possédant pas de nœud peuvent déléguer ESP à la place. Les interfaces publiques incluent stake.espresso.network ; l’efficacité de l’enregistrement et de la délégation est régie par les contrats on-chain et les règles d’epoch.
Espresso Network est une infrastructure multi-chain pour la confirmation et le règlement partagés, offrant une finalité décentralisée et rapide pour les chaînes et applications connectées via le consensus HotShot, avec des services de disponibilité des données optionnels. ESP assure la sécurité du staking et la fonctionnalité des frais de protocole, permettant la participation des validateurs et l’utilisation des services dans un système unifié.
HotShot est le protocole de consensus BFT d’Espresso Network, assurant la finalité décentralisée pour l’engagement des blocs issus des chaînes connectées, sans exécuter ces transactions. Sa sécurité repose sur un groupe de validateurs PoS délégués : renverser des résultats confirmés nécessite de compromettre une part importante d’ESP staké. HotShot fusionne la finalité rapide avec la sécurité économique PoS dans une couche de confirmation unique.
La participation à Espresso comporte plusieurs risques : slashing PoS et contraintes comportementales, vulnérabilités des Smart Contracts dans Stake Table / Fee Contract / Reward Claim, interruptions de validateur ou perte du statut dans le groupe actif, fenêtres d’undélégation et opérations de dépôt de frais. Les intégrateurs doivent distinguer la capacité de paiement et l’intégration complète. Ce qui précède est fourni à titre informatif uniquement.





