Lista blanca de tokens: guía completa para las listas aprobadas en

Domine las estrategias de lista blanca de tokens para proyectos de criptomonedas. Conozca los métodos de implementación, las mejores prácticas de seguridad y el cumplimiento normativo para las listas de direcciones aprobadas.

8 min read52 sections
CoinCryptoRank Editorial
Trusted analysis

Comprensión de la lista blanca de tokens

¿Qué son las listas blancas?

La inclusión en la lista blanca restringe las interacciones de tokens o protocolos a direcciones aprobadas explícitamente, lo que requiere autorización previa para participar.

Concepto central:

Lista negra: todos permitidos EXCEPTO direcciones prohibidas
Lista blanca: NADIE permitido EXCEPTO direcciones aprobadasEstados predeterminados:
Lista negra: abierta (permisiva)
Lista blanca: Cerrada (restrictiva)

Por qué es importante incluir en la lista blanca

1. Ventas y ventas de tokens. ICO:

  • • Verificación de inversor acreditado
  • • Cumplimiento KYC/AML
  • • Restricciones geográficas
  • • Protección anti-bot
  • • Mecánica de lanzamiento justa

2. Casas de moneda NFT:

  • • Recompensas anticipadas para seguidores
  • • Prioridad de miembro de la comunidad
  • • Evitar el recorte de robots
  • • Acceso por niveles
  • • Asignación garantizada

3. Cumplimiento normativo:

  • • Cumplimiento de la ley de valores
  • • Requisitos del inversor acreditado
  • • Restricciones geográficas
  • • Verificación de inversor profesional

4. Protocolos DeFi:

  • • Acceso a prueba beta
  • • Gestión de riesgos
  • • Implementación gradual
  • • Funciones premium
  • • Servicios institucionales

5. Seguridad:

  • • Limitar la superficie de ataque
  • • Controlar la calidad de los participantes
  • • Reducir el riesgo de fraude
  • • Habilitar mecanismos de recuperación

Implementación técnica

1. Método de almacenamiento en cadena

Enfoque más simple: almacenamiento de mapas

Ventajas:Verificación simple en tiempo real, actualizaciones sencillas, transparencia en la cadena

Desventajas:Altos costos de gas, costos de almacenamiento aumentan, costoso para listas grandes

Ideal para:Listas blancas pequeñas (<100 direcciones), listas que cambian con frecuencia

Implementación básica de la lista blanca:

// Implementación básica de la lista blanca
contrato WhitelistToken {
  mapeo (dirección =&gt; bool) público en la lista blanca;
  dirigirse a la administración pública;
  
  modificador onlyWhitelisted() {
    require(en la lista blanca[msg.sender], "No en la lista blanca");
    _;
  }
  
  modificador onlyAdmin() {
    require(msg.sender == admin, "No administrador");
    _;
  }
  
  constructor() {administrador = mensaje.remitente;
  }
  
  // Agregar dirección única
  función addToWhitelist(cuenta de dirección) external onlyAdmin {
    en la lista blanca [cuenta] = verdadero;
    emitir AddedToWhitelist(cuenta);
  }
  
  // Agregar múltiples direcciones (por lotes)
  función addMultipleToWhitelist(dirección[] cuentas de datos de llamada) 
    externo 
    solo administrador 
  {
    for (uint i = 0; i &lt; cuentas.longitud; i++) {
      en la lista blanca [cuentas [i]] = verdadero;
      emitir AddedToWhitelist(cuentas[i]);
    }
  }
  
  // Ejemplo de función incluida en la lista blanca
  función mintTokens (cantidad uint256) solo externa Lista blanca {
    _mint(msg.remitente, importe);
  }
}

2. Método del árbol Merkle

Eficiencia de gas para listas grandes

Ventajas:Extremadamente eficiente en cuanto a gas, escala a millones, almacenamiento de raíz única

Desventajas:Implementación compleja, computación fuera de cadena, complejidad de UX

Mejor para:Listas blancas grandes (más de 1000 direcciones), actualizaciones poco frecuentes

Implementación del árbol Merkle:

import "@openzeppelin/contracts/utils/cryptography/MerkleProof.sol";contrato MerkleWhitelist {
  bytes32 público merkleRoot;
  mapeo (dirección =&gt; bool) public hasClaimed;
  
  dirigirse a la administración pública;
  
  constructor(bytes32 _merkleRoot) {
    merkleRoot = _merkleRoot;
    administrador = mensaje.remitente;
  }
  
  // Actualizar raíz de merkle (nueva lista blanca)
  función actualizarMerkleRoot(bytes32 _merkleRoot) externo {
    require(msg.sender == admin, "No administrador");
    merkleRoot = _merkleRoot;
  }
  
  // Verificar membresía en la lista blanca
  función verificar lista blanca (
    bytes32[] prueba de datos de llamada,
    cuenta de dirección
  ) la vista pública devuelve (bool) {
    bytes32 hoja = keccak256(abi.encodePacked(cuenta));
    return MerkleProof.verify(prueba, merkleRoot, hoja);
  }
  
  // Perfecto con verificación de lista blanca
  función lista blancaMint (bytes32 [] prueba de datos de llamada) externo {
    require(!hasClaimed[msg.sender], "Ya reclamado");
    requerir (
      verificarListablanca(prueba, mensaje.remitente),
      "Prueba Merkle no válida"
    );
    
    hasClaimed[msg.sender] = verdadero;
    _mint(msg.remitente, 1);
  }
}

Generando árbol Merkle (fuera de cadena):

const { MerkleTree } = require('merkletreejs');
const keccak256 = require('keccak256');// Direcciones de la lista blanca
lista blanca constante = [
  '0x1234...', 
  '0x5678...',
  '0x9abc...',
  // ... miles más
];// Crear nodos hoja
const leafNodes = whitelist.map(addr =&gt; 
  keccak256(dirección)
);// Crear árbol Merkle
const merkleTree = nuevo MerkleTree(leafNodes, keccak256, {
  ordenar pares: verdadero
});// Obtener root (almacenar en contrato)
const rootHash = merkleTree.getRoot();// Generar prueba para una dirección específica
función obtener prueba (dirección) {
  hoja constante = keccak256(dirección);
  prueba constante = merkleTree.getHexProof(hoja);
  prueba de devolución;
}

3. Método de firma digital

Autorización fuera de cadena

Ventajas:Sin almacenamiento en cadena, aprobación dinámica, lógica flexible, preservación de la privacidad

Desventajas:Firmante centralizado, se requiere backend, riesgo de compromiso de firma

Ideal para:Listas blancas dinámicas, verificación compleja, requisitos de privacidad

Implementación de verificación de firma:

contrato SignatureWhitelist {
  dirección del firmante público;
  mapeo (dirección =&gt; bool) public hasMinted;
  
  constructor(dirección _firmante) {
    firmante = _firmante;
  }
  
  // Verificar la firma del firmante autorizado
  función verificarFirma(
    cuenta de dirección,
    firma de memoria de bytes
  ) la vista pública devuelve (bool) {
    bytes32 messageHash = keccak256(abi.encodePacked(cuenta));
    bytes32 ethSignedMessageHash = getEthSignedMessageHash(messageHash);
    
    return recoverySigner(ethSignedMessageHash, firma) == firmante;
  }
  
  función getEthSignedMessageHash(bytes32 mensajeHash)
    interno
    puro
    devuelve (bytes32)
  {
    devolver keccak256(
      abi.encodePacked("\x19Mensaje firmado de Ethereum:\n32", messageHash)
    );
  }
  
  función recuperar firmante (
    bytes32 ethSignedMessageHash,
    firma de memoria de bytes
  ) retornos puros internos (dirección) {
    (bytes32 r, bytes32 s, uint8 v) = splitSignature(firma);
    devolver ecrecover(ethSignedMessageHash, v, r, s);
  }
  
  función splitSignature (bytes de memoria sig)
    interno
    puro
    devuelve (bytes32 r, bytes32 s, uint8 v)
  {
    require(sig.length == 65, "Longitud de firma no válida");
    
    asamblea {
      r := mload(agregar(sig, 32))
      s := mload(agregar(sig, 64))
      v := byte(0, mload(agregar(sig, 96)))
    }
  }
  
  // Nuevo con verificación de firma
  función firmaMint (firma de memoria de bytes) externa {
    require(!hasMinted[msg.sender], "Ya acuñado");
    requerir (
      verificarFirma(msg.sender, firma),
      "Firma no válida"
    );
    
    hasMinted[msg.sender] = verdadero;
    _mint(msg.remitente, 1);
  }
}

4. Puerta de NFT/Token

Lista blanca basada en propiedad

Ventajas:Verificación automatizada, creación de comunidad, valor de mercado secundario

Desventajas:Acceso transferible, manipulación del mercado, dependencia externa

Ideal para:Recompensas comunitarias, acceso a DAO, beneficios escalonados

Implementación de activación de NFT:

interfaz IERC721 {
  función balanceOf(propietario de la dirección) vista externa devuelve (uint256);
}contrato NFTGatedWhitelist {
  NFT público requerido IERC721;
  
  constructor(dirección _nftAddress) {
    requeridoNFT = IERC721(_nftAddress);
  }
  
  modificador onlyNFTHolder() {
    requerir (
      requeridoNFT.balanceOf(msg.sender) &gt; 0,
      "Debe contener el NFT requerido"
    );
    _;
  }
  
  // Acceso restringido a titulares de NFT
  función privilegiodMint() externo onlyNFTHolder {
    _mint(msg.remitente, 1);
  }
}

Casos de uso del mundo real

Lista blanca de ICO/IDO

Flujo de proceso:

Fase de solicitud (1-2 semanas): solicitud de usuario, verificación KYC/AML, verificación de inversor acreditado, selección geográfica

Fase de selección: revisión de solicitudes, por orden de llegada O lotería O basado en criterios

Publicación en lista blanca: generar raíz de Merkle, implementar contrato, anunciar a la comunidad

Fase de venta: participan direcciones en la lista blanca, bloqueadas no incluidas en la lista blanca, acceso por tiempo limitado

Fase pública (opcional): abierta a todos después del período de la lista blanca, asignación restante

Lista blanca de NFT Mint

Acceso por niveles:

Nivel 1 - VIP (24 horas antes):

Equipo central, moderadores de Discord, primeros partidarios, contribuyentes especiales

Nivel 2 - Lista blanca (12 horas antes):

Miembros activos de la comunidad, participación en las redes sociales, ganadores del concurso, proyectos asociados

Nivel 3 - Lista de permitidos (6 horas antes):

Usuarios registrados, verificación básica, suscriptores de correo electrónico

Nivel 4 - Público:

Cualquiera, por orden de llegada, normalmente gasolina más alta

Implementación escalonada de NFT Mint:

contrato TieredNFTMint {
  bytes32 vip públicoMerkleRoot;
  bytes32 lista blanca públicaMerkleRoot;
  bytes32 lista de permitidos pública MerkleRoot;
  
  uint256 vipStartTime público = 1700000000;
  uint256 lista blanca públicaStartTime = vipStartTime + 24 horas;
  uint256 permitlistStartTime público = whitelistStartTime + 12 horas;
  uint256 public publicStartTime = enablelistStartTime + 6 horas;
  
  mapeo (dirección =&gt; uint256) public mintedAmount;
  uint256 público maxPerWallet = 3;
  
  función vipMint (cantidad uint256, bytes32 [] prueba de datos de llamada) externo {
    require(block.timestamp &gt;= vipStartTime, "Demasiado pronto");
    requerir (
      verificarMerkleProof(prueba, vipMerkleRoot, msg.sender),
      "No VIP"
    );
    require(mintedAmount[msg.sender] + monto &lt;= maxPerWallet);
    
    mintedAmount[msg.sender] += cantidad;
    _mint(msg.remitente, importe);
  }
  
  función lista blancaMint (cantidad uint256, bytes32 [] prueba de datos de llamada) externo {
    require(block.timestamp &gt;= whitelistStartTime, "Demasiado pronto");
    requerir (
      verificarMerkleProof(prueba, lista blancaMerkleRoot, msg.sender),
      "No incluido en la lista blanca"
    );
    require(mintedAmount[msg.sender] + monto &lt;= maxPerWallet);
    
    mintedAmount[msg.sender] += cantidad;
    _mint(msg.remitente, importe);
  }
  
  función publicMint (monto uint256) pagadero externo {
    require(block.timestamp &gt;= publicStartTime, "Demasiado pronto");
    require(msg.value &gt;= monto * PUBLIC_PRICE);
    require(mintedAmount[msg.sender] + monto &lt;= maxPerWallet);
    
    mintedAmount[msg.sender] += cantidad;
    _mint(msg.remitente, importe);
  }
}

Cumplimiento normativo

Ofertas de tokens de seguridad (STO):

Requisitos de cumplimiento:

  • • Verificación de inversionista acreditado ($1M+ patrimonio neto o $200K+ ingresos)
  • • Restricciones geográficas (Reg S, Reg D)
  • • Períodos de bloqueo
  • • Restricciones de transferencia
  • • Registros de auditoría

Acceso al protocolo DeFi

Prueba Beta:

Casos de uso:Implementación gradual, limitación de riesgos, programas de recompensas por errores, funciones premium, servicios institucionales

Mejores prácticas

Para proyectos

1. Comunicación clara:

Información esencial: criterios de la lista blanca, proceso de solicitud, método de selección, cronograma, límites de asignación, requisitos técnicos

2. Selección justa:

Criterios transparentes, medidas anti-sybil, enfoque comunitario primero, lotería por exceso de demanda, proceso de apelación

3. Seguridad:

Auditoría de contratos, claves de administración seguras, prueba en testnet, verificación de árboles merkle, limitación de velocidad, protección frontal

4. Experiencia de usuario:

Proceso de verificación simple, instrucciones claras, canales de soporte, herramientas de generación de pruebas, interfaz de verificación de estado

KYC/AML si es necesario, cumplimiento de la ley de valores, restricciones geográficas, términos de servicio, revisión legal

Para usuarios

Consejos de verificación:

  • • Sigue solo los canales oficiales
  • • Complete KYC honestamente
  • • Cumplir con los plazos
  • • Proporcionar información precisa
  • • Conserve el comprobante de solicitud
  • • Verificar direcciones de contrato

Seguridad:

  • • Nunca comparta claves privadas
  • • Verificar las URL del sitio web
  • • Verificar direcciones de contrato
  • • Cuidado con el phishing
  • • Usar carteras de hardware
  • • Prueba con pequeñas cantidades

Errores comunes:

  • • ❌ Falta la fecha límite para la solicitud
  • • ❌ KYC incompleto
  • • ❌ Dirección de billetera incorrecta
  • • ❌ No cumple con los criterios
  • • ❌ Caer en estafas
  • • ❌ Usando direcciones de intercambio

Comparación: Métodos

Método Costo de gasolina Escalabilidad Flexibilidad Seguridad Mejor para
Mapeo Alto Pobre Excelente Bueno Listas pequeñas
Árbol Merkle Bajo ExcelenteDeficiente Bueno Listas grandes
Firma Bajo Excelente Excelente Medio Listas dinámicas
NFT/Token Bajo Excelente Bueno Bueno Puerta de la comunidad

Tendencias futuras

1. Integración de identidad descentralizada

Lista blanca autosoberana con credenciales portátiles, verificación que preserva la privacidad, listas blancas multiplataforma

2. Selección impulsada por IA

Curación automatizada con análisis de comportamiento, puntuación de contribuciones, detección de sybil, distribución justa

3. Listas blancas de protocolos cruzados

Acceso interoperable con una lista blanca para múltiples usos, portabilidad de reputación, asociaciones de ecosistemas

4. Tecnología regulatoria

Automatización del cumplimiento con verificaciones de jurisdicción en tiempo real, listas blancas dinámicas, informes regulatorios

Conclusión

La lista blanca de tokens proporciona un control de acceso esencial para proyectos de criptomonedas, lo que permite el cumplimiento normativo, la distribución justa, la creación de comunidades y la seguridad. Desde el simple almacenamiento de mapas hasta los sofisticados árboles Merkle y la verificación de firmas, las opciones de implementación dependen de la escala, las necesidades de flexibilidad y las consideraciones de gas.

Conclusiones clave:

  • • Elija el método correcto: mapeo para listas pequeñas/dinámicas, Merkle para listas grandes/estáticas, firmas para flexibilidad
  • • Equilibrio entre acceso y equidad: criterios claros, selección transparente, enfoque centrado en la comunidad
  • • Priorice la seguridad: audite contratos, asegure las claves de administrador, proteja los datos del usuario
  • • Optimice la UX: procesos simples, instrucciones claras, herramientas útiles
  • • Cumpla con las normas: siga las regulaciones, implemente KYC cuando sea necesario, documente todo

A medida que las criptomonedas evolucionan, las listas blancas se volverán más sofisticadas, automatizadas y que preservarán la privacidad. Los proyectos que implementen cuidadosamente las listas blancas (equilibrando el control de acceso con la equidad, la seguridad con la usabilidad y el cumplimiento de la descentralización) construirán comunidades más fuertes y lanzamientos de tokens más exitosos.

Preguntas frecuentes

P: ¿Por qué los proyectos utilizan listas blancas en lugar de ventas abiertas?

A: Las listas blancas permiten: (1) Cumplimiento normativo (inversores acreditados, restricciones geográficas), (2) Prevención de bots, (3) Distribución justa a la comunidad, (4) Implementación controlada por seguridad.

P: ¿Cómo puedo incluirme en la lista blanca para una menta NFT?

R: Normalmente: (1) unirse al proyecto Discord/redes sociales, (2) interactuar con la comunidad, (3) seguir las instrucciones de la solicitud, (4) completar la verificación (KYC si es necesario), (5) enviar la dirección de la billetera, (6) esperar la confirmación. Cada proyecto es diferente.

P: ¿Se pueden cambiar las listas blancas después de la implementación?

R: Depende de la implementación. Almacenamiento de mapas: sí (si se incluyen controles administrativos). Árbol Merkle: requiere actualizar el hash raíz. Firma: sí (controlada por el backend). Puerta NFT: automática según la propiedad.

P: ¿Los lugares de la lista blanca son transferibles?

R: Generalmente no para listas blancas basadas en direcciones (vinculadas a una billetera específica). Excepción: el acceso controlado por NFT/token es transferible con la propiedad de NFT/token.

P: ¿Cuál es la diferencia en el costo del gas entre los métodos de la lista blanca?

A: Mapeo: más de 20 000 gases por adición de dirección. Merkle: ~3000-5000 gas para verificación (constante independientemente del tamaño de la lista blanca). Firma: ~3000-5000 gas para verificación. El ahorro de gasolina aumenta drásticamente con el tamaño de la lista.

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