Qu'est-ce que l'ERC-677 : Faciliter les interactions avec les contrats intelligents

Les contrats intelligents alimentent presque toutes les interactions significatives sur les chaînes EVM, de l'échange de jetons au jalonnement, en passant par le pontage d'actifs et le déclenchement de mises à jour d'oracles. Pourtant, la norme de base des jetons ERC-20 nécessite souvent des modèles d'expérience utilisateur en plusieurs étapes comme « approuver » suivi de « appeler », ce qui ajoute des frictions, coûte plus de gaz et augmente le risque d'erreurs utilisateur. L'ERC-677 est une extension pragmatique de l'ERC-20 qui rationalise ces flux en combinant un transfert de jeton avec un appel de contrat immédiat.

Cet article explique ce qu'est l'ERC-677, comment il fonctionne, où il est utile et sur quoi les développeurs et les utilisateurs devraient se concentrer en 2025.

Le problème avec l'ERC-20 seul

L'ERC-20 définit une interface simple pour les jetons fongibles : transfert, approbation et transfertDepuis. Cette simplicité a aidé l'ERC-20 à devenir l'épine dorsale de la DeFi et des stablecoins, mais elle force également les flux de travail courants en deux transactions :

• Approuver le dépensier
• Appeler le contrat du protocole (qui utilise ensuite transfertDepuis)

Ce modèle en deux étapes :

• Augmente le nombre de transactions et le gaz.
• Crée des frictions et de la confusion dans l'expérience utilisateur.
• Peut introduire des conditions de concurrence lors des approbations et des allocations restantes. Voir les conseils d'OpenZeppelin sur l'ajustement des allocations pour atténuer les problèmes liés à la sémantique d'approbation. Recommandations d'OpenZeppelin sur les allocations ERC-20

Pour un aperçu de l'ERC-20 lui-même, consultez la documentation d'Ethereum.org. Aperçu de la norme ERC-20

Ce que l'ERC-677 ajoute

L'ERC-677 étend l'ERC-20 avec une fonction clé : transferAndCall. En une seule transaction, le jeton est transféré vers un contrat destinataire et invoque immédiatement un rappel prédéfini (communément onTokenTransfer) sur ce destinataire avec des données arbitraires.

Flux de haut niveau :

1. L'utilisateur signe un transferAndCall sur le jeton ERC-677.
2. Le contrat de jeton transfère les jetons au destinataire.
3. Le contrat de jeton appelle recipient.onTokenTransfer(sender, amount, data).
4. Le contrat destinataire exécute la logique – par exemple, dépôt, jalonnement, échange ou déclenchement d'un oracle.

Ce modèle supprime la nécessité d'une étape d'approbation distincte et permet aux contrats de réagir immédiatement à la réception des jetons.

Le jeton LINK de Chainlink est une implémentation ERC-677 bien connue, conçue pour que les contrats puissent réagir immédiatement aux transferts de LINK afin de payer les services d'oracle et les interactions associées. Jeton LINK de Chainlink et ERC-677

Utilisations typiques

• Dépôts dans des pools de jalonnement et des coffres-forts : les utilisateurs déposent en une seule transaction, et le coffre-fort comptabilise le dépôt dans le rappel.
• Flux DEX et de liquidité : les protocoles peuvent recevoir les jetons et exécuter directement la logique d'échange ou d'ajout de liquidité.
• Paiements d'oracles et de services : transférez des jetons vers un contrat de service et déclenchez l'utilisation ou la facturation dans le même appel. C'est ainsi que l'ERC-677 de LINK permet des paiements d'oracle fluides. Jeton LINK de Chainlink et ERC-677
• Ponts et protocoles cross-chain : combinez la livraison de jetons avec une charge utile d'instructions pour le pontage ou la messagerie.
• Interopérabilité cross-chain : à mesure que l'utilisation cross-chain augmente, la combinaison du transfert de valeur avec l'exécution est utile. La conception de CCIP de Chainlink illustre la demande croissante de flux de jetons programmables entre les réseaux. Qu'est-ce que CCIP

Comment l'ERC-677 se compare aux alternatives

• ERC-1363 (jetons « payables » similaires à transferAndCall) : objectif similaire – permettre aux contrats de réagir lorsqu'ils reçoivent des jetons – avec des rappels standardisés pour les flux de dépenses et d'approbation. Idéal pour les expériences similaires au paiement. Spécification ERC-1363

• ERC-777 (jetons basés sur des hooks) : fournit des sémantiques de jetons plus riches et des hooks de réception. Puissant, mais historiquement livré avec plus de complexité et un risque de réentrance si les récepteurs ne sont pas soigneusement conçus. Spécification ERC-777

• EIP-2612 (permit) et Permit2 : se concentrent sur les approbations sans gaz via des messages signés, réduisant ainsi le besoin de transactions d'approbation. Idéal pour les DEX et les portefeuilles, mais laisse souvent un appel de contrat ultérieur. L'ERC-677 réduit les étapes utilisateur en regroupant le transfert et l'exécution. EIP-2612 permit, Uniswap Permit2

• Abstraction de compte (EIP-4337) : permet aux portefeuilles et aux paymasters de regrouper plusieurs opérations et de sponsoriser le gaz, améliorant ainsi l'expérience utilisateur. L'ERC-677 complète l'AA en réduisant encore davantage les étapes côté protocole. Abstraction de compte EIP-4337

En bref : permit et l'AA réduisent les frictions du côté du portefeuille ; l'ERC-677 réduit les frictions en permettant au transfert de jeton lui-même de déclencher la logique du contrat intelligent.

Considérations pour les développeurs et sécurité

Avec les rappels à la réception des jetons, la prudence est essentielle :

• Réentrance : le contrat de jeton appelle la logique du destinataire. Si les destinataires rappellent le jeton ou d'autres contrats externes, vous pouvez introduire des vulnérabilités de réentrance. Utilisez des modèles de vérifications-effets-interactions ou des gardes si nécessaire. SWC-107 Réentrance, OpenZeppelin ReentrancyGuard

• Valider l'expéditeur et le jeton : assurez-vous que les contrats destinataires vérifient que msg.sender est égal au contrat de jeton de confiance et validez l'adresse du jeton si plusieurs jetons sont pris en charge.

• Listes blanches : envisagez de mettre sur liste blanche les contrats destinataires autorisés (ou de valider les interfaces) pour les jetons où le rappel peut effectuer des opérations sensibles.

• Conception des événements : l'émission d'événements riches aide à l'indexation et à l'analyse. Maintenez des événements Transfer compatibles ERC-20 aux côtés de données spécifiques à l'ERC-677 lorsque cela est possible pour la compatibilité des outils.

• Sécurité du fallback : si le destinataire n'implémente pas le rappel attendu, le transfert doit être annulé ou suivre un chemin d'échec sûr et explicite pour éviter une perte de fonctionnalité « silencieuse ».

• Gaz et modes d'échec : le rappel peut échouer ; gérez les échecs avec des messages d'erreur clairs et assurez-vous que les utilisateurs comprennent si le transfert a réussi ou si l'intégralité de la transaction a échoué.

Pour la sécurité générale des contrats intelligents, la documentation de Solidity sur les considérations de sécurité reste une lecture essentielle. Considérations de sécurité de Solidity

Expérience utilisateur du portefeuille : pourquoi c'est important pour les utilisateurs

En supprimant la séquence « approuver puis appeler », l'ERC-677 peut donner l'impression que des interactions complexes sont une seule action ciblée. Cela réduit la fatigue des signatures, diminue la charge cognitive et permet souvent d'économiser du gaz. Cependant, la transaction unique est plus riche : vous transférez des jetons et exécutez une logique de contrat. Cela nécessite des aperçus clairs, une simulation et des données d'appel lisibles de la part des portefeuilles.

Si vous êtes un utilisateur soucieux de la sécurité interagissant avec des protocoles utilisant l'ERC-677, l'utilisation d'un portefeuille matériel qui affiche les noms de fonctions, les paramètres et les changements de valeur estimés de manière lisible peut vous aider à signer en toute confiance.

Contexte 2025 : adoption et composabilité

En 2025, la tendance se poursuit vers le regroupement du transfert de valeur et de l'exécution des intentions :

• De plus en plus de protocoles préfèrent les dépôts, les échanges ou les paiements de services en « un clic » qui semblent natifs et réduisent l'encombrement des approbations.
• Les cadres cross-chain mettent l'accent sur les mouvements de jetons programmables et les charges utiles de messages – les sémantiques similaires à l'ERC-677 s'intègrent bien à ces architectures. Voyez comment CCIP formalise les messages programmables aux côtés du transfert de jetons pour les cas d'utilisation cross-chain. Qu'est-ce que CCIP

Attendez-vous à un plus grand soutien des portefeuilles et des middlewares pour simuler les flux de rappel, signaler les risques et fournir des invites intelligibles qui rendent les opérations combinées de transfert et d'exécution plus sûres.

Esquisse d'interface minimale

Conceptuellement, l'ERC-677 ressemble à ceci (les implémentations peuvent varier légèrement) :

interface IERC677 {
    function transferAndCall(address to, uint256 value, bytes calldata data) external returns (bool);
    event Transfer([address](https://onekey.so/blog/fr/ecosystem/what-is-a-crypto-wallet-address/) indexed from, [address](https://onekey.so/blog/fr/ecosystem/what-is-a-crypto-wallet-address/) indexed to, uint256 value, bytes data);
}

interface IERC677Receiver {
    function onTokenTransfer([address](https://onekey.so/blog/fr/ecosystem/what-is-a-crypto-wallet-address/) sender, uint256 value, bytes calldata data) external;
}

Le contrat de jeton appelle onTokenTransfer sur le destinataire immédiatement après le transfert de la valeur, permettant au destinataire de réagir en une seule transaction.

Conseils pratiques

• Pour les développeurs de protocoles : Documentez clairement les interfaces de rappel attendues et les raisons d'annulation. Le cas échéant, publiez des listes blanches ou des vérifications d'interface afin que les intégrateurs puissent vérifier le comportement.
• Pour les intégrateurs : Simulez transferAndCall pour prévisualiser les changements d'état post-rappel. Signalez les destinataires risqués ou les rappels inconnus aux utilisateurs.
• Pour les utilisateurs : Préférez les protocoles de confiance et inspectez les aperçus de transaction. Si votre portefeuille prend en charge le décodage lisible, prenez un moment pour examiner les paramètres passés au rappel.

Devriez-vous utiliser l'ERC-677 ?

Utilisez l'ERC-677 lorsque :

• Vous souhaitez éliminer le modèle « approuver + appeler » pour les flux d'utilisateurs principaux.
• Le protocole bénéficie d'une réaction immédiate et atomique à la réception des jetons.
• Vous pouvez renforcer les rappels des destinataires contre la réentrance et valider minutieusement les sources de jetons.

Si votre cas d'utilisation est purement axé sur l'approbation (par exemple, permettre à un DEX de dépenser des jetons plus tard), EIP-2612 ou Permit2 pourraient suffire. Si vous avez besoin de sémantiques de hook plus riches sur de nombreux destinataires, évaluez l'ERC-777 mais soyez conscient de sa complexité.

Une note pour les utilisateurs de OneKey

Les transactions ERC-677 combinent un transfert de jeton avec un appel de contrat. Lors de la signature, il est utile de voir exactement quelle fonction sera exécutée et avec quels paramètres. L'approche open-source de OneKey et son support EVM visent à fournir des aperçus d'appel transparents et une signature fiable pour les interactions avancées comme transferAndCall, afin que les utilisateurs expérimentés puissent maintenir une sécurité solide tout en profitant d'une expérience utilisateur rationalisée.

En comprenant l'ERC-677 et en utilisant un portefeuille qui présente clairement les détails de la transaction, vous pouvez bénéficier en toute sécurité d'interactions de contrats intelligents plus simples, en une seule transaction.