Whitelist

¿Qué es una whitelist en cripto?

Una whitelist en cripto es una lista de direcciones de wallet, usuarios, contratos inteligentes, dispositivos o cuentas aprobados para realizar una acción específica.

El término más moderno y claro es allowlist, pero muchos usuarios de criptomonedas siguen buscando whitelist porque se ha utilizado durante años en acuñaciones de NFT, lanzamientos de tokens, airdrops, aplicaciones DeFi y ajustes de seguridad de carteras.

En términos sencillos, una whitelist decide quién tiene permiso para hacer algo.

Un proyecto cripto puede utilizar una whitelist para decidir quién puede acuñar un NFT anticipadamente.

Un lanzamiento de token puede utilizar una whitelist para decidir quién puede participar en una venta.

Un contrato inteligente puede utilizar una whitelist para decidir qué direcciones pueden llamar a una función protegida.

Una cartera puede utilizar una whitelist para decidir qué direcciones de retirada están aprobadas.

Un protocolo DeFi puede utilizar una whitelist para controlar qué activos, bóvedas u operadores pueden interactuar con un sistema.

El significado en ciberseguridad es similar.

NIST define una whitelist como una lista de entidades que se sabe que están aprobadas para su uso dentro de una organización o sistema de información mediante su definición de whitelist en el glosario.

En cripto, la entidad aprobada suele ser una dirección blockchain.

Para principiantes, la forma más sencilla de entender una whitelist es esta: si tu cartera está en la lista, puedes tener permiso para participar; si no está en la lista, el contrato inteligente o la plataforma puede rechazar tu acción.

Whitelist frente a allowlist

Whitelist y allowlist suelen significar lo mismo en cripto.

Allowlist es cada vez más habitual porque es más claro y directo.

El National Cyber Security Centre del Reino Unido indica que utiliza «allow list» y «deny list» en lugar de «whitelist» y «blacklist» porque los términos nuevos son más claros y menos ambiguos en su guía de terminología.

Actualmente, muchos equipos cripto utilizan allowlist en su documentación, mientras que muchos usuarios siguen diciendo whitelist en los chats de comunidad.

Para SEO y comprensión del usuario, ambos términos son útiles.

Una página sobre «Whitelist» debe explicar que allowlist es el término moderno.

La función es la misma: concede permiso a las direcciones o usuarios incluidos en la lista.

El concepto opuesto suele denominarse denylist o blocklist.

Una allowlist indica quién tiene permiso.

Una denylist indica quién está bloqueado.

En los contratos inteligentes, las allowlists suelen ser más fáciles de razonar desde el punto de vista de la seguridad porque todo se deniega de forma predeterminada salvo que se apruebe explícitamente.

Cómo funciona una whitelist cripto

Una whitelist cripto funciona comprobando si una dirección de wallet o cuenta coincide con una lista aprobada.

La lista puede almacenarse directamente en un contrato inteligente.

La lista puede almacenarse off-chain por un equipo de proyecto.

La lista puede representarse mediante una raíz de Merkle.

La lista puede controlarse mediante mensajes firmados.

La lista también puede gestionarse mediante control de acceso basado en roles.

Cuando un usuario intenta acuñar, reclamar, retirar, votar, operar o realizar otra acción restringida, el sistema comprueba si está aprobado.

Si la dirección está aprobada, la acción puede continuar.

Si la dirección no está aprobada, la acción falla o se bloquea.

En un contrato inteligente sencillo, el contrato puede almacenar un mapping que marque las direcciones aprobadas como true o false.

En una gran acuñación de NFT, almacenar directamente miles de direcciones on-chain puede resultar costoso.

Por este motivo, muchos proyectos utilizan árboles de Merkle para demostrar que una cartera está en una lista sin almacenar la lista completa on-chain.

Esto hace que la verificación de whitelist sea más barata y escalable.

Por qué se utilizan whitelists en cripto

Los proyectos cripto utilizan whitelists para controlar el acceso.

El control de acceso es importante porque las blockchains son sistemas abiertos.

Por lo general, cualquiera puede enviar una transacción a un contrato inteligente público si el contrato lo permite.

Una whitelist añade una capa de permisos.

OpenZeppelin explica que el control de acceso de contratos inteligentes regula quién puede acuñar tokens, votar propuestas, congelar transferencias o realizar otras acciones sensibles mediante su documentación de Access Control.

Para los proyectos NFT, las whitelists pueden recompensar a los primeros seguidores.

Para los lanzamientos de tokens, las whitelists pueden controlar quién participa en una venta.

Para los protocolos DeFi, las whitelists pueden reducir el riesgo al limitar los contratos o activos aceptados.

Para las carteras, las whitelists de retirada pueden proteger a los usuarios frente al envío de fondos a direcciones desconocidas.

Para las instituciones, las whitelists pueden contribuir al cumplimiento al permitir solo contrapartes aprobadas.

Para los desarrolladores, las whitelists pueden ayudar a proteger las funciones administrativas frente al uso no autorizado.

En todos los casos, una whitelist es un filtro de permisos.

Whitelists en acuñaciones de NFT

Las whitelists de NFT se popularizaron durante el boom de los NFT porque los proyectos querían controlar el acceso anticipado a la acuñación.

Una whitelist puede permitir a determinadas carteras acuñar antes de la venta pública.

Puede ofrecer un precio de acuñación más bajo.

Puede reservar una asignación de acuñación garantizada.

Puede reducir la competencia por el gas al distribuir el acceso a la acuñación entre distintas ventanas temporales.

Puede recompensar a miembros de la comunidad que se unieron pronto, contribuyeron al proyecto, ganaron sorteos o completaron determinadas tareas.

Un proceso típico de whitelist de NFT comienza cuando un proyecto recopila direcciones de wallet elegibles.

Posteriormente, el proyecto puede publicar las reglas de acuñación y una ventana de reclamación.

Durante la acuñación, el contrato inteligente comprueba si la cartera tiene permiso.

Si la cartera está aprobada y todavía no ha utilizado su asignación, puede acuñar.

Si la cartera no está aprobada, la transacción se revierte o el botón de acuñación no funciona.

Algunos contratos NFT utilizan pruebas de Merkle para una acuñación mediante allowlist eficiente en gas.

La guía de contratos inteligentes NFT de QuickNode explica que utilizar un árbol de Merkle puede hacer que la verificación de allowlist sea independiente del tamaño de la lista y requiere una prueba de Merkle para comprobar si una dirección se encuentra dentro del árbol mediante su análisis de allowlists para contratos inteligentes NFT.

Whitelists en lanzamientos de tokens

Los lanzamientos de tokens pueden utilizar whitelists para controlar la participación en ventas.

Un proyecto puede exigir que los usuarios se registren antes de una venta.

Puede requerir verificación de wallet.

Puede limitar la participación por región, tipo de usuario, puntuación de elegibilidad o reglas de campaña.

Puede utilizar una whitelist para impedir que los bots compren toda la asignación.

También puede utilizar una whitelist para aplicar normas de cumplimiento.

En algunos lanzamientos, una whitelist solo concede el derecho a participar.

No garantiza beneficios.

No garantiza que el precio de un token suba.

No garantiza liquidez después del lanzamiento.

No garantiza que el proyecto sea seguro.

Esta distinción es importante porque los usuarios suelen tratar las plazas en whitelists como activos valiosos.

Una whitelist puede mejorar el acceso, pero no puede eliminar el riesgo de mercado, el riesgo de contratos inteligentes, el riesgo de tokenomics ni el riesgo de ejecución del proyecto.

Los usuarios deben seguir evaluando la oferta, el vesting, la credibilidad del equipo, el avance del producto, la liquidez, las auditorías de contratos inteligentes y los riesgos legales antes de participar.

Whitelists en airdrops

Los airdrops pueden utilizar whitelists para decidir quién puede reclamar tokens.

Un proyecto puede realizar una snapshot de blockchain y crear después una lista de direcciones de wallet elegibles.

La elegibilidad puede depender de la actividad de la cartera, las tenencias de tokens, la participación en gobernanza, el uso de testnet, la propiedad de NFT, la interacción con el protocolo o la contribución a la comunidad.

La lista final de direcciones elegibles se convierte en una whitelist o allowlist de airdrop.

Cuando un usuario visita la página de reclamación, el sistema comprueba si la cartera es elegible.

Si la cartera está en la lista, el usuario puede poder reclamar tokens.

Si no está en la lista, la reclamación falla.

La guía de airdrops de criptomonedas de Investopedia explica que algunos airdrops seleccionan usuarios según criterios específicos y pueden utilizar snapshots o tenencias de wallet mediante su guía de airdrops de criptomonedas.

Las whitelists de airdrops son útiles, pero también son objeto de un uso abusivo intenso por parte de estafadores.

Las páginas de airdrop falsas suelen fingir que una cartera está incluida en una whitelist y después engañan a los usuarios para que firmen aprobaciones maliciosas.

Un airdrop real nunca debe pedir una frase de recuperación o clave privada.

Whitelists en contratos inteligentes

Los contratos inteligentes utilizan whitelists para el control de acceso.

Un contrato puede permitir que solo las direcciones aprobadas acuñen tokens.

Un contrato puede permitir que solo operadores aprobados llamen a funciones administrativas.

Una bóveda DeFi puede permitir únicamente activos aprobados.

Un bridge puede permitir únicamente relayers aprobados.

Un protocolo de préstamos puede permitir únicamente tipos de colateral aprobados.

Un contrato de token puede permitir únicamente agentes de transferencia aprobados en un sistema con permisos.

La documentación de seguridad de contratos inteligentes de Ethereum advierte que los contratos inteligentes pueden controlar grandes cantidades de valor y crear oportunidades para atacantes mediante su guía de seguridad de contratos inteligentes.

Por ello, el control de acceso debe diseñarse cuidadosamente.

Una whitelist puede mejorar la seguridad, pero una whitelist mal diseñada puede crear riesgo de centralización o riesgo administrativo oculto.

Si una sola clave privada puede añadir o eliminar direcciones de una whitelist, esa clave privada se vuelve poderosa.

Si la clave administrativa se ve comprometida, el atacante puede cambiar permisos y abusar del contrato.

Un buen diseño de whitelist debe incluir reglas claras, control administrativo seguro, registros de eventos, auditorías y gobernanza transparente cuando corresponda.

Whitelists en la seguridad de carteras

Las carteras y los sistemas de custodia pueden utilizar whitelists de retirada.

Una whitelist de retirada es una lista de direcciones aprobadas a las que pueden enviarse fondos.

Si una dirección de retirada no está aprobada, la cartera o plataforma bloquea la retirada.

Esto puede proteger a los usuarios frente a errores y el compromiso de la cuenta.

Por ejemplo, si un atacante obtiene acceso a la cuenta de un usuario pero no puede añadir una nueva dirección de retirada sin un retraso o verificación adicional, la whitelist puede reducir el riesgo de robo.

Algunas carteras también permiten etiquetar direcciones de confianza.

Algunos sistemas de custodia requieren aprobación multifirma antes de añadir una dirección nueva.

Algunas configuraciones institucionales utilizan whitelists de direcciones para cumplir políticas internas de riesgo y cumplimiento.

Las whitelists de retirada son útiles, pero no son perfectas.

Si un usuario incluye en whitelist una dirección incorrecta, los fondos aún pueden perderse.

Si un atacante controla una dirección aprobada, la whitelist no ayuda.

Si un usuario aprueba un contrato inteligente malicioso, una whitelist de retirada puede no proteger todos los activos.

La seguridad de la cartera sigue requiriendo protección de la clave privada, revisión de transacciones, gestión de aprobaciones y conciencia sobre phishing.

Whitelists en DeFi

Los protocolos DeFi pueden utilizar whitelists para gestionar el riesgo.

Un protocolo puede incluir en whitelist activos que pueden utilizarse como colateral.

Una bóveda puede incluir en whitelist estrategias que pueden gestionar fondos.

Un mercado de préstamos puede incluir en whitelist o listar únicamente tokens específicos.

Un pool con permisos puede incluir en whitelist a usuarios que cumplan las reglas de elegibilidad.

Un sistema de oráculos puede incluir en whitelist a proveedores de datos o feeds de precios.

Un sistema de gobernanza puede incluir en whitelist direcciones que pueden realizar acciones de emergencia.

Estos controles pueden hacer que un protocolo sea más seguro, pero también reducen su apertura.

Un protocolo DeFi completamente abierto permite que cualquiera interactúe si cumple las reglas del contrato inteligente.

Un sistema DeFi con whitelist añade una capa de permisos.

Esa capa de permisos puede ser útil para cumplimiento, seguridad o un lanzamiento controlado.

También puede crear supuestos de confianza, ya que los usuarios deben confiar en quien controla la lista.

Los usuarios deben preguntar quién puede añadir o eliminar direcciones, si los cambios se retrasan, si la gobernanza controla la lista y si la lista puede utilizarse de forma abusiva.

Whitelists y árboles de Merkle

Un árbol de Merkle es una estructura criptográfica que permite demostrar eficazmente que un elemento pertenece a un conjunto.

En las whitelists cripto, el conjunto suele ser una lista de direcciones de wallet aprobadas.

En lugar de almacenar cada dirección directamente en el contrato inteligente, el proyecto almacena una única raíz de Merkle.

Cuando un usuario intenta reclamar o acuñar, proporciona una prueba de Merkle.

El contrato inteligente comprueba la prueba frente a la raíz de Merkle.

Si la prueba es válida, el contrato sabe que la dirección forma parte de la lista aprobada.

Esto puede ahorrar gas porque el contrato no necesita almacenar miles de direcciones individuales.

También puede facilitar la gestión de allowlists grandes.

Sin embargo, las allowlists de Merkle pueden resultar confusas para los usuarios.

Un usuario puede ser elegible, pero el front end debe proporcionar la prueba correcta.

Si el sitio web está roto o la prueba es incorrecta, la reclamación puede fallar.

Los usuarios también deben verificar que el sitio de acuñación es oficial, ya que los estafadores suelen copiar páginas de reclamación de allowlists.

Whitelists y mensajes firmados

Algunos sistemas cripto utilizan mensajes firmados en lugar de una whitelist almacenada.

En este modelo, un servidor de confianza firma un mensaje que indica que una cartera tiene permiso para realizar una acción.

El usuario envía esa firma al contrato inteligente.

El contrato inteligente verifica que la firma procede de un firmante aprobado.

Si la firma es válida y no ha caducado ni se ha utilizado, se permite la acción.

Este método puede ser flexible porque el proyecto no necesita publicar una lista completa on-chain.

También puede admitir elegibilidad dinámica.

Sin embargo, crea confianza en el sistema de firma.

Si el servidor de firma se ve comprometido, los atacantes pueden generar aprobaciones no autorizadas.

Si las reglas de firma están mal diseñadas, pueden producirse ataques de repetición o reclamaciones dobles.

Las buenas allowlists de mensajes firmados deben incluir ID de cadena, dirección del contrato, dirección de wallet, asignación, fecha límite, nonce y separación clara de dominio.

Los usuarios deben leer cuidadosamente los avisos de la cartera antes de firmar cualquier mensaje.

Asignación de whitelist

Una asignación de whitelist es la cantidad que una dirección incluida en whitelist puede acuñar, reclamar, comprar o retirar.

En una acuñación de NFT, una cartera puede tener permiso para acuñar un NFT.

Otra cartera puede tener permiso para acuñar tres NFT.

En una venta de tokens, una dirección puede tener un importe máximo de compra.

En un airdrop, una dirección puede tener una cantidad de tokens reclamable según su actividad.

Las reglas de asignación son importantes porque estar en una whitelist no siempre significa tener acceso ilimitado.

Un usuario puede estar aprobado, pero seguir fallando si supera la asignación.

Un usuario también puede fallar si la ventana de reclamación ha terminado.

Un proyecto puede utilizar límites por cartera para reducir la concentración de whales.

También puede utilizar distintos niveles para los primeros seguidores, colaboradores, titulares de NFT, usuarios de testnet o participantes en gobernanza.

Los usuarios deben leer atentamente las reglas de asignación antes de enviar transacciones.

Una transacción fallida puede seguir costando gas en algunas redes.

Snapshot de whitelist

Una snapshot de whitelist es un registro de la elegibilidad de una cartera en un momento específico.

Los proyectos utilizan snapshots para impedir que los usuarios cambien su comportamiento después de conocer las reglas.

Por ejemplo, un airdrop puede contabilizar las carteras que mantenían un token antes de un número de bloque concreto.

Un proyecto NFT puede contabilizar los titulares de una colección anterior en un momento determinado.

Un sistema de gobernanza puede contabilizar votantes o delegados en un bloque definido.

Las snapshots hacen que la elegibilidad sea más objetiva.

Sin embargo, las snapshots también pueden generar confusión.

Un usuario puede comprar un token después de la snapshot y descubrir que no es elegible.

Un usuario puede mover activos a otra cartera después de la snapshot y seguir siendo elegible con la cartera antigua.

Un usuario puede utilizar una cartera de contrato inteligente que no sea compatible con la interfaz de reclamación.

Las reglas de snapshot deben anunciarse claramente.

Los usuarios deben comprobar el bloque, la marca temporal, el activo, la red y la dirección de wallet exactos utilizados para la elegibilidad.

Whitelist grinding y ataques Sybil

El whitelist grinding ocurre cuando los usuarios crean muchas carteras o cuentas para aumentar la probabilidad de incluirse en una whitelist.

Un ataque Sybil es un término más amplio para una persona o grupo que finge ser muchos usuarios independientes.

En cripto, el comportamiento Sybil es habitual porque crear carteras es barato.

Un proyecto puede querer recompensar a usuarios reales, pero los bots pueden crear miles de carteras para farmear elegibilidad.

Esto puede hacer que las whitelists sean menos justas.

Los proyectos pueden combatir los ataques Sybil mediante verificaciones de identidad, herramientas proof-of-humanity, análisis de grafos sociales, puntuación de actividad, requisitos de depósito, sistemas antibot o revisión manual.

Cada método tiene sus contrapartidas.

Las verificaciones estrictas de identidad pueden reducir la privacidad.

La puntuación de actividad puede perjudicar a usuarios nuevos.

La revisión manual puede crear sesgos o errores.

Los requisitos de depósito pueden excluir a usuarios más pequeños.

Un buen diseño de whitelist debe equilibrar equidad, privacidad, experiencia de usuario y resistencia al farming.

Whitelist y KYC

Algunas whitelists cripto están vinculadas a verificaciones know-your-customer, habitualmente denominadas KYC.

KYC significa verificar la identidad del usuario por motivos de cumplimiento o control de riesgos.

Una venta de tokens, un pool con permisos o una plataforma de activos regulados puede requerir que los usuarios completen KYC antes de añadir su cartera a una allowlist.

Esto puede ayudar al proyecto a cumplir requisitos legales.

También puede limitar el acceso por región o tipo de usuario.

Sin embargo, las whitelists basadas en KYC crean preocupaciones sobre privacidad y seguridad de los datos.

Es posible que los usuarios deban enviar información personal a un proveedor externo.

Si ese proveedor se ve comprometido, la información sensible puede quedar expuesta.

Los usuarios deben entender quién recopila los datos, cómo se almacenan, qué reglas se aplican y si el proyecto es legítimo.

Una whitelist que solicita información de identidad debe tratarse con más cuidado que una allowlist sencilla de direcciones de wallet.

Los usuarios deben evitar cargar documentos en enlaces enviados mediante mensajes directos o canales no oficiales.

Whitelist y claves privadas

Una whitelist nunca requiere una clave privada o frase de recuperación.

Esta es una de las normas de seguridad más importantes en cripto.

Un proyecto puede pedir una dirección pública de wallet para añadirla a una whitelist.

Un proyecto puede pedir a los usuarios que conecten una cartera para comprobar la elegibilidad.

Un proyecto puede pedir a los usuarios que firmen un mensaje para demostrar la propiedad de la cartera.

Ninguna de estas acciones debe requerir que el usuario revele una frase de recuperación o clave privada.

La FTC advierte que las estafas con criptomonedas suelen utilizar oportunidades falsas y tácticas engañosas para engañar a los usuarios mediante su guía sobre estafas con criptomonedas.

Chainalysis también ha descrito ataques de phishing de aprobaciones en los que se engaña a víctimas para que concedan permisos que permiten a delincuentes vaciar carteras mediante su informe sobre phishing de aprobaciones.

Si una página de whitelist pide una frase de recuperación, casi con toda seguridad es una estafa.

Si una reclamación de whitelist solicita una aprobación ilimitada de tokens, los usuarios deben detenerse y revisar la transacción cuidadosamente.

Estafas de whitelist

Las estafas de whitelist son habituales en cripto porque los usuarios quieren acceso anticipado.

Los estafadores utilizan urgencia, escasez y miedo a perderse algo para lograr que los usuarios actúen rápidamente.

Una cuenta falsa puede decir que un usuario ha ganado una plaza en whitelist.

Un sitio web falso puede indicar que una cartera es elegible para un airdrop.

Una página de acuñación falsa puede copiar el diseño de un proyecto real.

Un moderador de comunidad falso puede pedir a los usuarios que verifiquen su cartera.

Una cuenta de soporte falsa puede afirmar que el usuario debe restablecer el acceso a la whitelist.

El peligro normalmente no es la palabra whitelist en sí.

El peligro es la transacción o el mensaje que se engaña al usuario para que firme.

Una aprobación maliciosa puede permitir a un estafador transferir tokens o NFT.

Una firma maliciosa puede autorizar una acción que el usuario no entiende.

Una solicitud de frase de recuperación puede dar al estafador control completo de la cartera.

Los usuarios deben verificar los enlaces oficiales, evitar enlaces de acuñación enviados por mensaje directo, guardar páginas de confianza en marcadores y utilizar herramientas de seguridad de cartera antes de interactuar con cualquier reclamación de whitelist.

Whitelist frente a venta pública

Una venta mediante whitelist está restringida a carteras aprobadas.

Una venta pública está abierta a cualquiera que pueda interactuar con el contrato y cumplir las reglas de venta.

Las ventas mediante whitelist se utilizan a menudo antes de las ventas públicas.

Pueden dar acceso anticipado a miembros de la comunidad.

Pueden reducir las guerras de gas al controlar la demanda.

Pueden ayudar a un proyecto a recompensar a colaboradores reales.

Las ventas públicas pueden ser más abiertas, pero pueden atraer bots, costes de gas elevados y agotamientos rápidos.

Ninguno de los dos modelos es automáticamente mejor.

Una venta mediante whitelist puede ser injusta si el proceso de selección está oculto o manipulado.

Una venta pública puede ser injusta si los bots capturan la mayor parte de la oferta.

Los usuarios deben evaluar las reglas, la asignación, el precio, el periodo de bloqueo, el contrato inteligente, el comportamiento del equipo y el riesgo antes de participar en cualquiera de los formatos.

El acceso no equivale a valor.

Whitelist frente a lista de espera

Una whitelist y una lista de espera no son lo mismo.

Una whitelist significa que una cartera o usuario está aprobado para acceder.

Una lista de espera significa que un usuario espera un posible acceso posterior.

Algunos proyectos utilizan ambas.

Un usuario puede unirse primero a una lista de espera.

El proyecto puede seleccionar más adelante a algunos usuarios de la lista de espera para la whitelist.

Una lista de espera no garantiza una acuñación, reclamación de tokens, asignación de venta ni aprobación de cuenta.

Los usuarios de criptomonedas deben leer cuidadosamente la redacción.

«Únete a la lista de espera» normalmente significa registro de interés.

«Estás en la whitelist» normalmente significa acceso aprobado conforme a determinadas reglas.

Aun así, el usuario puede tener que completar la acción antes de una fecha límite.

Una plaza en whitelist puede caducar si el usuario no cumple la ventana de reclamación.

Whitelist frente a preventa

Una preventa es una venta anticipada antes de un lanzamiento público.

Una whitelist es la lista de usuarios autorizados a participar en esa preventa.

Los dos términos están relacionados, pero no son idénticos.

Un proyecto puede celebrar una preventa solo para carteras incluidas en whitelist.

Un proyecto también puede celebrar una preventa sin whitelist si utiliza otra regla de acceso.

Estar en whitelist para una preventa no garantiza que la preventa sea segura.

Las preventas pueden seguir implicando tokenomics deficientes, asignaciones internas ocultas, liquidez débil, contratos no auditados, equipos falsos o riesgo de rug pull.

Los usuarios deben evaluar el proyecto en lugar de asumir que el acceso a una whitelist es un sello de calidad.

Los estafadores suelen hacer que las plazas de whitelist parezcan exclusivas porque la exclusividad genera presión.

Un usuario prudente debe detenerse cuando un proyecto afirma que quedan solo unos minutos para reclamar una plaza.

Whitelist frente a control de acceso basado en roles

Una whitelist sencilla suele conceder el mismo permiso a todas las direcciones aprobadas.

El control de acceso basado en roles concede permisos diferentes a roles distintos.

Por ejemplo, un rol puede tener permiso para pausar un contrato.

Otro rol puede tener permiso para acuñar.

Otro rol puede tener permiso para actualizar metadatos.

Otro rol puede tener permiso para gestionar una whitelist.

La documentación de control de acceso de OpenZeppelin explica los sistemas de permisos basados en roles y por qué es fundamental entender quién puede hacer qué en los contratos inteligentes.

El control de acceso basado en roles es más flexible que una whitelist sencilla.

También es más complejo.

Los sistemas de permisos complejos pueden ocultar poderes administrativos peligrosos.

Los usuarios y auditores deben comprobar qué roles existen, quién los controla, si pueden transferirse, si utilizan control multifirma y si existen retrasos temporales.

Una whitelist responde a «¿tiene permiso esta dirección?».

El control de acceso basado en roles responde a «¿qué puede hacer exactamente esta dirección?».

Whitelist y comisiones de gas

Las transacciones de whitelist pueden seguir requiriendo comisiones de gas.

Estar aprobado no significa que una transacción sea gratuita.

Un usuario puede tener que pagar comisiones de red para acuñar, reclamar, aprobar, transferir o interactuar con un contrato inteligente.

Si la transacción falla, el usuario puede seguir perdiendo gas en función de la red y del tipo de fallo.

Por ello, los usuarios deben confirmar que están en la red correcta y dentro de la ventana de reclamación correcta.

También deben comprobar que su dirección de wallet coincide exactamente con la dirección incluida en whitelist.

Si una acuñación de NFT utiliza una prueba de Merkle, la reclamación puede fallar si la interfaz proporciona una prueba incorrecta.

Si una venta de tokens tiene un límite por cartera, la transacción puede fallar si el usuario intenta comprar demasiado.

Si una whitelist ya se ha utilizado, la segunda reclamación puede fallar.

Los usuarios deben leer los resultados de la simulación de transacciones cuando estén disponibles antes de firmar.

Whitelist y privacidad

Las whitelists pueden afectar a la privacidad.

Si un proyecto publica una lista de direcciones de wallet elegibles, los observadores pueden analizar esas carteras.

Pueden ver saldos, historial de transacciones, tenencias de NFT, actividad DeFi y otros comportamientos on-chain.

Incluso si un proyecto no publica la lista completa, las reclamaciones exitosas pueden revelar las carteras elegibles con el tiempo.

Los usuarios que se preocupan por la privacidad pueden utilizar carteras separadas para diferentes actividades.

Sin embargo, utilizar muchas carteras puede crear riesgo de gestión.

También puede generar preocupaciones Sybil si el proyecto trata de recompensar a usuarios únicos.

La privacidad y la elegibilidad suelen estar en tensión.

Un proyecto quiere identificar usuarios reales.

Un usuario puede querer evitar vincular toda su actividad a una sola dirección.

Un buen diseño de whitelist debe recopilar solo la información necesaria y explicar cómo se utilizan los datos de elegibilidad.

Cómo comprobar si una cartera está en whitelist

La forma más segura de comprobar el estado de una whitelist es mediante una página oficial del proyecto o un método de contrato.

Los usuarios deben comenzar desde el sitio web oficial del proyecto o canales sociales verificados.

Deben evitar enlaces de mensajes directos, respuestas, comentarios y anuncios aleatorios de búsqueda.

Deben confirmar la dirección del contrato y la red.

Solo deben conectar una cartera si la página está verificada.

Deben leer el aviso de la cartera antes de firmar cualquier cosa.

Algunas comprobaciones solo requieren leer datos públicos y no necesitan una firma.

Algunas comprobaciones requieren una firma de mensaje inocua para demostrar la propiedad de la cartera.

Algunas acciones requieren una transacción on-chain y gas.

Los usuarios deben entender qué tipo de acción están realizando.

Si un comprobador de whitelist solicita una frase de recuperación, clave privada o información completa de recuperación de cartera, los usuarios deben cerrarlo inmediatamente.

Cómo deben crear los proyectos una whitelist

Los proyectos deben diseñar whitelists con reglas claras.

Deben explicar los criterios de elegibilidad antes de recopilar direcciones de wallet.

Deben evitar cambiar las reglas en silencio después de que los usuarios inviertan tiempo o dinero para cumplir los requisitos.

Deben utilizar patrones seguros de contratos inteligentes.

Deben considerar pruebas de Merkle o mensajes firmados para listas grandes.

Deben probar la lógica de reclamación antes del lanzamiento.

Deben publicar enlaces oficiales en varios canales verificados.

Deben advertir a los usuarios de que nunca se requieren frases de recuperación.

Deben limitar los poderes administrativos cuando sea posible.

Deben utilizar controles multifirma y retrasos temporales para funciones sensibles.

Deben emitir eventos cuando cambien los ajustes de whitelist.

Deben documentar la asignación, las fechas límite, el precio, las reglas de reembolso y los factores de riesgo.

OWASP explica que la validación mediante allowlist define exactamente qué está autorizado y rechaza todo lo demás mediante su Input Validation Cheat Sheet.

El mismo principio se aplica al control de acceso cripto: define qué está permitido y aplícalo de forma coherente.

Ventajas de una whitelist

La primera ventaja de una whitelist es el acceso controlado.

Un proyecto puede decidir quién puede acuñar, reclamar, comprar, retirar o llamar a una función.

La segunda ventaja es la reducción de bots.

Las whitelists pueden dificultar que los bots automatizados capturen toda la oferta durante un lanzamiento.

La tercera ventaja son las recompensas para la comunidad.

Los proyectos pueden recompensar a los primeros seguidores, colaboradores, testers, votantes, creadores o holders a largo plazo.

La cuarta ventaja es una menor presión en el lanzamiento.

Las ventanas de whitelist pueden reducir las guerras de gas al distribuir la demanda a lo largo del tiempo.

La quinta ventaja es un mejor control de cumplimiento.

Algunos sistemas necesitan participantes aprobados por motivos legales o institucionales.

La sexta ventaja es la seguridad de la cartera.

Las whitelists de retirada pueden reducir el riesgo de enviar fondos a direcciones desconocidas.

La séptima ventaja es la seguridad de los contratos inteligentes.

Los controles de acceso pueden impedir que usuarios no autorizados llamen a funciones sensibles.

Riesgos de una whitelist

El primer riesgo es la falsa confianza.

Los usuarios pueden creer que estar en whitelist significa que el proyecto es seguro.

No es así.

El segundo riesgo es la centralización.

Normalmente, alguien debe decidir quién se añade o elimina.

El tercer riesgo es el compromiso de la clave administrativa.

Si el control de la whitelist recae en una sola clave privada, esa clave puede convertirse en un objetivo importante para atacantes.

El cuarto riesgo es la asignación injusta.

Las whitelists pueden favorecer a personas internas, bots, influencers o usuarios que comprenden reglas ocultas.

El quinto riesgo es el phishing.

Los enlaces falsos de whitelist son habituales.

El sexto riesgo es la pérdida de privacidad.

La elegibilidad para una whitelist puede revelar actividad de cartera o vincular usuarios a direcciones.

El séptimo riesgo es el fallo técnico.

Pruebas de Merkle incorrectas, snapshots equivocadas, front ends rotos o errores de contrato pueden bloquear a usuarios legítimos.

El octavo riesgo es la exageración.

La escasez de whitelist puede hacer que los usuarios ignoren los fundamentos del proyecto.

Malentendidos comunes sobre las whitelists

Un malentendido es que el acceso a whitelist garantiza beneficios.

No es así.

Otro malentendido es que una whitelist significa que un proyecto ha sido verificado por la blockchain.

No es así, porque la blockchain solo aplica las reglas del código.

Un tercer malentendido es que los usuarios necesitan compartir una frase de recuperación para unirse a una whitelist.

Nunca deben hacerlo.

Un cuarto malentendido es que conectar una cartera por sí solo siempre es seguro.

Conectar una cartera suele ser menos peligroso que firmar, pero los usuarios pueden seguir siendo guiados hacia aprobaciones maliciosas después de conectarla.

Un quinto malentendido es que todas las whitelists son justas.

Algunas son justas, otras están mal gestionadas y otras se diseñan para generar hype.

Un sexto malentendido es que una allowlist no puede cambiarse.

Algunas listas son fijas, mientras que otras pueden actualizarse mediante administradores o gobernanza.

Un séptimo malentendido es que una whitelist siempre está on-chain.

Muchas whitelists se almacenan off-chain o se representan mediante pruebas.

Lista de comprobación de seguridad de whitelist

Los usuarios deben verificar el sitio web oficial antes de unirse a cualquier whitelist.

Los usuarios deben confirmar la red y dirección de contrato correctas.

Los usuarios nunca deben compartir una frase de recuperación o clave privada.

Los usuarios deben evitar enlaces de acuñación de mensajes directos.

Los usuarios deben leer cuidadosamente los avisos de la cartera antes de firmar.

Los usuarios deben comprobar si una transacción concede aprobaciones de token o NFT.

Los usuarios deben entender el precio de acuñación, el importe reclamable, la asignación y la fecha límite.

Los usuarios deben comprobar si el proyecto ha publicado reglas claras.

Los usuarios deben evaluar el proyecto, no solo la plaza de whitelist.

Los usuarios deben mantener una cartera separada para acuñaciones de mayor riesgo si tienen suficiente experiencia para gestionar varias carteras de forma segura.

Los usuarios deben revocar aprobaciones arriesgadas cuando ya no sean necesarias.

Los usuarios deben recordar que la urgencia es una táctica habitual de estafa.

Whitelist en términos sencillos

Una whitelist es una lista aprobada.

En cripto, la lista normalmente contiene direcciones de wallet.

Si tu dirección está en la lista, puedes tener permiso para acuñar, reclamar, comprar, retirar o utilizar una función.

Si tu dirección no está en la lista, el sistema puede bloquearte.

Whitelist y allowlist suelen significar lo mismo.

Allowlist es el término moderno más claro.

Las whitelists pueden resultar útiles para el control de acceso, las recompensas comunitarias, las acuñaciones de NFT, los airdrops y la seguridad de las carteras.

También pueden ser utilizadas de forma abusiva por estafadores que crean páginas de reclamación falsas.

Para principiantes, la regla más importante es sencilla.

Una whitelist real puede necesitar tu dirección pública de wallet, pero nunca necesita tu frase de recuperación.

Preguntas frecuentes

¿Qué significa whitelist en cripto?

Una whitelist en cripto es una lista de direcciones de wallet, usuarios o contratos aprobados que tienen permiso para realizar una acción específica.

¿Es whitelist lo mismo que allowlist?

Sí. Whitelist y allowlist suelen significar lo mismo, pero allowlist es más claro y moderno.

¿Qué es una whitelist de NFT?

Una whitelist de NFT es una lista de carteras aprobadas que pueden acuñar un NFT durante una ventana de acuñación restringida.

¿Qué es una whitelist para una venta de tokens?

Una whitelist para una venta de tokens es una lista de participantes aprobados que pueden participar en una venta de tokens conforme a reglas específicas.

¿Qué es una whitelist de airdrop?

Una whitelist de airdrop es una lista de carteras elegibles que pueden reclamar tokens o recompensas.

¿Estar en whitelist garantiza beneficios?

No. El acceso mediante whitelist solo concede permiso para participar y no garantiza beneficios ni el éxito del proyecto.

¿Puede almacenarse una whitelist on-chain?

Sí. Una whitelist puede almacenarse directamente en un contrato inteligente, pero las listas grandes suelen utilizar pruebas de Merkle o sistemas off-chain.

¿Qué es una whitelist de Merkle?

Una whitelist de Merkle utiliza una raíz de Merkle y pruebas de Merkle para verificar que una cartera forma parte de una lista aprobada sin almacenar cada dirección on-chain.

¿Por qué los proyectos utilizan whitelists?

Los proyectos utilizan whitelists para controlar el acceso, recompensar a los primeros usuarios, reducir bots, gestionar el cumplimiento o proteger funciones sensibles de contratos inteligentes.

¿Pueden ser injustas las whitelists?

Sí. Las whitelists pueden ser injustas si las reglas de asignación no están claras, se favorece a personas internas, los bots farmean plazas o los equipos de proyecto cambian reglas sin transparencia.

¿Puede cambiarse una whitelist?

Algunas whitelists son fijas, mientras que otras pueden cambiarse mediante administradores, multifirmas, gobernanza o sistemas off-chain.

¿Qué es una whitelist de retirada?

Una whitelist de retirada es una lista de direcciones aprobadas a las que una cartera o sistema de custodia permite enviar fondos.

¿Necesito conectar mi cartera para comprobar el estado de whitelist?

A veces sí, pero los usuarios solo deben conectar mediante enlaces oficiales y nunca deben compartir una frase de recuperación.

¿Debo firmar un mensaje para una whitelist?

Firmar un mensaje puede ser normal para demostrar la propiedad de una cartera, pero los usuarios deben leer el mensaje cuidadosamente y evitar solicitudes sospechosas.

¿Puede una reclamación de whitelist vaciar mi cartera?

Una reclamación de whitelist falsa puede vaciar una cartera si engaña al usuario para que firme aprobaciones maliciosas o revele información privada.

¿Cuál es la principal señal de advertencia de una estafa de whitelist?

La principal señal de advertencia es cualquier sitio o persona que pida una frase de recuperación, clave privada o aprobación urgente de cartera mediante un enlace no oficial.

¿Es una whitelist lo mismo que KYC?

No. Una whitelist es una lista de acceso aprobada, mientras que KYC es un proceso de verificación de identidad que puede utilizarse antes de añadir a alguien a una whitelist.

¿Qué debo comprobar antes de utilizar un enlace de whitelist?

Los usuarios deben verificar el sitio web oficial, la dirección del contrato, la red, las reglas de reclamación, el aviso de la cartera y la legitimidad del proyecto antes de firmar nada.

Conclusión

Una whitelist es una de las herramientas de control de acceso más habituales en cripto.

Se utiliza para acuñaciones de NFT, ventas de tokens, airdrops, retiradas de cartera, permisos DeFi, funciones administrativas de contratos inteligentes y recompensas comunitarias.

El término moderno allowlist es más claro, pero whitelist sigue siendo ampliamente utilizado por los usuarios de criptomonedas.

La idea básica es sencilla: las direcciones aprobadas pueden actuar y las direcciones no aprobadas no pueden hacerlo.

Las whitelists pueden hacer que los lanzamientos sean más fluidos, recompensar a usuarios reales, reducir bots, facilitar el cumplimiento y proteger funciones sensibles.

También pueden crear riesgos si son injustas, centralizadas, están mal protegidas o los estafadores las utilizan como cebo.

Los usuarios nunca deben asumir que el acceso a una whitelist significa que un proyecto es seguro o rentable.

Tampoco deben compartir nunca frases de recuperación o claves privadas para unirse a una whitelist.

El enfoque más seguro es verificar enlaces oficiales, leer los avisos de cartera, entender las reglas, comprobar el contrato y evaluar el propio proyecto.

Para los desarrolladores, una whitelist debe crearse con control de acceso seguro, reglas de elegibilidad claras, una gestión administrativa cuidadosa y comunicación transparente.

Para los usuarios, una whitelist solo es útil cuando es real, segura y está vinculada a un proyecto digno de confianza.

En cripto, tener permiso para entrar es solo el primer paso.

Lo más importante es entender en qué se te está permitiendo entrar.