---
title: "Piano di isolamento del wallet per gli airdrop"
description: "Un processo basato sul modello di minaccia per separare le interazioni speculative dalla custodia di lungo periodo e controllare approvazioni, firme, percorsi di finanziamento, fughe di informazioni e risposta agli incidenti."
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.
# Piano di isolamento del wallet per gli airdrop
> Solo a scopo educativo; non costituisce consulenza né raccomandazione d’investimento. Gli investimenti possono comportare perdite.
## Risposta diretta
Un wallet di interazione per gli airdrop è un compartimento destinato ad applicazioni incerte, non una garanzia che la perdita sia limitata al saldo visibile. Tieni le chiavi di custodia di lungo periodo fuori dalle sessioni sperimentali del browser, finanzia il wallet di interazione solo per un'attività definita, verifica ogni rete, indirizzo, chiamata e firma e dismettilo o mettilo in quarantena quando la sua cronologia delle autorizzazioni non è più affidabile.
L'isolamento riduce l'ampiezza del danno solo se i compartimenti sono davvero separati. Una seed condivisa, un dispositivo compromesso, l'owner di uno smart account, un'allowance illimitata, un'autorizzazione cross-chain, un percorso di finanziamento ricorrente o un'identità esposta possono ricollegare il wallet apparentemente isolato ad altri asset.
## Come funziona
1. Definisci il modello di minaccia e i compartimenti prima di collegarti: custodia, negoziazione ordinaria, interazione sperimentale e quarantena. Registra se sono condivisi chiavi, materiale della seed, account owner, dispositivi, profili del browser, endpoint RPC o percorsi di recupero.
2. Fissa la rete esatta, il dominio del progetto, gli indirizzi dei contratti, l'implementazione del proxy e la fonte dell'attività attraverso canali indipendenti. Considera un badge di codice sorgente verificato, un account social o un link popolare come indizio, non come garanzia.
3. Stabilisci un budget per l'attività in gas nativo, token e NFT. Finanzialo solo al momento necessario tramite un percorso che non richieda al wallet di custodia di connettersi all'applicazione e includi nel registro bridge, swap, prelievi e gas di emergenza.
4. Decodifica ogni transazione e firma. Controlla `chainId`, `to`, il `value` nativo, il selettore di funzione, il token, spender od operatore, importo, scadenza, nonce, contratto di verifica, chiamate in batch ed eventuali effetti di `delegatecall`, moduli, chiavi di sessione o deleghe EIP-7702.
5. Preferisci autorizzazioni esatte o limitate quando il protocollo le supporta. Distingui le allowance ERC-20 tramite `approve`, le firme ERC-2612 tramite `permit`, l'autorizzazione NFT `setApprovalForAll`, i permessi degli smart account e le semplici firme di accesso; anche una firma senza gas può autorizzare il movimento di asset.
6. Simula, invia tramite un wallet affidabile e riconcilia lo stato effettivo, non soltanto la schermata di conferma. Sulla rete corretta verifica stato della ricevuta, trasferimenti, allowance, operatori NFT, owner o moduli degli smart account, saldi, gas e indirizzi di destinazione.
7. Dopo l'attività, sposta gli asset previsti lungo un percorso verificato, revoca i permessi on-chain non necessari, disconnetti il sito separatamente, archivia le prove e metti il wallet in quarantena dopo firme sospette, esposizione della chiave o variazioni di stato inspiegabili. Se la chiave potrebbe essere compromessa, l'evacuazione verso una chiave nuova ha priorità rispetto all'affidarsi alla revoca.
## Esempi svolti
- **Il finanziamento è un budget, non un limite rigido alla perdita.** Un wallet di interazione riceve `0.08 ETH` quando ETH vale `$2,400` e `180 USDC`. Il saldo fungibile valorizzato è `0.08 * $2,400 + $180 = $372`. Dopo `0.012 ETH` di gas, contiene `0.068 ETH`, pari a `$163.20`, oltre a `180 USDC`, per un totale di `$343.20`. La cifra esclude il valore degli NFT, i depositi futuri, i permessi ancora attivi, i fondi trasferiti tramite bridge e qualsiasi esposizione dovuta a chiavi condivise; quindi `$372` era un budget di finanziamento, non una perdita massima garantita.
- **Allowance ERC-20 limitata.** Un wallet possiede `1,000 USDC` e approva lo spender `S` per `250 USDC`. Una chiamata legittima utilizza `120 USDC`, lasciando un saldo di `880 USDC` e un'allowance di `130 USDC`. Se non sono previsti altri utilizzi, un'approvazione on-chain pari a `0 USDC` elimina tale allowance ERC-20. Disconnettere il sito non esegue la revoca e un'allowance illimitata potrebbe esporre anche depositi futuri, oltre al saldo corrente.
- **Una firma può modificare lo stato successivo.** Un permit ERC-2612 firma owner `A`, spender `S`, valore `300 USDC`, nonce `41`, scadenza tra `1,800 seconds`, contratto di verifica del token e `chainId` attivo. Un relayer lo invia, il nonce del permit diventa `42` e `S` spende `180 USDC`; partendo da `1,000 USDC`, il saldo diventa `820 USDC` e l'allowance residua è `120 USDC`. La firma non ha comportato gas per `A`, ma ha creato un'autorità di spesa al momento dell'invio.
- **Mantieni separati il registro di sicurezza e quello economico.** Una campagna distribuisce `420 USDC`. Il wallet ha utilizzato `0.035 ETH` a `$2,200` per ETH per il gas, `$18` in commissioni di bridge e prelievo e `$9` di slippage misurato. Il valore netto ante imposte è `$420 - $77 - $18 - $9 = $316`. Il risultato non dimostra che le firme fossero sicure, che la ricompensa fosse priva di rischio o che ripetere il processo sia redditizio.
## Rischi
- Una seed condivisa o un albero deterministico di account può includere più indirizzi nello stesso dominio di compromissione della chiave.
- Un dispositivo, un'estensione del browser, gli appunti o un'applicazione wallet compromessi possono superare i confini nominali fra account.
- Un dominio, account di assistenza, codice QR o annuncio di ricerca falsi possono deviare anche una procedura attenta.
- Un contratto verificato o un frontend noto può comunque essere vulnerabile, aggiornato, configurato male o compromesso.
- Selezionare la rete sbagliata può trasferire asset o autorizzare un altro deployment con un indirizzo dall'aspetto identico.
- L'address poisoning e le visualizzazioni troncate possono eludere controlli limitati ai primi o agli ultimi caratteri.
- Un'allowance ERC-20 può superare l'importo previsto o restare utilizzabile sui depositi futuri.
- Un'approvazione di operatore ERC-721 o ERC-1155 può riguardare un'intera collezione anziché un singolo token.
- I permit ERC-2612 e altre firme tipizzate possono creare autorità senza una transazione immediata del firmatario.
- Una separazione dei domini debole, una scadenza lunga o una gestione del nonce specifica del protocollo possono creare rischi di replay o invio ritardato.
- Un `personal_sign` alla cieca o calldata opaco possono nascondere un ordine, un'autorizzazione, un cambio di owner o un trasferimento.
- Un batch può includere una chiamata inattesa, un trasferimento di valore nativo, un `delegatecall` o una regola di fallimento parziale.
- Moduli di smart account, chiavi di sessione, recovery guardian e delegati EIP-7702 possono sopravvivere a una singola sessione dapp.
- Disconnettere un sito non revoca allowance, operatori, permit, moduli o deleghe on-chain.
- Una revoca può subire front-running, fallire, interessare la rete sbagliata o arrivare dopo che un attaccante ha usato il permesso.
- I bridge aggiungono modalità di errore sulla rete di origine e di destinazione, nel messaggio, nel relayer, nella liquidità e nella finalità.
- Finanziare da un indirizzo pubblico di custodia e restituirvi fondi può rivelare il legame tra wallet e attirare phishing mirato.
- Regole anti-Sybil, verifiche dell'identità o condizioni del progetto possono invalidare una ricompensa anche se l'interazione tecnica riesce.
- Gas, slippage, tasse sui token, illiquidità e ricompense prive di valore possono rendere la campagna economicamente negativa.
- Chiavi perse, documentazione incompleta, malware, sanzioni, imposte e ritardi nella risposta agli incidenti possono trasformare un piccolo esperimento in una perdita operativa maggiore.
## Idee errate comuni
- Un burner wallet rende sicuro qualsiasi sito o firma.
- Il saldo visibile del wallet è la massima perdita possibile.
- Una firma senza gas o simile a un login non può spostare asset.
- Disconnettere una dapp revoca i suoi permessi on-chain.
- Un hardware wallet protegge chi conferma dettagli dannosi sul display affidabile.
## Argomenti correlati
- [Approvazione del wallet](/it/crypto/wallet-approval/)
- [Firma del wallet](/it/crypto/wallet-signature/)
- [Simulazione delle transazioni](/it/crypto/transaction-simulation/)
## Fonti
- [Ethereum security and scam prevention](https://ethereum.org/security/) - Ethereum.org (consultato il: 2026-08-12)
- [Trillion Dollar Security Project - Security Challenges Overview Report](https://ethereum.org/reports/trillion-dollar-security/) - Ethereum.org (consultato il: 2026-08-12)
- [ERC-20: Token Standard](https://eips.ethereum.org/EIPS/eip-20) - Ethereum Improvement Proposals (consultato il: 2026-08-12)
- [EIP-712: Typed structured data hashing and signing](https://eips.ethereum.org/EIPS/eip-712) - Ethereum Improvement Proposals (consultato il: 2026-08-12)
- [ERC-2612: Permit Extension for EIP-20 Signed Approvals](https://eips.ethereum.org/EIPS/eip-2612) - Ethereum Improvement Proposals (consultato il: 2026-08-12)
- [ERC-1155: Multi Token Standard](https://eips.ethereum.org/EIPS/eip-1155) - Ethereum Improvement Proposals (consultato il: 2026-08-12)
- [EIP-7702: Set Code for EOAs](https://eips.ethereum.org/EIPS/eip-7702) - Ethereum Improvement Proposals (consultato il: 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 (consultato il: 2026-08-12)
Source: https://wiki.fcontext.com/it/crypto/airdrop-wallet-isolation-plan/index.mdx