Lista de permissões de tokens: guia completo para listas aprovadas em

Domine estratégias de listas de permissões de tokens para projetos de criptomoeda. Aprenda métodos de implementação, práticas recomendadas de segurança e conformidade regulatória para listas de endereços aprovadas.

8 min read52 sections
CoinCryptoRank Editorial
Trusted analysis

Compreendendo a lista de permissões de token

O que é lista branca?

A lista de permissões restringe as interações de token ou protocolo a endereços explicitamente aprovados, exigindo pré-autorização para participação.

Conceito Central:

Lista negra: todos permitidos, EXCETO endereços proibidos
Lista de permissões: NINGUÉM permitido, EXCETO endereços aprovados Estados padrão:
Lista negra: aberta (permissiva)
Lista de permissões: Fechada (restritiva)

Por que a lista de permissões é importante

1. Vendas e tokens ICOs:

  • • Verificação de investidor credenciado
  • • Conformidade com KYC/AML
  • • Restrições geográficas
  • • Proteção anti-bot
  • • Mecânica de lançamento justo

2. Moedas NFT:

  • • Recompensas antecipadas para apoiadores
  • • Prioridade dos membros da comunidade
  • • Evitando captura de bot
  • • Acesso em camadas
  • • Alocação garantida

3. Conformidade regulatória:

  • • Conformidade com a legislação de valores mobiliários
  • • Requisitos de investidores credenciados
  • • Restrições geográficas
  • • Verificação de investidor profissional

4. Protocolos DeFi:

  • • Acesso para teste beta
  • • Gerenciamento de riscos
  • • Implementação gradual
  • • Recursos premium
  • • Serviços institucionais

5. Segurança:

  • • Limitar a superfície de ataque
  • • Controlar a qualidade dos participantes
  • • Reduza o risco de fraude
  • • Ativar mecanismos de recuperação

Implementação Técnica

1. Método de armazenamento na cadeia

Abordagem mais simples: mapeamento de armazenamento

Vantagens:Verificação simples e em tempo real, atualizações fáceis, transparência na cadeia

Desvantagens:Altos custos de gás, escala de custos de armazenamento, caro para listas grandes

Melhor para:Listas brancas pequenas (<100 endereços), listas que mudam frequentemente

Implementação básica da lista de permissões:

// Implementação básica da lista de permissões
contrato WhitelistToken {
  mapeamento (endereço =&gt; bool) público na lista de permissões;
  endereço administrador público;
  
  modificador apenasWhitelisted() {
    require(lista de permissões[msg.sender], "Não está na lista de permissões");
    _;
  }
  
  modificador somenteAdmin() {
    require(msg.sender == admin, "Não é admin");
    _;
  }
  
  construtor() {admin = mensagem.remetente;
  }
  
  //Adiciona endereço único
  function addToWhitelist(endereço da conta) external onlyAdmin {
    lista de permissões[conta] = true;
    emitir AddedToWhitelist(conta);
  }
  
  //Adiciona vários endereços (lote)
  função addMultipleToWhitelist(endereço[] contas de dados de chamada) 
    externo 
    somenteAdmin 
  {
    for (uint i = 0; i &lt; contas.length; i++) {
      lista de permissões[contas[i]] = true;
      emitir AddedToWhitelist(contas[i]);
    }
  }
  
  // Exemplo de função na lista de permissões
  função mintTokens (quantidade uint256) somente externo Whitelisted {
    _mint(msg.remetente, valor);
  }
}

2. Método Merkle Tree

Eficiente em termos de gás para listas grandes

Vantagens:Extremamente eficiente em termos de gás, escala para milhões, armazenamento de raiz única

Desvantagens:Implementação complexa, computação fora da cadeia, complexidade UX

Melhor para:Listas brancas grandes (mais de 1.000 endereços), atualizações pouco frequentes

Implementação da árvore Merkle:

import "@openzeppelin/contracts/utils/cryptography/MerkleProof.sol";contrato MerkleWhitelist {
  bytes32 public merkleRoot;
  mapeamento (endereço =&gt; bool) public hasClaimed;
  
  endereço administrador público;
  
  construtor(bytes32 _merkleRoot) {
    merkleRoot = _merkleRoot;
    admin = mensagem.remetente;
  }
  
  //Atualiza raiz merkle (nova lista de permissões)
  função updateMerkleRoot(bytes32 _merkleRoot) externo {
    require(msg.sender == admin, "Não é admin");
    merkleRoot = _merkleRoot;
  }
  
  // Verifica a adesão à lista de permissões
  função verificarWhitelist(
    bytes32[] prova de dados de chamada,
    conta de endereço
  ) retornos de visualização pública (bool) {
    bytes32 folha = keccak256(abi.encodePacked(conta));
    retornar MerkleProof.verify(prova, merkleRoot, folha);
  }
  
  // Mint com verificação de lista de permissões
  function whitelistMint(bytes32[] prova de dados de chamada) externo {
    require(!hasClaimed[msg.sender], "Já reivindicado");
    exigir (
      verificarWhitelist(prova, msg.sender),
      "Prova de Merkle inválida"
    );
    
    hasClaimed[msg.sender] = verdadeiro;
    _mint(msg.sender, 1);
  }
}

Gerando árvore Merkle (fora da cadeia):

const { MerkleTree } = require('merkletreejs');
const keccak256 = require('keccak256');// Lista de endereços de permissões
lista de permissões const = [
  '0x1234...', 
  '0x5678...',
  '0x9abc...',
  // ... milhares mais
];// Cria nós folha
const leafNodes = whitelist.map(addr =&gt; 
  keccak256(endereço)
);// Cria árvore Merkle
const merkleTree = new MerkleTree(leafNodes, keccak256, {
  sortPairs: verdadeiro
});// Obter root (armazenar no contrato)
const rootHash = merkleTree.getRoot();// Gera prova para endereço específico
function getProof(endereço) {
  folha const = keccak256(endereço);
  prova const = merkleTree.getHexProof(leaf);
  comprovante de devolução;
}

3. Método de assinatura digital

Autorização fora da cadeia

Vantagens:Sem armazenamento em cadeia, aprovação dinâmica, lógica flexível, preservação de privacidade

Desvantagens:Assinante centralizado, back-end necessário, risco de comprometimento de assinatura

Ideal para:Listas de permissões dinâmicas, verificação complexa, requisitos de privacidade

Implementação de verificação de assinatura:

contrato SignatureWhitelist {
  endereço do signatário público;
  mapeamento (endereço =&gt; bool) public hasMinted;
  
  construtor(endereço _signer) {
    signatário = _signatário;
  }
  
  //Verifica a assinatura do signatário autorizado
  função verificarAssinatura(
    conta de endereço,
    assinatura de memória de bytes
  ) retornos de visualização pública (bool) {
    bytes32 mensagemHash = keccak256(abi.encodePacked(conta));
    bytes32 ethSignedMessageHash = getEthSignedMessageHash(messageHash);
    
    return recuperaSigner(ethSignedMessageHash, assinatura) == signatário;
  }
  
  função getEthSignedMessageHash(bytes32 mensagemHash)
    interno
    puro
    retorna (bytes32)
  {
    retornar keccak256(
      abi.encodePacked("\x19Ethereum Mensagem Assinada:\n32", messageHash)
    );
  }
  
  função recuperarSigner(
    bytes32 ethSignedMessageHash,
    assinatura de memória de bytes
  ) retornos puros internos (endereço) {
    (bytes32 r, bytes32 s, uint8 v) = splitSignature(assinatura);
    retornar ecrecover(ethSignedMessageHash, v, r, s);
  }
  
  função splitSignature (bytes de memória sig)
    interno
    puro
    retorna (bytes32 r, bytes32 s, uint8 v)
  {
    require(sig.length == 65, "Comprimento de assinatura inválido");
    
    montagem {
      r := mload(adicionar(sig, 32))
      s := mload(adicionar(sig, 64))
      v := byte(0, mload(add(sig, 96)))
    }
  }
  
  // Mint com verificação de assinatura
  function assinaturaMint(assinatura de memória de bytes) externo {
    require(!hasMinted[msg.sender], "Já cunhado");
    exigir (
      verificarAssinatura(msg.sender, assinatura),
      "Assinatura inválida"
    );
    
    hasMinted[msg.sender] = verdadeiro;
    _mint(msg.sender, 1);
  }
}

4. Controle de NFT/Token

Lista de permissões baseada em propriedade

Vantagens:Verificação automatizada, construção de comunidade, valor de mercado secundário

Desvantagens:Acesso transferível, manipulação de mercado, dependência externa

Melhor para:Recompensas da comunidade, acesso ao DAO, benefícios escalonados

Implementação de controle NFT:

interface IERC721 {
  função balanceOf (proprietário do endereço) retornos de visão externa (uint256);
}contrato NFTGatedWhitelist {
  IERC721 público necessárioNFT;
  
  construtor(endereço _nftAddress) {
    obrigatórioNFT = IERC721(_nftAddress);
  }
  
  modificador somenteNFTHolder() {
    exigir (
      obrigatórioNFT.balanceOf(msg.sender) &gt; 0,
      "Deve conter o NFT necessário"
    );
    _;
  }
  
  // Acesso restrito a detentores de NFT
  função privilegiadaMint() apenas externoNFTHolder {
    _mint(msg.sender, 1);
  }
}

Casos de uso do mundo real

Lista de permissões de ICO/IDO

Fluxo do processo:

Fase de inscrição (1-2 semanas): inscrição do usuário, verificação KYC/AML, verificação de investidor credenciado, triagem geográfica

Fase de seleção: análise de inscrições, ordem de chegada OU loteria OU baseada em critérios

Publicação da lista de permissões: gerar raiz Merkle, implantar contrato, anunciar à comunidade

Fase de venda: endereços na lista de permissões participam, não incluídos na lista de permissões são bloqueados, acesso por tempo limitado

Fase pública (opcional): aberta a todos após o período da lista de permissões, alocação restante

Lista de permissões do NFT Mint

Acesso em camadas:

Nível 1 - VIP (24 horas antes):

Equipe principal, moderadores do Discord, primeiros apoiadores, contribuidores especiais

Camada 2 - Lista de permissões (12 horas antes):

Membros ativos da comunidade, envolvimento nas redes sociais, vencedores de concursos, projetos parceiros

Camada 3 - Lista de permissões (6 horas antes):

Usuários registrados, verificação básica, assinantes de e-mail

Camada 4 - Público:

Qualquer pessoa, por ordem de chegada, normalmente com gás mais alto

Implementação NFT Mint em camadas:

contrato TieredNFTMint {
  bytes32 public vipMerkleRoot;
  bytes32 lista de permissões públicaMerkleRoot;
  bytes32 lista de permissões públicaMerkleRoot;
  
  uint256 public vipStartTime = 1700000000;
  uint256 public whitelistStartTime = vipStartTime + 24 horas;
  uint256 public AllowlistStartTime = whitelistStartTime + 12 horas;
  uint256 public publicStartTime =allowlistStartTime + 6 horas;
  
  mapeamento (endereço =&gt; uint256) public mintedAmount;
  uint256 public maxPerWallet = 3;
  
  função vipMint(quantidade uint256, bytes32[] prova de dados de chamada) externo {
    require(block.timestamp &gt;= vipStartTime, "Muito cedo");
    exigir (
      verifyMerkleProof(prova, vipMerkleRoot, msg.sender),
      "Não é VIP"
    );
    require(mintedAmount[msg.sender] + valor &lt;= maxPerWallet);
    
    mintedAmount[msg.sender] += valor;
    _mint(msg.remetente, valor);
  }
  
  function whitelistMint(quantidade uint256, bytes32[] prova de dados de chamada) externo {
    require(block.timestamp &gt;= whitelistStartTime, "Muito cedo");
    exigir (
      verifyMerkleProof(prova, whitelistMerkleRoot, msg.sender),
      "Não está na lista de permissões"
    );
    require(mintedAmount[msg.sender] + valor &lt;= maxPerWallet);
    
    mintedAmount[msg.sender] += valor;
    _mint(msg.remetente, valor);
  }
  
  function publicMint(uint256 valor) a pagar externo {
    require(block.timestamp &gt;= publicStartTime, "Muito cedo");
    require(msg.value &gt;= valor * PUBLIC_PRICE);
    require(mintedAmount[msg.sender] + valor &lt;= maxPerWallet);
    
    mintedAmount[msg.sender] += valor;
    _mint(msg.remetente, valor);
  }
}

Conformidade Regulatória

Ofertas de token de segurança (STOs):

Requisitos de conformidade:

  • • Verificação de investidor credenciado ($ 1 milhão + patrimônio líquido ou $ 200 mil + renda)
  • • Restrições geográficas (Reg S, Reg D)
  • • Períodos de bloqueio
  • • Restrições de transferência
  • • Trilhas de auditoria

Acesso ao protocolo DeFi

Teste beta:

Casos de uso:Implementação gradual, limitação de risco, programas de recompensa de bugs, recursos premium, serviços institucionais

Melhores Práticas

Para projetos

1. Comunicação clara:

Informações essenciais: critérios da lista de permissões, processo de inscrição, método de seleção, cronograma, limites de alocação, requisitos técnicos

2. Seleção Justa:

Critérios transparentes, medidas anti-sibilos, abordagem comunitária em primeiro lugar, loteria para excesso de demanda, processo de apelação

3. Segurança:

Contratos de auditoria, chaves de administração seguras, teste em testnet, verificação de árvores merkle, limitação de taxa, proteção frontal

4. Experiência do usuário:

Processo de verificação simples, instruções claras, canais de suporte, ferramentas de geração de provas, interface de verificação de status

KYC/AML se necessário, conformidade com a legislação de valores mobiliários, restrições geográficas, termos de serviço, revisão legal

Para usuários

Dicas de verificação:

  • • Siga apenas canais oficiais
  • • Preencha o KYC honestamente
  • • Cumprir prazos
  • • Forneça informações precisas
  • • Guarde o comprovante de aplicação
  • • Verifique os endereços do contrato

Segurança:

  • • Nunca compartilhe chaves privadas
  • • Verifique URLs de sites
  • • Verifique os endereços do contrato
  • • Cuidado com phishing
  • • Use carteiras de hardware
  • • Teste com pequenas quantidades

Erros comuns:

  • • ❌ Prazo de inscrição perdido
  • • ❌ KYC incompleto
  • • ❌ Endereço de carteira errado
  • • ❌ Não atende aos critérios
  • • ❌ Caindo em golpes
  • • ❌ Usando endereços de troca

Comparação: Métodos

Método Custo do gás Escalabilidade Flexibilidade Segurança Melhor para
Mapeamento Alto Ruim Excelente Bom Listas pequenas
Árvore Merkle Baixo ExcelenteRuim Bom Listas grandes
Assinatura Baixo Excelente Excelente Médio Listas dinâmicas
NFT/Token Baixo Excelente Bom Bom Controle da comunidade

Tendências Futuras

1. Integração de identidade descentralizada

Lista de permissões autossoberana com credenciais portáteis, verificação de preservação de privacidade, listas de permissões de plataforma cruzada

2. Seleção baseada em IA

Curadoria automatizada com análise de comportamento, pontuação de contribuição, detecção de sibilas, distribuição justa

3. Listas de permissões entre protocolos

Acesso interoperável com uma lista branca para múltiplos usos, portabilidade de reputação, parcerias de ecossistemas

4. Tecnologia Regulatória

Automação de conformidade com verificações de jurisdição em tempo real, lista de permissões dinâmica, relatórios regulatórios

Conclusão

A lista branca de tokens fornece controle de acesso essencial para projetos de criptomoeda, permitindo conformidade regulatória, distribuição justa, construção de comunidade e segurança. Do simples armazenamento de mapeamento às sofisticadas árvores Merkle e verificação de assinaturas, as opções de implementação dependem da escala, das necessidades de flexibilidade e das considerações sobre gás.

Principais conclusões:

  • • Escolha o método certo: Mapeamento para listas pequenas/dinâmicas, Merkle para listas grandes/estáticas, assinaturas para flexibilidade
  • • Equilibrar acesso e justiça: critérios claros, seleção transparente, abordagem que prioriza a comunidade
  • • Priorize a segurança: audite contratos, proteja chaves de administração, proteja dados do usuário
  • • Otimize a experiência do usuário: processos simples, instruções claras, ferramentas úteis
  • • Mantenha-se em conformidade: siga os regulamentos, implemente KYC quando necessário, documente tudo

À medida que a criptomoeda evolui, a lista branca se tornará mais sofisticada, automatizada e preservará a privacidade. Os projetos que implementam cuidadosamente a lista de permissões – equilibrando o controle de acesso com justiça, segurança com usabilidade e conformidade com a descentralização – construirão comunidades mais fortes e lançamentos de tokens mais bem-sucedidos.

Perguntas frequentes

P: Por que os projetos usam listas de permissões em vez de vendas abertas?

R: As listas de permissões permitem: (1) Conformidade regulatória (investidores credenciados, restrições geográficas), (2) Prevenção de bots, (3) Distribuição justa para a comunidade, (4) Implementação controlada para segurança.

P: Como faço para entrar na lista de permissões de um NFT mint?

R: Normalmente: (1) Junte-se ao projeto Discord/mídia social, (2) Envolva-se com a comunidade, (3) Siga as instruções de inscrição, (4) Conclua a verificação (KYC, se necessário), (5) Envie o endereço da carteira, (6) Aguarde a confirmação. Cada projeto é diferente.

P: As listas de permissões podem ser alteradas após a implantação?

R: Depende da implementação. Armazenamento de mapeamento: sim (se os controles administrativos estiverem incluídos). Árvore Merkle: requer atualização do hash raiz. Assinatura: sim (backend controlado). NFT-gating: automático com base na propriedade.

P: Os pontos da lista de permissões são transferíveis?

R: Normalmente não para listas brancas baseadas em endereços (vinculadas a carteiras específicas). Exceção: o acesso NFT/token-gated é transferível com a propriedade NFT/token.

P: Qual é a diferença de custo do gás entre os métodos da lista de permissões?

A: Mapeamento: mais de 20.000 gases por adição de endereço. Merkle: ~3.000-5.000 gás para verificação (constante, independentemente do tamanho da lista branca). Assinatura: ~3.000-5.000 gás para verificação. A economia de gás aumenta dramaticamente com o tamanho da 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