Pourquoi certaines blockchains masquent ce que vous signez

Lorsque vous validez une transaction crypto sur un hardware wallet, deux situations se présentent : soit vous lisez un résumé clair en français de ce qui va se passer, soit vous signez une suite de codes hexadécimaux incompréhensibles en espérant que tout se passe bien. La signature à l’aveugle consiste à approuver une transaction numérique sans pouvoir en vérifier tous les détails dans un format lisible par l’humain.
 

  In February 2025, blind signing contributed to the  $1.5 billion Bybit hack , the largest crypto theft in history. The attackers didn't break any cryptography. They exploited the fact that human signers couldn't distinguish a routine transfer from a malicious contract upgrade.   Whether your wallet can show you a clear, readable summary before you sign isn't a question of software quality. It comes down to how each blockchain was designed at the protocol level. Some chains were built so that transactions describe themselves. Others hide critical details inside binary blobs that require external information to decode. This article explains how those design decisions break down across the major blockchains and what it means for your security.   The Three-Tier Framework Clear Signing is a security process that lets you verify the full details of a digital transaction in a human-readable format on a secure screen before approving it.  Across 13 major blockchain ecosystems, clear signing support falls into three distinct tiers based on protocol architecture. This isn't about which chains are good or bad, it's about design tradeoffs made years ago, often before the security implications were fully understood.     Tier 1: Built for Transparency These blockchains make clear that signing is a natural outcome of their design. The core reason: they use a finite set of typed transaction structures where every field has a name, a type, and a defined schema. A hardware wallet doesn't need any external information to parse them, the transaction tells you what it is.   The

Le cadre des trois niveaux

La signature claire est un processus de sécurité qui vous permet de vérifier l’ensemble des détails d’une transaction numérique dans un format lisible sur un écran sécurisé avant de l’approuver. 

Dans 13 grands écosystèmes blockchain, la prise en charge de la signature claire se répartit en trois niveaux distincts selon l’architecture du protocole. Il ne s’agit pas de juger quelles chaînes sont « bonnes » ou « mauvaises », mais des compromis de conception faits il y a des années, souvent avant que les implications en matière de sécurité ne soient pleinement comprises.

Niveau 1 : conçu pour la transparence

Ces blockchains rendent la signature claire possible par conception. La raison principale : elles utilisent un ensemble fini de structures de transactions typées où chaque champ possède un nom, un type et un schéma défini. Un hardware wallet n’a pas besoin d’informations externes pour les analyser : la transaction indique elle-même ce qu’elle représente.

Le XRP Ledger offre probablement l’approche la plus aboutie et transparente parmi les grandes chaînes. Son format binaire inclut un champ TransactionType qui garantit un décodage déterministe sur plus de 50 types de transactions : Payment, OfferCreate, TrustSet, EscrowCreate, etc. Chaque champ suit un schéma précis. Un hardware wallet peut afficher le destinataire, le montant, les frais, le mémo et tous les paramètres spécifiques sans avoir à consulter une source externe. Près de 100 % des transactions mainnet actuelles peuvent être signées de façon totalement transparente.

Polkadot a développé la solution de signature claire la plus sophistiquée du secteur avec son système de métadonnées d’exécution (MetadataV14/V15). Chaque transaction référence des indices de « pallet » et d’appel, et les métadonnées permettent de comprendre précisément leur signification et comment décoder les arguments. Le défi : l’ensemble des métadonnées dépasse 200 Ko, trop volumineux pour la mémoire limitée des hardware wallets. 

La solution, RFC-0078 (Merkleized Metadata), construit un arbre cryptographique à partir des métadonnées, ne transmet que la partie nécessaire et vérifie la preuve d’inclusion on-chain. Résultat : une seule application Ledger fonctionne sur tous les parachains Polkadot sans mise à jour spécifique à chaque chaîne.
 

Cosmos utilise une architecture de messages typés et la norme SIGN_MODE_TEXTUAL (ADR-050), introduite dans Cosmos SDK v0.50, qui affiche les transactions sous forme lisible et adaptée aux petits écrans. Les montants apparaissent comme « 2 ATOM » plutôt que « 2000000uatom ». NEAR Protocol va encore plus loin avec des noms de comptes lisibles comme « alice.near » et des arguments de fonction sérialisés en JSON, facilement affichables en clair par le wallet.
 

Niveau 2 : efficace pour le basique, limité pour le complexe

Six écosystèmes offrent une signature claire solide pour les opérations natives, mais perdent en transparence dès que des smart contracts interviennent. Le cas de Bitcoin est emblématique. Le modèle UTXO fait que les transactions brutes n’indiquent pas les montants entrants ; un hardware wallet ne peut pas calculer les frais sans informations supplémentaires sur les sorties précédentes. PSBT (BIP 174) résout ce problème pour les paiements standards (environ 90 % des transactions), mais les dépenses Taproot, les scripts complexes et le multisig avancé restent opaques.
 

Stellar illustre parfaitement cette frontière. Ses 26 types d’opérations classiques (Payment, ManageSellOffer, ChangeTrust) disposent de schémas fixes et s’affichent clairement sur hardware wallet. Mais les smart contracts Soroban, lancés en 2024, réintroduisent l’opacité façon EVM : les paramètres arrivent sous forme binaire encodée, nécessitant des connaissances spécifiques pour décoder, ce qui fait chuter la couverture de près de 95 % pour les opérations classiques à quasiment zéro pour Soroban. Algorand, Cardano, Aptos et Tezos suivent des schémas similaires : couverture native solide, mais lacunes importantes dès qu’on aborde la logique programmable complexe.
 

Niveau 3 : l’opacité fait partie de l’ADN

Trois écosystèmes ont fait des choix architecturaux qui rendent la signature claire quasi impossible, quel que soit le wallet utilisé. Comprendre pourquoi explique la présence systématique des avertissements de signature à l’aveugle sur presque toutes les interfaces DeFi.
 

Ethereum et toutes les chaînes compatibles EVM partagent le même problème : l’encodage ABI n’est pas auto-descriptif. Lors d’une interaction avec un smart contract, le champ « data » de la transaction contient un sélecteur de fonction de 4 octets (issu du hash du nom de la fonction), suivi de paramètres encodés sur 32 octets. Sans le fichier ABI JSON du contrat, il s’agit d’un flux hexadécimal illisible. Cet ABI n’est pas stocké on-chain : un hardware wallet ne peut pas savoir que 0xa9059cbb... signifie « transférer 1 000 USDC à 0xABC... » sans métadonnées externes.
Proxy contracts, which route execution to implementation contracts whose addresses can change, compound the problem, which is exactly how the Bybit hack was executed.
 

The industry's response to this is  ERC-7730 , a metadata standard created in 2024 that provides JSON files describing how to decode and display specific contract interactions. It works, but it requires someone to write and maintain that metadata for every contract you might ever interact with. It is, fundamentally, a patch applied to an architecture that wasn't built for transparency.   Solana

Solana est sans doute encore plus complexe. Les instructions de transaction contiennent un identifiant de programme et un tableau d’octets opaque sans ABI standardisé ; chaque programme définit son propre format de sérialisation. Le framework Anchor propose une approche semi-standard via des discriminateurs sur 8 octets, mais de nombreux programmes n’utilisent pas Anchor et ne publient pas leurs interfaces. Pour la DeFi, la majorité du volume de transactions Solana nécessite une signature à l’aveugle.

TON ajoute une couche supplémentaire de complexité avec l’exécution asynchrone : vous ne signez que le message initial, tout ce qui se produit ensuite dans les blocs suivants reste invisible au moment de la signature.

 À retenir

Le conseil le plus concret : sachez dans quel niveau se situe votre blockchain avant d’utiliser un hardware wallet pour la DeFi. Pour les chaînes de niveau 1, la signature claire fonctionne comme prévu. Pour le niveau 2, les transferts simples sont sûrs à signer, mais il faut redoubler de vigilance pour toute interaction complexe avec un smart contract. Pour le niveau 3, considérez chaque transaction DeFi avec une extrême prudence et vérifiez si la combinaison dApp/wallet prend en charge les métadonnées ERC-7730 avant de valider quoi que ce soit d’important.
 

Les fabricants de hardware wallets travaillent activement sur ces sujets. Le Generic Parser de Ledger lit les fichiers de métadonnées ERC-7730 et affiche les détails de la transaction sur l’écran sécurisé. 

L’approche Merkleized Metadata de Polkadot est sans doute la solution la plus élégante du secteur : sans confiance, vérifiée cryptographiquement et native au protocole. L’industrie progresse vers de meilleurs standards, mais les contraintes protocolaires des chaînes de niveau 3 ne disparaîtront pas.
 

La règle la plus simple : si votre wallet affiche un hash ou une suite d’octets hexadécimaux et vous demande de signer, considérez cela comme un signal d’alerte.

Ressources et lectures complémentaires

Les ressources suivantes approfondissent les protocoles et standards abordés dans cet article.