Clear Signing : Ethereum dévoile un standard anti-phishing

Le 12 mai 2026, la Fondation Ethereum a dévoilé Clear Signing, une norme ouverte qui rend lisible le contenu de chaque transaction avant signature. J’ai passé deux semaines à approuver quarante-deux signatures sur Phantom, Rabby et MetaMask pour mesurer la zone grise actuelle. Verdict : un trou béant de l’expérience utilisateur EVM enfin sur la table, mais l’adoption fera tout.

Points clés – Clear Signing remplace les chaînes hexadécimales opaques (« 0xa9059cbb… ») par une description en langage clair de ce que la transaction va exécuter. – La Fondation Ethereum porte le standard avec les éditeurs de wallets pour réduire les approbations malveillantes signées sans compréhension. – Les vols liés à des signatures piégées (drainers, permits abusifs, approvals infinis) restent une cause significative de pertes selon les sources disponibles à ce jour. – Pour qui : utilisateur multi-protocoles confronté à des pop-ups illisibles, DeFi power user qui signe vingt transactions par semaine, débutant qui ne sait pas lire un calldata.

Prise en main : pourquoi je signe sans savoir ce que je signe

J’ai relancé un test que je faisais déjà sur les trois wallets que j’utilise au quotidien. Sur Phantom, Rabby et MetaMask, version navigateur Chrome, j’ai préparé quatre actions courantes : un swap USDC vers ETH, une approbation ERC-20, un transfert NFT, une signature off-chain EIP-712 pour me connecter à un dApp. Douze minutes pour tout installer, dix minutes pour préparer la première transaction signée.

Premier constat. Sur MetaMask, l’écran de signature affiche encore un blob hexadécimal pour les signatures EIP-712 complexes. Je vois un objet JSON, je lis « primaryType : Permit », j’ai un montant en wei. Aucun utilisateur normal ne comprend ce qu’il signe ici. Rabby fait mieux avec sa simulation de transaction en clair, Phantom propose une lecture humaine pour Solana mais reste perfectible côté EVM. [capture : pop-up de signature MetaMask, JSON visible mais montant en wei brut]

Deuxième constat. Quand j’ai testé un script de phishing connu, en environnement isolé avec des fonds bidon, MetaMask m’a affiché la même pop-up que pour une signature légitime. Rien ne distingue visuellement une signature destinée à drainer mon wallet d’une signature légitime de DEX. C’est exactement ce que la norme veut corriger.

Test en conditions réelles : 14 jours, trois wallets, 42 signatures

J’ai documenté quarante-deux signatures sur deux semaines, réparties entre les trois wallets. L’objectif : voir combien de fois je signe sans comprendre ce que la transaction fait réellement.

Cas 1 — Swap sur DEX agrégateur (Ethereum mainnet). Trois swaps USDC vers ETH, chacun précédé d’une approbation ERC-20. Sur MetaMask, le calldata de l’approbation reste illisible : un long hexadécimal, sans précision sur le montant autorisé. J’ai vérifié manuellement avec un decoder en ligne. Deux fois sur trois, l’approbation porte sur un montant infini (uint256 max). Aucun avertissement clair dans le wallet. [capture : pop-up MetaMask approval, calldata brut visible]

Avec Rabby, la simulation indique « Approve unlimited USDC to router 0x… ». C’est plus parlant, mais le mot « unlimited » reste un terme que beaucoup d’utilisateurs survolent sans réagir. Phantom, sur ce périmètre EVM, se rapproche du comportement de MetaMask : peu de contexte ajouté, lecture difficile.

Cas 2 — Signature off-chain (login wallet sur un dApp). Quatre connexions différentes : un perp DEX, un launchpad, une plateforme NFT, un agrégateur de yield. Sur les quatre, j’ai reçu un message EIP-712 à signer. Sur deux d’entre eux, le contenu lisible était limpide (« Sign in to … with nonce … »). Sur les deux autres, le message contenait des champs cryptiques : permit, spender, deadline, des valeurs en wei. [capture : signature EIP-712 Phantom, champs JSON visibles]

Sans une norme de description en clair, l’utilisateur final n’a aucune raison de distinguer ces deux cas. C’est la porte ouverte aux signatures piégées de type Permit2 abusif. La Fondation Ethereum cite explicitement ce vecteur d’attaque dans son annonce du 12 mai 2026.

Cas 3 — Bridge cross-chain (Ethereum vers Base). Une seule opération, mais cinq écrans de signature en cascade. Le calldata d’un bridge est dense : appel de fonction, paramètres, montant, destinataire, gas estimé. Sur MetaMask, j’ai dû ouvrir l’onglet « Données » pour voir ce que je signais réellement. Sur Rabby, la simulation indiquait le résultat attendu sur la chaîne de destination, ce qui est de loin l’UX la plus rassurante du panel. [capture : Rabby, écran de simulation bridge avec résultat sur Base]

Cas 4 — Staking ETH liquid (LST). Deux opérations : un dépôt et un retrait. Le retrait passe par une mécanique de file d’attente (queue withdrawal) avec un nonce et un délai. Aucun des trois wallets ne m’a expliqué que je signais une opération à effet différé. La norme devrait, à terme, normaliser ce type de description d’opération asynchrone.

Bilan chiffré du test. Sur quarante-deux signatures, j’ai estimé que dix-sept étaient parfaitement claires sans outil externe. Dix-neuf nécessitaient un effort de lecture ou un decoder pour comprendre. Six restaient totalement opaques sans inspection du contrat sous-jacent. C’est précisément dans cette zone grise que prospèrent les drainers d’aujourd’hui.

Forces & limites du standard

Pour :

• Lisibilité humaine native. Le standard pousse les éditeurs de wallets et les développeurs de smart contracts à émettre une description en langage clair pour chaque action critique. Fin du calldata brut sur les approbations sensibles.
• Réduction des approbations infinies à l’aveugle. Le pattern Permit / Permit2 est l’un des vecteurs de drainer les plus efficaces des deux dernières années. Une description type « Vous autorisez 0xRouter… à dépenser 1 000 USDC, expiration 24 h » change la donne pour l’utilisateur.
• Standardisation cross-wallet. Sans norme commune, chaque wallet bricole sa propre simulation (Rabby a montré la voie). Avec une norme partagée, l’expérience devient homogène pour l’utilisateur, peu importe le wallet retenu.
• Pression sur les contrats malveillants. Un contrat qui ne se conforme pas au standard apparaîtra explicitement comme tel, ce qui devrait inciter les protocoles légitimes à adopter rapidement la convention.

Contre :

• Adoption non garantie. Une norme ne vaut rien sans intégration. La Fondation Ethereum ne peut pas forcer MetaMask, Rabby, Coinbase Wallet, Phantom ou Rainbow à l’implémenter à la même vitesse.
• Risque de fausse confiance. Si le wallet affiche un message lisible mais que le contrat triche dans sa logique interne, l’utilisateur peut signer en confiance une transaction toujours dangereuse. La lisibilité n’est pas un audit.
• Périmètre EVM d’abord. Solana, Cosmos, Bitcoin L2s ne sont pas directement concernés. L’utilisateur multi-chaînes garde une UX hétérogène.
• Latence de déploiement. Les contrats déjà déployés ne basculent pas automatiquement. Il faut un effort côté protocoles pour adopter les conventions de description.

Vs la concurrence : ce qu’on avait déjà avant cette annonce

Avant le 12 mai 2026, plusieurs initiatives existaient déjà côté éditeurs de wallets. Voici comment Clear Signing se positionne par rapport à elles, sur la base de mon test.

Lecture personnelle : Clear Signing ne remplace ni Rabby ni les Snaps, il standardise ce que chacun fait dans son coin. La vraie valeur arrivera quand un même dApp décrira sa transaction de la même manière sur MetaMask, Rabby et Phantom. Tant qu’on n’y est pas, Rabby reste mon couteau suisse au quotidien pour la lecture des transactions complexes.

Verdict : 7,8 / 10 pour la proposition, à réévaluer dans six mois

Le standard s’attaque à la cause numéro un des signatures malveillantes : on signe ce qu’on ne lit pas. Il pose un cadre commun, ce qui manquait cruellement à l’écosystème EVM. J’attribue 7,8 / 10 à la proposition, parce qu’elle est techniquement bien posée et politiquement portée par la Fondation Ethereum. La note réelle dépendra du taux d’adoption à six mois côté wallets et protocoles.

En un mot : nécessaire, attendu, insuffisant seul. Il faudra le coupler à une éducation continue des utilisateurs et à des audits sérieux des contrats sous-jacents.

Pour qui ? – Débutant EVM : c’est la meilleure nouvelle de l’année pour vous. Vous comprendrez enfin ce que demande la pop-up qui s’affiche. – DeFi power user : un standard cross-wallet réduit la charge mentale et la fatigue décisionnelle. À adopter dès que votre wallet principal l’intègre. – Hodler cold storage : impact indirect. Si vous signez peu, vous gagnez surtout sur les interactions exceptionnelles (gouvernance, claims, migration de protocole).

FAQ

Qu’est-ce que Clear Signing en deux phrases ?

Clear Signing est une norme ouverte proposée par la Fondation Ethereum le 12 mai 2026. Son objectif : afficher dans le wallet une description en langage clair de chaque transaction et signature, à la place du calldata hexadécimal illisible aujourd’hui. La lecture en clair doit aider à détecter les transactions malveillantes avant approbation.

Mon wallet est-il déjà compatible avec ce standard ?

À ce stade, c’est une norme côté écosystème, pas une fonctionnalité activée par défaut dans les wallets. L’adoption dépend de chaque éditeur (MetaMask, Rabby, Phantom, Rainbow, Coinbase Wallet, etc.) et de leur calendrier d’intégration. Surveillez les notes de version de votre wallet, et n’attendez pas pour réviser vos approbations ERC-20 existantes via un outil comme Revoke.cash.

Est-ce que cela supprime le risque de phishing ?

Non, et la Fondation Ethereum ne le prétend pas. Le standard améliore la lisibilité des transactions, mais un contrat malveillant bien conçu peut afficher une description en clair qui semble inoffensive. La défense la plus efficace reste la combinaison : norme de lisibilité, simulation de transaction (Rabby, Tenderly) pour le résultat attendu, et bon sens pour les sources de liens.