Quando si apre una pagina su Etherscan, la presenza di un segno di verifica o di una scheda “Contract” completa può dare un’impressione di sicurezza. Ma un contratto verificato non è automaticamente un contratto affidabile. E, soprattutto, il codice mostrato nella pagina potrebbe non essere quello che esegue davvero tutta la logica dell’applicazione.
Questo accade spesso con i contratti proxy: un indirizzo pubblico riceve le transazioni, mentre il codice operativo si trova in un altro indirizzo, chiamato implementazione. Il proxy può anche essere aggiornato nel tempo da un amministratore o da una governance. Capire questo meccanismo è utile quando si vuole controllare un token, una dApp o una funzione prima di firmare una transazione.
La procedura descritta qui è informativa e non sostituisce un audit del codice. Serve a leggere meglio ciò che Etherscan mostra, individuare segnali di attenzione e non confondere la verifica tecnica del codice con una certificazione del progetto.
Che cosa significa “contratto verificato” su Etherscan
Un contratto smart viene distribuito sulla blockchain tramite bytecode, cioè il codice macchina eseguito dalla rete. Il codice sorgente scritto dagli sviluppatori, invece, è più leggibile per una persona. Etherscan permette di confrontare il codice sorgente pubblicato con il bytecode effettivamente presente all’indirizzo.
Quando la verifica va a buon fine, il codice sorgente fornito corrisponde al bytecode distribuito, tenendo conto delle impostazioni di compilazione utilizzate. Questo consente di leggere funzioni, variabili ed eventi con maggiore chiarezza rispetto al solo bytecode.
La verifica, però, dimostra principalmente una corrispondenza tecnica. Non dimostra che:
- il contratto sia stato scritto bene;
- non contenga funzioni rischiose o intenzionalmente penalizzanti;
- il team sia affidabile;
- il contratto non possa essere modificato in futuro;
- il token abbia valore, liquidità o un mercato legittimo.
Un contratto può quindi essere verificato e contenere comunque commissioni elevate, funzioni di blocco dei trasferimenti, ruoli amministrativi molto potenti o logiche difficili da comprendere.
Come riconoscere un contratto proxy
La prima operazione consiste nell’aprire su Etherscan l’indirizzo corretto del contratto. È importante non affidarsi soltanto a un link ricevuto via social, chat o messaggio privato: un sito truffaldino può indirizzare a un contratto diverso da quello ufficiale.
Nella pagina del contratto si può osservare la scheda dedicata al codice. Se Etherscan riconosce una struttura proxy, può comparire un’indicazione come “Read as Proxy” o “Write as Proxy”. In altri casi la pagina segnala che l’indirizzo è un proxy oppure mostra un collegamento all’indirizzo dell’implementazione.
Un proxy svolge generalmente il ruolo di punto di accesso. Gli utenti chiamano il suo indirizzo, ma una particolare istruzione della macchina virtuale di Ethereum, il meccanismo delegatecall, fa eseguire la logica contenuta in un altro contratto. L’esecuzione mantiene, in linea generale, lo stato e il contesto del proxy, mentre il codice viene preso dall’implementazione.
Questo significa che leggere soltanto il codice del proxy può non bastare. Bisogna individuare anche l’indirizzo dell’implementazione e aprire la relativa pagina su Etherscan. È lì che spesso si trovano le funzioni operative del token o della dApp.
Dove trovare l’implementazione effettiva
Il collegamento all’implementazione può essere esposto direttamente nella pagina di Etherscan oppure individuato nella scheda “Read as Proxy”. Le modalità dipendono dallo standard usato dal contratto e dal modo in cui l’explorer riconosce il proxy.
Una volta individuato l’indirizzo, è utile controllare almeno questi elementi:
- se l’implementazione è verificata;
- quale compilatore e quali impostazioni di compilazione sono stati usati;
- se il codice presenta una struttura comprensibile o è fortemente offuscato;
- se esistono funzioni di aggiornamento dell’implementazione;
- quale indirizzo o quale meccanismo può autorizzare gli aggiornamenti.
Un’implementazione verificata è un elemento positivo sul piano della trasparenza, ma non elimina il rischio. È anche possibile che il proxy punti a un’implementazione non verificata o che venga aggiornato in seguito verso un nuovo contratto. Per questo la verifica va considerata una fotografia tecnica, non una garanzia permanente.
Proxy aggiornabile e proxy immutabile
La differenza più importante riguarda la possibilità di cambiare l’implementazione. In un sistema aggiornabile, un amministratore, un multisig o un meccanismo di governance può modificare il contratto a cui il proxy inoltra le chiamate.
L’aggiornabilità può avere motivazioni legittime: correggere un errore, adattare il protocollo o introdurre una nuova versione. D’altra parte, attribuisce a determinati soggetti un potere significativo. Se l’implementazione cambia, anche il comportamento delle funzioni chiamate dagli utenti può cambiare.
Su Etherscan si possono cercare nomi e funzioni come upgradeTo, upgradeToAndCall, upgradeImplementation o funzioni con significato analogo. I nomi non sono sempre identici e la loro assenza non prova da sola che il contratto sia immutabile. È necessario capire quale schema proxy viene utilizzato e quali controlli di accesso sono applicati.
Occorre inoltre verificare chi possiede il ruolo amministrativo. Nella scheda “Read Contract” dell’implementazione o del proxy possono comparire funzioni come owner, admin, getRoleMember o funzioni relative ai ruoli. Il risultato restituito è spesso un indirizzo. Questo indirizzo può essere esaminato separatamente per capire se appartiene a un singolo wallet, a un contratto multisig o a un altro componente.
Un singolo indirizzo con potere di aggiornamento presenta un profilo diverso rispetto a un sistema che richiede più firme o un processo di governance. Anche in questo caso non si tratta di una valutazione assoluta: il multisig riduce alcuni rischi, ma non rende automaticamente sicura la logica del contratto.
Come usare “Read Contract” senza inviare transazioni
La sezione “Read Contract” consente di interrogare alcune variabili e funzioni pubbliche senza firmare una transazione e senza pagare gas. È quindi uno strumento utile per una prima verifica non operativa.
Per un token, possono essere rilevanti:
- name e symbol, che indicano nome e ticker dichiarati;
- decimals, che stabilisce come viene visualizzata la quantità;
- totalSupply, cioè l’offerta registrata dal contratto secondo la sua logica;
- balanceOf, per interrogare il saldo associato a un indirizzo;
- owner o funzioni di ruolo, quando presenti;
- funzioni relative a mint, burn, pause, blacklist, fee o limiti di trasferimento.
La presenza di una funzione non indica necessariamente che sia stata utilizzata o che sia ancora attiva. Bisogna leggere il codice per capire quali condizioni ne regolano l’esecuzione e quali indirizzi sono autorizzati.
La sezione “Write Contract” è diversa: mostra funzioni che possono modificare lo stato della blockchain. Anche se l’interfaccia di Etherscan permette di collegare un wallet, non è necessario farlo per studiare la struttura. Prima di usare una funzione bisogna comprendere esattamente quali parametri richiede, quali autorizzazioni coinvolge e quali conseguenze può avere.
Le funzioni che meritano maggiore attenzione
Nei token e nelle dApp esistono funzioni legittime che possono tuttavia avere un impatto rilevante. Le funzioni di mint possono creare nuove unità, se il ruolo autorizzato non è stato revocato o limitato. Le funzioni di burn possono distruggere token secondo condizioni specifiche. Le funzioni pause possono sospendere trasferimenti o operazioni.
Alcuni contratti includono meccanismi per applicare commissioni, modificare i limiti di trasferimento o escludere determinati indirizzi. In altri casi il codice può impedire di vendere, consentire la vendita soltanto a certi indirizzi o cambiare rapidamente le condizioni operative.
Questi elementi non sono sempre una prova di truffa: possono appartenere a modelli progettati per esigenze regolamentari, amministrative o di gestione del rischio. Sono però segnali che richiedono un’analisi più approfondita e che rendono imprudente basarsi soltanto sul nome del token o sul numero dei possessori.
Come controllare l’aggiornamento del contratto
La cronologia delle transazioni del proxy può aiutare a capire se l’implementazione è stata cambiata. È utile cercare eventi relativi a upgrade, cambi di amministratore o trasferimenti di ruoli. La nomenclatura varia in base allo standard e al progetto, quindi non bisogna limitarsi a una singola parola chiave.
Si possono inoltre confrontare l’indirizzo dell’implementazione attuale e quelli indicati nelle transazioni precedenti. Se il contratto è aggiornabile, la lettura della pagina in un momento successivo potrebbe non descrivere il comportamento esistente quando è stata effettuata una vecchia operazione.
Un’ulteriore cautela riguarda l’indirizzo visualizzato nella pagina del token. Un progetto può cambiare contratto, distribuire nuove versioni o utilizzare contratti diversi su reti differenti. Il nome e il simbolo non sono identificatori sufficienti: l’indirizzo completo e la rete sono gli elementi da confrontare.
Errori comuni da evitare
- Confondere la verifica con un audit: Etherscan certifica la corrispondenza tra sorgente dichiarato e bytecode, non la qualità economica o di sicurezza del progetto.
- Leggere solo il proxy: la logica principale può trovarsi nell’implementazione.
- Ignorare i poteri amministrativi: owner, admin e ruoli possono modificare parametri o codice.
- Fidarsi del nome del token: nomi e ticker possono essere copiati da progetti noti.
- Usare “Write Contract” come test: una transazione di prova può avere conseguenze reali e irreversibili.
- Valutare soltanto il numero degli holder: gli indirizzi possono includere contratti, wallet inattivi o distribuzioni artificiali.
- Trascurare la rete: lo stesso nome può esistere su blockchain diverse con indirizzi e contratti differenti.
Una procedura pratica prima di interagire
Una verifica ragionevole può seguire una sequenza semplice. Prima si confermano rete e indirizzo direttamente da una fonte ufficiale e indipendente. Poi si controlla se il contratto è verificato e se Etherscan lo identifica come proxy.
Se è un proxy, si apre l’implementazione e si verifica la presenza del codice sorgente. Successivamente si esaminano le funzioni di amministrazione, gli eventuali ruoli, la possibilità di aggiornamento e le funzioni che possono creare, bloccare o limitare i token.
Infine si osservano transazioni ed eventi rilevanti per capire se vi siano stati aggiornamenti, cambi di proprietà o modifiche dei parametri. Questa procedura non elimina il rischio di bug, attacchi o comportamenti dannosi, ma evita uno degli errori più comuni: credere che l’indirizzo visibile sia sempre l’intero contratto e che il bollino di verifica equivalga a una garanzia.
Leggere Etherscan in modo consapevole significa quindi distinguere tre livelli: che cosa è stato pubblicato, quale codice viene eseguito davvero e chi può cambiarne il comportamento. Solo dopo questa distinzione la pagina del contratto diventa uno strumento utile per informarsi, invece di un semplice elemento grafico da interpretare come un segnale di sicurezza.
