Validateur d'adresses crypto

Ce que cet outil vérifie, et ce qu'il ne peut pas

Deux questions différentes se cachent derrière « cette adresse est-elle valide ». La première est de savoir si la chaîne de caractères est bien formée : bonne longueur, bon alphabet, checksum intact. Cette question a une réponse définitive, et cette page y répond dans votre navigateur sans envoyer l'adresse où que ce soit. La seconde est de savoir si l'adresse existe, détient un solde, ou appartient à la personne qui vous l'a donnée. Aucun vérificateur hors ligne ne peut répondre à cela, et tout outil qui prétend le faire lit une blockchain, pas la chaîne de caractères.

Cette distinction compte parce que les deux modes d'échec ne se ressemblent en rien. Une adresse mal formée est détectée ici et par tous les wallets, si bien qu'une faute de frappe dans une adresse TRON reste un désagrément plutôt qu'une perte. Une adresse bien formée mais appartenant à la mauvaise personne est invisible pour tout vérificateur jamais écrit.

TRON : Base58Check, vérifié jusqu'au checksum

Une adresse TRON compte 34 caractères et commence par T. Derrière cette chaîne se trouvent 25 octets : un octet de version, 20 octets d'adresse, et un checksum de 4 octets. L'octet de version vaut 0x41 sur le mainnet, et c'est la raison pour laquelle toute adresse s'affiche avec un T initial une fois les 25 octets encodés en Base58.

Le checksum correspond aux quatre premiers octets de SHA-256(SHA-256(payload)), où le payload est l'octet de version plus les 20 octets d'adresse. Cette page calcule réellement ce hash, via la Web Crypto API du navigateur lui-même, et le compare aux quatre octets portés par l'adresse. Un seul caractère modifié produit un payload différent, un hash différent, et une non-correspondance. C'est tout le mécanisme, et c'est pourquoi une adresse TRON mal saisie est rejetée plutôt qu'acceptée dans le vide.

Base58 exclut aussi volontairement quatre caractères de son alphabet : le zéro, le O majuscule, le I majuscule et le l minuscule. Ce sont les paires que l'on confond en lisant une adresse à voix haute ou en la recopiant à la main, et les retirer signifie que ces confusions ne peuvent pas produire une autre adresse valide. Si le vérificateur signale un caractère hors alphabet, l'un de ces quatre est généralement le coupable.

Une chose que le format ne vous dit pas : si l'adresse est un wallet ou un contrat de token. Les deux utilisent la même forme préfixée par T sur TRON. Le contrat de l'USDT, TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t, est une adresse valide selon toutes les vérifications de cette page, et y envoyer un dépôt reste une erreur. La page sur l'adresse TRC20 détaille cette distinction ainsi que la notation hexadécimale.

Ethereum et BSC : un même format, deux chaînes

Une adresse EVM est 0x suivi de 40 caractères hexadécimaux, soit 42 caractères au total. Ethereum, BNB Smart Chain, Polygon et Arbitrum l'utilisent tous, parce qu'ils partagent la même couche d'exécution et la même dérivation de clés. Cela a une conséquence qui mérite d'être dite clairement : il est tout simplement impossible de distinguer une adresse ERC-20 d'une adresse BEP-20 en la regardant. La chaîne de caractères est identique. Ce qui diffère, c'est le réseau vers lequel vous diffusez la transaction, et les soldes qui existent sur chaque chaîne.

C'est de là que proviennent la plupart des pertes inter-chaînes. Une adresse parfaitement valide sur Ethereum l'est tout autant sur BSC, si bien qu'un wallet enverra sans problème des tokens BEP-20 vers une adresse que le destinataire ne surveille que sur Ethereum. Les fonds ne sont pas perdus, ils se trouvent sur l'autre chaîne, mais les récupérer nécessite la clé privée et un wallet configuré pour ce réseau. La page sur l'adresse ERC20 et la page sur l'adresse BEP20 traitent le côté pratique de la question, y compris la façon dont le BEP-20 diffère de l'ancien format BEP-2, qui commence par bnb1 et n'est interchangeable avec rien de ce qui est décrit ici.

EIP-55 : le checksum caché dans la casse

L'hexadécimal ne distingue pas la casse, donc 0xab… et 0xAB… désignent le même compte. EIP-55 met cette marge à profit : hasher l'adresse en minuscules avec Keccak-256, et laisser chaque nibble du hash décider si la lettre hexadécimale correspondante s'écrit en majuscule ou en minuscule. Le résultat ressemble à une adresse ordinaire à casse mixte et porte environ quatre bits de détection d'erreur par lettre.

Une adresse EVM à casse mixte porte donc une affirmation vérifiable, une adresse tout en minuscules ou tout en majuscules non. Les deux formes sont des saisies valides pour tout wallet et tout nœud. Seule celle à casse mixte peut être vérifiée.

Cette page indique laquelle des deux vous avez collée, et s'arrête là. Vérifier le checksum EIP-55 nécessite une implémentation de Keccak-256, et la Web Crypto API du navigateur n'offre pas Keccak — elle offre SHA-256, ce qu'utilise la vérification TRON ci-dessus. Plutôt que d'embarquer une fonction de hachage écrite maison pour une vérification sensible en matière de sécurité, l'outil vous indique ce qu'il n'a pas vérifié. Si votre adresse provient de l'interface d'un wallet, elle porte presque certainement déjà un checksum correct ; si elle provient d'une base de données ou d'un fichier de log, une vérification EIP-55 complète vaut la peine d'être exécutée dans votre propre code, où une bibliothèque éprouvée n'est qu'à un import de distance.

D'où viennent les adresses dans une intégration

Valider une adresse collée est la dernière ligne de défense. La précédente, c'est de ne jamais coller d'adresse du tout. Dans un flux de paiement ou de versement, les adresses de dépôt sont générées par client et surveillées de façon programmatique, si bien qu'aucun humain ne les ressaisit jamais et que la question du format ne se pose pas.

C'est le rôle que jouent l'API TRON et les endpoints équivalents pour Ethereum et BSC : créer une adresse, y enregistrer un webhook, créditer le dépôt quand la notification arrive. Les adresses restent non-custodial, et l'essai dure sept jours, sans carte de crédit ni KYC. Deux détails opérationnels valent la peine d'être connus avant de construire dessus : les webhooks n'ont pas de nouvel essai automatique, une livraison échouée se récupère donc avec POST /<chain>/webhooks/notifications/failed plutôt qu'en attendant une nouvelle livraison, et Solana ne prend en charge aucun webhook.

Les autres calculateurs de ce site sont répertoriés sur l'aperçu des outils.

Questions fréquentes

L'adresse quitte-t-elle mon navigateur ?

Non. Le décodage Base58 et le hachage SHA-256 s'exécutent tous deux localement, via l'API Web Crypto du navigateur. Aucune requête n'est envoyée à un serveur, ce qui veut aussi dire que l'outil fonctionne même sans connexion réseau.

Que vérifie-t-on exactement pour une adresse TRON ?

Quatre choses : que la chaîne compte 34 caractères, que chaque caractère appartient à l'alphabet Base58, qu'elle se décode en 25 octets avec l'octet de version 0x41, et que les quatre derniers octets correspondent aux quatre premiers octets de SHA-256(SHA-256(payload)). Le checksum est calculé, pas supposé.

Peut-on distinguer une adresse ERC-20 d'une adresse BEP-20 ?

Non, et rien d'autre ne le peut non plus. Les deux standards utilisent le format identique 0x suivi de 40 caractères hexadécimaux. Un outil qui prétend les distinguer devine, ou interroge une blockchain pour connaître des soldes, ce qui est une question différente de la validité de l'adresse.

Pourquoi le checksum EIP-55 n'est-il pas vérifié ?

Cela nécessite Keccak-256, que la cryptographie intégrée du navigateur ne fournit pas, et cette page n'embarque pas d'implémentation de hachage maison pour une vérification sur laquelle on voudrait s'appuyer. Ce que la page indique, c'est si l'adresse est écrite en casse mixte, ce qui signifie qu'elle porte un checksum EIP-55, ou dans une seule casse, ce qui signifie qu'elle n'en porte aucun.

Une adresse valide garantit-elle que les fonds arriveront ?

Non. La validité est une propriété de la chaîne de caractères. Savoir si l'adresse est surveillée, si elle appartient à la chaîne depuis laquelle vous envoyez, et si elle appartient bien au destinataire prévu sont des questions distinctes qu'aucune vérification hors ligne ne peut trancher.

Pourquoi le Base58 exclut-il certains caractères ?

Le zéro, le O majuscule, le I majuscule et le l minuscule sont exclus car ils sont facilement confondus les uns avec les autres. Les exclure évite qu'une lecture ambiguë produise silencieusement une autre adresse valide.

Quelle est la forme hexadécimale d'une adresse TRON ?

Les mêmes 21 octets de payload écrits en hexadécimal : 41 suivi de 40 caractères hexadécimaux. La TVM utilise cette forme en interne, les wallets affichent la forme Base58Check. La forme hexadécimale ne porte aucun checksum, il n'y a donc rien à vérifier.

L'adresse d'un contrat est-elle une adresse valide ?

Oui, selon toute vérification de format. Sur TRON comme sur les chaînes EVM, les adresses de contrat et les adresses de wallet sont indiscernables par leur forme. Envoyer un dépôt vers un contrat de token passe la validation et perd quand même les fonds, c'est pourquoi la validation d'adresse est une vérification de format, pas une vérification de sécurité.