ERC-7683 évolue, et de nombreuses explications décrivent encore une version antérieure de la norme. Le projet actuel d’ERC-7683 est plus centré sur les résolveurs. Au lieu d’imposer à chaque protocole d’intention cross-chain un contrat de dépôt partagé, un système de vente aux enchères, un mécanisme de règlement, un modèle d’autorisation ou une fonction de remplissage de destination unique, les protocoles peuvent conserver leur propre architecture d’exécution tout en exposant leurs ordres aux solveurs via une couche de résolution commune. Cette distinction est cruciale. Une commande ERC-7683 est essentiellement une offre de paiement en échange de la satisfaction d’un ensemble défini de conditions. Les solveurs, également appelés remplisseurs, évaluent ces conditions, déterminent l’exécution nécessaire, engagent du capital ou du gaz, et s’attendent à un paiement s’ils remplissent correctement l’ordre. La conception actuelle permet à un protocole d’exposer une charge utile opaque et spécifique au protocole accompagnée d’un contrat résolveur. Ce résolveur traduit la charge utile en une représentation commune contenant : • des étapes d’exécution • des variables • des paiements • des hypothèses explicites Cela donne aux solveurs programmables un moyen standardisé de comprendre ce qu’exige réellement une commande, sans que chaque solveur doive implémenter une logique entièrement sur mesure pour chaque protocole d’intention. Le modèle d’exécution résolu peut exposer des exigences de dépense de jetons, des exigences de gaz, des contraintes temporelles, des dépendances et un comportement d’annulation. Les variables peuvent représenter des adresses de paiement des solveurs, des chaînes de paiement, des sorties d’exécution, des appelants d’étapes, des témoins hors chaîne, des requêtes de contrat et des requêtes d’événements. ERC-7683 intègre également des représentations d’adresses interopérables via ERC-7930, liant le contexte de chaîne à l’adresse au lieu de s’appuyer uniquement sur une adresse EVM conventionnelle de 20 octets. Mais il existe une limite de sécurité importante. La standardisation ERC-7683 ne rend pas automatiquement le protocole d’intention sous-jacent sûr. Les contrats de règlement, les ponts, les systèmes de transmission de messages, les jetons, les mécanismes de vente aux enchères, les services hors chaîne, les oracles, les verrous de ressources, la protection contre les rejeux, la logique d’annulation, le comportement de remboursement et le remplissage partiel restent des risques spécifiques au protocole, à moins qu’ils ne soient explicitement représentés par les exigences ou hypothèses résolues. La sécurité du résolveur est donc cruciale. Un résolveur doit valider correctement sa charge utile spécifique au protocole et exposer une représentation permettant à un solveur agissant correctement de comprendre ce qui doit se produire et dans quelles hypothèses le paiement deviendra disponible. Un résolveur correct ne peut pas rendre un système de règlement insécure sécurisé. Et un format d’ordre conforme n’élimine pas le risque pour le solveur. Un remplisseur devient économiquement exposé dès qu’il engage des autorisations, du gaz, du capital ou des transactions jusqu’à ce que son paiement attendu devienne final et utilisable. Pour les utilisateurs, les points clés de vérification restent pratiques : • chaîne d’origine • actif d’entrée • chaîne de destination • destinataire • sortie attendue • date limite • portée d’autorisation • transaction ou données typées signées ERC-7683 s’intègre naturellement dans des systèmes d’intention plus larges tels que le Open Intents Framework, mais les deux ne sont pas interchangeables. ERC-7683 est principalement une couche de standardisation pour la résolution d’ordres orientée solveurs. OIF est un cadre d’infrastructure plus large couvrant l’origine des intentions, la résolution, l’exécution, le règlement, l’agrégation et les composants associés. Notre dernière recherche sur TokenToolHub décortique la conception actuelle d’ERC-7683, ses différences avec les versions antérieures, le cycle de vie des ordres, les remplisseurs, la sécurité des résolveurs, les étapes d’exécution, les paiements, les hypothèses, les adresses interopérables et les risques pour les solveurs qui restent en dehors du standard lui-même. Analyse complète : https://t.co/VK5Yb4wvJ3