Quando una transazione Ethereum non va a buon fine, il wallet può mostrare un messaggio generico come “transazione fallita” o “execution reverted”. Per capire il motivo reale, però, spesso bisogna esaminare la pagina della transazione su Etherscan.
La distinzione più importante è questa: una transazione fallita può non aver modificato il saldo o lo stato del contratto, ma normalmente il gas utilizzato per tentare l’esecuzione non viene restituito. Per questo leggere correttamente la ricevuta, il campo “Status”, il gas e i dati della chiamata è utile sia per evitare tentativi ripetuti sia per riconoscere errori di autorizzazione, slippage, nonce o configurazione.
Che cosa significa “Failed” su Etherscan
La pagina di una transazione Ethereum contiene un campo chiamato “Status”. Se la transazione è stata inclusa in un blocco e l’esecuzione è terminata correttamente, lo stato viene generalmente indicato come “Success”. Se invece l’esecuzione è stata annullata dal protocollo o dal contratto, compare “Failed” oppure un’indicazione equivalente.
Una transazione fallita non è la stessa cosa di una transazione ancora in attesa. Una transazione pending non è stata ancora definitivamente inclusa in un blocco; una transazione failed, invece, è stata già registrata sulla blockchain, ma la sua esecuzione non ha prodotto il risultato richiesto.
In caso di revert, le modifiche di stato eseguite prima dell’errore vengono normalmente annullate. Per esempio, un trasferimento di token iniziato da uno smart contract può non completarsi se una condizione successiva non viene soddisfatta. Non significa però che l’operazione sia stata gratuita: il network ha comunque consumato risorse per elaborare la chiamata e il mittente paga il gas utilizzato.
La lettura pratica della pagina della transazione
Per iniziare, copia l’hash della transazione dal wallet e incollalo su Etherscan. Verifica innanzitutto di essere sul network corretto: una transazione Ethereum mainnet, una su una rete layer 2 o una su una testnet possono avere esploratori e costi differenti.
Nella parte principale della pagina si trovano alcuni elementi fondamentali:
- Transaction Hash: è l’identificativo univoco della transazione. Serve per cercarla e condividerla, ma non contiene la seed phrase né permette da solo di spendere i fondi.
- Status: indica se la transazione è riuscita, fallita o, in alcuni casi, se è ancora in attesa di essere indicizzata.
- Block: mostra il blocco in cui la transazione è stata inclusa. La presenza di un numero di blocco indica che non è più semplicemente pending.
- From: è l’indirizzo che ha firmato e inviato la transazione.
- To: è il destinatario della chiamata. Può essere un normale indirizzo, un contratto o, in alcuni casi, un indirizzo speciale utilizzato dal protocollo.
- Value: indica la quantità di ETH inviata direttamente nella transazione, se presente. Non include automaticamente il valore dei token trasferiti dentro una funzione di smart contract.
- Transaction Fee: è il costo pagato per l’esecuzione. Dipende dal gas effettivamente consumato e dal prezzo del gas applicato alla transazione.
Il campo “To” merita attenzione. Se la transazione interagisce con un exchange decentralizzato, un bridge, un protocollo di lending o un altro servizio, l’indirizzo indicato spesso è quello del contratto che riceve la chiamata, non necessariamente quello dell’utente o del destinatario finale dei token.
Gas limit, gas utilizzato e costo effettivo
Per comprendere una transazione fallita bisogna distinguere tra “Gas Limit” e “Gas Used”. Il gas limit è la quantità massima di gas che il mittente autorizza per quella transazione. Il gas used è la quantità effettivamente consumata durante l’esecuzione.
Se il gas utilizzato raggiunge il limite impostato, una possibile causa è “out of gas”. In questo caso l’esecuzione si interrompe perché il limite non era sufficiente per completare il calcolo. Altri revert possono invece consumare solo una parte del limite, perché il contratto interrompe l’operazione prima di esaurire il gas.
Il costo effettivo non si determina guardando soltanto il limite massimo. In linea generale, la commissione dipende dal gas utilizzato e dal prezzo applicato per unità di gas. Il limite rappresenta soprattutto il tetto autorizzato; l’importo realmente addebitato è collegato al consumo effettivo, salvo meccanismi specifici della rete e della transazione.
Una transazione fallita per “out of gas” non è automaticamente la stessa cosa di una transazione rifiutata perché il contratto ha restituito un errore. Nel primo caso può essere mancato il gas necessario; nel secondo, la logica del contratto ha bloccato l’operazione per una condizione non rispettata.
Come individuare il motivo del revert
Su Etherscan può essere disponibile una sezione come “More Details”, “Click to see More” o un collegamento a una simulazione o a un messaggio di errore. La disponibilità e la chiarezza della decodifica dipendono dal contratto, dall’ABI pubblicata e dagli strumenti utilizzati dall’esploratore.
Tra gli errori più comuni si possono incontrare:
- Execution reverted: il contratto ha rifiutato l’operazione. Il messaggio può essere generico oppure accompagnato da una motivazione, come saldo insufficiente, autorizzazione mancante o condizione non soddisfatta.
- Insufficient allowance: il contratto non dispone dell’autorizzazione necessaria a utilizzare i token per conto dell’utente.
- Insufficient balance: il saldo disponibile non è sufficiente, eventualmente anche dopo aver considerato il gas da pagare in ETH.
- Slippage o limite di prezzo: in uno scambio, il prezzo ottenibile durante l’esecuzione non rispettava il limite impostato dall’utente o dal protocollo.
- Deadline expired: l’operazione è arrivata dopo il termine entro cui era valida.
- Paused, not authorized o wrong caller: il contratto è in pausa oppure la funzione può essere chiamata soltanto da determinati indirizzi.
- Out of gas: il limite di gas non è stato sufficiente oppure l’esecuzione ha richiesto più risorse di quelle autorizzate.
Non tutti i messaggi sono decodificati in modo completo. Un errore visibile nel wallet può essere più leggibile di quello mostrato dall’esploratore, mentre in altri casi accade il contrario. La pagina Etherscan va quindi considerata come una fonte tecnica da interpretare insieme ai dettagli dell’operazione, non come un traduttore infallibile.
Input Data: che cosa stava cercando di fare la transazione
Il campo “Input Data” contiene i dati della chiamata al contratto. In una semplice transazione di ETH può essere vuoto; quando si interagisce con uno smart contract, invece, contiene il selettore della funzione e i relativi parametri codificati.
Se il contratto è verificato, Etherscan può mostrare una versione leggibile della funzione, con nomi come “approve”, “transfer”, “swap” o “deposit”. Questo aiuta a capire l’azione richiesta, ma bisogna leggere con attenzione i parametri: quantità, indirizzi, scadenze, limiti di prezzo e autorizzazioni possono essere codificati in formati non immediatamente intuitivi.
Un contratto verificato non è automaticamente sicuro e una funzione decodificata non è automaticamente innocua. La verifica del codice migliora la trasparenza, ma non elimina bug, funzioni amministrative, rischi economici o comportamenti inattesi. Prima di ripetere un’operazione fallita, è importante capire quale parametro o quale condizione ha causato il revert.
Internal transactions e token transfers: perché possono confondere
Nella pagina della transazione si possono trovare schede come “Internal Txns” e “Token Transfers”. Non sono necessariamente nuove transazioni firmate dall’utente.
Le internal transactions sono chiamate interne o tracce generate durante l’esecuzione di uno smart contract. Possono mostrare, per esempio, un trasferimento di ETH effettuato dal contratto verso un altro indirizzo. Non hanno un hash indipendente firmato dall’utente come una normale transazione.
La scheda “Token Transfers” mostra invece i trasferimenti di token rilevati dagli eventi standard o dagli strumenti di indicizzazione. In una transazione riuscita può aiutare a verificare chi ha inviato e ricevuto un token. In una transazione fallita, tuttavia, bisogna evitare conclusioni affrettate: se l’esecuzione è stata revertita, i trasferimenti di stato collegati alla chiamata non dovrebbero restare validi, anche se alcune interfacce possono presentare tracce tecniche o dati parziali durante l’elaborazione.
Nonce e transazioni sostitutive
Il nonce è il numero progressivo associato alle transazioni inviate da un determinato indirizzo. Ogni nuova transazione deve utilizzare il nonce previsto dalla sequenza dell’account.
Se una transazione è bloccata, sostituita o inviata con un nonce già utilizzato, il wallet può mostrare messaggi come “replacement transaction underpriced”, “nonce too low” o “already known”. Questi errori non descrivono necessariamente un problema dello smart contract: possono riguardare la gestione locale delle transazioni e la sincronizzazione tra wallet e rete.
Prima di inviare nuovamente una transazione, controlla se esiste già un’altra transazione con lo stesso nonce e quale sia il suo stato. Creare molti tentativi senza capire la sequenza può aumentare la confusione e generare ulteriori costi.
Che cosa fare dopo una transazione fallita
La procedura più prudente è separare diagnosi e nuovo invio:
- controlla network, indirizzo mittente e contratto destinatario;
- verifica il saldo del token e la quantità di ETH disponibile per il gas;
- leggi il messaggio di revert e confrontalo con l’azione richiesta;
- controlla allowance, deadline, slippage e altri parametri dell’operazione;
- verifica nonce e presenza di transazioni precedenti ancora pending;
- non aumentare automaticamente il gas limit se l’errore è una condizione logica del contratto;
- non ripetere la stessa chiamata se il contratto è sconosciuto o se la richiesta del wallet appare diversa da quella prevista.
Un simulatore o un’anteprima della transazione può aiutare a individuare un revert prima della firma, ma non garantisce che il risultato resti identico: saldo, liquidità, prezzo e stato del contratto possono cambiare prima dell’inclusione nel blocco.
Errori da evitare nella lettura di Etherscan
Il primo errore è pensare che “Failed” significhi sempre perdita definitiva dei fondi. Spesso il risultato economico principale non si è verificato, ma il gas può essere stato consumato.
Il secondo è considerare la presenza di un trasferimento nella pagina come prova sufficiente che i token siano stati ricevuti. Bisogna verificare lo stato finale della transazione, l’indirizzo corretto, il contratto del token e la rete utilizzata.
Il terzo è confondere un contratto verificato con un contratto affidabile. La verifica rende il codice consultabile, ma non costituisce un audit, una garanzia o un’approvazione.
Infine, non bisogna inserire seed phrase, chiavi private o codici di accesso in siti che promettono di “sbloccare” una transazione fallita. Etherscan serve per osservare dati pubblici della blockchain: nessun servizio legittimo ha bisogno della chiave privata per spiegare un revert.
Leggere una transazione fallita su Etherscan significa ricostruire la sequenza completa: chi ha firmato, quale contratto è stato chiamato, quale funzione è stata richiesta, quanto gas è stato consumato e quale condizione ha interrotto l’esecuzione. Questa analisi non elimina i rischi degli smart contract, ma permette di distinguere un problema di rete o nonce da un errore di saldo, autorizzazione o logica del protocollo, evitando di ripetere operazioni alla cieca.
