Pourquoi certaines blockchains masquent ce que vous signez

Lorsque vous validez une transaction crypto sur un hardware wallet, vous faites l’une de ces deux choses : soit vous lisez un résumé clair et lisible de ce qui va se passer, soit vous signez un bloc de code hexadécimal brut en espérant que tout se passe bien. La signature à l’aveugle consiste à approuver une transaction numérique sans pouvoir vérifier l’ensemble de ses détails dans un format compréhensible.
 

  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 modèle à trois niveaux

La signature claire est un processus de sécurité qui vous permet de vérifier tous les 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 savoir quelles chaînes sont « bonnes » ou « mauvaises », mais des choix 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 montrent que la signature claire découle naturellement de leur conception. La raison principale : elles utilisent un ensemble fini de structures de transaction typées, où chaque champ a un nom, un type et un schéma défini. Un hardware wallet n’a pas besoin d’informations externes pour les interpréter : la transaction indique ce qu’elle est.

Le XRP Ledger offre probablement l’exemple le plus abouti de signature claire 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 besoin d’informations supplémentaires. Près de 100 % des transactions sur le mainnet peuvent être signées de façon totalement transparente.

Polkadot a développé la solution de signature claire la plus avancée techniquement grâce à 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 indiquent précisément ce qu’ils signifient et comment décoder les arguments. Le défi : les métadonnées complètes dépassent 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 pertinente, 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 le standard SIGN_MODE_TEXTUAL (ADR-050), introduit dans Cosmos SDK v0.50, qui affiche les transactions sous forme lisible, adaptée aux petits écrans. Les montants apparaissent comme « 2 ATOM » au lieu de « 2000000uatom ». NEAR va encore plus loin avec des comptes lisibles comme « alice.near » et des arguments de fonction en JSON que le wallet peut afficher en texte clair.
 

Niveau 2 : efficace pour les opérations simples, limité sous pression

Six écosystèmes offrent une signature claire fiable pour leurs opérations natives, mais perdent cette transparence dès que des smart contracts sont impliqués. Bitcoin est le cas le plus parlant. Le modèle UTXO fait que les transactions brutes n’incluent pas les montants d’entrée : un hardware wallet ne peut pas calculer vos frais sans informations supplémentaires sur les sorties précédentes. PSBT (BIP 174) résout ce problème pour les paiements standards, couvrant environ 90 % des transactions typiques, mais les dépenses Taproot et les multisigs complexes restent opaques.
 

Stellar illustre parfaitement cette limite du niveau 2. Ses 26 types d’opérations classiques (Payment, ManageSellOffer, ChangeTrust) ont des schémas fixes et s’affichent parfaitement sur hardware wallet. Mais les smart contracts Soroban, lancés en 2024, ramènent l’opacité du modèle EVM : les paramètres sont des types binaires encodés qui nécessitent une connaissance spécifique du contrat pour être décodés, faisant 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 : excellente couverture pour les opérations natives, mais de grandes lacunes pour la logique programmable complexe.
 

Niveau 3 : l’opacité est structurelle

  Tier 3: Opacity Is Baked In Three ecosystems have architectural choices that make clear signing an uphill battle, regardless of how good the wallet software is. Understanding why helps explain why blind signing warnings exist on almost every major DeFi interface.   Ethereum and all EVM-compatible chains

Le problème central : l’encodage ABI n’est pas auto-descriptif. Lorsqu’on interagit avec un smart contract, le champ data contient un sélecteur de fonction sur 4 octets (les quatre premiers octets 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 deviner que 0xa9059cbb... correspond à « 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.
 

La réponse de l’industrie est  ERC-7730 , une norme de métadonnées créée en 2024 qui fournit des fichiers JSON décrivant comment décoder et afficher les interactions avec un contrat. Cela fonctionne, mais il faut que quelqu’un écrive et maintienne ces métadonnées pour chaque contrat avec lequel vous interagissez. C’est, fondamentalement, un pansement sur une architecture qui n’a pas été conçue pour la transparence.
 

Solana est encore plus complexe. Les instructions de transaction contiennent un programme ID 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-standardisée avec des discriminateurs sur 8 octets, mais beaucoup de programmes n’utilisent pas Anchor et ne publient pas leurs interfaces. Pour la plupart des interactions DeFi, la majorité du volume sur Solana nécessite une signature à l’aveugle. 

TON ajoute une difficulté supplémentaire avec l’exécution asynchrone : vous ne signez que le message initial, tout ce qui se passe 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 être vigilant et se renseigner avant toute interaction complexe avec un smart contract. Pour le niveau 3, traitez chaque transaction DeFi avec la plus grande prudence et vérifiez si la combinaison dApp/wallet prend en charge les métadonnées ERC-7730 avant d’approuver quoi que ce soit d’important.
 

Les fabricants de hardware wallets travaillent activement sur ce sujet. Le Generic Parser de Ledger lit les fichiers de métadonnées ERC-7730 et affiche les détails des transactions 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 avance vers de meilleurs standards, mais les contraintes structurelles 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 apportent un éclairage technique sur les protocoles et standards évoqués dans cet article.