Ir para o conteúdo
Financial Context Wiki

Plano de isolamento de carteira para airdrops

Um processo orientado por modelo de ameaças para separar interações especulativas da custódia de longo prazo e controlar aprovações, assinaturas, rotas de financiamento, vazamento de privacidade e resposta a incidentes.

Atualizado

Somente para fins educacionais; não constitui recomendação nem aconselhamento de investimento. Investir pode causar perdas.

Resposta direta

Uma carteira de interação com airdrops é um compartimento para aplicações incertas, não uma garantia de que a perda esteja limitada ao saldo visível. Mantenha as chaves de custódia de longo prazo fora de sessões experimentais do navegador, financie a carteira de interação apenas para uma tarefa definida, confira cada rede, endereço, chamada e assinatura e desative-a ou coloque-a em quarentena quando seu histórico de permissões deixar de ser confiável.

O isolamento só reduz a extensão do dano quando os compartimentos são realmente separados. Uma seed compartilhada, um dispositivo comprometido, o proprietário de uma conta inteligente, uma allowance ilimitada, uma autorização entre redes, uma rota recorrente de financiamento ou uma identidade exposta podem ligar a carteira supostamente isolada a outros ativos.

Como funciona

  1. Defina o modelo de ameaças e os compartimentos antes de conectar: custódia, negociação rotineira, interação experimental e quarentena. Registre se há compartilhamento de chaves, material da seed, contas proprietárias, dispositivos, perfis de navegador, endpoints RPC ou rotas de recuperação.
  2. Fixe a rede exata, o domínio do projeto, os endereços dos contratos, a implementação do proxy e a fonte da tarefa com base em canais independentes. Trate um selo de código-fonte verificado, uma conta social ou um link popular como evidência, não como garantia.
  3. Defina um orçamento por tarefa em gás nativo, tokens e NFTs. Financie-o apenas no momento necessário, por uma rota que não exija conectar a carteira de custódia à aplicação, e inclua bridge, swap, saque e gás de emergência no registro.
  4. Decodifique cada transação e assinatura. Confira chainId, to, o value nativo, o seletor da função, token, spender ou operador, valor, prazo, nonce, contrato verificador, chamadas em lote e qualquer efeito de delegatecall, módulo, chave de sessão ou delegação EIP-7702.
  5. Prefira permissões exatas ou limitadas quando o protocolo oferecer suporte. Diferencie allowances ERC-20 por approve, assinaturas ERC-2612 por permit, a permissão NFT setApprovalForAll, permissões de contas inteligentes e simples assinaturas de login; uma assinatura sem gás ainda pode autorizar movimentação de ativos.
  6. Simule, envie por uma carteira confiável e reconcilie o estado efetivo, não apenas a tela de confirmação. Na rede correta, verifique status do recibo, transferências, allowances, operadores de NFT, proprietários ou módulos de contas inteligentes, saldos, gás e endereços de destino.
  7. Após a tarefa, mova os ativos previstos por uma rota revisada, revogue permissões on-chain desnecessárias, desconecte o site separadamente, arquive as evidências e coloque a carteira em quarentena após assinatura suspeita, exposição de chave ou mudança de estado inexplicada. Se a chave puder estar comprometida, evacuar os ativos para uma chave nova tem prioridade sobre confiar na revogação.

Exemplos resolvidos

  • O financiamento é um orçamento, não um teto rígido de perda. Uma carteira de interação recebe 0.08 ETH quando o ETH vale $2,400 e 180 USDC. O saldo fungível marcado a mercado é 0.08 * $2,400 + $180 = $372. Depois de 0.012 ETH em gás, ela possui 0.068 ETH, no valor de $163.20, mais 180 USDC, totalizando $343.20. Esse valor exclui NFTs, depósitos futuros, permissões pendentes, fundos em bridges e qualquer exposição por chave compartilhada; portanto, $372 era um orçamento de financiamento, não uma perda máxima garantida.
  • Allowance ERC-20 limitada. Uma carteira tem 1,000 USDC e aprova o spender S para 250 USDC. Uma chamada legítima usa 120 USDC, restando saldo de 880 USDC e allowance de 130 USDC. Se não houver mais uso previsto, uma aprovação on-chain de 0 USDC elimina essa allowance ERC-20. Desconectar o site não realiza a revogação, e uma allowance ilimitada pode expor depósitos futuros além do saldo atual.
  • Uma assinatura pode alterar o estado posterior. Um permit ERC-2612 assina proprietário A, spender S, valor 300 USDC, nonce 41, prazo de 1,800 seconds, contrato verificador do token e chainId ativo. Um relayer o envia, o nonce do permit passa a 42 e S gasta 180 USDC; partindo de 1,000 USDC, o saldo passa a 820 USDC e a allowance restante é 120 USDC. A assinatura não custou gás para A, mas criou autoridade de gasto quando foi enviada.
  • Mantenha separados os registros de segurança e de economia. Uma campanha distribui 420 USDC. A carteira usou 0.035 ETH a $2,200 por ETH em gás, $18 em taxas de bridge e saque e $9 em slippage medido. O valor líquido antes dos impostos é $420 - $77 - $18 - $9 = $316. Esse resultado não prova que as assinaturas eram seguras, que a recompensa não tinha risco nem que repetir o processo será lucrativo.

Riscos

  • Uma seed compartilhada ou árvore determinística de contas pode colocar vários endereços no mesmo domínio de comprometimento de chave.
  • Um dispositivo, extensão de navegador, clipboard ou aplicativo de carteira comprometido pode atravessar limites nominais entre contas.
  • Um domínio, perfil de suporte, QR code ou anúncio de busca falso pode desviar até um processo cuidadoso.
  • Um contrato verificado ou frontend conhecido ainda pode ser vulnerável, atualizado, configurado incorretamente ou comprometido.
  • Escolher a rede errada pode enviar ativos ou autorizar outro deployment com endereço visualmente igual.
  • Address poisoning e telas truncadas podem derrotar conferências apenas dos primeiros ou últimos caracteres.
  • Uma allowance ERC-20 pode superar o valor previsto para a tarefa ou continuar utilizável contra depósitos futuros.
  • Uma aprovação de operador ERC-721 ou ERC-1155 pode abranger uma coleção inteira, não apenas um token.
  • Permits ERC-2612 e outras assinaturas tipadas podem criar autoridade sem transação imediata do signatário.
  • Separação de domínio fraca, prazo longo ou tratamento de nonce específico do protocolo pode criar risco de replay ou envio tardio.
  • personal_sign às cegas ou calldata opaco pode ocultar ordem, autorização, mudança de proprietário ou transferência.
  • Um lote pode incluir chamada inesperada, transferência de valor nativo, delegatecall ou política de falha parcial.
  • Módulos de contas inteligentes, chaves de sessão, guardiões de recuperação e delegados EIP-7702 podem sobreviver a uma sessão de dapp.
  • Desconectar um site não revoga allowances, operadores, permits, módulos ou delegações on-chain.
  • Uma revogação pode sofrer front-running, falhar, atingir a rede errada ou chegar depois do uso da permissão por um invasor.
  • Bridges acrescentam modos de falha na rede de origem, rede de destino, mensagem, relayer, liquidez e finalidade.
  • Financiar a partir de um endereço público de custódia e devolver fundos a ele pode revelar o vínculo entre carteiras e atrair phishing direcionado.
  • Regras anti-Sybil, verificações de identidade ou termos do projeto podem invalidar uma recompensa mesmo após uma interação técnica bem-sucedida.
  • Gás, slippage, taxas do token, iliquidez e recompensas sem valor podem tornar a campanha economicamente negativa.
  • Chaves perdidas, registros incompletos, malware, sanções, tributos e demora na resposta a incidentes podem transformar um pequeno experimento em perda operacional maior.

Equívocos comuns

  • Uma burner wallet torna qualquer site ou assinatura seguro.
  • O saldo visível da carteira é a maior perda possível.
  • Uma assinatura sem gás ou com aparência de login não pode mover ativos.
  • Desconectar uma dapp revoga suas permissões on-chain.
  • Uma hardware wallet protege quem confirma informações maliciosas na tela confiável.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...