Modello account e tracciamento dei token

Su Ethereum e su altre chain basate sul modello account, gran parte del valore coinvolto in una frode o in un furto tipici non appare mai come un semplice trasferimento tra due indirizzi. Si sposta all'interno di chiamate ai contratti, come eventi dei token o tramite una firma che la vittima ha ceduto giorni prima. Un esaminatore che traccia solo ciò che mostra la scheda «transazioni» di un explorer non rileverà alcuni passaggi, attribuirà in modo errato chi ha spostato i fondi e riporterà cifre che la controparte potrà confutare usando la stessa chain.

Quattro canali in cui si sposta il valore

La decodifica di queste strutture viene insegnata nel modulo 5 di IDFE-BA, in particolare nelle lezioni Lettura dei trasferimenti di token e Decodifica delle interazioni con gli smart contract, mentre le query su di esse vengono trattate in Esecuzione di query su log e tracce EVM. Il punto di vista forense è che ciascun canale viene registrato in un luogo diverso: perciò il record di ogni passaggio deve indicare da dove proviene l'evidenza.

I trasferimenti interni sono la causa più comune di passaggi non rilevati. Uno swap che paga in ETH nativo, un contratto che inoltra fondi o un contratto di wallet che esegue un batch spostano tutti ETH tramite chiamate che non lasciano log. Per ottenerli serve un nodo che supporti il tracing, di solito un nodo archivio, e i nomi dei metodi variano tra i client (debug_traceTransaction con un call tracer in alcuni, trace_transaction in altri). Registra quale client, versione e metodo ha prodotto ciascuna traccia, perché due tracer possono rappresentare la stessa esecuzione in modo diverso.

Registrare un passaggio mediato da un contratto

Il record del passaggio trattato nella lezione Tracciamento secondo uno standard probatorio richiede campi aggiuntivi sulle chain basate sul modello account:

• l'indice del log (per un evento) o la posizione nella traccia (per una chiamata interna), perché una transazione può contenere decine di trasferimenti;
• l'indirizzo del contratto del token e i suoi decimali, insieme al valore intero grezzo;
• il mittente della transazione, oltre ai campi from e to del trasferimento, perché spesso si tratta di soggetti diversi;
• lo stato della transazione, poiché le transazioni annullate lasciano tracce ma non trasferimenti permanenti.

La questione del mittente è importante in tribunale. In un transferFrom, i token escono dall'indirizzo della vittima, ma la transazione è firmata e pagata da qualcun altro: lo spender a cui la vittima ha concesso l'approvazione. Un rapporto che afferma «la vittima ha inviato 25.000 USDC» quando in quella transazione non è stata firmata alcuna transazione con la chiave della vittima descrive l'evento in modo errato.

Due insidie relative all'identità sono specifiche dei token. I token contraffatti copiano il nome e il simbolo di una stablecoin reale; solo l'indirizzo del contratto mostra quale sia quella autentica. L'avvelenamento degli indirizzi consiste nell'inviare trasferimenti di valore zero o di importo minimo da un indirizzo simile a uno usato dalla vittima, nella speranza che la vittima lo copi dalla cronologia. Confronta sempre gli indirizzi completi, mai soltanto i primi e gli ultimi caratteri.

Approvazioni e drainer

Un drainer è un kit di phishing che induce una vittima a concedere un'autorizzazione di spesa e poi la utilizza. L'azione della vittima consiste in una delle seguenti:

1. una transazione di approvazione on-chain (approve), spesso per un importo illimitato, firmata e inviata dalla vittima;
2. una firma permit off-chain (EIP-2612), che l'attaccante invia; la specifica consente a qualsiasi indirizzo di inviare un permit valido e, se l'operazione riesce, viene impostata l'autorizzazione e viene emesso un evento Approval;
3. una firma per un contratto di approvazione condivisa che la vittima aveva già approvato e che poi autorizza il trasferimento.

Il contratto drainer chiama quindi transferFrom e divide i proventi. Uno studio di He e colleghi della Zhejiang University e della Mohamed bin Zayed University of Artificial Intelligence (Smascherare l'economia sommersa: analisi approfondita del phishing drainer-as-a-service su Ethereum, 2025), relativo al periodo da marzo 2023 ad aprile 2025, ha rilevato che la suddivisione più comune era del 20% all'operatore del kit e dell'80% all'affiliato che gestiva la campagna di phishing. Una ripartizione fissa ripetuta ai danni di molte vittime è un forte indizio, ma resta un'inferenza sui ruoli finché altre evidenze non la confermano.

L'evidenza relativa alle modalità del furto si trova quindi in parte off-chain. In presenza di un'autorizzazione legittima, il dispositivo della vittima può contenere la cronologia del browser relativa al sito di phishing e il registro delle richieste di firma del wallet, che insieme consentono di stabilire quando è avvenuta l'azione della vittima; la loro conservazione è trattata nella lezione Acquisizione e analisi dei dispositivi. Le firme off-chain non lasciano tracce on-chain fino al loro utilizzo, perciò può trascorrere molto tempo tra la firma e il drenaggio dei fondi.

Traccia svolta: un drainer con permit

Una vittima segnala la perdita di 25.000 USDC. L'esaminatore decodifica le transazioni pertinenti da un nodo di tracing:

tx 0x3b9e…a417  blocco 24,598,331  esito 1  mittente 0xD7c4…19
  chiamata  0xD7c4…19 -> 0x8f2A…c3 (contratto, non verificato)
  log 41  token 0xA0b8…eB48  Approval  titolare 0x5e1C…2e  spender 0x8f2A…c3  valore 25000000000
  log 42  token 0xA0b8…eB48  Transfer  da 0x5e1C…2e  a 0x0dE3…7a  valore 5000000000
  log 43  token 0xA0b8…eB48  Transfer  da 0x5e1C…2e  a 0xAf10…d0  valore 20000000000

tx 0x77c0…5b12  blocco 24,598,402  esito 1  mittente 0xAf10…d0
  log 7   token 0xA0b8…eB48  Transfer  da 0xAf10…d0  a 0x9c3B…e1 (pool)  valore 20000000000
  log 9   token WETH         Transfer  da 0x9c3B…e1  a 0x4d1F…80 (router)  valore 7.9e18
  traccia [0,3]  CALL  0x4d1F…80 -> 0xF5a9…31  valore 7.9 ETH

tx 0x1e44…c9a0  blocco 24,598,460  esito 1  mittente 0xF5a9…31
  valore di primo livello  0xF5a9…31 -> 0x2bD1…f6  7.89 ETH

La prima transazione non è stata inviata dalla vittima. Il suo mittente ha chiamato un contratto non verificato, che ha inviato il permit della vittima (log 41, un'autorizzazione di 25.000 USDC con 6 decimali) e ha trasferito 5.000 e 20.000 USDC dall'indirizzo della vittima nella stessa transazione (log 42 e 43). Gli importi tornano: 5.000 + 20.000 = 25.000, una ripartizione 20/80. Nella seconda transazione, il destinatario dell'importo maggiore ha scambiato i suoi 20.000 USDC tramite un pool; il router ha convertito 7.9 WETH in ETH e ha inviato 7.9 ETH a un indirizzo nuovo. Quest'ultimo passaggio compare solo nella traccia, alla posizione [0,3]; un esaminatore che leggesse soltanto i log perderebbe qui le tracce dei fondi. Nella terza transazione, il nuovo indirizzo ha inviato 7.89 ETH a 0x2bD1…f6, trattenendo circa 0,01 ETH per pagare il gas; quest'ultimo inoltra i depositi a un hot wallet di un exchange.

Ogni flusso qui è di grado A: è registrato on-chain e verificabile da un nodo. I ruoli (operatore e affiliato) sono inferenze basate sul modello di ripartizione. L'etichetta dell'indirizzo di deposito dell'exchange è una singola euristica finché l'exchange non la conferma; da lì la traccia prosegue come descritto nella lezione Tracciamento attraverso i servizi di custodia.

Stablecoin e visibilità a livello di emittente

I trasferimenti di stablecoin sono normali eventi di token e si tracciano in modo deterministico, ma le stablecoin hanno due caratteristiche aggiuntive. Primo, i contratti delle principali stablecoin garantite da valuta fiat mettono a disposizione dell'emittente una funzione di congelamento (blocklist), per cui a volte un saldo in stablecoin che non è ancora stato trasferito può essere bloccato più rapidamente di quanto si possa ottenere qualsiasi ordine del tribunale; le opzioni sono trattate nella lezione Opzioni di congelamento e sequestro. Secondo, l'emittente vede la stessa chain di chiunque altro e detiene registri d'identità soltanto per i propri clienti diretti, in genere quelli che creano e riscattano token. Un emittente può confermare quali indirizzi ha congelato e quali clienti hanno creato o riscattato token; non può dire chi controlla l'indirizzo di un normale detentore.

Registra la chain e l'indirizzo del contratto per ogni passaggio di stablecoin. Lo stesso ticker esiste su molte chain con contratti diversi, e una versione bridged è un contratto separato che la funzione di congelamento dell'emittente originale potrebbe non raggiungere. I grandi flussi di stablecoin su Tron sono trattati nella lezione Layer 2, sidechain e altre chain.

Flussi di wash trading di NFT

Gli NFT possono mascherare un trasferimento di valore da vendita. Un riciclatore compra un NFT da un wallet che controlla anch'egli, pagando con fondi illeciti, e i proventi sembrano redditi da trading. Per il tracciamento, è la parte del pagamento a veicolare il valore, non il token: segui l'ETH o la stablecoin pagati al venditore e considera il movimento dell'NFT come contesto. Gli indizi, come un finanziatore comune, cicli chiusi e prezzi molto superiori al prezzo minimo della collezione, sono trattati nella lezione IDFE-BA NFT e standard multi-token; il riciclaggio tramite NFT e gioco d'azzardo è trattato nella lezione Altre tecniche di offuscamento.

Focus sull'esame: i quattro canali in cui si sposta il valore sulle chain basate sul modello account e dove viene registrato ciascuno; perché i trasferimenti interni richiedono tracce da un nodo abilitato al tracing e perché vanno registrati client, versione e metodo; i campi aggiuntivi del record di un passaggio (indice del log o posizione nella traccia, contratto del token e decimali, mittente rispetto a from, stato); identificazione dei token tramite indirizzo del contratto e insidie dei token contraffatti e dell'avvelenamento degli indirizzi; approve, permit EIP-2612 (qualsiasi mittente, evento Approval emesso) e ripartizioni dei drainer come inferenza sui ruoli; lettura di una traccia decodificata di un drainer e riconciliazione degli importi; funzioni di congelamento delle stablecoin e limiti della visibilità dell'emittente; tracciamento della parte del pagamento nei flussi di wash trading di NFT.