Une intention est un ordre qui dit quel résultat vous voulez obtenir, et non quelles transactions envoyer. Vous la signez, des solveurs en concurrence se disputent la livraison du résultat, et une couche de règlement paie celui qui l'a fait. Le routage, le gas et l'attente entre chaînes passent ainsi de l'utilisateur à une contrepartie professionnelle, et une autre série de questions apparaît : qui a le droit d'enchérir, à quelle aune on le mesure, ce qui garantit sa promesse, et ce que devient votre argent quand personne n'enchérit.
Ordres déclaratifs : ce qu'est vraiment une intention
Une transaction ordinaire est impérative. Elle nomme le contrat, la fonction, les arguments et le gas, et la signer autorise exactement un chemin de calcul sur un état donné. Tout est décidé avant la signature, et tout ce qui n'a pas été prévu est votre problème.
Une intention est déclarative. C'est un ensemble signé de contraintes décrivant le résultat que vous acceptez, et elle autorise n'importe quel chemin d'exécution qui les respecte. La transaction dit « fais A puis B, paie exactement C et reçois X » ; l'intention dit « je veux X et je suis prêt à payer au plus C ». Vue ainsi, la transaction est le cas particulier d'une intention qui n'autorise qu'une seule transition d'état.
La conséquence pratique est qu'en signant et en diffusant une intention, vous accordez à un tiers la permission de choisir le chemin de calcul à votre place. C'est de là que vient le confort, et c'est de là que vient aussi chaque risque décrit ici.
Rien de tout cela n'est nouveau par nature. Les ordres à cours limité, le paiement des frais avec un jeton que l'on détient déjà, les agrégateurs qui promettent la meilleure route entre plusieurs marchés ont tous la forme d'une intention : l'utilisateur pose une condition, quelqu'un d'autre choisit l'exécution. Ce qui est nouveau, c'est qu'on en fait une infrastructure générale et qu'un même ordre peut couvrir plusieurs chaînes.
Les quatre rôles d'un système d'intentions
Écrit comme un cycle de vie, le schéma comporte quatre parties. Un utilisateur exprime une intention à une application ; l'application la transforme en un ordre destiné à un protocole précis ; l'ordre rejoint un flux d'ordres où les solveurs le voient ; un solveur l'évalue, exécute les étapes requises, et une procédure de règlement paie le solveur.
Le vocabulaire vaut la peine d'être appris, car il figure désormais dans une norme. Un ordre est une offre de paiement en échange de la satisfaction d'un ensemble d'exigences. Un solveur, appelé aussi filler, est l'acteur qui satisfait ces exigences. Le paiement referme la boucle : le solveur travaille d'abord et n'est payé qu'au règlement.
La norme en question est l'ERC-7683, les intentions entre chaînes (Cross Chain Intents). C'est un ERC de la voie Standards Track, créé en avril 2024, et au moment où ces lignes sont écrites il reste au statut Draft, c'est-à-dire brouillon. Il a par ailleurs été refondu en profondeur : un brouillon antérieur normalisait l'encodage des ordres, un flux d'ordres en chaîne, la mise sous séquestre et la fonction d'exécution, alors que le texte actuel ne normalise que l'interface par laquelle un solveur lit un ordre, en laissant chaque protocole libre sur la création des ordres, l'autorisation, le prix et le règlement. Il s'appuie sur l'ERC-7930, le format d'adresses interopérables, qui est au statut Review.
Le statut de brouillon pèse ici plus qu'ailleurs, car ce n'est pas la seule proposition du domaine : l'ERC-7521 traite des intentions générales pour les portefeuilles à contrat intelligent et reste lui aussi un brouillon. Ne tenez rien de tout cela pour acquis. Le champ de statut de chaque ERC figure en tête de sa page dans le dépôt des ERC d'Ethereum, et la discussion en cours se trouve dans le fil Ethereum Magicians qu'il indique, alors vérifiez vous-même l'étape actuelle.
Pourquoi c'est le solveur qui avance l'argent
Sous les intentions entre chaînes se cache un fait gênant : deux chaînes ne se règlent pas de façon atomique, quelqu'un doit bouger en premier. Dans le schéma courant, les fonds de l'utilisateur sont bloqués dans un contrat de la chaîne d'origine au moment où l'ordre est créé, afin que le solveur ait la certitude que l'argent existe avant d'engager son propre capital de l'autre côté.
Le solveur livre ensuite le résultat sur son propre stock : il détient l'actif sur la chaîne de destination, vous l'envoie, et n'est remboursé que plus tard sur les fonds bloqués, via la procédure de règlement. Dans un schéma déjà en production, les exécutions sont regroupées par lots et remboursées selon un cycle qui se compte en heures et non en secondes, et c'est pourquoi un solveur a besoin de fonds de roulement et pas seulement d'un robot rapide.
Les transactions sont elles aussi envoyées par le solveur, donc c'est lui qui paie le gas. Voilà le mécanisme derrière les parcours d'intention annoncés sans gas : le coût n'a pas disparu, il a été déplacé dans le prix que le solveur vous annonce.
Cet écart entre la dépense et l'encaissement est précisément là où loge le risque du solveur. La section sécurité de la norme le dit sans détour : un solveur est exposé dès l'instant où il engage du capital, des autorisations ou des transactions, et jusqu'à ce que le paiement attendu soit définitif et disponible. Tout ce qui peut mal tourner dans cette fenêtre, réorganisation de chaîne, acheminement des messages, protocole qui change d'état, est déjà intégré au prix que vous voyez.
Comment la concurrence fixe le prix que vous obtenez
Puisque l'utilisateur ne précise plus la route, le prix doit être produit par la concurrence. Les conceptions diffèrent sur la manière : certaines lancent des enchères hollandaises où le seuil à battre se déplace dans le temps, d'autres tirent le prix d'un oracle, d'autres fixent les frais et laissent les solveurs ne se battre que sur la vitesse.
Les enchères par lots en sont la version la plus explicite. Les ordres sont collectés pendant une courte fenêtre, les solveurs soumettent des solutions complètes, chaque solution est notée à peu près selon le surplus qu'elle procure aux utilisateurs du lot, et la mieux notée l'emporte. Les gagnants sont payés selon une règle de second prix : la récompense tient à l'écart avec la meilleure offre suivante, et non à ce que le gagnant a lui-même déclaré.
La concurrence n'aide que s'il existe une référence. Un corpus de règles publié exige que les prix d'un solveur ne soient pas moins bons que ce que l'utilisateur aurait obtenu auprès d'une liste définie de sources de liquidité de référence, et exige des prix de règlement uniformes : deux ordres sur la même paire et dans le même sens doivent recevoir le même prix. Sans quelque chose de ce genre, la meilleure exécution signifie ce que le solveur gagnant veut bien lui faire dire.
C'est aussi la réponse honnête à la question de savoir pourquoi les intentions peuvent battre un routage manuel. Un solveur peut compenser votre ordre avec l'ordre inverse d'un autre utilisateur, empaqueter plusieurs exécutions dans une seule transaction et choisir pour son remboursement la chaîne qui lui coûte le moins. Les économies sont réelles, mais elles ne vous parviennent que dans la mesure où la concurrence et la règle de notation l'imposent.
Ce qui garantit réellement la promesse du solveur
Signer une intention, c'est donner de la latitude à quelqu'un. Ce qui empêche les abus n'est pas la signature, c'est la couche de responsabilité bâtie autour de l'ensemble des solveurs, et cette couche diffère dans chaque système, ce que la plupart des explications passent sous silence.
Le premier garde-fou est en général l'entrée. Dans un corpus de règles publié, un solveur doit figurer sur une liste blanche avant même de pouvoir soumettre un règlement ; les opérateurs font tourner une surveillance qui inspecte chaque règlement en chaîne et signale les cas suspects ; une violation systématique des règles peut être sanctionnée, jusqu'au slashing.
Le deuxième garde-fou est la vérification assortie d'une fenêtre de contestation. Plutôt que de prouver chaque exécution en chaîne, un schéma de règlement laisse un acteur proposer un lot de résultats accompagné d'une garantie, lot accepté si personne ne le conteste dans un délai fixe. L'utilisateur obtient la vitesse tout de suite ; la preuve vient après.
Le troisième garde-fou est la frontière de confiance elle-même, et la norme dit avec une franchise inhabituelle où elle s'arrête. L'ERC-7683 normalise la façon dont un ordre est décrit aux solveurs ; il ne normalise ni ne garantit la sécurité du protocole qui finit par le régler. Les solveurs sont censés auditer eux-mêmes le contrat qui leur traduit les ordres et valider les hypothèses que ce contrat ne peut pas vérifier seul. À l'utilisateur, la norme ne promet rien sur le système de règlement situé en dessous.
Concentration, censure et le chemin de retour de votre argent
Le risque structurel du modèle par intentions, c'est que l'ensemble de ceux qui voient votre ordre et peuvent l'exécuter devienne étroit. Si l'accès au flux d'intentions est sur autorisation et que la liste est choisie sans soin, le flux d'ordres se concentre, et celui qui en contrôle une large part est en mesure de prélever une rente et, à l'extrême, de censurer.
La diffusion ouverte ne règle pas cela toute seule. Un noeud capable d'exécuter une intention avec profit n'a aucun intérêt à la transmettre à ses concurrents, et un réservoir d'intentions entièrement public expose les ordres à la même extraction qu'un mempool public. C'est pourquoi tant de systèmes finissent sur des conceptions sur autorisation ou hybrides, et pourquoi la vraie question n'est pas de savoir si c'est décentralisé, mais qui est sur la liste et qui en décide.
Le coût associé est l'opacité. Dans la pire version, vous signez quelque chose, cela disparaît, puis réapparaît sous la forme d'une transaction sans qu'on voie qui l'a construite ni quelles solutions ont été écartées. Une qualité d'exécution que l'on ne peut pas auditer est une qualité d'exécution acceptée sur parole.
Vient ensuite l'échec le plus banal, plus fréquent que les cas exotiques : personne n'enchérit. Les ordres portent une échéance d'exécution. Si elle passe sans exécution et sans exécution partielle, l'ordre expire et les fonds bloqués repartent, en général vers l'adresse indiquée dans l'ordre et, par défaut, sur la chaîne d'origine. Les causes sont prosaïques : un montant inhabituellement gros, une paire de jetons rare, ou des solveurs brièvement hors service.
Ce remboursement, en revanche, n'a rien d'immédiat. L'argent revient par la même procédure de règlement par lots qui paie les solveurs, si bien qu'une exécution normale prend quelques secondes quand une expiration peut mettre des heures à se dénouer. Quand vous dimensionnez un ordre ou construisez un produit par-dessus, l'échéance d'exécution et la voie de remboursement sont les deux paramètres à lire avant les frais.
Conclusion
Les intentions déplacent le travail d'exécution de l'utilisateur vers un enchérisseur : vous signez le résultat voulu, les solveurs se disputent sa livraison, ils avancent le capital et le gas, et une couche de règlement paie celui qui a tenu. Le gain d'efficacité est réel et l'échange l'est tout autant, car vous confiez à un tiers le pouvoir d'apprécier comment votre ordre est exécuté, et ce qui vous protège n'est pas la signature, mais les règles de l'enchère, la référence à laquelle ces offres sont notées, les conditions d'entrée et la surveillance autour de l'ensemble des solveurs, et l'échéance qui vous rend vos fonds quand personne n'enchérit. La norme d'ordres entre chaînes, l'ERC-7683, reste un brouillon et a déjà été repensée une fois : traitez toute description de celle-ci, y compris la présente, comme un instantané, et vérifiez son champ de statut avant de bâtir dessus.
Articles associés
Autres articles Bitbase sur ce sujet :
- Modèles de ponts : verrouillage, destruction et émission native
- Qu'est-ce que Hyperlane, l'interopérabilité sans autorisation
- Ponts de stablecoins : déplacer des dollars entre chaînes
Avertissement : Cet article est un contenu pédagogique de Bitbase Academy, fourni à titre d'information uniquement. Il ne constitue pas un conseil en investissement, en trading, en fiscalité ou en finance. Les cryptoactifs sont volatils ; évaluez votre propre risque. Rédigé en août 2026 ; référez-vous aux informations officielles les plus récentes.
Sources
[1] ERC-7683: Cross Chain Intents eips.ethereum.org
[2] ERC-7930: Interoperable Addresses eips.ethereum.org
[3] ERC-7521: General Intents for Smart Contract Wallets eips.ethereum.org
[4] Intent-Based Architecture and Their Risks paradigm.xyz
[5] What are Crosschain Intents? docs.across.to
[6] Intent Lifecycle in Across docs.across.to
[7] Refunds docs.across.to
[8] Solver competition rules docs.cow.fi
