Whitelist

O que é uma whitelist em cripto?

Uma whitelist em cripto é uma lista de endereços de carteira, usuários, smart contracts, dispositivos ou contas aprovados para uma ação específica.

O termo mais moderno e claro é allowlist, mas muitos usuários de cripto ainda buscam por whitelist porque ele é usado há anos em mintagens de NFT, lançamentos de tokens, airdrops, aplicativos DeFi e configurações de segurança de carteiras.

Em termos simples, uma whitelist decide quem tem permissão para fazer algo.

Um projeto cripto pode usar uma whitelist para decidir quem pode fazer a mintagem antecipada de um NFT.

Um lançamento de token pode usar uma whitelist para decidir quem pode participar de uma venda.

Um smart contract pode usar uma whitelist para decidir quais endereços podem chamar uma função protegida.

Uma carteira pode usar uma whitelist para decidir quais endereços de saque são aprovados.

Um protocolo DeFi pode usar uma whitelist para controlar quais ativos, cofres ou operadores podem interagir com um sistema.

O significado em cibersegurança é semelhante.

O NIST define uma whitelist como uma lista de entidades reconhecidamente aprovadas para uso dentro de uma organização ou sistema de informação, por meio de sua definição de whitelist no glossário.

Em cripto, a entidade aprovada geralmente é um endereço blockchain.

Para iniciantes, a forma mais simples de entender uma whitelist é esta: se sua carteira estiver na lista, você poderá ter permissão para participar; se não estiver, o smart contract ou a plataforma poderá rejeitar sua ação.

Whitelist vs. allowlist

Whitelist e allowlist geralmente significam a mesma coisa em cripto.

Allowlist é cada vez mais preferido porque é mais claro e direto.

O National Cyber Security Centre do Reino Unido afirma que utiliza “allow list” e “deny list” em vez de “whitelist” e “blacklist”, pois os termos mais recentes são mais claros e menos ambíguos, por meio de sua orientação sobre terminologia.

Muitas equipes cripto agora usam allowlist na documentação, enquanto muitos usuários ainda dizem whitelist em chats de comunidades.

Para SEO e compreensão dos usuários, ambos os termos são úteis.

Uma página sobre “Whitelist” deve explicar que allowlist é o termo moderno.

A função é a mesma: ela concede permissão a endereços ou usuários listados.

O conceito oposto costuma ser chamado de denylist ou blocklist.

Uma allowlist informa quem tem permissão.

Uma denylist informa quem está bloqueado.

Em smart contracts, as allowlists geralmente são mais fáceis de analisar com segurança porque tudo é negado por padrão, a menos que seja explicitamente aprovado.

Como funciona uma whitelist cripto

Uma whitelist cripto funciona verificando se um endereço de carteira ou conta corresponde a uma lista aprovada.

A lista pode ser armazenada diretamente em um smart contract.

A lista pode ser armazenada off-chain por uma equipe de projeto.

A lista pode ser representada por uma raiz de Merkle.

A lista pode ser controlada por meio de mensagens assinadas.

A lista também pode ser gerenciada por controle de acesso baseado em funções.

Quando um usuário tenta fazer mint, reivindicar, sacar, votar, negociar ou executar outra ação restrita, o sistema verifica se o usuário foi aprovado.

Se o endereço for aprovado, a ação poderá continuar.

Se o endereço não for aprovado, a ação falhará ou será bloqueada.

Em um smart contract simples, o contrato pode armazenar um mapeamento que marca endereços aprovados como verdadeiros ou falsos.

Em uma grande mintagem de NFT, armazenar milhares de endereços diretamente on-chain pode ser caro.

Por esse motivo, muitos projetos usam árvores de Merkle para provar que uma carteira está em uma lista sem armazenar toda a lista on-chain.

Isso torna a verificação da whitelist mais barata e escalável.

Por que as whitelists são usadas em cripto

Projetos cripto usam whitelists para controlar o acesso.

O controle de acesso é importante porque blockchains são sistemas abertos.

Em geral, qualquer pessoa pode enviar uma transação a um smart contract público se o contrato permitir.

Uma whitelist adiciona uma camada de permissão.

A OpenZeppelin explica, por meio de sua documentação sobre controle de acesso, que o controle de acesso em smart contracts determina quem pode fazer mint de tokens, votar em propostas, congelar transferências ou realizar outras ações sensíveis.

Para projetos de NFT, whitelists podem recompensar apoiadores iniciais.

Para lançamentos de tokens, whitelists podem controlar quem participa de uma venda.

Para protocolos DeFi, whitelists podem reduzir riscos ao limitar quais contratos ou ativos são aceitos.

Para carteiras, whitelists de saque podem proteger usuários contra o envio de fundos para endereços desconhecidos.

Para instituições, whitelists podem contribuir para a conformidade ao permitir apenas contrapartes aprovadas.

Para desenvolvedores, whitelists podem ajudar a proteger funções administrativas contra uso não autorizado.

Em todos os casos, uma whitelist é um filtro de permissões.

Whitelists em mintagens de NFT

As whitelists de NFT se popularizaram durante o boom dos NFTs porque os projetos queriam controlar o acesso antecipado à mintagem.

Uma whitelist pode permitir que carteiras selecionadas façam mint antes da venda pública.

Pode oferecer um preço de mint mais baixo.

Pode reservar uma alocação de mint garantida.

Pode reduzir a competição por gas ao distribuir o acesso à mintagem ao longo de janelas de tempo.

Pode recompensar membros da comunidade que entraram cedo, contribuíram para o projeto, ganharam rifas ou concluíram determinadas tarefas.

Um processo típico de whitelist de NFT começa com um projeto coletando endereços de carteira elegíveis.

O projeto pode então publicar regras de mint e uma janela de reivindicação.

Durante a mintagem, o smart contract verifica se a carteira tem permissão.

Se a carteira for aprovada e ainda não tiver usado sua alocação, poderá fazer mint.

Se a carteira não for aprovada, a transação será revertida ou o botão de mint não funcionará.

Alguns contratos de NFT usam provas de Merkle para mintagem eficiente em gas por allowlist.

O guia de smart contracts para NFT da QuickNode explica que usar uma árvore de Merkle pode tornar a verificação de allowlist independente do tamanho da lista e exige uma prova de Merkle para verificar se um endereço está dentro da árvore, por meio de sua discussão sobre allowlists em smart contracts de NFT.

Whitelists em lançamentos de tokens

Lançamentos de tokens podem usar whitelists para controlar a participação em vendas.

Um projeto pode exigir que os usuários se registrem antes de uma venda.

Pode exigir verificação da carteira.

Pode limitar a participação por região, tipo de usuário, pontuação de elegibilidade ou regras da campanha.

Pode usar uma whitelist para impedir que bots comprem toda a alocação.

Também pode usar uma whitelist para aplicar regras de conformidade.

Em alguns lançamentos, uma whitelist concede apenas o direito de participar.

Ela não garante lucro.

Ela não garante que um token subirá de preço.

Ela não garante liquidez após o lançamento.

Ela não garante que o projeto seja seguro.

Essa distinção é importante porque os usuários frequentemente tratam vagas em whitelist como ativos valiosos.

Uma whitelist pode melhorar o acesso, mas não pode eliminar risco de mercado, risco de smart contract, risco de tokenomics ou risco de execução do projeto.

Os usuários ainda devem avaliar oferta, vesting, credibilidade da equipe, progresso do produto, liquidez, auditorias de smart contracts e riscos legais antes de participar.

Whitelists em airdrops

Airdrops podem usar whitelists para decidir quem pode reivindicar tokens.

Um projeto pode capturar um snapshot da blockchain e criar uma lista de endereços de carteira elegíveis.

A elegibilidade pode depender da atividade da carteira, holdings de tokens, participação na governança, uso de testnet, propriedade de NFT, interação com o protocolo ou contribuição para a comunidade.

A lista final de endereços elegíveis torna-se uma whitelist ou allowlist de airdrop.

Quando um usuário visita a página de reivindicação, o sistema verifica se a carteira é elegível.

Se a carteira estiver na lista, o usuário poderá conseguir reivindicar tokens.

Se não estiver na lista, a reivindicação falhará.

O guia de airdrops de criptomoedas da Investopedia explica que alguns airdrops selecionam usuários com base em critérios específicos e podem usar snapshots ou holdings em carteira por meio de seu guia sobre airdrops de criptomoedas.

Whitelists de airdrop são úteis, mas também são muito exploradas por golpistas.

Páginas falsas de airdrop frequentemente fingem que uma carteira está em uma whitelist e enganam usuários para que assinem aprovações maliciosas.

Um airdrop real nunca deve pedir uma frase de recuperação ou chave privada.

Whitelists em smart contracts

Smart contracts usam whitelists para controle de acesso.

Um contrato pode permitir que apenas endereços aprovados façam mint de tokens.

Um contrato pode permitir que apenas operadores aprovados chamem funções administrativas.

Um cofre DeFi pode permitir apenas ativos aprovados.

Uma bridge pode permitir apenas relayers aprovados.

Um protocolo de empréstimos pode permitir apenas tipos de garantia aprovados.

Um contrato de token pode permitir apenas agentes de transferência aprovados em um sistema permissionado.

A documentação de segurança de smart contracts da Ethereum alerta, por meio de seu guia de segurança de smart contracts, que smart contracts podem controlar grandes quantidades de valor e criar oportunidades para invasores.

Por isso, o controle de acesso deve ser projetado cuidadosamente.

Uma whitelist pode melhorar a segurança, mas uma whitelist mal projetada pode criar risco de centralização ou risco administrativo oculto.

Se uma única chave privada puder adicionar ou remover endereços de uma whitelist, essa chave privada se torna poderosa.

Se a chave administrativa for comprometida, o invasor poderá alterar permissões e abusar do contrato.

Um bom projeto de whitelist deve incluir regras claras, controle administrativo seguro, registros de eventos, auditorias e governança transparente quando apropriado.

Whitelists na segurança de carteiras

Carteiras e sistemas de custódia podem usar whitelists de saque.

Uma whitelist de saque é uma lista de endereços aprovados para os quais os fundos podem ser enviados.

Se um endereço de saque não for aprovado, a carteira ou plataforma bloqueia o saque.

Isso pode proteger usuários contra erros e comprometimento de conta.

Por exemplo, se um invasor obtiver acesso à conta de um usuário, mas não puder adicionar um novo endereço de saque sem atraso ou verificação adicional, a whitelist poderá reduzir o risco de roubo.

Algumas carteiras também permitem que usuários rotulem endereços confiáveis.

Alguns sistemas de custódia exigem aprovação multisig antes de adicionar um novo endereço.

Algumas configurações institucionais usam whitelists de endereços para cumprir políticas internas de risco e conformidade.

Whitelists de saque são úteis, mas não são perfeitas.

Se um usuário incluir o endereço errado na whitelist, os fundos ainda poderão ser perdidos.

Se um invasor controlar um endereço aprovado, a whitelist não ajudará.

Se um usuário aprovar um smart contract malicioso, uma whitelist de saque pode não proteger todos os ativos.

A segurança da carteira ainda exige proteção da chave privada, revisão de transações, gerenciamento de aprovações e atenção a phishing.

Whitelists em DeFi

Protocolos DeFi podem usar whitelists para gerenciar riscos.

Um protocolo pode incluir em whitelist ativos que podem ser usados como garantia.

Um cofre pode incluir em whitelist estratégias autorizadas a gerenciar fundos.

Um mercado de empréstimos pode incluir em whitelist ou listar somente tokens específicos.

Um pool permissionado pode incluir em whitelist usuários que atendam a regras de elegibilidade.

Um sistema de oráculos pode incluir em whitelist provedores de dados ou feeds de preços.

Um sistema de governança pode incluir em whitelist endereços que podem executar ações de emergência.

Esses controles podem tornar um protocolo mais seguro, mas também reduzem sua abertura.

Um protocolo DeFi totalmente aberto permite que qualquer pessoa interaja se seguir as regras do smart contract.

Um sistema DeFi com whitelist adiciona uma camada de permissão.

Essa camada de permissão pode ser útil para conformidade, segurança ou lançamento controlado.

Também pode criar pressupostos de confiança, pois os usuários devem confiar em quem controla a lista.

Os usuários devem perguntar quem pode adicionar ou remover endereços, se as alterações têm atraso, se a governança controla a lista e se a lista pode ser abusada.

Whitelists e árvores de Merkle

Uma árvore de Merkle é uma estrutura criptográfica que permite provar de forma eficiente que um item pertence a um conjunto.

Em whitelists cripto, o conjunto geralmente é uma lista de endereços de carteira aprovados.

Em vez de armazenar cada endereço diretamente no smart contract, o projeto armazena uma única raiz de Merkle.

Quando um usuário tenta reivindicar ou fazer mint, ele fornece uma prova de Merkle.

O smart contract verifica a prova em relação à raiz de Merkle.

Se a prova for válida, o contrato sabe que o endereço faz parte da lista aprovada.

Isso pode economizar gas porque o contrato não precisa armazenar milhares de endereços individuais.

Também pode facilitar o gerenciamento de grandes allowlists.

No entanto, allowlists de Merkle podem ser confusas para usuários.

Um usuário pode ser elegível, mas o front end deve fornecer a prova correta.

Se o site estiver com problema ou a prova estiver incorreta, a reivindicação poderá falhar.

Os usuários também devem verificar se o site de mint é oficial, pois golpistas frequentemente copiam páginas de reivindicação de allowlist.

Whitelists e mensagens assinadas

Alguns sistemas cripto usam mensagens assinadas em vez de uma whitelist armazenada.

Nesse modelo, um servidor confiável assina uma mensagem informando que uma carteira pode executar uma ação.

O usuário envia essa assinatura ao smart contract.

O smart contract verifica se a assinatura veio de um signatário aprovado.

Se a assinatura for válida e não tiver expirado nem sido usada, a ação será permitida.

Esse método pode ser flexível porque o projeto não precisa publicar uma lista completa on-chain.

Também pode oferecer suporte à elegibilidade dinâmica.

No entanto, ele cria confiança no sistema de assinatura.

Se o servidor de assinatura for comprometido, invasores poderão gerar aprovações não autorizadas.

Se as regras de assinatura forem mal projetadas, poderão ocorrer ataques de repetição ou reivindicações duplicadas.

Allowlists com mensagens assinadas bem projetadas devem incluir ID da cadeia, endereço do contrato, endereço da carteira, alocação, prazo, nonce e separação clara de domínio.

Os usuários devem ler cuidadosamente as solicitações da carteira antes de assinar qualquer mensagem.

Alocação de whitelist

Uma alocação de whitelist é a quantidade que um endereço incluído em whitelist pode fazer mint, reivindicar, comprar ou sacar.

Em uma mintagem de NFT, uma carteira pode ter permissão para fazer mint de um NFT.

Outra carteira pode ter permissão para fazer mint de três NFTs.

Em uma venda de tokens, um endereço pode ter um valor máximo de compra.

Em um airdrop, um endereço pode ter uma quantidade de tokens reivindicável com base em sua atividade.

As regras de alocação são importantes porque estar em uma whitelist nem sempre significa acesso ilimitado.

Um usuário pode ser aprovado, mas ainda falhar se exceder a alocação.

Um usuário também pode falhar se a janela de reivindicação tiver terminado.

Um projeto pode usar limites por carteira para reduzir a concentração por baleias.

Também pode usar diferentes níveis para apoiadores iniciais, colaboradores, detentores de NFT, usuários de testnet ou participantes de governança.

Os usuários devem ler cuidadosamente as regras de alocação antes de enviar transações.

Uma transação que falha ainda pode ter custo de gas em algumas redes.

Snapshot de whitelist

Um snapshot de whitelist é um registro da elegibilidade de carteiras em um momento específico.

Projetos usam snapshots para impedir que usuários alterem seu comportamento depois que as regras se tornam conhecidas.

Por exemplo, um airdrop pode contabilizar carteiras que mantinham um token antes de determinado número de bloco.

Um projeto de NFT pode contabilizar detentores de uma coleção anterior em determinado momento.

Um sistema de governança pode contabilizar eleitores ou delegados em um bloco definido.

Snapshots tornam a elegibilidade mais objetiva.

No entanto, snapshots também podem gerar confusão.

Um usuário pode comprar um token após o snapshot e descobrir que não é elegível.

Um usuário pode mover ativos para outra carteira após o snapshot e ainda ser elegível na carteira antiga.

Um usuário pode utilizar uma carteira de smart contract que não é aceita pela interface de reivindicação.

As regras do snapshot devem ser anunciadas claramente.

Os usuários devem verificar o bloco exato, timestamp, ativo, rede e endereço de carteira usados para elegibilidade.

Whitelist grinding e ataques Sybil

Whitelist grinding ocorre quando usuários criam muitas carteiras ou contas para aumentar a chance de entrar em uma whitelist.

Um ataque Sybil é um termo mais amplo para uma pessoa ou grupo que finge ser muitos usuários independentes.

Em cripto, o comportamento Sybil é comum porque criar carteiras é barato.

Um projeto pode querer recompensar usuários reais, mas bots podem criar milhares de carteiras para cultivar elegibilidade.

Isso pode tornar as whitelists menos justas.

Projetos podem combater ataques Sybil com verificações de identidade, ferramentas de prova de humanidade, análise de gráfico social, pontuação de atividade, requisitos de depósito, sistemas antibot ou revisão manual.

Cada método tem desvantagens e vantagens.

Verificações rigorosas de identidade podem reduzir a privacidade.

A pontuação de atividade pode punir usuários novos.

A revisão manual pode criar viés ou erros.

Requisitos de depósito podem excluir usuários menores.

Um bom desenho de whitelist deve equilibrar justiça, privacidade, experiência do usuário e resistência ao farming.

Whitelist e KYC

Algumas whitelists cripto estão conectadas a verificações know-your-customer, frequentemente chamadas de KYC.

KYC significa verificar a identidade do usuário por motivos de conformidade ou controle de risco.

Uma venda de tokens, pool permissionado ou plataforma de ativos regulados pode exigir que os usuários concluam o KYC antes que sua carteira seja adicionada a uma allowlist.

Isso pode ajudar o projeto a cumprir requisitos legais.

Também pode limitar o acesso por região ou tipo de usuário.

No entanto, whitelists baseadas em KYC criam preocupações de privacidade e segurança de dados.

Os usuários podem precisar enviar informações pessoais a um provedor terceirizado.

Se esse provedor for comprometido, informações sensíveis poderão ser expostas.

Os usuários devem entender quem coleta os dados, como são armazenados, quais regras se aplicam e se o projeto é legítimo.

Uma whitelist que solicita informações de identidade deve ser tratada com mais cuidado do que uma allowlist simples de endereços de carteira.

Os usuários devem evitar enviar documentos por links recebidos em mensagens diretas ou canais não oficiais.

Whitelist e chaves privadas

Uma whitelist nunca exige uma chave privada ou frase de recuperação.

Esta é uma das regras de segurança mais importantes em cripto.

Um projeto pode solicitar um endereço público de carteira para adicioná-lo a uma whitelist.

Um projeto pode pedir que usuários conectem uma carteira para verificar a elegibilidade.

Um projeto pode pedir que usuários assinem uma mensagem para comprovar a propriedade da carteira.

Nenhuma dessas ações deve exigir que o usuário revele uma frase de recuperação ou chave privada.

A FTC alerta que golpes com criptomoedas frequentemente usam oportunidades falsas e táticas enganosas para enganar usuários por meio de seu guia sobre golpes com criptomoedas.

A Chainalysis também descreveu ataques de phishing por aprovação, nos quais vítimas são enganadas para conceder permissões que permitem que criminosos esvaziem carteiras, por meio de seu relatório sobre phishing por aprovação.

Se uma página de whitelist solicitar uma frase de recuperação, quase certamente se trata de um golpe.

Se uma reivindicação de whitelist solicitar aprovação ilimitada de tokens, os usuários devem parar e revisar a transação cuidadosamente.

Golpes de whitelist

Golpes de whitelist são comuns em cripto porque os usuários desejam acesso antecipado.

Golpistas usam urgência, escassez e medo de ficar de fora para fazer com que usuários ajam rapidamente.

Uma conta falsa pode informar que o usuário ganhou uma vaga em whitelist.

Um site falso pode informar que uma carteira é elegível para um airdrop.

Uma página falsa de mint pode copiar o design de um projeto real.

Um moderador falso de comunidade pode pedir que os usuários verifiquem sua carteira.

Uma conta falsa de suporte pode alegar que um usuário precisa redefinir o acesso à whitelist.

O perigo geralmente não está na palavra whitelist em si.

O perigo está na transação ou mensagem que o usuário é induzido a assinar.

Uma aprovação maliciosa pode permitir que um golpista transfira tokens ou NFTs.

Uma assinatura maliciosa pode autorizar uma ação que o usuário não entende.

Uma solicitação de frase de recuperação pode conceder ao golpista controle total da carteira.

Os usuários devem verificar links oficiais, evitar links de mint enviados por mensagem direta, salvar páginas confiáveis nos favoritos e usar ferramentas de segurança de carteira antes de interagir com qualquer reivindicação de whitelist.

Whitelist vs. venda pública

Uma venda por whitelist é restrita a carteiras aprovadas.

Uma venda pública é aberta a qualquer pessoa que possa interagir com o contrato e atender às regras da venda.

Vendas por whitelist são frequentemente usadas antes de vendas públicas.

Elas podem conceder acesso antecipado a membros da comunidade.

Podem reduzir guerras de gas ao controlar a demanda.

Podem ajudar um projeto a recompensar colaboradores reais.

Vendas públicas podem ser mais abertas, mas podem atrair bots, custos altos de gas e esgotamento rápido.

Nenhum dos modelos é automaticamente melhor.

Uma venda por whitelist pode ser injusta se o processo de seleção for oculto ou manipulado.

Uma venda pública pode ser injusta se bots capturarem a maior parte da oferta.

Os usuários devem avaliar as regras, a alocação, o preço, o lock-up, o smart contract, o comportamento da equipe e os riscos antes de participar de qualquer formato.

Acesso não é sinônimo de valor.

Whitelist vs. lista de espera

Uma whitelist e uma lista de espera não são a mesma coisa.

Uma whitelist significa que uma carteira ou usuário foi aprovado para acesso.

Uma lista de espera significa que um usuário aguarda um possível acesso posterior.

Alguns projetos usam ambas.

Um usuário pode primeiro entrar em uma lista de espera.

O projeto pode posteriormente escolher alguns usuários da lista de espera para a whitelist.

Uma lista de espera não garante uma mintagem, reivindicação de token, alocação de venda ou aprovação de conta.

Usuários de cripto devem ler a redação cuidadosamente.

“Entrar na lista de espera” geralmente significa registrar interesse.

“Você está em whitelist” geralmente significa acesso aprovado sob determinadas regras.

Ainda assim, o usuário pode precisar concluir a ação antes de um prazo.

Uma vaga em whitelist pode expirar se o usuário perder a janela de reivindicação.

Whitelist vs. pré-venda

Uma pré-venda é uma venda antecipada antes de um lançamento público.

Uma whitelist é a lista de usuários autorizados a participar dessa pré-venda.

Os dois termos estão relacionados, mas não são idênticos.

Um projeto pode realizar uma pré-venda apenas para carteiras incluídas em whitelist.

Um projeto também pode realizar uma pré-venda sem whitelist se utilizar outra regra de acesso.

Estar em whitelist para uma pré-venda não garante que a pré-venda seja segura.

Pré-vendas ainda podem envolver tokenomics ruins, alocações ocultas para insiders, liquidez fraca, contratos não auditados, equipes falsas ou risco de rug pull.

Os usuários devem avaliar o projeto em vez de presumir que o acesso à whitelist é um selo de qualidade.

Golpistas frequentemente fazem vagas em whitelist parecerem exclusivas porque a exclusividade cria pressão.

Um usuário prudente deve ir com calma quando um projeto afirma que restam apenas alguns minutos para reivindicar uma vaga.

Whitelist vs. controle de acesso baseado em funções

Uma whitelist simples geralmente concede a mesma permissão a todos os endereços aprovados.

O controle de acesso baseado em funções concede permissões diferentes a funções diferentes.

Por exemplo, uma função pode ter permissão para pausar um contrato.

Outra função pode ter permissão para fazer mint.

Outra função pode ter permissão para atualizar metadados.

Outra função pode ter permissão para gerenciar uma whitelist.

A documentação de controle de acesso da OpenZeppelin explica sistemas de permissões baseados em funções e por que compreender quem pode fazer o quê é essencial em smart contracts.

O controle de acesso baseado em funções é mais flexível do que uma whitelist simples.

Também é mais complexo.

Sistemas complexos de permissões podem ocultar poderes administrativos perigosos.

Usuários e auditores devem verificar quais funções existem, quem as controla, se podem ser transferidas, se usam controle multisig e se há atrasos de tempo.

Uma whitelist responde: “este endereço tem permissão?”

O controle de acesso baseado em funções responde: “o que exatamente este endereço tem permissão para fazer?”

Whitelist e taxas de gas

Transações de whitelist ainda podem exigir taxas de gas.

Ser aprovado não significa que uma transação seja gratuita.

Um usuário ainda poderá ter de pagar taxas de rede para fazer mint, reivindicar, aprovar, transferir ou interagir com um smart contract.

Se a transação falhar, o usuário ainda poderá perder gas, dependendo da rede e do tipo de falha.

Por isso, os usuários devem confirmar que estão na rede correta e dentro da janela de reivindicação correta.

Também devem verificar se o endereço de sua carteira corresponde exatamente ao endereço incluído na whitelist.

Se uma mintagem de NFT usar uma prova de Merkle, a reivindicação poderá falhar se a interface fornecer a prova errada.

Se uma venda de tokens tiver um limite por carteira, a transação poderá falhar se o usuário tentar comprar demais.

Se uma whitelist já tiver sido usada, a segunda reivindicação poderá falhar.

Os usuários devem ler os resultados da simulação de transação, quando disponíveis, antes de assinar.

Whitelist e privacidade

Whitelists podem afetar a privacidade.

Se um projeto publicar uma lista de endereços de carteira elegíveis, observadores poderão analisar essas carteiras.

Eles poderão ver saldos, histórico de transações, holdings de NFT, atividade DeFi e outros comportamentos on-chain.

Mesmo que um projeto não publique a lista completa, reivindicações bem-sucedidas podem revelar carteiras elegíveis ao longo do tempo.

Usuários que se preocupam com privacidade podem usar carteiras separadas para diferentes atividades.

No entanto, usar muitas carteiras pode criar risco de gerenciamento.

Também pode criar preocupações com Sybil se o projeto tentar recompensar usuários únicos.

Privacidade e elegibilidade frequentemente entram em conflito.

Um projeto quer identificar usuários reais.

Um usuário pode querer evitar vincular toda a atividade a um único endereço.

Um bom projeto de whitelist deve coletar apenas as informações necessárias e explicar como os dados de elegibilidade são usados.

Como verificar se uma carteira está em whitelist

A maneira mais segura de verificar o status de whitelist é por meio de uma página oficial do projeto ou método de contrato.

Os usuários devem começar pelo site oficial do projeto ou canais sociais verificados.

Devem evitar links de mensagens diretas, respostas, comentários e anúncios aleatórios em mecanismos de busca.

Devem confirmar o endereço do contrato e a rede.

Devem conectar uma carteira somente se a página for verificada.

Devem ler a solicitação da carteira antes de assinar qualquer coisa.

Algumas verificações exigem apenas a leitura de dados públicos e não precisam de assinatura.

Algumas verificações exigem uma assinatura de mensagem inofensiva para comprovar a propriedade da carteira.

Algumas ações exigem uma transação on-chain e gas.

Os usuários devem entender qual tipo de ação estão realizando.

Se um verificador de whitelist solicitar uma frase de recuperação, chave privada ou informações completas de recuperação da carteira, os usuários devem fechá-lo imediatamente.

Como projetos devem criar uma whitelist

Projetos devem criar whitelists com regras claras.

Devem explicar os critérios de elegibilidade antes de coletar endereços de carteira.

Devem evitar mudar regras silenciosamente depois que usuários gastarem tempo ou dinheiro tentando se qualificar.

Devem utilizar padrões seguros de smart contracts.

Devem considerar provas de Merkle ou mensagens assinadas para listas grandes.

Devem testar a lógica de reivindicação antes do lançamento.

Devem publicar links oficiais em vários canais verificados.

Devem alertar os usuários de que frases de recuperação nunca são necessárias.

Devem limitar poderes administrativos sempre que possível.

Devem usar controles multisig e atrasos de tempo para funções sensíveis.

Devem emitir eventos quando configurações de whitelist forem alteradas.

Devem documentar alocação, prazos, preço, regras de reembolso e fatores de risco.

A OWASP explica que a validação por allowlist define exatamente o que é autorizado e rejeita todo o restante, por meio de seu Input Validation Cheat Sheet.

O mesmo princípio se aplica ao controle de acesso em cripto: defina o que é permitido e aplique isso de forma consistente.

Benefícios de uma whitelist

O primeiro benefício de uma whitelist é o acesso controlado.

Um projeto pode decidir quem pode fazer mint, reivindicar, comprar, sacar ou chamar uma função.

O segundo benefício é a redução de bots.

Whitelists podem dificultar que bots automatizados capturem toda a oferta durante um lançamento.

O terceiro benefício são as recompensas à comunidade.

Projetos podem recompensar apoiadores iniciais, colaboradores, testadores, eleitores, criadores ou detentores de longo prazo.

O quarto benefício é menor pressão no lançamento.

Janelas de whitelist podem reduzir guerras de gas ao distribuir a demanda ao longo do tempo.

O quinto benefício é melhor controle de conformidade.

Alguns sistemas precisam de participantes aprovados por razões legais ou institucionais.

O sexto benefício é a segurança da carteira.

Whitelists de saque podem reduzir o risco de enviar fundos para endereços desconhecidos.

O sétimo benefício é a segurança de smart contracts.

Controles de acesso podem impedir que usuários não autorizados chamem funções sensíveis.

Riscos de uma whitelist

O primeiro risco é a falsa confiança.

Usuários podem pensar que estar em whitelist significa que o projeto é seguro.

Não significa.

O segundo risco é a centralização.

Normalmente, alguém precisa decidir quem será adicionado ou removido.

O terceiro risco é o comprometimento da chave administrativa.

Se o controle da whitelist estiver em uma única chave privada, essa chave poderá se tornar um alvo importante de ataque.

O quarto risco é a alocação injusta.

Whitelists podem favorecer insiders, bots, influenciadores ou usuários que entendem regras ocultas.

O quinto risco é phishing.

Links falsos de whitelist são comuns.

O sexto risco é a perda de privacidade.

A elegibilidade para whitelist pode revelar atividade de carteira ou vincular usuários a endereços.

O sétimo risco é a falha técnica.

Provas de Merkle inválidas, snapshots errados, front ends com falhas ou bugs de contrato podem bloquear usuários legítimos.

O oitavo risco é o hype excessivo.

A escassez de whitelist pode fazer usuários ignorarem os fundamentos do projeto.

Equívocos comuns sobre whitelists

Um equívoco é que o acesso à whitelist garante lucro.

Não garante.

Outro equívoco é que uma whitelist significa que um projeto foi verificado pela blockchain.

Não significa, pois a blockchain apenas aplica regras de código.

Um terceiro equívoco é que usuários precisam compartilhar uma frase de recuperação para entrar em uma whitelist.

Isso nunca deve ser feito.

Um quarto equívoco é que conectar uma carteira por si só é sempre seguro.

Conectar uma carteira geralmente é menos perigoso do que assinar, mas os usuários ainda podem ser direcionados a aprovações maliciosas após a conexão.

Um quinto equívoco é que toda whitelist é justa.

Algumas são justas, algumas são mal administradas e algumas são criadas para gerar hype.

Um sexto equívoco é que uma allowlist não pode ser alterada.

Algumas listas são fixas, enquanto outras podem ser atualizadas por administradores ou governança.

Um sétimo equívoco é que uma whitelist está sempre on-chain.

Muitas whitelists são armazenadas off-chain ou representadas por provas.

Checklist de segurança para whitelist

Os usuários devem verificar o site oficial antes de entrar em qualquer whitelist.

Os usuários devem confirmar a rede e o endereço de contrato corretos.

Os usuários nunca devem compartilhar uma frase de recuperação ou chave privada.

Os usuários devem evitar links de mint em mensagens diretas.

Os usuários devem ler cuidadosamente as solicitações da carteira antes de assinar.

Os usuários devem verificar se uma transação concede aprovações de tokens ou NFTs.

Os usuários devem entender o preço de mint, o valor da reivindicação, a alocação e o prazo.

Os usuários devem verificar se o projeto publicou regras claras.

Os usuários devem avaliar o projeto, não apenas a vaga na whitelist.

Os usuários devem manter uma carteira separada para mintagens de maior risco se tiverem experiência suficiente para gerenciar várias carteiras com segurança.

Os usuários devem revogar aprovações arriscadas quando elas não forem mais necessárias.

Os usuários devem lembrar que urgência é uma tática comum de golpe.

Whitelist em termos simples

Uma whitelist é uma lista aprovada.

Em cripto, a lista geralmente contém endereços de carteira.

Se seu endereço estiver na lista, você poderá ter permissão para fazer mint, reivindicar, comprar, sacar ou usar um recurso.

Se seu endereço não estiver na lista, o sistema poderá bloqueá-lo.

Whitelist e allowlist geralmente significam a mesma coisa.

Allowlist é o termo moderno mais claro.

Whitelists podem ser úteis para controle de acesso, recompensas à comunidade, mintagens de NFT, airdrops e segurança de carteiras.

Também podem ser exploradas por golpistas que criam páginas falsas de reivindicação.

Para iniciantes, a regra mais importante é simples.

Uma whitelist real pode precisar de seu endereço público de carteira, mas nunca precisa de sua frase de recuperação.

FAQ

O que whitelist significa em cripto?

Uma whitelist em cripto é uma lista de endereços de carteira, usuários ou contratos aprovados que têm permissão para executar uma ação específica.

Whitelist é igual a allowlist?

Sim. Whitelist e allowlist geralmente significam a mesma coisa, mas allowlist é mais claro e moderno.

O que é uma whitelist de NFT?

Uma whitelist de NFT é uma lista de carteiras aprovadas que podem fazer mint de um NFT durante uma janela de mint restrita.

O que é uma whitelist de venda de tokens?

Uma whitelist de venda de tokens é uma lista de participantes aprovados que têm permissão para participar de uma venda de tokens sob regras específicas.

O que é uma whitelist de airdrop?

Uma whitelist de airdrop é uma lista de carteiras elegíveis que podem reivindicar tokens ou recompensas.

Estar em whitelist garante lucro?

Não. O acesso à whitelist apenas concede permissão para participar e não garante lucro nem sucesso do projeto.

Uma whitelist pode ser armazenada on-chain?

Sim. Uma whitelist pode ser armazenada diretamente em um smart contract, mas listas grandes geralmente usam provas de Merkle ou sistemas off-chain.

O que é uma whitelist de Merkle?

Uma whitelist de Merkle usa uma raiz de Merkle e provas de Merkle para verificar se uma carteira faz parte de uma lista aprovada sem armazenar todos os endereços on-chain.

Por que projetos usam whitelists?

Projetos usam whitelists para controlar o acesso, recompensar usuários iniciais, reduzir bots, gerenciar a conformidade ou proteger funções sensíveis de smart contracts.

Whitelists podem ser injustas?

Sim. Whitelists podem ser injustas se as regras de alocação não forem claras, insiders forem favorecidos, bots cultivarem vagas ou as equipes do projeto alterarem regras sem transparência.

Uma whitelist pode ser alterada?

Algumas whitelists são fixas, enquanto outras podem ser alteradas por administradores, multisigs, governança ou sistemas off-chain.

O que é uma whitelist de saque?

Uma whitelist de saque é uma lista de endereços aprovados para os quais uma carteira ou sistema de custódia permite o envio de fundos.

Preciso conectar minha carteira para verificar o status da whitelist?

Às vezes, sim, mas os usuários devem conectar apenas por links oficiais e nunca devem compartilhar uma frase de recuperação.

Devo assinar uma mensagem para uma whitelist?

Assinar uma mensagem pode ser normal para comprovar a propriedade da carteira, mas os usuários devem ler a mensagem cuidadosamente e evitar solicitações suspeitas.

Uma reivindicação de whitelist pode esvaziar minha carteira?

Uma reivindicação falsa de whitelist pode esvaziar uma carteira se enganar o usuário para que assine aprovações maliciosas ou revele informações privadas.

Qual é o maior sinal de alerta de golpe de whitelist?

O maior sinal de alerta é qualquer site ou pessoa que peça uma frase de recuperação, chave privada ou aprovação urgente de carteira por um link não oficial.

Uma whitelist é igual a KYC?

Não. Uma whitelist é uma lista de acesso aprovada, enquanto KYC é um processo de verificação de identidade que pode ser usado antes de adicionar alguém a uma whitelist.

O que devo verificar antes de usar um link de whitelist?

Os usuários devem verificar o site oficial, endereço de contrato, rede, regras de reivindicação, solicitação da carteira e legitimidade do projeto antes de assinar qualquer coisa.

Conclusão

Uma whitelist é uma das ferramentas de controle de acesso mais comuns em cripto.

Ela é usada para mintagens de NFT, vendas de tokens, airdrops, saques de carteira, permissões DeFi, funções administrativas de smart contracts e recompensas à comunidade.

O termo moderno allowlist é mais claro, mas whitelist continua amplamente utilizado por usuários de cripto.

A ideia básica é simples: endereços aprovados podem agir, e endereços não aprovados não podem.

Whitelists podem tornar lançamentos mais tranquilos, recompensar usuários reais, reduzir bots, apoiar a conformidade e proteger funções sensíveis.

Também podem criar riscos se forem injustas, centralizadas, mal protegidas ou usadas como isca por golpistas.

Os usuários nunca devem presumir que o acesso à whitelist significa que um projeto é seguro ou lucrativo.

Também nunca devem compartilhar frases de recuperação ou chaves privadas para entrar em uma whitelist.

A abordagem mais segura é verificar links oficiais, ler solicitações da carteira, entender as regras, verificar o contrato e avaliar o próprio projeto.

Para desenvolvedores, uma whitelist deve ser criada com controle de acesso seguro, regras de elegibilidade claras, gerenciamento administrativo cuidadoso e comunicação transparente.

Para usuários, uma whitelist só é útil quando é real, segura e vinculada a um projeto digno de confiança.

Em cripto, ter permissão para entrar é apenas o primeiro passo.

Entender no que você está recebendo permissão para entrar é o que mais importa.