Une transaction SUAVE typique ne démarre pas dans un mempool, mais par une intention. Cette intention peut correspondre à la volonté d’un utilisateur d’échanger un jeton, de placer une enchère sur un NFT, de participer à une liquidation ou de réaliser une opération inter-chaînes. Contrairement aux transactions traditionnelles, qui sont entièrement spécifiées et diffusées publiquement, une intention SUAVE est chiffrée et seulement partiellement définie. Cela offre aux solveurs la liberté de proposer les trajectoires d’exécution les plus optimales.
Après la signature et l’envoi de l’intention par l’utilisateur vers la Membrane SUAVE, celle-ci est chiffrée par la couche de confidentialité puis injectée dans un environnement sécurisé. Il s’agit d’une enclave d’exécution de confiance (TEE), d’un système de preuve à connaissance nulle ou d’un réseau d’enclaves sécurisées répliquées. L’intention y reste confidentielle jusqu’à son évaluation par le réseau de solveurs.
Les solveurs accèdent à un ensemble d’intentions chiffrées et s’affrontent dans une enchère universelle afin de proposer la meilleure exécution. Chacun soumet un chemin d’exécution complet accompagné d’une offre : cela peut être un rabais octroyé à l’utilisateur, un minimum garanti ou tout autre avantage objectivement mesurable. Pendant la durée de l’enchère, ces offres restent invisibles aux autres solveurs, garantissant ainsi l’équité.
Le MEVM, moteur d’exécution de SUAVE, évalue les solutions proposées et sélectionne le gagnant sur la base d’une logique programmable. Le lot d’exécution du solveur retenu est ensuite déchiffré, finalisé et acheminé vers la blockchain appropriée via la Membrane. La chaîne destinataire traite la transaction comme un lot standard ou une preuve d’inclusion, la finalise on-chain et retourne à SUAVE la confirmation correspondante.
À aucun moment, les données transactionnelles de l’utilisateur ne sont exposées au public. La finalité est assurée par la couche de règlement de la chaîne de destination, tandis que l’ordonnancement et la confidentialité relèvent de SUAVE.
L’écosystème SUAVE rassemble plusieurs profils d’acteurs, chacun jouant un rôle essentiel dans la dynamique globale. Maîtriser ces rôles est indispensable à toute personne envisageant de développer sur SUAVE ou d’y intégrer ses services.
Utilisateurs : ils constituent la source du flux d’ordres. Leur interaction avec des dApps ou des portefeuilles leur permet d’exprimer leurs intentions. SUAVE prend en charge les utilisateurs individuels autant que les protocoles soumettant des transactions pour leurs clients. Les utilisateurs gardent la maîtrise de leur intention et peuvent configurer leurs préférences, notamment la tolérance au slippage, la rapidité ou le niveau de confidentialité.
Solveurs : ces acteurs interprètent les intentions des utilisateurs et proposent des plans d’exécution adaptés. Ils décodent les intentions chiffrées à travers la couche de confidentialité et se disputent leur réalisation via des enchères. Il s’agit généralement d’arbitragistes, de routeurs de liquidité, de teneurs de marché ou de bots spécialisés. Leur rémunération dépend exclusivement de leur capacité à fournir l’exécution la plus bénéfique à l’utilisateur.
Builders : ils constituent des intermédiaires facultatifs, agrégeant plusieurs intentions résolues au sein d’un même lot. Alors que les solveurs peuvent soumettre directement leurs propositions à la Membrane, les builders peuvent optimiser l’efficacité du gaz, le réordonnancement ou la co-intégration de transactions multiples. Ils apportent un levier de scalabilité et de flexibilité, surtout pendant les périodes de forte activité.
Le MEVM : il arbitre et exécute la logique métier. Il examine les propositions des solveurs, impose les règles d’enchères et veille à ce que seules des solutions valides soient retenues. Les équipes de développement peuvent personnaliser la logique du MEVM, par exemple en donnant la priorité aux solveurs décentralisés, en fixant un rabais minimum garanti pour l’utilisateur, ou en imposant des preuves de liquidité inter-chaînes.
La Membrane : elle assure la liaison entre SUAVE et les chaînes tierces. Elle réceptionne les intentions, transmet les transactions finalisées et pilote la synchronisation des états. La Membrane gère également les permissions et la fourniture de preuves d’intégrité lors de règlements inter-chaînes.
Validateurs : dans ce contexte, leur rôle se limite à la chaîne de règlement. Ils n’ont aucune connaissance du fonctionnement interne de SUAVE et se contentent de traiter les lots finalisés. Cette singularité garantit la légèreté de SUAVE tout en évitant de transformer les couches de consensus.
SUAVE introduit une innovation clé : le concept de value router, à savoir des services assimilables à des smart contracts installés au sein du MEVM et dédiés à des catégories déterminées d’intentions. Un value router s’apparente à une dApp, mais se distingue en opérant sur des flux d’ordres privés, en amont de la chaîne, au lieu de traiter des transactions rendues publiques.
Pour concevoir un value router, le développeur organise trois volets :
Après déploiement dans le MEVM, le value router accepte les intentions transmises via la Membrane. Les solveurs s’y connectent par le biais d’une API unifiée et entrent en concurrence pour répondre aux requêtes. Parce que ces routers opèrent dans un environnement préservant la confidentialité, ils peuvent gérer de gros volumes de données sensibles sans révéler leurs stratégies d’exécution.
Les principaux usages des value routers incluent :
Le MEVM étant agnostique des chaînes, un même router peut opérer sur plusieurs réseaux, ce qui permet aux développeurs de mutualiser le code pour une audience mondiale.
L’un des objectifs phares de SUAVE est de rendre la résistance au MEV complètement transparente pour l’utilisateur final. Pour cela, les portefeuilles doivent intégrer SUAVE à la fois au niveau interface utilisateur et RPC. Plutôt que d’envoyer les transactions dans un mempool classique, le portefeuille les transmet via la Membrane et présente à l’utilisateur les options d’exécution issues des solveurs.
Concrètement, côté utilisateur, rien ne change : il clique sur « Échanger », « Mintrer » ou « Voter » comme d’habitude. Pourtant, sa transaction est, en coulisses, chiffrée, mise aux enchères puis exécutée par SUAVE. L’utilisateur profite de meilleurs taux, de confirmations plus rapides ou d’un rabais, sans avoir besoin de comprendre le fonctionnement technique sous-jacent.
Le portefeuille peut, en option, afficher une liste d’options de solveur, triées par prix, confidentialité ou vitesse. Les utilisateurs avancés peuvent ainsi personnaliser leur expérience, tandis que les utilisateurs occasionnels bénéficient des paramètres par défaut, optimisés pour l’équité. Les futurs SDK de portefeuilles proposés par Flashbots et d’autres acteurs tiers devraient simplifier encore davantage cet aspect.
Puisque SUAVE ne prend pas en charge le règlement des transactions, il doit fonctionner en parfaite synergie avec les blockchains externes. Cette contrainte apporte une certaine complexité mais ouvre également la voie à des processus avancés. Imaginons le cas d’un utilisateur qui souhaite :
Avec une architecture traditionnelle, cela impose plusieurs étapes, des validations manuelles et la confiance envers des relayeurs de pont. Avec SUAVE, toutes ces opérations sont encapsulées dans une seule intention. Les solveurs rivalisent pour satisfaire cette demande de la façon la plus efficiente possible. La solution optimale est retenue, réglée entre les chaînes puis notifiée à l’utilisateur en une seule signature.
L’obtention de cette composabilité multi-chaînes reste difficile avec les infrastructures existantes. SUAVE l’autorise en dissociant l’exécution du règlement, de sorte que les processus puissent être coordonnés avant d’être soumis séquentiellement à chaque réseau.
La question cruciale pour l’adoption reste : comment rémunérer efficacement les intervenants ? Solveurs, builders et relayeurs doivent trouver un intérêt à effectuer des calculs, participer aux enchères et router des transactions.
Sous SUAVE, les incitations sont programmables. Les solveurs déposent des offres présentant un paiement vers l’utilisateur (rabais), vers le système (commission) et vers la chaîne de règlement (frais de gaz). Ces paiements sont garantis au niveau du MEVM et ne sont validés qu’à la confirmation de la transaction par la couche de règlement.
Un système de réputation suit la performance des solveurs dans la durée. Les solveurs sous-performants, échouant ou produisant des slippages supérieurs aux seuils annoncés, peuvent être exclus des enchères ultérieures. Les utilisateurs peuvent également blacklister les solveurs dont le comportement serait jugé malveillant.
L’équilibre entre incitations et réputation constitue l’assise de la viabilité de SUAVE. Au lieu de s’appuyer sur l’altruisme ou la confiance, le système organise un marché dans lequel la conduite intègre devient la plus rentable.
Scénario :
Sarah souhaite acquérir un NFT proposé sur une marketplace Arbitrum, alors qu’elle ne détient que de l’ETH sur Ethereum Mainnet. Dans un schéma Web3 classique, elle devrait :
Ce flux est chronophage, multiplie les interfaces, expose Sarah au MEV ainsi qu’aux risques liés aux ponts, et entraîne d’importants frais de gaz sur Ethereum.
La question de la rémunération des participants reste inchangée : solveurs, builders et relayeurs doivent être incités à effectuer le calcul, à participer aux enchères et à router les transactions.
Dans SUAVE, les incitations sont programmables. Les solveurs proposent des offres prévoyant un paiement à l’utilisateur (rabais), au système (commission) et à la chaîne de règlement (gaz). Ces paiements sont validés au niveau du MEVM et ne sont finalisés qu’après règlement effectif.
Un système de réputation évalue la performance des solveurs dans le temps. Les underperformers, échecs ou slippages excessifs par rapport aux tolérances déclarées, sont écartés des futures enchères. Les utilisateurs peuvent aussi exclure les solveurs malveillants.
Cet équilibre entre incitations et réputation est fondamental pour la viabilité de SUAVE. Le système repose sur une incitation à la bonne conduite, qui s’avère la stratégie la plus rentable.
Étape 1 : Soumission de l’intention
Sarah utilise un portefeuille compatible SUAVE. Elle clique sur « Acheter un NFT » sur l’interface de la marketplace et approuve une intention unique :
Étape 2 : Confidentialité et enchère entre solveurs
Les solveurs reçoivent ce lot d’intentions. L’un d’eux propose :
Conversion ETH→USDC via la route MEV la plus optimisée sur Ethereum.
Étape 3 : Exécution et finalité
Cet exemple démontre comment SUAVE transforme une expérience multi-étapes et complexe en une exécution privée inter-chaînes en un clic, avec des coûts optimisés et des incitations intégrées. On retrouve les comportements familiers de la DeFi (swaps, ponts), enrichis par une exécution plus performante, ce qui rend la vision technique de SUAVE aussi intuitive qu’efficace dans un contexte réel.