ERC-777 expliqué : La norme de jeton moderne avec des "hooks"

ERC-777 est une norme de jeton Ethereum plus récente, conçue pour résoudre les limitations de longue date d'ERC-20 tout en introduisant des "hooks" (crochets) programmables pour des flux de jetons plus riches. Si vous avez suivi les conversations des développeurs concernant la composabilité, les approbations plus sûres et l'automatisation des protocoles, ERC-777 se situe à l'intersection de ces besoins. Cet article explique comment fonctionne ERC-777, pourquoi il existe, où il excelle, les compromis de sécurité à surveiller, et comment les utilisateurs et les constructeurs peuvent l'aborder en 2025.

Le problème qu'ERC-777 a cherché à résoudre

ERC-20 est devenu la norme par défaut pour les jetons fongibles, mais il présente des points faibles notables :

• Les approbations sont maladroites et sujettes aux erreurs (par exemple, oublier de réinitialiser les allocations).
• Les contrats ne peuvent pas réagir automatiquement à l'arrivée des jetons ; ils nécessitent des interactions de type "pull" (tirer).
• Les sémantiques de transfert sont limitées, ce qui rend plus difficiles les flux complexes (frais, rappels, flux de travail en plusieurs étapes).

ERC-777 tente de moderniser cela en offrant :

• Des hooks d'envoi/réception intégrés pour que les contrats puissent réagir aux transferts au sein de la même transaction.
• Des transferts basés sur des opérateurs, qui simplifient la gestion des jetons pour les dépositaires et les services.
• Une compatibilité ascendante avec les interfaces ERC-20 pour faciliter l'adoption par l'écosystème.

Pour une spécification formelle, consultez la norme canonique ERC-777 sur le site des propositions d'amélioration d'Ethereum : EIP-777. Pour le situer dans le contexte plus large de l'écosystème des jetons, la documentation des développeurs d'Ethereum sur les normes de jetons fournit un contexte et des liens vers les EIP connexes : Aperçu des normes de jetons Ethereum.

Comment fonctionne ERC-777 : hooks et opérateurs

Deux idées principales sont au cœur d'ERC-777.

1. Hooks (Crochets)

• tokensToSend : Un hook côté expéditeur appelé avant que les jetons ne soient déplacés.
• tokensReceived : Un hook côté récepteur appelé après l'arrivée des jetons.
• Ces hooks sont optionnels et découverts via le registre d'interfaces global, EIP-1820.

À l'aide des hooks, les contrats peuvent implémenter une logique métier lors des transferts : auto-staking, répartition des frais, journalisation, filtrage ou rejet des jetons inattendus. Les hooks augmentent la composabilité et réduisent le besoin de flux séparés "approuver puis appeler".

2. Opérateurs

• Un opérateur est autorisé à transférer des jetons au nom d'un détenteur, similaire à un dépositaire délégué.
• Les opérateurs par défaut peuvent être définis par un jeton, et les utilisateurs peuvent les révoquer à tout moment.
• Les opérateurs sur ERC-777 constituent un modèle plus explicite et flexible comparé aux allocations ERC-20.

En pratique, la plupart des équipes s'appuient sur des bibliothèques auditées. OpenZeppelin fournit une implémentation largement utilisée avec des API claires et des gardes-fous : Contrats ERC-777 d'OpenZeppelin.

Un exemple minimal pour développeurs

Ci-dessous se trouve un schéma d'un contrat récepteur utilisant tokensReceived via EIP-1820. Utilisez toujours des bibliothèques vérifiées et effectuez des audits pour le code de production.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/token/ERC777/IERC777.[sol](https://onekey.so/blog/fr/ecosystem/best-sol-wallets-in-2025-ultimate-guide-to-software-hardware-options/)";
import "@openzeppelin/contracts/interfaces/IERC1820Registry.[sol](https://onekey.so/blog/fr/ecosystem/best-sol-wallets-in-2025-ultimate-guide-to-software-hardware-options/)";

[contract](https://onekey.so/blog/fr/ecosystem/what-is-a-smart-contract/) ExampleReceiver {
    IERC1820Registry constant _ERC1820 =
        IERC1820Registry(0x1820a4B7618BdE71Dce8cdc73aAB6C95905faD24);

    bytes32 constant TOKENS_RECIPIENT_INTERFACE_HASH =
        keccak256("ERC777TokensRecipient");

    event Received(address operator, address from, uint256 amount, bytes data, bytes operatorData);

    constructor() {
        _ERC1820.setInterfaceImplementer(address(this), TOKENS_RECIPIENT_INTERFACE_HASH, address(this));
    }

    // Hook ERC777 tokensReceived
    function tokensReceived(
        [address](https://onekey.so/blog/fr/ecosystem/what-is-a-crypto-wallet-address/) operator,
        [address](https://onekey.so/blog/fr/ecosystem/what-is-a-crypto-wallet-address/) from,
        [address](https://onekey.so/blog/fr/ecosystem/what-is-a-crypto-wallet-address/) /*to*/,
        uint256 amount,
        bytes calldata data,
        bytes calldata operatorData
    ) external {
        // Logique personnalisée, par exemple, enregistrer un dépôt ou déclencher une comptabilité interne
        emit Received(operator, from, amount, data, operatorData);
    }
}

Message clé : les hooks permettent aux contrats d'"écouter" les mouvements de jetons sans appels de fonction séparés, réduisant les frictions et donnant l'impression que les flux complexes sont natifs.

Considérations de sécurité : réentrance et conception de protocole

Les hooks sont puissants, mais ils introduisent un risque de réentrance si les contrats ne sont pas conçus de manière défensive. Au début de la DeFi, une série d'incidents a montré comment les rappels de jetons pouvaient interagir de manière inattendue avec des protocoles qui supposaient un comportement de type ERC-20. Ces leçons ont conduit à des meilleures pratiques qui restent pertinentes aujourd'hui :

• Privilégiez le modèle "checks-effects-interactions" dans les fonctions qui modifient l'état.
• Utilisez des gardes de réentrance sur les chemins d'appels externes.
• Concevez soigneusement la logique des pools/comptabilité pour qu'elle soit robuste face à l'exécution de rappels en milieu de transfert.
• Envisagez un modèle de "pull" pour les opérations sensibles lorsque cela est possible.
• Évitez de supposer que les transferts sont sans effets secondaires.

Même si les exploits spécifiques de l'ère Uniswap v1 appartiennent au passé, le principe demeure : les hooks rendent les transferts de jetons actifs, et non passifs. Les audits et les bibliothèques modernes ont évolué en conséquence. Pour une référence fondamentale sur la norme et ses notes de sécurité, consultez EIP-777. Pour étudier les modèles bien entretenus et les gardes-fous, référez-vous à la documentation ERC-777 d'OpenZeppelin.

Interopérabilité et migration depuis ERC-20

Les jetons ERC-777 sont généralement rétrocompatibles avec les interfaces ERC-20, mais les hypothèses diffèrent :

• Les transferts peuvent déclencher des hooks, qui peuvent avoir des effets secondaires.
• Les opérateurs remplacent ou complètent les allocations, modifiant la manière dont les services interagissent.
• Les portefeuilles et les dApps doivent gérer correctement les métadonnées et les flux basés sur les hooks.

Certaines équipes s'en tiennent à ERC-20 avec des améliorations comme EIP-2612 permit (approbations sans gaz), compte tenu de la familiarité généralisée de l'écosystème. D'autres adoptent ERC-777 lorsque la réception programmable ou la sémantique des opérateurs améliorent matériellement l'expérience utilisateur ou la logique du protocole.

Le paysage en 2025 : où s'intègrent les hooks

Bien qu'ERC-20 domine encore les jetons fongibles, les hooks ont influencé la conception ailleurs. Un exemple clair est l'architecture d'Uniswap v4, qui adopte des "hooks" programmables au niveau du pool de liquidité pour activer des fonctionnalités telles que les frais dynamiques et la logique sur mesure, rendant le protocole plus composable par conception. Pour un contexte sur cette évolution, consultez l'aperçu d'Uniswap v4 et la discussion sur les hooks : Annonce et hooks d'Uniswap v4.

Au niveau des jetons, l'adoption d'ERC-777 reste sélective – en particulier dans les contextes où les rappels automatiques et la sémantique des opérateurs apportent une valeur tangible, tels que :

• Les flux de services de garde ou de fournisseurs de services qui bénéficient des transferts d'opérateurs.
• Les programmes de fidélité sur chaîne ou les paiements en continu qui réagissent à la réception.
• Les couches d'infrastructure qui souhaitent des rappels natifs des jetons pour la comptabilité ou la collecte de frais.

Pendant ce temps, les réseaux de couche 2 continuent d'améliorer le débit et les profils de coût, rendant la logique plus complexe du cycle de vie des jetons viable. Cet environnement rend la programmabilité d'ERC-777 pertinente pour les équipes qui ont besoin de sémantiques de transfert plus riches mais qui peuvent investir dans une ingénierie de sécurité robuste.

Meilleures pratiques pour les constructeurs

• Utilisez des bibliothèques auditées et privilégiez les implémentations bien connues. Commencez par ERC-777 d'OpenZeppelin.
• Concevez la logique des hooks pour les scénarios d'échec : rejetez les jetons inattendus, validez l'origine et maintenez des vérifications d'invariants.
• Documentez clairement les opérateurs par défaut ; fournissez des chemins de révocation simples pour les utilisateurs.
• Appliquez des protections contre la réentrance, en particulier autour de tokensReceived, et évitez les appels externes pendant les étapes comptables critiques sauf si strictement nécessaire.
• Réfléchissez si vous avez vraiment besoin de hooks. Sinon, ERC-20 plus EIP-2612 permit pourrait simplifier l'intégration et les attentes des utilisateurs.
• Testez avec différents portefeuilles et dApps qui peuvent traiter ERC-777 différemment. Utilisez correctement le registre EIP-1820 pour enregistrer les implémenteurs.

Conseils pratiques pour les utilisateurs

• Comprenez que les jetons ERC-777 peuvent déclencher une logique lorsqu'ils atteignent certains contrats. C'est généralement bénéfique, mais cela modifie les hypothèses par rapport aux transferts ERC-20 "passifs".
• Examinez ce que vous approuvez et à qui. Si un jeton utilise des opérateurs ou des rappels, assurez-vous de faire confiance au code et à la réputation du contrat récepteur.
• Privilégiez les portefeuilles qui affichent des détails clairs sur les méthodes du contrat, pas seulement "transfert" ou "envoi". Si quelque chose semble inhabituel ou inclut des champs de données arbitraires, arrêtez-vous et vérifiez.

Quand envisager ERC-777

ERC-777 est pertinent lorsque :

• Vous avez besoin d'un comportement de jeton piloté par les événements au moment du transfert (par exemple, dépôt automatique, routage des frais, filtrage personnalisé).
• Les opérateurs simplifient considérablement votre modèle de service ou de garde.
• Vous vous engagez dans une ingénierie de sécurité rigoureuse et des audits pour gérer en toute sécurité la sémantique basée sur les rappels.

ERC-777 peut être moins idéal lorsque :

• La simplicité et une large compatibilité avec l'écosystème sont primordiales.
• Vous pouvez atteindre vos objectifs via ERC-20 plus permit, ou des mécanismes de protocole de niveau supérieur (par exemple, des contrôleurs spécifiques à l'application sans hooks de jeton).

Une perspective de portefeuille matériel

Pour les normes de jetons avec un comportement plus riche et des effets secondaires potentiels, une introspection claire des transactions et une signature hors ligne sont inestimables. OneKey est un portefeuille matériel open-source qui met l'accent sur des confirmations transparentes sur l'appareil et une large prise en charge des jetons EVM. Si vous interagissez régulièrement avec des normes de jetons avancées ou des protocoles DeFi qui utilisent des rappels, l'utilisation d'un portefeuille matériel permet de s'assurer que vous vérifiez exactement ce que vous signez et réduit l'exposition aux contrats malveillants. En d'autres termes, la sophistication d'ERC-777 rend la gestion sécurisée des clés et les confirmations explicites et lisibles par l'homme encore plus importantes – des domaines où un appareil comme OneKey peut apporter une tranquillité d'esprit significative.

Conclusion

ERC-777 introduit des fonctionnalités de jeton modernes – hooks et opérateurs – qui débloquent des flux de jetons plus riches et plus composables sur Ethereum et les chaînes EVM. Sa puissance s'accompagne de responsabilités : les hooks sont actifs, et non passifs, et exigent une programmation défensive et une expérience utilisateur soignée. En 2025, le concept de hooks a influencé la conception des protocoles au-delà des jetons, comme on le voit dans Uniswap v4, tandis qu'ERC-777 lui-même reste un choix ciblé pour les équipes qui bénéficient réellement de la réception programmable et de la sémantique des opérateurs. Que vous adoptiez ERC-777 ou que vous vous en teniez aux modèles ERC-20 améliorés, associez de bonnes pratiques d'ingénierie à des flux d'utilisateurs sécurisés – et envisagez la signature protégée par matériel – afin que votre logique de jeton soit à la fois puissante et sûre.