Qu'est-ce qu'une adresse BEP20 ?

Une adresse BEP20 est une adresse de compte sur BNB Smart Chain (BSC), le réseau qui s’appelait Binance Smart Chain jusqu’à son renommage en février 2022. Elle commence par 0x, comporte 42 caractères et utilise exactement le même format qu’une adresse Ethereum. Si vous pouvez gérer des adresses Ethereum dans votre code, vous pouvez gérer des adresses BEP20 sans changer une seule ligne.

Cela semble être toute l’histoire, mais deux détails posent problème en pratique. D’abord, BEP20 est confondu avec BEP-2, un ancien standard Binance avec un format d’adresse complètement différent. Ensuite, la même adresse 0x existe simultanément sur chaque chaîne EVM, ce qui a de vraies conséquences lorsque vous envoyez des tokens. Ce guide couvre le format, la somme de contrôle EIP-55, le code de validation, et comment créer des adresses BSC par programmation.

Le format : 0x plus 40 caractères hexadécimaux

Une adresse BEP20 encode 20 octets (160 bits) en texte hexadécimal :

0x71C7656EC7ab88b098defB751B7401B5f6d8976F

Trois vérifications vous indiquent si une chaîne de caractères peut être une adresse :

• Elle commence par le préfixe 0x.
• Exactement 40 caractères suivent le préfixe.
• Chacun de ces caractères est un chiffre hexadécimal : 0–9, a–f ou A–F.

Il n’existe pas de type d’adresse séparé pour les tokens. Les tokens BEP20 tels que USDT, USDC ou CAKE sont envoyés vers les mêmes adresses de compte de 42 caractères qui détiennent du BNB. Votre adresse de wallet Binance Smart Chain pour le BNB et votre adresse BEP20 pour les tokens sont une seule et même chaîne de caractères.

D’où proviennent les 20 octets ? Un compte commence par une clé privée aléatoire sur la courbe secp256k1, la même courbe utilisée par Bitcoin et Ethereum. La clé publique dérivée de cette clé est hachée avec Keccak-256, et les 20 derniers octets du hash deviennent l’adresse. Aucun enregistrement n’a lieu nulle part. Une adresse existe dès que le calcul est effectué, même avant que la chaîne n’ait jamais vu la moindre transaction depuis celle-ci.

Pourquoi elle ressemble exactement à une adresse Ethereum

BSC a été lancée en septembre 2020 en tant que chaîne compatible EVM. Elle exécute la machine virtuelle Ethereum, héritant ainsi entièrement du modèle de compte d’Ethereum, de sa dérivation de clés et de son format d’adresse. BEP-20 lui-même est le portage par BSC du standard de token ERC-20 d’Ethereum ; les noms de fonctions (transfer, balanceOf, approve) sont identiques.

Le seul séparateur technique entre les deux réseaux est le chain ID : 56 pour le mainnet BSC, 1 pour le mainnet Ethereum, 97 pour le testnet BSC. Le chain ID entre dans chaque signature de transaction, ce qui empêche qu’une transaction signée pour une chaîne soit rejouée sur l’autre. L’adresse elle-même ne porte aucune information de chaîne. Vous ne pouvez pas regarder 0x71C7...976F et savoir si son propriétaire l’utilise sur BSC, Ethereum, ou les deux.

BEP-20 vs ERC-20 vs TRC-20 côte à côte

Les paiements en stablecoins atteignent des entreprises réelles via trois réseaux, et la plupart des tickets de support liés à des fonds perdus impliquent une confusion entre deux d’entre eux. Voici ce qui diffère réellement, avec des chiffres à mi-2026 :

Deux lignes méritent un examen plus approfondi. Les lignes d’adresse pour BEP-20 et ERC-20 sont identiques car BSC a copié le format d’Ethereum jusqu’à l’algorithme de somme de contrôle. Un validateur qui accepte l’une accepte l’autre et ne peut pas vous dire quel réseau l’utilisateur avait en tête ; seul le contexte environnant le peut. TRC-20 fait figure d’exception. Une adresse TRON échoue instantanément à la validation EVM, ce qui ressemble à un inconvénient et constitue en réalité une protection, car une adresse collée par erreur est rejetée sur la seule base du format, avant qu’aucun fonds ne soit déplacé.

Les chiffres de vitesse ont une durée de vie courte ; les lignes de format non. BSC a divisé par deux son temps de bloc à deux reprises en huit mois : le hard fork Maxwell l’a réduit de 1,5 à 0,75 seconde en juin 2025, et le hard fork Fermi a apporté 0,45 seconde en janvier 2026. TRON maintient son intervalle de 3 secondes depuis des années, et la feuille de route d’Ethereum débat de slots plus courts pour de futures mises à niveau. Les trois formats d’adresse, quant à eux, n’ont pas changé depuis le lancement des chaînes. Le code de validation que vous écrivez aujourd’hui survit à chaque fork. Les tableaux de frais que vous imprimez aujourd’hui nécessiteront une maintenance.

En matière de coût, BSC est actuellement la moins chère des trois pour un simple transfert de token, TRON la plus prévisible (les frais sont fixés en termes d’énergie, non mis aux enchères), et Ethereum la plus coûteuse chaque fois que le réseau est chargé. Si vos clients choisissent eux-mêmes le réseau de dépôt, attendez-vous à ce que BEP-20 et TRC-20 dominent et planifiez votre gestion des frais en conséquence.

La somme de contrôle EIP-55 : pourquoi certaines lettres sont en majuscules

L’hexadécimal ne fait pas de distinction entre majuscules et minuscules, donc 0xab... et 0xAB... pointent vers le même compte. EIP-55, proposé en 2016 pour Ethereum et adopté par BSC avec tout le reste, transforme ce degré de liberté superflu en vérification d’erreur.

La règle : prenez l’adresse en minuscules (sans 0x), hachez-la avec Keccak-256, et parcourez les 40 caractères. Si le chiffre du hash à une position est 8 ou plus, la lettre de l’adresse à cette position est écrite en majuscule ; sinon en minuscule. Les chiffres restent tels quels.

Le résultat est la forme à casse mixte que les wallets et les explorateurs affichent. Si un utilisateur se trompe en tapant un caractère d’une adresse avec somme de contrôle, le motif de casse ne correspond plus au hash et la validation échoue, ce qui permet de détecter la faute de frappe avant tout mouvement de fonds. Une adresse entièrement en minuscules reste techniquement valide, elle ne porte simplement pas de somme de contrôle, et votre code devrait la traiter comme une entrée non vérifiée plutôt que de la rejeter.

Un exemple détaillé

La propre suite de tests d’EIP-55 commence avec cette adresse. En minuscules, sans le 0x, et à côté le hash Keccak-256 de cette chaîne de 40 caractères :

address: 5aaeb6053f3e94c9b9a09f33669435e7ef1beaed
keccak:  d385650ce8fdc6db7ee3a091d34814dbc4ce18219ffae52182efff4034d707e5

Comparez maintenant position par position. Le premier caractère de l’adresse est 5, un chiffre, il reste donc 5 quoi que dise le hash. Le deuxième est a, et le chiffre du hash au-dessus est 3, inférieur à 8, il reste donc en minuscule. Le troisième est encore a, mais cette fois le chiffre du hash est 8, il devient donc A. Le quatrième, e, se trouve sous un 5 et reste en minuscule. Poursuivez ainsi sur les 40 positions et vous obtenez la forme avec somme de contrôle :

0x5aAeb6053F3E94C9b9A09f33669435E7Ef1BeAed

Deux détails d’implémentation causent la plupart des bugs en pratique. L’entrée du hash est le texte ASCII de l’adresse en minuscules, pas les 20 octets bruts qu’elle encode, et pas la chaîne avec 0x encore attaché. Faites l’un ou l’autre de travers, et chaque somme de contrôle que vous calculez sera fausse. Quant à la protection offerte par ce schéma : l’EIP lui-même l’estime à environ 15 bits de vérification par adresse en moyenne, ce qui signifie qu’une adresse mal saisie passe avec une probabilité d’environ 0,0247 pour cent, soit une adresse erronée sur quatre mille au lieu d’une acceptation garantie.

BEP-2 vs BEP-20 : deux standards, deux formats d’adresse

C’est la confusion qui a coûté de l’argent réel aux utilisateurs. Binance exploitait autrefois deux chaînes en parallèle :

• BNB Beacon Chain, avec le standard de token BEP-2 et des adresses commençant par bnb1
• BNB Smart Chain, avec le standard BEP-20 et des adresses 0x

Les dépôts BEP-2 vers les exchanges nécessitaient également un champ mémo, et un mémo oublié était un ticket de support classique. Cette époque est révolue : Binance a retiré la Beacon Chain en 2024 dans le cadre de la BNB Chain Fusion, et le BEP-2 avec elle. Si un tutoriel vous parle d’adresses bnb1 ou de mémos, il est obsolète. Aujourd’hui, « adresse BNB » et « adresse BSC » désignent en pratique le format BEP20 en 0x.

Le nom survit dans les menus de retrait des exchanges, où le réseau est généralement étiqueté « BSC (BEP20) » ou « BNB Smart Chain (BEP20) ». Lorsque vous voyez ce libellé, la destination doit être une adresse 0x.

Une adresse, plusieurs chaînes : pourquoi le sélecteur de réseau compte

Parce que BSC a copié la dérivation d’Ethereum, la même clé privée contrôle la même adresse 0x sur Ethereum, BSC, Polygon, Arbitrum et toute autre chaîne EVM. C’est à la fois pratique et dangereux.

Pratique : un utilisateur avec un compte MetaMask ou Trust Wallet dispose déjà d’une adresse BEP20. Il ajoute le réseau BSC dans les paramètres de son wallet et son adresse existante fonctionne.

Dangereux : des tokens portant le même nom vivent sous forme de contrats séparés sur des chaînes séparées. L’USDT sur BSC et l’USDT sur Ethereum n’ont rien en commun à part le ticker. Si quelqu’un retire de l’USDT d’une exchange et choisit le mauvais réseau, les tokens arrivent à la bonne adresse sur la mauvaise chaîne. Deux issues sont possibles :

1. Le destinataire contrôle la clé privée (wallet en auto-garde). Alors rien n’est perdu. Il bascule son wallet vers l’autre réseau et y retrouve les tokens.
2. Le destinataire est une adresse de dépôt d’une exchange ou d’un prestataire de paiement qui ne surveille qu’un seul réseau. Alors les tokens restent dans un compte que personne ne surveille. Certaines exchanges récupèrent de tels dépôts moyennant des frais, d’autres non.

La règle pratique pour les développeurs : indiquez toujours le réseau à côté de l’adresse affichée, et vérifiez les dépôts entrants sur la chaîne que vous créditez réellement. Une simple chaîne d’adresse est ambiguë par conception.

Comment trouver votre adresse BEP20 dans MetaMask, Trust Wallet et les wallets matériels

Tout wallet parlant EVM vous montre finalement la même chose, une adresse 0x, mais le chemin pour y arriver diffère légèrement. Les étapes ci-dessous restent délibérément génériques, car les libellés des menus évoluent d’une version d’application à l’autre.

MetaMask

MetaMask démarre au départ connecté uniquement à Ethereum. Pour l’utiliser sur BSC, ajoutez BNB Smart Chain comme réseau (chain ID 56, devise BNB) ; les versions actuelles le listent dans le catalogue de réseaux intégré, donc aucune saisie RPC manuelle n’est nécessaire. L’adresse de votre compte se trouve en haut de la vue principale et se copie en un clic. Elle ne change pas lorsque vous changez de réseau. Sélectionner BSC dans le menu réseau change la destination de vos transactions, pas qui vous êtes.

Trust Wallet

Trust Wallet prend en charge BSC nativement. Choisissez l’actif que vous attendez, par exemple du BNB ou un token étiqueté « BEP20 », ouvrez l’écran de réception, et l’application affiche l’adresse 0x sous forme de texte et de code QR. Le libellé du réseau à côté de chaque token compte plus que l’adresse elle-même : « USDT BEP20 » et « USDT ERC20 » résolvent vers la même chaîne d’adresse dans votre wallet, mais indiquent à l’expéditeur quelle chaîne utiliser, et c’est là que les choses tournent mal.

Wallets matériels

Avec un Ledger ou un Trezor, la clé privée ne quitte jamais l’appareil, et BSC transite par la même intégration EVM qu’Ethereum. Le flux de réception ajoute une étape qui mérite d’être conservée : l’appareil affiche l’adresse sur son propre écran, et vous la comparez avec ce que montre l’ordinateur avant de la partager. Cette comparaison déjoue les logiciels malveillants de presse-papiers, qui échangent des adresses sur l’ordinateur mais ne peuvent pas toucher à l’écran de l’appareil.

Quel que soit le wallet que vous utilisez, la chaîne copiée ne porte aucune information de réseau. Lorsque vous la collez dans un formulaire de retrait d’exchange, le menu déroulant du réseau à côté détermine la décision, alors vérifiez qu’il indique BSC ou BEP20.

Une phrase de récupération, de nombreuses adresses : les wallets HD en deux minutes

Les wallets modernes ne conservent pas un sac de clés sans lien entre elles. Ils dérivent tout à partir d’une seule graine (seed), en suivant trois standards qui s’empilent les uns sur les autres. BIP-39 transforme 12 ou 24 mots du dictionnaire en une graine. BIP-32 fait pousser un arbre déterministe de paires de clés à partir de cette graine, de sorte que les mêmes mots produisent toujours le même arbre. BIP-44 fixe quelle branche appartient à quelle monnaie, écrit sous forme de chemin de dérivation.

Pour Ethereum, le chemin enregistré est m/44'/60'/0'/0/0, avec 60 comme type de monnaie. BSC n’a jamais enregistré son propre type de monnaie ; les wallets réutilisent 60, ce qui est la raison technique pour laquelle votre wallet affiche la même adresse sur BSC, Ethereum, Polygon et Arbitrum. Le dernier chiffre du chemin est un index. Incrémentez-le et le wallet dérive une deuxième adresse à partir des mêmes mots, puis une troisième, sans qu’aucune nouvelle sauvegarde ne soit nécessaire.

Deux conséquences en découlent. Restaurer les mots de la graine dans n’importe quel wallet BIP-44 recrée chaque adresse que vous avez jamais dérivée, les mots constituent donc la sauvegarde, toute la sauvegarde. Et une plateforme nécessitant des milliers d’adresses de dépôt pourrait en principe toutes les dériver d’une seule graine, bien que les configurations en production génèrent généralement les clés individuellement et les enregistrent via l’API, de sorte qu’aucun secret unique ne contrôle tous les dépôts clients à la fois.

Vérifier une adresse sur BscScan

BscScan est l’explorateur de blocs de BSC, et trente secondes passées dessus répondent à la plupart des questions du type « est-ce que ça a marché ? ».

Collez n’importe quelle adresse dans le champ de recherche et vous atterrissez sur sa page de compte : solde BNB, avoirs en tokens, liste de transactions. Pour une adresse de dépôt que vous venez de créer, une page vide est normale. L’adresse existe mathématiquement ; l’explorateur n’a quelque chose à montrer qu’une fois que le premier transfert l’a atteinte.

Regardez le libellé en haut de la page. Les comptes portant une étiquette « Contract » sont des smart contracts, tokens inclus. Les fonds doivent circuler vers des adresses simples, donc si une contrepartie vous demande de payer une adresse de contrat, arrêtez-vous et demandez pourquoi.

La vérification des tokens est le troisième usage. N’importe qui peut déployer un token nommé « USDT » sur BSC, et les résultats de recherche listent les faux à côté du vrai. Le ticker ne prouve rien ; l’adresse du contrat, si. Comparez-la à celle que l’émetteur du token publie, puis jetez un œil au nombre de détenteurs et au code source vérifié sur la page du token. Les faux imitent rarement bien ces éléments-là.

Après une transaction test, recherchez plutôt le hash de transaction. La page de détail affiche l’expéditeur, le destinataire, le contrat de token et le montant, qui confirment ensemble que l’argent est arrivé là où vous le vouliez, sur la chaîne que vous vouliez.

Avant d’envoyer : une courte routine contre les erreurs coûteuses

Trois habitudes couvrent presque toutes les façons dont les transferts BEP20 tournent mal.

Faites correspondre le libellé du réseau à l’ère de l’adresse. Tout ce qui est actuel est « BSC (BEP20) » avec une destination 0x. Un guide, un formulaire ou une contrepartie mentionnant des adresses bnb1 ou des mémos de dépôt décrit le BEP-2, retiré avec la Beacon Chain en 2024. Traitez de telles instructions comme obsolètes, pas comme une option alternative.

Lisez le formulaire de retrait deux fois : une fois pour l’adresse, une fois pour le menu déroulant du réseau. Le champ adresse valide le format, le menu déroulant décide de la chaîne, et aucun validateur ne détecte une adresse correcte sur le mauvais réseau. C’est le mode de défaillance décrit dans la section précédente, et il se produit du côté de l’envoi, ce qui signifie que vous pouvez l’y prévenir.

Envoyez un montant test à chaque nouvelle adresse. Sur BSC, cette discipline coûte quelques centimes et une à deux secondes d’attente, il n’y a donc aucun argument économique contre. Confirmez le test sur BscScan, puis envoyez le reste. Les équipes qui gèrent des paiements formalisent cette habitude : une nouvelle adresse de paiement n’est mise sur liste blanche qu’après un transfert test confirmé.

Valider une adresse BEP20 dans le code

La vérification du format est une seule expression régulière. En JavaScript :

function isValidFormat(address) {
  return /^0x[0-9a-fA-F]{40}$/.test(address);
}

La vérification de la somme de contrôle nécessite Keccak-256, par exemple depuis @noble/hashes :

import { keccak_256 } from "@noble/hashes/sha3";
import { bytesToHex } from "@noble/hashes/utils";

function toChecksumAddress(address) {
  const addr = address.toLowerCase().replace("0x", "");
  const hash = bytesToHex(keccak_256(addr));
  let out = "0x";
  for (let i = 0; i < 40; i++) {
    out += parseInt(hash[i], 16) >= 8 ? addr[i].toUpperCase() : addr[i];
  }
  return out;
}

function hasValidChecksum(address) {
  return toChecksumAddress(address) === address;
}

En PHP, l’expression régulière suffit pour une vérification de format, et le package kornrunner/keccak couvre la somme de contrôle :

use kornrunner\Keccak;

function isValidBep20Address(string $address): bool
{
    if (preg_match('/^0x[0-9a-fA-F]{40}$/', $address) !== 1) {
        return false;
    }
    $hex = substr($address, 2);
    // All one case: format-valid, but no checksum to verify
    if ($hex === strtolower($hex) || $hex === strtoupper($hex)) {
        return true;
    }
    $hash = Keccak::hash(strtolower($hex), 256);
    for ($i = 0; $i < 40; $i++) {
        $expectUpper = intval($hash[$i], 16) >= 8;
        if (ctype_alpha($hex[$i]) && $expectUpper !== ctype_upper($hex[$i])) {
            return false;
        }
    }
    return true;
}

Notez qu’une vérification réussie prouve seulement que la chaîne est bien formée. Elle ne prouve pas que quelqu’un possède la clé privée, et elle ne vous indique pas quel réseau l’expéditeur a l’intention d’utiliser.

Créer des adresses BSC via une API

Si vous gérez une boutique, un produit SaaS ou une plateforme de type exchange, vous avez besoin de plus d’une adresse : typiquement une adresse de dépôt par client, afin de pouvoir distinguer les paiements entrants. Faire cela manuellement dans une application de wallet ne passe pas à l’échelle au-delà d’une poignée d’utilisateurs.

Avec l’API REST de Chaingateway, vous générez des clés dans votre propre environnement et les enregistrez pour une utilisation sur BSC. L’authentification utilise un jeton Bearer dans l’en-tête Authorization :

curl -X POST https://app.chaingateway.io/api/v2/bsc/addresses/import \
  -H "Authorization: Bearer <API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "address": "0xYourGeneratedBscAddress",
    "privatekey": "<generated secp256k1 private key, hex>",
    "password": "<encryption password for this key>"
  }'

Ajoutez l’en-tête X-Network: testnet et le même appel s’exécute sur le testnet BSC (chain ID 97), afin que vous puissiez tester tout le flux avec du BNB de test gratuit avant de toucher au mainnet. L’envoi ultérieur de tokens BEP20 passe par POST /api/v2/bsc/transactions/bep20.

Un essai gratuit de 7 jours suffit pour construire et tester cela ; vous ne passez pas par un processus KYC pour démarrer. Les étapes de configuration se trouvent dans le guide de démarrage rapide, et les formules sont listées sur la page tarifs.

Adresses de dépôt par client, plus les webhooks

L’adresse ne représente que la moitié d’un flux de paiement. L’autre moitié consiste à savoir que de l’argent est arrivé, sans interroger vous-même la chaîne. Le schéma :

1. Lorsqu’un client démarre un paiement, attribuez-lui une adresse BSC dédiée et stockez le mappage adresse-client dans votre base de données.
2. Enregistrez un webhook pour cette adresse. Lorsqu’un transfert BEP20 l’atteint, Chaingateway appelle votre endpoint avec les détails de la transaction.
3. Vérifiez la signature HMAC du webhook, puis créditez le client dans votre propre système.

Les livraisons de webhooks sont signées par HMAC afin que vous puissiez rejeter les appels falsifiés. Les livraisons que votre serveur a manquées ne sont pas non plus perdues : GET /api/v2/bsc/webhooks/notifications/failed les liste, et POST /api/v2/bsc/webhooks/notifications/{id}/retry en renvoie une. Si votre serveur était hors ligne, GET /api/v2/bsc/webhooks/notifications renvoie les notifications passées, de sorte que la réconciliation après une panne se résume à un seul appel API. La configuration complète, y compris la vérification de signature, se trouve dans le guide des webhooks.

Le même schéma fonctionne sur TRON, où le format d’adresse est entièrement différent ; voir Qu’est-ce qu’une adresse TRC20 ? pour ce côté-là.