Liste blanche des jetons : guide complet des listes approuvées en 2025

Stratégies principales de liste blanche des jetons pour les projets de crypto-monnaie. Découvrez les méthodes de mise en œuvre, les meilleures pratiques de sécurité et la conformité réglementaire pour les listes d'adresses approuvées.

8 min read52 sections
CoinCryptoRank Editorial
Trusted analysis

Comprendre la liste blanche des jetons

Qu'est-ce que la liste blanche ?

La liste blanche restreint les interactions de jetons ou de protocoles aux adresses explicitement approuvées, nécessitant une autorisation préalable pour la participation.

Concept de base :

Liste noire : tout le monde est autorisé SAUF les adresses interdites
Liste blanche : PERSONNE autorisé SAUF les adresses approuvéesÉtats par défaut :
Liste noire : Ouverte (permissive)
Liste blanche : fermée (restrictive)

Pourquoi la liste blanche est importante

1. Ventes et amp; ICO :

  • • Vérification des investisseurs accrédités
  • • Conformité KYC/AML
  • • Restrictions géographiques
  • • Protection anti-bots
  • • Mécanismes de lancement équitables

2. Monnaies NFT :

  • • Récompenses des premiers supporters
  • • Priorité aux membres de la communauté
  • • Empêcher la capture de robots
  • • Accès hiérarchisé
  • • Allocation garantie

3. Conformité réglementaire :

  • • Conformité à la loi sur les valeurs mobilières
  • • Exigences pour les investisseurs qualifiés
  • • Restrictions géographiques
  • • Vérification des investisseurs professionnels

4. Protocoles DeFi :

  • • Accès aux tests bêta
  • • Gestion des risques
  • • Déploiement progressif
  • • Fonctionnalités premium
  • • Services institutionnels

5. Sécurité :

  • • Limiter la surface d'attaque
  • • Contrôler la qualité des participants
  • • Réduire le risque de fraude
  • • Activer les mécanismes de récupération

Mise en œuvre technique

1. Méthode de stockage en chaîne

Approche la plus simple : mappage du stockage

Avantages :Vérification simple en temps réel, mises à jour faciles, transparence en chaîne

Inconvénients :Coûts du gaz élevés, coûts de stockage élevés, cher pour les grandes listes

Idéal pour :Petites listes blanches (<100 adresses), listes qui changent fréquemment

Implémentation de la liste blanche de base :

// Implémentation de base de la liste blanche
contrat Liste blancheToken {
  mapping(address =&gt; bool) public sur liste blanche ;
  s'adresser à l'administrateur public ;
  
  modificateur uniquementWhitelisted() {
    require(whitelisted[msg.sender], "Pas sur liste blanche");
    _;
  }
  
  modificateur onlyAdmin() {
    require(msg.sender == admin, "Pas admin");
    _;
  }
  
  constructeur() {admin = msg.expéditeur ;
  }
  
  // Ajouter une seule adresse
  fonction addToWhitelist (compte d'adresse) externe uniquement Admin {
    liste blanche[compte] = true ;
    émettre AddedToWhitelist (compte);
  }
  
  // Ajouter plusieurs adresses (batch)
  fonction addMultipleToWhitelist (adresse [] comptes de données d'appel) 
    externe 
    uniquementAdmin 
  {
    pour (uint i = 0; i &lt; comptes.longueur; i++) {
      liste blanche[comptes[i]] = true ;
      émettre AddedToWhitelist (comptes [i]);
    }
  }
  
  // Exemple de fonction sur liste blanche
  function mintTokens (montant uint256) externe uniquementWhitelisted {
    _mint(msg.sender, montant);
  }
}

2. Méthode de l'arbre Merkle

Économe en gaz pour les grandes listes

Avantages :Extrêmement économe en gaz, peut atteindre plusieurs millions, stockage à racine unique

Inconvénients :Implémentation complexe, calcul hors chaîne, complexité UX

Idéal pour :Grandes listes blanches (plus de 1 000 adresses), mises à jour peu fréquentes

Implémentation de l'arbre Merkle :

import "@openzeppelin/contracts/utils/cryptography/MerkleProof.sol";contract MerkleWhitelist {
  octets32 public merkleRoot ;
  mapping(adresse =&gt; bool) public hasClamed;
  
  s'adresser à l'administrateur public ;
  
  constructeur (octets32 _merkleRoot) {
    merkleRoot = _merkleRoot;
    admin = msg.expéditeur ;
  }
  
  // Mise à jour de la racine Merkle (nouvelle liste blanche)
  fonction updateMerkleRoot(bytes32 _merkleRoot) externe {
    require(msg.sender == admin, "Pas admin");
    merkleRoot = _merkleRoot;
  }
  
  // Vérifier l'adhésion à la liste blanche
  fonction verifyWhitelist (
    bytes32[] preuve de données d'appel,
    adresse du compte
  ) la vue publique renvoie (bool) {
    feuille octets32 = keccak256(abi.encodePacked(compte));
    return MerkleProof.verify(proof, merkleRoot, leaf);
  }
  
  // Mint avec vérification de la liste blanche
  function liste blancheMint(bytes32[] calldata proof) externe {
    require(!hasClamed[msg.sender], "Déjà réclamé");
    exiger (
      verifyWhitelist(preuve, msg.sender),
      "Preuve Merkle invalide"
    );
    
    hasClamed[msg.sender] = true;
    _mint(msg.expéditeur, 1);
  }
}

Génération de l'arbre Merkle (hors chaîne) :

const { MerkleTree } = require('merkletreejs');
const keccak256 = require('keccak256');// Adresses de la liste blanche
liste blanche const = [
  '0x1234...', 
  '0x5678...',
  '0x9abc...',
  // ... des milliers d'autres
];// Créer des nœuds feuilles
const leafNodes = whitelist.map(addr =&gt; 
  keccak256 (adresse)
);// Créer un arbre Merkle
const merkleTree = nouveau MerkleTree(leafNodes, keccak256, {
  sortPaires : vrai
});// Obtenir root (stocker dans le contrat)
const rootHash = merkleTree.getRoot();// Générer une preuve pour une adresse spécifique
fonction getProof (adresse) {
  const leaf = keccak256(adresse);
  const proof = merkleTree.getHexProof(leaf);
  retourner la preuve ;
}

3. Méthode de signature numérique

Autorisation hors chaîne

Avantages :Pas de stockage en chaîne, approbation dynamique, logique flexible, préservation de la confidentialité

Inconvénients :Signataire centralisé, backend requis, risque de compromission de signature

Idéal pour :Listes blanches dynamiques, vérification complexe, exigences de confidentialité

Mise en œuvre de la vérification de signature :

contrat SignatureWhitelist {
  s'adresser au signataire public ;
  mapping(adresse =&gt; bool) public hasMinted;
  
  constructeur (adresse _signer) {
    signataire = _signer;
  }
  
  // Vérifier la signature du signataire autorisé
  fonction verifySignature (
    compte d'adresse,
    signature de mémoire en octets
  ) la vue publique renvoie (bool) {
    bytes32 messageHash = keccak256(abi.encodePacked(account));
    bytes32 ethSignedMessageHash = getEthSignedMessageHash(messageHash);
    
    return recoverySigner(ethSignedMessageHash, signature) == signataire ;
  }
  
  fonction getEthSignedMessageHash (bytes32 messageHash)
    interne
    pur
    renvoie (octets32)
  {
    retourner keccak256(
      abi.encodePacked("\x19Message signé Ethereum :\n32", messageHash)
    );
  }
  
  fonction récupérerSigner(
    octets32 ethSignedMessageHash,
    signature de mémoire en octets
  ) retours purs internes (adresse) {
    (octets32 r, octets32 s, uint8 v) = splitSignature(signature);
    return ecrecover(ethSignedMessageHash, v, r, s);
  }
  
  fonction splitSignature (octets de mémoire sig)
    interne
    pur
    renvoie (octets32 r, octets32 s, uint8 v)
  {
    require(sig.length == 65, "Longueur de signature invalide");
    
    assemblage {
      r := mload(ajouter(sig, 32))
      s := mload(ajouter(sig, 64))
      v := octet(0, mload(ajouter(sig, 96)))
    }
  }
  
  // Neuf avec vérification de signature
  signature de fonctionMint(signature mémoire en octets) externe {
    require(!hasMinted[msg.sender], "Déjà créé");
    exiger (
      verifySignature(msg.sender, signature),
      "Signature invalide"
    );
    
    hasMinted[msg.sender] = true;
    _mint(msg.expéditeur, 1);
  }
}

4. NFT/Token Gating

Liste blanche basée sur la propriété

Avantages :Vérification automatisée, renforcement de la communauté, valeur sur le marché secondaire

Inconvénients :Accès transférable, manipulation de marché, dépendance externe

Idéal pour :Récompenses communautaires, accès DAO, avantages hiérarchisés

Implémentation du portail NFT :

interface IERC721 {
  la fonction balanceOf (propriétaire de l'adresse) renvoie la vue externe (uint256) ;
}contrat NFTGatedWhitelist {
  IERC721 public requisNFT ;
  
  constructeur (adresse _nftAddress) {
    requisNFT = IERC721(_nftAddress);
  }
  
  modificateur uniquementNFTHolder() {
    exiger (
      requisNFT.balanceOf(msg.sender) &gt; 0,
      "Doit détenir le NFT requis"
    );
    _;
  }
  
  // Accès réservé aux détenteurs de NFT
  fonctionprivilégiedMint() externe onlyNFTHolder {
    _mint(msg.expéditeur, 1);
  }
}

Cas d'utilisation réels

Liste blanche ICO/IDO

Flux de processus :

Phase de candidature (1 à 2 semaines) : candidature de l'utilisateur, vérification KYC/AML, contrôle des investisseurs accrédités, sélection géographique

Phase de sélection : examen des candidatures, premier arrivé, premier servi OU loterie OU basé sur des critères

Publication de la liste blanche : générer la racine Merkle, déployer le contrat, annoncer à la communauté

Phase de vente : les adresses sur liste blanche participent, les adresses non sur liste blanche sont bloquées, accès limité dans le temps

Phase publique (facultatif) : ouvert à tous après la période de liste blanche, allocation restante

Liste blanche NFT Mint

Accès hiérarchisé :

Niveau 1 - VIP (24 heures plus tôt) :

Équipe principale, modérateurs Discord, premiers supporters, contributeurs spéciaux

Niveau 2 - Liste blanche (12 heures plus tôt) :

Membres actifs de la communauté, engagement sur les réseaux sociaux, gagnants du concours, projets partenaires

Niveau 3 – Liste autorisée (6 heures plus tôt) :

Utilisateurs enregistrés, vérification de base, abonnés par courrier électronique

Niveau 4 - Public :

Tout le monde, premier arrivé, premier servi, généralement un gaz plus élevé

Mise en œuvre de NFT Mint à plusieurs niveaux :

contrat TieredNFTMint {
  bytes32 public vipMerkleRoot ;
  bytes32 liste blanche publiqueMerkleRoot ;
  bytes32 liste autorisée publiqueMerkleRoot ;
  
  uint256 public vipStartTime = 1700000000 ;
  uint256 public whitelistStartTime = vipStartTime + 24 heures ;
  uint256 public allowlistStartTime = whitelistStartTime + 12 heures ;
  uint256 public publicStartTime = allowlistStartTime + 6 heures ;
  
  mapping(adresse =&gt; uint256) public mintedAmount;
  uint256 public maxPerWallet = 3 ;
  
  function vipMint(montant uint256, bytes32[] preuve des données d'appel) externe {
    require(block.timestamp &gt;= vipStartTime, "Trop tôt");
    exiger (
      verifyMerkleProof(preuve, vipMerkleRoot, msg.sender),
      "Pas VIP"
    );
    require(mintedAmount[msg.sender] + montant &lt;= maxPerWallet);
    
    mintedAmount[msg.sender] += montant ;
    _mint(msg.sender, montant);
  }
  
  function whitelistMint (montant uint256, bytes32[] preuve de données d'appel) externe {
    require(block.timestamp &gt;= whitelistStartTime, "Trop tôt");
    exiger (
      verifyMerkleProof(preuve, liste blancheMerkleRoot, msg.sender),
      "Pas sur liste blanche"
    );
    require(mintedAmount[msg.sender] + montant &lt;= maxPerWallet);
    
    mintedAmount[msg.sender] += montant ;
    _mint(msg.sender, montant);
  }
  
  function publicMint (montant uint256) externe payable {
    require(block.timestamp &gt;= publicStartTime, "Trop tôt");
    require(msg.value &gt;= montant * PUBLIC_PRICE);
    require(mintedAmount[msg.sender] + montant &lt;= maxPerWallet);
    
    mintedAmount[msg.sender] += montant ;
    _mint(msg.sender, montant);
  }
}

Conformité réglementaire

Offres de jetons de sécurité (STO) :

Exigences de conformité :

  • • Vérification des investisseurs accrédités (valeur nette de 1 million $ ou plus ou revenu de 200 000 $ ou plus)
  • • Restrictions géographiques (Reg S, Reg D)
  • • Périodes de conservation
  • • Restrictions de transfert
  • • Pistes d'audit

Accès au protocole DeFi

Tests bêta :

Cas d'utilisation :Déploiement progressif, limitation des risques, programmes de bug bounty, fonctionnalités premium, services institutionnels

Meilleures pratiques

Pour les projets

1. Communication claire :

Informations essentielles : critères de liste blanche, processus de candidature, méthode de sélection, calendrier, limites d'allocation, exigences techniques

2. Sélection équitable :

Critères transparents, mesures anti-sybil, approche communautaire d'abord, loterie pour la demande excédentaire, processus d'appel

3. Sécurité :

Contrats d'audit, clés d'administration sécurisées, test sur testnet, vérification des arbres Merkle, limitation de débit, protection frontale

4. Expérience utilisateur :

Processus de vérification simple, instructions claires, canaux d'assistance, outils de génération de preuves, interface de vérification de l'état

5. Conformité légale :

KYC/AML si nécessaire, conformité à la loi sur les valeurs mobilières, restrictions géographiques, conditions de service, examen juridique

Pour les utilisateurs

Conseils de vérification :

  • • Suivez uniquement les chaînes officielles
  • • Complétez honnêtement votre KYC
  • • Respecter les délais
  • • Fournir des informations précises
  • • Conserver la preuve de demande
  • • Vérifier les adresses du contrat

Sécurité :

  • • Ne partagez jamais de clés privées
  • • Vérifier les URL des sites Web
  • • Vérifier les adresses des contrats
  • • Attention au phishing
  • • Utiliser des portefeuilles matériels
  • • Test avec de petites quantités

Erreurs courantes :

  • • ❌ Date limite de candidature manquante
  • • ❌ KYC incomplet
  • • ❌ Mauvaise adresse de portefeuille
  • • ❌ Ne répond pas aux critères
  • • ❌ Tomber dans le piège des arnaques
  • • ❌ Utilisation des adresses d'échange

Comparaison : méthodes

Méthode Coût du gaz Évolutivité Flexibilité Sécurité Idéal pour
Cartographie Élevé Mauvais Excellent Bon Petites listes
Arbre Merkle Faible ExcellentMauvais Bon Grandes listes
Signature Faible Excellent Excellent Moyen Listes dynamiques
NFT/Jeton Faible Excellent Bon Bon Portail communautaire

Tendances futures

1. Intégration d'identité décentralisée

Liste blanche auto-souveraine avec informations d'identification portables, vérification préservant la confidentialité, listes blanches multiplateformes

2. Sélection basée sur l'IA

Curation automatisée avec analyse du comportement, notation des contributions, détection de sybil, distribution équitable

3. Listes blanches inter-protocoles

Accès interopérable avec une liste blanche pour des usages multiples, portabilité de la réputation, partenariats écosystémiques

4. Technologie de réglementation

Automatisation de la conformité avec vérifications de juridiction en temps réel, liste blanche dynamique, rapports réglementaires

Conclusion

La liste blanche des jetons fournit un contrôle d'accès essentiel pour les projets de crypto-monnaie, permettant la conformité réglementaire, une distribution équitable, la création d'une communauté et la sécurité. Du simple stockage de cartographie aux arbres Merkle sophistiqués et à la vérification des signatures, les choix de mise en œuvre dépendent de l'échelle, des besoins de flexibilité et des considérations liées au gaz.

Points clés à retenir :

  • • Choisissez la bonne méthode : mappage pour les petites listes/dynamiques, Merkle pour les grandes/statiques, signatures pour la flexibilité
  • • Équilibrer accès et équité : critères clairs, sélection transparente, approche axée sur la communauté
  • • Donner la priorité à la sécurité : auditer les contrats, sécuriser les clés d'administration, protéger les données des utilisateurs
  • • Optimiser l'UX : processus simples, instructions claires, outils utiles
  • • Restez conforme : suivez les réglementations, mettez en œuvre le KYC si nécessaire, documentez tout

À mesure que la crypto-monnaie évolue, la liste blanche deviendra plus sophistiquée, automatisée et préservant la confidentialité. Les projets qui mettent en œuvre de manière réfléchie la liste blanche – en équilibrant le contrôle d’accès avec l’équité, la sécurité avec la convivialité et le respect avec la décentralisation – bâtiront des communautés plus fortes et des lancements de jetons plus réussis.

Questions fréquemment posées

Q : Pourquoi les projets utilisent-ils des listes blanches au lieu de ventes ouvertes ?

A : Les listes blanches permettent : (1) la conformité réglementaire (investisseurs accrédités, restrictions géographiques), (2) la prévention des robots, (3) une distribution équitable à la communauté, (4) un déploiement contrôlé pour la sécurité.

Q : Comment puis-je être inscrit sur la liste blanche pour un menthe NFT ?

A : Généralement : (1) Rejoignez le projet Discord/réseaux sociaux, (2) Engagez-vous avec la communauté, (3) Suivez les instructions de candidature, (4) Terminez la vérification (KYC si nécessaire), (5) Soumettez l'adresse du portefeuille, (6) Attendez la confirmation. Chaque projet est différent.

Q : Les listes blanches peuvent-elles être modifiées après le déploiement ?

A : Dépend de la mise en œuvre. Stockage de mappage : oui (si les contrôles d'administration sont inclus). Arbre Merkle : nécessite la mise à jour du hachage racine. Signature : oui (contrôlé par le backend). NFT-gating : automatique en fonction de la propriété.

Q : Les spots de la liste blanche sont-ils transférables ?

A : Généralement non pour les listes blanches basées sur des adresses (liées à un portefeuille spécifique). Exception : l'accès NFT/token-gated est transférable avec la propriété du NFT/token.

Q : Quelle est la différence de coût du gaz entre les méthodes de liste blanche ?

A : Cartographie : plus de 20 000 gaz par ajout d'adresse. Merkle : environ 3 000 à 5 000 gaz pour vérification (constant quelle que soit la taille de la liste blanche). Signature : ~3 000 à 5 000 gaz pour vérification. Les économies de gaz augmentent considérablement avec la taille de la liste.

Live Market Data

Track 10,000+ crypto assets with real-time prices

Arbitrage Scanner

Find price differences across 60+ exchanges

Crypto Converter

Convert between 200+ assets with live rates