Vedere uno swap diventare rosso è una delle esperienze più frustranti su Solana, in particolare su una rete pubblicizzata come veloce e quasi gratuita da usare. Il messaggio di errore che compare spiega raramente cosa sia effettivamente andato storto con termini comprensibili a chiunque non sia un ingegnere di protocollo.

La parte incoraggiante è che questi fallimenti seguono modelli altamente prevedibili. Una volta che si riesce a distinguere una transazione rifiutata dalla rete da una che non è mai arrivata, la correzione corretta è quasi sempre una singola impostazione specifica, anziché una questione di fare clic di nuovo e sperare. 👇

Cos'è una transazione fallita su Solana?

Una transazione fallita su Solana è una transazione che ha raggiunto con successo un validatore, è stata inclusa in un blocco ed è stata poi rifiutata durante l'esecuzione perché alcune condizioni da cui dipendeva non erano più soddisfatte. Viene comunque registrata permanentemente onchain, con un codice di errore e i registri dei programmi allegati.

I wallet in genere mostrano questo evento come un banner rosso o una semplice etichetta "failed" senza ulteriori dettagli. Per trovare la causa sottostante, 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 il motivo.

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

Questa atomicità è una funzione di sicurezza deliberata anziché un difetto di progettazione. Garantisce che non ti ritroverai mai a metà di uno swap, con i token detratti da un lato ma nulla ricevuto dall'altro, il che sarebbe un risultato considerevolmente peggiore rispetto a un rifiuto pulito e completamente invertito.

Transazioni Solana scartate e fallite a confronto

Questi due risultati sembrano praticamente identici dall'interno dell'interfaccia di un wallet, eppure hanno cause opposte e richiedono correzioni opposte. Imparare a distinguerli è il singolo 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 rifiutata dalla logica del programma, lasciando una registrazione permanente. Una transazione scartata non ha mai raggiunto un block leader, in genere perché è scaduta durante il transito o il nodo RPC ricevente era sovraccarico, e non ti costa nulla.

Il meccanismo alla base della maggior parte degli scarti è la scadenza del blockhash. Ogni transazione di Solana fa riferimento a un blockhash recente che rimane valido per circa 150 blocchi, ovvero circa 60-90 secondi in tempo reale. Se si perde quella stretta finestra temporale, i validatori la rifiutano categoricamente, una regola che esiste per prevenire attacchi di replay.

Esempio A (Fallita): Fai uno swap da USDC a SOL su Meteora, ma il prezzo supera la tua tolleranza allo slippage configurata mentre la transazione è in corso di esecuzione, quindi il programma la annulla. Il tentativo appare onchain con un errore di slippage esplicito allegato e ti costa solo la commissione di rete.

Esempio B (Scartata): Compri un token su Pump.fun durante una frenesia di lanci, ma il tuo endpoint RPC rimane indietro di diversi slot rispetto alla testa della catena e il blockhash scade prima che qualsiasi leader veda la transazione. Nulla appare su alcun explorer e non viene addebitata alcuna commissione.

Quante transazioni di Solana falliscono realmente?

I dati generali secondo cui la metà di tutte le transazioni di Solana fallisce sono allo stesso tempo accurati e quasi del tutto privi di significato nella pratica, perché raggruppano enormi volumi di spam di arbitraggio automatizzato insieme alla normale attività dei wallet che le persone reali generano ogni giorno.

La 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 su 72 milioni di blocchi ha rilevato che gli account dei bot falliscono nel 58,43% dei casi, mentre gli account gestiti da umani hanno fallito a un tasso molto più modesto del 6,22%.

Quella cifra relativa agli umani è estremamente importante per il contesto. Si colloca ragionevolmente vicino al tipico intervallo di Ethereum dall'1% al 3% e comodamente al di sotto dei tassi di fallimento del 21% e del 15,4% osservati su Base e Arbitrum, il che ridefinisce la reputazione di inaffidabilità di Solana come un problema statistico guidato principalmente dai bot piuttosto che un problema di esperienza utente.

La concentrazione rafforza lo stesso concetto. I dieci programmi che generano più fallimenti rappresentano il 77,95% del volume totale, con Raydium Liquidity Pool V4 da sola responsabile del 21,69% mentre i bot cecchini fanno a gara per scambiare pool appena creati prima ancora che l'inizializzazione sia completata.

Tuttavia, la congestione si fa ancora sentire durante i periodi di picco. Quando la volatilità delle memecoin aumenta, i tassi di successo misurati dei voti non validati sono scesi intorno al 76%, il che significa che circa una transazione utente legittima su quattro fallisce, nonostante le incoraggianti medie a lungo termine prodotte dai dati accademici.

Cosa mostrano i dati sui motivi per cui le transazioni falliscono

I registri degli errori sono considerevolmente più informativi di quanto la maggior parte degli utenti realizzi, e lo stesso corpo di ricerca ha classificato ogni fallimento osservato in dieci categorie distinte. La distribuzione risultante è fortemente sbilanciata, il che è una buona notizia, perché significa che una piccola manciata di soluzioni mirate risolve la stragrande 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 o un percorso di arbitraggio ha smesso di essere redditizio tra l'invio e l'esecuzione, attivando il meccanismo di protezione che i DEX aggregators integrano.
• Stato non valido (19,19%): La transazione era diretta a un account o a un liquidity pool in uno stato che non consentiva l'operazione, spesso un pool non inizializzato o un account di token bloccato.
• Scadenza della validità (17,72%): Il blockhash di riferimento è scaduto prima che un validatore lo elaborasse, l'impronta onchain di congestione, endpoint RPC in ritardo o una firma lato client lenta.
• Account di input non valido (3,27%): Indirizzi di account richiesti mancanti, ordinati in modo errato o non autorizzati, un problema frequente in percorsi complessi che toccano molti programmi contemporaneamente.
• Parametri di input non validi (2,55%): Un argomento è uscito dall'intervallo accettato da un programma, come un importo di output minimo impostato su zero su un'istruzione di swap di Raydium.
• Fondi insufficienti (2,16%): Il wallet non aveva abbastanza SOL per coprire il trasferimento più le commissioni e il rent, l'errore che colpisce in modo sproporzionato gli utenti umani piuttosto che i bot.
• Risorse esaurite (0,49%): La transazione ha esaurito il budget di calcolo o ha violato i limiti di runtime sulla memoria heap, tipico di percorsi a hop multipli che toccano decine di account.

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

Motivi comuni dei fallimenti delle transazioni su Solana

Traducendo queste categorie di errore in termini pratici, i fallimenti si concentrano attorno a una manciata di errori di configurazione e tempistica che sono quasi interamente sotto il vostro controllo come utenti.

Ecco le cause più frequenti alla base delle transazioni fallite su Solana:

• Slippage ristretto: Impostare la tolleranza al di sotto di quanto richiesto dalla volatilità attuale garantisce l'annullamento sui token a bassa liquidità, dove i prezzi possono variare di diversi percento tra la firma e l'esecuzione.
• Priority fee basse: I validatori ordinano le transazioni in base al prezzo per compute unit, quindi una transazione con un'offerta troppo bassa viene superata dalla concorrenza e spinta in profondità nei blocchi durante i periodi di forte domanda.
• Blockhash scaduto: Una firma lenta, un RPC in ritardo o semplicemente l'esitazione sul prompt di conferma possono consumare la finestra di validità prima che la transazione raggiunga mai un leader.
• Superamento dei limiti di calcolo: I percorsi a hop multipli attraverso diversi pool di decentralized exchange possono superare l'allocazione predefinita di 200.000 compute unit per istruzione e interrompersi.
• RPC sovraccarico: Gli endpoint pubblici sono condivisi da un numero enorme di utenti e subiscono un forte degrado durante i lanci, scartando le transazioni prima che vengano trasmesse ai validatori.
• Saldo insufficiente: Commissioni, rent per i nuovi account di token e offerte di priorità attingono tutti ai SOL, quindi i wallet che detengono solo il token oggetto dello swap falliscono immediatamente.
• Liquidità scarsa: Grandi ordini su pool poco profondi non possono essere eseguiti a nessun prezzo accettabile, producendo gli stessi annullamenti per insufficient liquidity già visti su altre chain.
• Account bloccati: Gli sviluppatori di token malevoli possono bloccare i trasferimenti dopo aver attirato acquirenti, uno schema honeypot che emerge come errore di stato non valido quando si tenta di vendere.

Come risolvere i fallimenti delle transazioni su Solana

Una volta identificato se il problema riguarda la logica di esecuzione o la trasmissione sulla rete, il rimedio consiste solitamente in un'impostazione specifica piuttosto che in un invito generico a riprovare.

Queste regolazioni risolvono la maggior parte dei fallimenti delle transazioni su Solana:

• Aumentare lo slippage in modo sensato: Portare la tolleranza dall'1% al 3% per i token volatili, accettando prezzi leggermente peggiori in cambio dell'esecuzione invece di un'altra commissione sprecata.
• Offrire priority fee in modo dinamico: In condizioni normali le transazioni vengono elaborate a 1.000 - 5.000 micro-lamport per compute unit, mentre i lanci e le liquidation possono richiedere 100.000 o più.
• Dimensiona i compute unit con precisione: Simula prima, poi imposta il limite vicino al consumo effettivo, poiché il prezzo compra priorità mentre un limite gonfiato spreca solo margine.
• Cambia i 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 le richieste.
• Aggiorna prima di riprovare: Recupera un nuovo blockhash per ogni tentativo anziché risottomettere quello originale, che probabilmente è scaduto e fallirà di nuovo silenziosamente.
• Tieni SOL di scorta: Solflare consiglia di lasciare intatti almeno 0,05 SOL, una quantità sufficiente per assorbire comodamente le base fee, le offerte di priorità e qualsiasi deposito di rent.
• Visualizza un'anteprima prima di firmare: La simulazione del wallet intercetta gratuitamente le transazioni destinate al fallimento, mentre un fallimento Onchain costa comunque la base fee e qualsiasi offerta di priorità associata.

Quanto costa una transazione Solana fallita?

Il danno finanziario derivante da una transazione fallita è minimo, il che rappresenta uno dei veri vantaggi strutturali di Solana rispetto alle blockchain con fee più elevate. Ogni transazione comporta una base fee di 0,000005 SOL per firma e tale costo si applica indipendentemente dal fatto che l'esecuzione vada a buon fine o venga annullata a metà.

Costi aggiuntivi si applicano in base alle situazioni piuttosto che universalmente. L'apertura di un nuovo account di token richiede un deposito di rent una tantum di circa 0,002 SOL, mentre qualsiasi priority fee aggiunta viene calcolata come il prezzo dei compute unit moltiplicato per il limite dei compute unit, diviso poi per un milione.

Da febbraio 2025, il 100% delle priority fee va direttamente ai validatori anziché vederne bruciata la metà, in seguito all'attivazione della modifica di governance SIMD-0096. La base fee stessa continua a dividersi equamente tra il meccanismo di burn e il produttore del blocco che include la transazione.

Esempio: Apri una posizione SOL con leverage tramite una piattaforma per perps, il prezzo si muove oltre la tua tolleranza mentre la transazione è in transito e questa viene annullata. La tua garanzia è intatta e ci hai rimesso solo una frazione di centesimo. Per un'analisi più dettagliata, consulta la nostra guida sulle gas fee di Solana.

In che modo Firedancer e Alpenglow cambiano la situazione

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

1. Firedancer

Firedancer, il client validatore indipendente scritto da zero in C e C++ da Jump Crypto, ha raggiunto la mainnet a dicembre 2025 dopo test approfonditi. Verso la metà del 2026, circa il 14% dello stake della rete eseguiva Firedancer in versione completa, con un ulteriore 26% sulla variante ibrida Frankendancer.

La diversità dei client è fondamentale per l'affidabilità. Fino a pochissimo tempo fa, ogni singolo validatore eseguiva software derivato da Agave, il che significava che un singolo bug non scoperto avrebbe potuto bloccare l'intera chain all'istante. Due implementazioni realmente indipendenti eliminano quel singolo punto di errore e aggiungono un prezioso margine di throughput durante i picchi di traffico.

2. Alpenglow

Alpenglow è la modifica notevolmente più grande ancora in sospeso. Approvato dai validatori a settembre 2025 con il 98,27% dei consensi, sostituisce del tutto sia Tower BFT che Proof of History, puntando a una finalità delle transazioni vicina a 150 millisecondi rispetto ai circa 12,8 secondi del design attuale.

Per quanto riguarda specificamente i tassi di fallimento, un dettaglio spicca rispetto ai dati principali sulla latenza. Alpenglow rimuove del tutto le transazioni di voto dei validatori dallo spazio dei blocchi e, poiché i voti consumano la stragrande maggioranza del throughput grezzo della rete, liberare tale capacità dovrebbe ridurre in modo significativo la contesa che causa gli scarti durante i picchi di domanda.

Tuttavia, la struttura delle fee rimane incerta. La base fee fissa per firma di Solana non risponde in alcun modo alla domanda e una riprogettazione basata sulle risorse, che prezzerebbe individualmente il calcolo e l'accesso agli account, è stata oggetto di discussione attiva per tutto il 2026 senza produrre una specifica definitiva.

Best practice per evitare il fallimento delle transazioni su Solana

La prevenzione batte costantemente la diagnosi su Solana, poiché le impostazioni che causano i fallimenti vengono scelte molto prima che qualsiasi cosa raggiunga un validatore. Qualche abitudine consolidata prima di iniziare a fare trading eliminerà la maggior parte dei fallimenti che altrimenti vi interromperebbero a metà sessione facendovi perdere i prezzi d'ingresso.

1. Mantieni aggiornata la tua configurazione

Software obsoleti e infrastrutture pubbliche condivise causano entrambi fallimenti che non hanno assolutamente nulla a che fare con i parametri di trading scelti. Affronta queste basi prima di ogni altra cosa:

• Aggiorna regolarmente i wallet: Phantom, Solflare e Backpack rilasciano frequentemente miglioramenti per la stima delle fee e le versioni obsolete perdono le correzioni di compatibilità per i cambiamenti del runtime e dei validatori.
• Utilizza un endpoint privato: l'accesso RPC dedicato costa poco e rimuove la principale fonte di transazioni scartate durante i lanci e altri eventi ad alto traffico.
• Cancella le sessioni bloccate: riavviare l'estensione o il browser risolve gli stati di connessione memorizzati nella cache che causano silenziosamente guasti ripetuti molto tempo dopo il ripristino delle condizioni di rete.

2. Configura prima di confermare

La maggior parte dei ripristini viene determinata dalle impostazioni scelte prima della firma, piuttosto da quanto sta accadendo sulla rete stessa in quel momento:

• Adatta lo slippage alla volatilità: i token appena lanciati richiedono una tolleranza notevolmente maggiore rispetto alle coppie consolidate, dove impostazioni rigide ti proteggono senza mettere significativamente a rischio l'esecuzione.
• Simula percorsi complessi: visualizza in anteprima gli swap che coinvolgono più pool, poiché la simulazione rivela problemi di consumo di calcolo e di stato dell'account a costo zero.
• Finanzia il buffer delle commissioni: tieni SOL separato dalla tua posizione di trading in modo che i depositi di rent e le offerte di priority fee non competano mai con gli asset che intendi negoziare.

3. Pianifica bene le tue transazioni

Il momento in cui invii una transazione conta quasi quanto il modo in cui la configuri, poiché la congestione della rete si concentra pesantemente in poche finestre prevedibili:

• Evita le finestre di lancio: i lanci di meme coin, le richieste di airdrop e le cascate di liquidation generano lo spam di bot che esclude più gravemente gli utenti comuni.
• Suddividi le operazioni di grandi dimensioni: dividere le azioni DeFi in più passaggi in transazioni separate mantiene ciascuna entro i limiti di calcolo e isola qualsiasi errore su un singolo componente.

Considerazioni finali

I fallimenti delle transazioni su Solana sono economici, completamente reversibili e ampiamente prevenibili una volta compresi. Nessun movimento, nulla viene perso se non una frazione di centesimo e i log di errore associati a ogni tentativo ti dicono esattamente quale condizione non è stata soddisfatta e perché.

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

Con Firedancer già attivo su mainnet e Alpenglow che si avvicina all'attivazione, le cause di fallimento a livello di rete si riducono costantemente anno dopo anno. Ciò che rimane è la configurazione, che è sempre stata la parte dell'equazione interamente sotto il tuo controllo.