---
title: "Plano de isolamento de carteira para airdrops"
description: "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."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Plano de isolamento de carteira para airdrops
> 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
- [Aprovação de carteira](/pt-br/crypto/wallet-approval/)
- [Assinatura de carteira](/pt-br/crypto/wallet-signature/)
- [Simulação de transações](/pt-br/crypto/transaction-simulation/)
## Fontes
- [Ethereum security and scam prevention](https://ethereum.org/security/) - Ethereum.org (acessado em: 2026-08-12)
- [Trillion Dollar Security Project - Security Challenges Overview Report](https://ethereum.org/reports/trillion-dollar-security/) - Ethereum.org (acessado em: 2026-08-12)
- [ERC-20: Token Standard](https://eips.ethereum.org/EIPS/eip-20) - Ethereum Improvement Proposals (acessado em: 2026-08-12)
- [EIP-712: Typed structured data hashing and signing](https://eips.ethereum.org/EIPS/eip-712) - Ethereum Improvement Proposals (acessado em: 2026-08-12)
- [ERC-2612: Permit Extension for EIP-20 Signed Approvals](https://eips.ethereum.org/EIPS/eip-2612) - Ethereum Improvement Proposals (acessado em: 2026-08-12)
- [ERC-1155: Multi Token Standard](https://eips.ethereum.org/EIPS/eip-1155) - Ethereum Improvement Proposals (acessado em: 2026-08-12)
- [EIP-7702: Set Code for EOAs](https://eips.ethereum.org/EIPS/eip-7702) - Ethereum Improvement Proposals (acessado em: 2026-08-12)
- [How to revoke smart contract allowances/token approvals](https://support.metamask.io/more-web3/learn/how-to-revoke-smart-contract-allowances-token-approvals/) - MetaMask Help Center (acessado em: 2026-08-12)
Source: https://wiki.fcontext.com/pt-br/crypto/airdrop-wallet-isolation-plan/index.mdx