Vedere uno swap fallire è una delle esperienze più frustranti su Solana, in particolare su una rete pubblicizzata come veloce e quasi gratuita. Il messaggio di errore che compare raramente spiega cosa sia andato storto in termini su cui chi non si occupa di ingegneria dei protocolli possa agire.

La parte incoraggiante è che questi errori seguono schemi molto prevedibili. Una volta che sai distinguere una transazione rifiutata dalla rete da una che non è mai arrivata, la soluzione corretta è quasi sempre una singola impostazione specifica, non questione di cliccare di nuovo sperando nel meglio. 👇

Che cos'è una transazione non riuscita su Solana?

Una transazione Solana fallita è una transazione che ha raggiunto con successo un validatore, è stata inclusa in un blocco e poi è stata rifiutata durante l'esecuzione perché una condizione da cui dipendeva non era più soddisfatta. Viene comunque registrata in modo permanente onchain, con un codice di errore e i log del programma allegati.

I wallet in genere mostrano questo errore come un banner rosso o una semplice etichetta «failed» senza ulteriori dettagli. Per trovare il motivo di fondo, incolla la firma della transazione in un explorer come Solscan e leggi i log del programma, che indicano l'istruzione esatta che è stata annullata e perché.

Un aspetto cruciale è che l'esecuzione su Solana è atomica. Se una singola istruzione all'interno della transazione genera un errore, ogni modifica di stato che la transazione avrebbe effettuato viene scartata completamente, quindi i saldi dei tuoi token restano esattamente come prima. L'unica cosa che perdi è la piccola commissione pagata per il tentativo.

Quell'atomicità è una caratteristica di sicurezza voluta, non un difetto di progettazione. Garantisce che non ti ritroverai mai con uno swap a metà, con token detratti da un lato ma nulla ricevuto dall'altro, un esito decisamente peggiore di un rifiuto pulito con annullamento completo.

Transazioni Solana scartate e fallite: le differenze

Questi due esiti sembrano praticamente identici dall'interno dell'interfaccia di un wallet, ma hanno cause opposte e richiedono soluzioni opposte. Imparare a distinguerli è il passaggio diagnostico più utile a disposizione di qualsiasi utente di Solana e non costa altro che attenzione.

Una transazione fallita è entrata in un blocco ed è stata poi respinta dalla logica del programma, lasciando una traccia permanente. Una transazione scartata non ha mai raggiunto un block leader, in genere perché è scaduta durante il tragitto o il nodo RPC ricevente era sovraccarico, e non ti costa nulla.

Il meccanismo dietro la maggior parte delle transazioni perse è la scadenza del blockhash. Ogni transazione Solana fa riferimento a un blockhash recente che resta valido per circa 150 blocchi, ovvero circa 60-90 secondi in tempo reale. Se perdi questa finestra ristretta, i validatori la rifiutano subito, una regola che esiste per prevenire gli attacchi di replay.

Esempio A (non riuscita): scambi USDC con SOL su Meteora, ma il prezzo supera la tolleranza di slippage impostata mentre la transazione è in esecuzione, quindi il programma la annulla. Il tentativo compare onchain con un errore di slippage esplicito e ti costa solo la commissione di rete.

Esempio B (scartata): acquisti un token su Pump.fun durante la frenesia di un lancio, ma il tuo endpoint RPC è indietro di diversi slot rispetto alla punta della catena e il blockhash scade prima che qualsiasi leader veda la transazione. Non compare nulla su alcun explorer e non viene addebitata alcuna commissione.

Quante transazioni Solana falliscono davvero?

I numeri da titolo secondo cui metà di tutte le transazioni su Solana fallisce sono al tempo stesso accurati e quasi del tutto privi di significato nella pratica, perché mettono insieme enormi volumi di spam di arbitraggio automatizzato e la normale attività dei wallet generata ogni giorno da persone reali.

Una ricerca accademica pubblicata nel 2025 ha finalmente risolto la questione con numeri concreti anziché stime. Uno studio sottoposto a revisione paritaria su 1,5 miliardi di transazioni fallite in 72 milioni di blocchi ha rilevato che gli account bot fallivano nel 58,43% dei casi, mentre gli account gestiti da persone fallivano in una quota molto più contenuta, pari al 6,22%.

Questo dato umano è molto importante per il contesto. Si colloca abbastanza vicino all'intervallo tipico di Ethereum, pari a 1 a 3%, e ben al di sotto dei tassi di fallimento del 21% e del 15,4% osservati su Base e Arbitrum, il che ridimensiona la reputazione di inaffidabilità di Solana, in gran parte un artefatto statistico dovuto ai bot più che un problema di esperienza utente.

La concentrazione conferma lo stesso punto. I dieci programmi che generano più fallimenti rappresentano il 77,95% del volume totale, con Raydium Liquidity Pool V4 da solo responsabile del 21,69%, mentre i bot sniper corrono a negoziare pool appena creati prima ancora che l'inizializzazione sia completata.

La congestione, però, pesa ancora molto nei periodi di picco. Quando la volatilità delle memecoin aumenta, i tassi di successo misurati delle transazioni non di voto sono scesi attorno al 76%, il che significa che circa una transazione genuina su quattro degli utenti fallisce, nonostante le medie di lungo periodo incoraggianti emerse dai dati accademici.

Cosa mostrano i dati sul motivo per cui le transazioni falliscono

I log degli errori sono molto più istruttivi di quanto la maggior parte degli utenti immagini, e lo stesso corpus di ricerche ha classificato ogni errore osservato in dieci categorie distinte. La distribuzione risultante è fortemente asimmetrica, e questa è una buona notizia, perché significa che un piccolo numero di correzioni mirate risolve la grande maggioranza dei problemi.

I tipi di errore alla base dei fallimenti delle transazioni su Solana si suddividono come segue:

• Prezzo o profitto non raggiunto (47,99%): la tolleranza di slippage è stata superata oppure una rotta di arbitraggio ha smesso di essere redditizia tra l'invio e l'esecuzione, attivando il revert di protezione che gli aggregatori DEX integrano.
• Stato non valido (19,19%): la transazione puntava a un account o a una liquidity pool in uno stato che non consentiva l'operazione, spesso una pool non inizializzata o un account token congelato.
• Scadenza della validità (17,72%): il blockhash di riferimento è diventato troppo vecchio prima che un validatore lo elaborasse, segno onchain di congestione, endpoint RPC in ritardo o firma lenta lato client.
• Account di input non valido (3,27%): gli indirizzi degli account richiesti erano mancanti, in ordine errato o non autorizzati, un problema frequente nei percorsi complessi che coinvolgono molti programmi contemporaneamente.
• Parametri di input non validi (2,55%): un argomento è fuori dall'intervallo accettato da un programma, ad esempio un importo minimo in output impostato a zero in un'istruzione di swap su Raydium.
• Fondi insufficienti (2,16%): il wallet non aveva abbastanza SOL per coprire il trasferimento più commissioni e rent, l'errore che colpisce in modo sproporzionato gli utenti umani piuttosto che i bot.
• Risorse esaurite (0,49%): la transazione ha esaurito il proprio budget di calcolo o ha superato i limiti di runtime sulla memoria heap, tipico dei percorsi multi-hop che coinvolgono decine di account.

Un risultato merita particolare attenzione da parte di chi è tentato di pagare semplicemente di più. Le transazioni fallite pagano in realtà commissioni più alte di quelle riuscite pur consumando meno unità di calcolo, e finiscono comunque più in profondità nei blocchi. Gettare denaro sul problema senza dimensionare correttamente il calcolo dimostrabilmente non funziona.

Cause comuni dei fallimenti delle transazioni su Solana

Traducendo queste categorie di errore in termini pratici, i fallimenti si concentrano in una manciata di errori di configurazione e di tempistica che dipendono quasi interamente da te come utente.

Ecco le cause più frequenti delle transazioni Solana fallite:

• Slippage troppo basso: impostare una tolleranza inferiore a quella richiesta dalla volatilità attuale porta quasi di certo ad======== annullamenti delle transazioni sui token a bassa liquidità, dove i prezzi possono muoversi di diversi punti percentuali tra la firma e l'esecuzione.
• Commissioni di priorità basse: i validatori ordinano le transazioni in base al prezzo per unità di calcolo, quindi una transazione con offerta troppo bassa viene superata e spinta in fondo ai blocchi nei periodi di forte domanda.
• Blockhash scaduto: una firma lenta, un RPC in ritardo o semplicemente l'esitazione davanti alla richiesta di conferma possono esaurire la finestra di validità prima che la transazione raggiunga un leader.
• Superamento del calcolo: i percorsi multi-hop attraverso più pool di exchange decentralizzato possono superare l'allocazione predefinita di 200.000 unità di calcolo per istruzione e venire interrotti.
• RPC sovraccarico: gli endpoint pubblici sono condivisi da un numero enorme di utenti e peggiorano nettamente durante i lanci, scartando le transazioni prima ancora che vengano trasmesse ai validatori.
• Saldo insufficiente: commissioni, rent per i nuovi account token e offerte di priorità utilizzano tutti SOL, quindi i wallet che detengono solo il token oggetto dello swap falliscono immediatamente.
• Liquidità scarsa: gli ordini di grandi dimensioni contro pool poco profondi non possono essere eseguiti a un prezzo accettabile e producono gli stessi revert insufficient liquidity già noti su altre chain.
• Account congelati: i creatori malevoli di token possono bloccare i trasferimenti dopo aver attirato acquirenti, uno schema honeypot che si manifesta come errore di stato non valido quando provi a vendere.

Come risolvere i fallimenti delle transazioni su Solana

Una volta individuato se il problema riguarda la logica di esecuzione o la trasmissione di rete, la soluzione è di solito un'impostazione specifica, più che un'indicazione generica di riprovare.

Queste modifiche risolvono la maggior parte degli errori nelle transazioni su Solana:

• Aumenta lo slippage con criterio: porta la tolleranza a 1 a 3% per i token volatili, accettando un prezzo leggermente peggiore in cambio dell'esecuzione invece di un'altra commissione sprecata.
• Offri commissioni di priorità in modo dinamico: in condizioni normali si chiude tra 1.000 e 5.000 micro-lamport per unità di calcolo, mentre lanci e liquidazioni possono richiedere 100.000 o più.
• Dimensiona con precisione le unità di calcolo: simula prima, poi imposta il limite vicino al consumo effettivo, poiché il prezzo compra priorità mentre un limite gonfiato spreca soltanto margine di manovra.
• Cambia provider RPC: gli endpoint dedicati di Helius, Triton o QuickNode trasmettono in modo affidabile durante la congestione, quando i nodi pubblici predefiniti sono già saturi e scartano richieste.
• Aggiorna prima di riprovare: recupera un nuovo blockhash a ogni tentativo invece di reinviare quello originale, che probabilmente è scaduto e fallirà di nuovo senza avvisi.
• Tieni da parte un po' di SOL: Solflare consiglia di lasciare almeno 0,05 SOL intatti, abbastanza per coprire senza problemi le commissioni di base, le offerte di priorità e gli eventuali depositi per l'affitto.
• Anteprima prima della firma: la simulazione del wallet individua gratuitamente le transazioni destinate a fallire, mentre un fallimento on-chain costa comunque la commissione base e l'eventuale offerta di priorità allegata.

Quanto costa una transazione Solana non riuscita?

Il danno finanziario di una transazione fallita è minimo, e questo è uno dei reali vantaggi strutturali di Solana rispetto alle chain con commissioni più alte. Ogni transazione prevede una commissione base di 0,000005 SOL per firma, e tale costo si applica sia che l'esecuzione vada a buon fine sia che si interrompa a metà.

Altri costi si applicano a seconda dei casi, non in modo generalizzato. L'apertura di un nuovo token account richiede un deposito una tantum per la rent di circa 0,002 SOL, mentre l'eventuale commissione di priorità che aggiungi è calcolata come prezzo per unità di calcolo moltiplicato per il limite di unità di calcolo, poi diviso per un milione.

Da febbraio 2025, il 100% delle commissioni di priorità va direttamente ai validatori invece di essere bruciato per metà, in seguito all'attivazione della modifica di governance SIMD-0096. La commissione di base continua a essere divisa equamente tra burn e produttore del blocco che include la tua transazione.

Esempio: Apri una posizione con leva su SOL tramite una piattaforma di contratti perpetui, il prezzo si muove oltre la tua tolleranza mentre la transazione è in corso e viene annullata. Il tuo collaterale resta intatto e perdi una frazione di centesimo. Per un'analisi più completa, consulta la nostra guida alle commissioni gas di Solana.

Come Firedancer e Alpenglow cambiano il quadro

La rete stessa sta cambiando in modi che affrontano direttamente la congestione responsabile delle transazioni perse, il che rende il trading nel 2026 un'esperienza sensibilmente diversa dal caos delle memecoin dell'inizio del 2024, che ha dato a Solana la sua reputazione di inaffidabilità.

1. Firedancer

Firedancer, il client validatore indipendente scritto da zero in C e C++ da Jump Crypto, è arrivato sulla mainnet a dicembre 2025 dopo test approfonditi. A metà 2026, circa il 14% dello stake della rete utilizzava Firedancer completo, e un ulteriore 26% la variante ibrida Frankendancer.

La diversità dei client incide direttamente sull'affidabilità. Fino a molto di recente, ogni singolo validatore eseguiva software derivato da Agave, il che significa che un bug non scoperto poteva bloccare l'intera chain in un colpo solo. Due implementazioni davvero indipendenti eliminano questo singolo punto di errore e aggiungono un utile margine di capacità durante i picchi di traffico.

2. Alpenglow

Alpenglow è la modifica molto più ampia ancora in sospeso. Approvata dai validatori a settembre 2025 con il 98,27% di consensi, sostituisce integralmente sia Tower BFT sia Proof of History, puntando a una finalità delle transazioni di circa 150 millisecondi rispetto ai circa 12,8 secondi del design attuale.

Per i tassi di errore in particolare, un dettaglio spicca più delle cifre di latenza principali. Alpenglow rimuove del tutto dal blockspace le transazioni di voto dei validatori e, poiché i voti consumano gran parte del throughput grezzo della rete, liberare quella capacità dovrebbe ridurre in modo significativo la contesa che causa perdite durante i picchi di domanda.

Tuttavia, la struttura delle commissioni resta irrisolta. La commissione base fissa per firma di Solana non risponde in alcun modo alla domanda, e una riprogettazione basata sulle risorse, che darebbe un prezzo separato al calcolo e all'accesso agli account, è in discussione attiva per tutto il 2026 senza aver prodotto una specifica definitiva.

Buone pratiche per evitare il fallimento delle transazioni su Solana

Su Solana la prevenzione batte sistematicamente la diagnosi, perché le impostazioni che causano i fallimenti vengono scelte molto prima che qualcosa raggiunga un validatore. Alcune abitudini adottate prima di iniziare a fare trading eliminano la maggior parte dei fallimenti che altrimenti ti interromperebbero a metà sessione e ti farebbero perdere i prezzi di ingresso.

1. Mantieni aggiornata la tua configurazione

Software obsoleto e infrastrutture pubbliche condivise causano errori che non hanno nulla a che vedere con i parametri di trading scelti. Affronta questa base prima di tutto il resto:

• Aggiorna i wallet regolarmente: Phantom, Solflare e Backpack rilasciano spesso miglioramenti nella stima delle commissioni, e le versioni obsolete non includono le correzioni di compatibilità per le modifiche a runtime e validatori.
• Usa un endpoint privato: l'accesso RPC dedicato costa poco ed elimina la principale causa di transazioni perse durante i lanci e altri eventi ad alto traffico.
• Elimina le sessioni bloccate: riavviare l'estensione o il browser risolve gli stati di connessione in cache che causano silenziosamente errori ripetuti molto dopo che le condizioni di rete si sono ripristinate.

2. Configura prima di confermare

La maggior parte dei revert dipende dalle impostazioni scelte prima di firmare, più che da ciò che accade in quel momento sulla rete stessa:

• Adatta lo slippage alla volatilità: i token appena lanciati richiedono una tolleranza sensibilmente più ampia rispetto alle coppie consolidate, per le quali impostazioni strette ti proteggono senza compromettere in modo significativo l'esecuzione.
• Simula i percorsi complessi: visualizza in anteprima gli swap che toccano più pool, perché la simulazione rivela il consumo di calcolo e i problemi di stato dell'account senza alcun costo.
• Finanzia il buffer per le commissioni: tieni SOL separati dalla tua posizione di trading, in modo che i depositi per la rent e le offerte di priorità non competano mai con gli asset che intendi negoziare.

3. Scegli bene il momento delle tue transazioni

Il momento in cui invii una transazione conta quasi quanto la configurazione, perché la congestione della rete si concentra in poche finestre prevedibili:

• Evita le finestre di lancio: i lanci di meme coin, le richieste di airdrop e le cascate di liquidazioni generano lo spam dei bot che penalizza più duramente gli utenti comuni.
• Suddividi le operazioni complesse: dividere le azioni DeFi in più passaggi in transazioni separate le mantiene entro i limiti di calcolo e isola eventuali errori in un solo componente.

Considerazioni finali

I fallimenti delle transazioni su Solana costano poco, sono del tutto reversibili e in gran parte evitabili una volta che li comprendi. Non si sposta nulla, non si perde nulla oltre una frazione di centesimo, e i log di errore associati a ogni tentativo indicano con precisione quale condizione non è stata soddisfatta e perché.

La distinzione da interiorizzare è quella tra rifiuto e mancata consegna. Una transazione fallita significa che i tuoi parametri erano sbagliati, mentre una scartata significa che non è mai arrivata; confondere le due porta le persone ad aumentare le commissioni quando dovrebbero aggiornare un blockhash.

Con Firedancer già attivo su mainnet e Alpenglow in arrivo, le cause di guasto a livello di rete diminuiscono costantemente di anno in anno. Resta la configurazione, che è sempre stata la parte dell'equazione interamente sotto il tuo controllo.