Cos'è la liquidità insufficiente su un DEX?
Una liquidità insufficiente su un exchange decentralizzato significa che il pool per la tua coppia di trading non è in grado di fornire una quantità sufficiente del token desiderato entro il limite di slippage scelto. Il contratto calcola l'output previsto, lo confronta con il tuo minimo e rifiuta la transazione quando tale soglia non può essere raggiunta.
Gli automated market maker prezzano i trade in base al rapporto tra i token detenuti in un pool. Acquistare da un lato altera tale rapporto e spinge il prezzo verso l'alto. Quando un ordine è di grandi dimensioni rispetto alle riserve disponibili, il tasso può muoversi a sufficienza affinché la quotazione originale non sia più valida. L'interfaccia mostra quindi un errore prima che venga speso qualsiasi gas.
Coppie profonde come ETH/USDC su Uniswap possono assorbire swap a sei cifre con solo una frazione di percentuale di impatto sul prezzo. I nuovi token, le memecoin e altri asset long-tail sono diversi. I loro pool detengono spesso meno di 100.000 $, rendendo un ordine di 5.000 $ sufficientemente grande da consumare una porzione visibile di una riserva.

Cause di liquidità insufficiente per questa operazione
Diverse condizioni possono attivare lo stesso errore. Le riserve scarse sono le più comuni, sebbene la liquidità concentrata, la frammentazione delle catene, le meccaniche dei token e la logica degli hook personalizzata possano produrre un risultato identico.
Come risolvere l'errore di liquidità insufficiente per questa operazione
Per eliminare l'errore, dai al contratto più margine di esecuzione o indirizza l'ordine verso riserve più profonde. I quattro metodi seguenti procedono dalla soluzione più semplice a quella più pratica.
Soluzione 1: Utilizza un aggregatore di DEX
Un DEX aggregator come 1inch, Jupiter o KyberSwap verifica decine di pool anziché affidarsi a un solo exchange. Può suddividere l'ordine tra più fonti e regolare il tutto in un'unica transazione, risolvendo spesso l'errore senza modificare le impostazioni.
Segui questi passaggi per completare uno swap tramite un aggregator:
- Connetti il wallet: Apri l'interfaccia dell'aggregator e connetti un crypto wallet in self-custody. Conferma di trovarti sulla blockchain in cui il token possiede il pool più profondo.
- Seleziona gli asset: Scegli il token in tuo possesso, quindi incolla l'indirizzo esatto del contratto per il token di output. Un semplice ticker potrebbe corrispondere a token imitatori con pool vuoti.
- Verifica la divisione: Controlla il percorso di esecuzione proposto. Una quotazione affidabile spesso suddivide il trade tra più exchange o versioni di pool anziché imporlo attraverso un unico pool poco profondo.
- Confronta l'impatto: Confronta il price impact visualizzato con la quotazione del pool diretto. Qualsiasi valore superiore al 2% costituisce un avviso del fatto che il token manca di profondità su quella blockchain.
- Imposta la tolleranza: Mantieni lo slippage predefinito dell'aggregator per le coppie principali. Aumentalo solo a piccoli passi se la simulazione segnala ancora un deficit di output.
- Conferma lo swap: Firma la transazione, quindi confronta la quantità ricevuta con l'output minimo mostrato prima dell'approvazione.

Soluzione 2: Modifica le impostazioni di tolleranza dello slippage
Ogni swap include un output minimo derivato dalle impostazioni di slippage. Se l'output stimato del pool scende al di sotto di tale cifra, il contratto rifiuta la transazione. Una tolleranza più elevata abbassa il minimo, offrendo a un pool volatile o poco profondo maggiore margine per essere eseguito a un tasso peggiore.
Aumentalo gradualmente. Passa dallo 0,5% all'1%, poi al 2%, fermandoti non appena la quotazione va a buon fine. Ogni punto percentuale aggiuntivo rappresenta un valore a cui hai accettato di rinunciare e offre ai bot di sandwich maggiore margine per sfruttare la transazione. La guida alla risoluzione dei problemi di PancakeSwap consiglia lo stesso approccio incrementale per i token con commissioni sui trasferimenti.
Soluzione 3: Frammenta l'importo totale della tua operazione
Suddividere un ordine di grandi dimensioni in diversi swap più piccoli riduce il movimento di prezzo causato da ciascuna esecuzione. Dà inoltre ai bot di arbitraggio il tempo di ribilanciare il pool tra un trade e l'altro, sebbene si paghi gas aggiuntivo.
Usa questo metodo manuale quando un aggregator segnala ancora un deficit:
- Dimensiona le parti: Dividi l'ordine in blocchi di valore non superiore al 2%-3% del valore totale bloccato del pool. In questo modo il price impact per ciascuna esecuzione rimane inferiore all'1%.
- Esegui la prima parte: Esegui il primo blocco e registra l'output esatto. Monitora il pool su DexScreener per verificare la rapidità con cui il prezzo si riprende.
- Attendi brevemente: Consenti ai bot di arbitraggio alcuni blocchi per ribilanciare la coppia prima di effettuare il trade successivo. Questa operazione richiede meno di un minuto su Ethereum e pochi secondi su Solana.
- Ripeti le esecuzioni: Procedi con blocchi uguali fino al completamento della posizione. Riduci le dimensioni se il price impact di una qualsiasi esecuzione supera la soglia scelta.
- Traccia i costi: Somma i costi di gas e i prezzi effettivi di ogni esecuzione. Confronta il totale con la quotazione iniziale per un singolo swap, poiché la frammentazione ha senso solo quando il costo finale risulta inferiore.
- Automatizza in seguito: Per i trade ricorrenti, applica lo stesso approccio tramite un ordine programmato o ponderato nel tempo su Jupiter o CoW Swap, in modo che la suddivisione avvenga senza firme manuali.
Soluzione 4: Fai trading tramite una coppia di intermediari liquidi
I pool diretti tra due token minori sono spesso sottili. Entrambi gli asset potrebbero comunque disporre di una profonda liquidità rispetto a ETH, SOL o USDC. Fare trading attraverso uno di questi asset principali sfrutta due pool liquidi anziché costringere l'intero ordine a passare attraverso una coppia diretta poco profonda.
Gli aggregator adottano già automaticamente questo percorso quando produce una quotazione migliore. Ogni passaggio aggiunge un'ulteriore commissione di pool e, su Ethereum, un ulteriore costo di gas. La spesa aggiuntiva è trascurabile su Solana, dove Jupiter può instradare un singolo ordine di memecoin attraverso diversi pool di Raydium, Orca e Meteora quando ciò garantisce un'esecuzione migliore.
Cos'è lo slippage nelle criptovalute?
Lo slippage è la differenza tra il prezzo quotato al momento dell'invio dello swap e il prezzo a cui viene infine regolato onchain. I blocchi richiedono tempo per essere confermati, altri ordini possono muovere il pool prima che il tuo venga elaborato e il tuo stesso trade modifica il prezzo man mano che viene eseguito.
Il price impact si riferisce nello specifico al movimento causato dal tuo ordine. Le sue dimensioni dipendono dal trade rispetto alla liquidità disponibile. Uno swap da 1.000 $ influisce a malapena su un pool da 10 milioni di $, mentre lo stesso ordine può muovere un pool da 50.000 $ di diversi punti percentuali.
La tolleranza allo slippage definisce il tasso peggiore che sei disposto ad accettare. Se l'output finale scende al di sotto di tale limite, il contratto rifiuta lo swap. Limiti rigorosi proteggono il trade ma falliscono più spesso nei pool sottili. Limiti flessibili migliorano le probabilità di esecuzione lasciando però una maggiore quantità di valore esposta ai bot.

Può verificarsi una liquidità insufficiente su qualsiasi DEX?
L'errore deriva dal modello automated market maker, in cui le riserve in pool sostituiscono una controparte in tempo reale. Le sedi con order book non restituiscono lo stesso messaggio, sebbene order book poco profondi possano comunque generare esecuzioni parziali e spread elevati.
Le sedi con order book come Hyperliquid abbinano i trade ai limit order presenti a libro. Di conseguenza, un grande ordine d'acquisto a mercato si sposta progressivamente nel libro a prezzi peggiori anziché fallire per la liquidità insufficiente del pool. La guida di Datawallet ai dex (exchange decentralizzati) di perpetual decentralizzati spiega come questi order book gestiscano la profondità e gli spread durante i periodi di volatilità.
Perché la liquidità Onchain continua a frammentarsi
Un singolo token può ora essere scambiato su più chain, versioni di pool e livelli di commissione. Ogni mercato necessita di una profondità indipendente sufficiente affinché un ordine diretto vada a buon fine senza attivare un errore di liquidità.
Gli hooks di Uniswap V4 moltiplicano i pool per coppia
Uniswap V4 consente a chiunque di collegare un hook contract a un pool. Gli hooks possono modificare le commissioni, limitare chi fa trading o cambiare il comportamento della liquidità attorno a uno swap. Ogni hook crea un pool separato per la stessa coppia. Un token può quindi avere una dozzina di pool V4 insieme ai suoi mercati V2 e V3, distribuendo le riserve su un numero maggiore di sedi.
L'analisi di Datawallet su Uniswap V4 spiega come l'Universal Router confronti i prezzi di V2, V3 e V4 all'interno di un'unica transazione e possa suddividere gli ordini tra le varie versioni. Un pool con hook selezionato manualmente salta questo confronto. È questo il motivo per cui uno swap instradato tramite un'interfaccia può avere successo quando un trade diretto su un pool fallisce.

I Layer 2 e i silo di Solana suddividono la profondità per chain
Le classifiche di DefiLlama sugli ultimi 30 giorni all'inizio di agosto collocavano Solana a quasi 50 miliardi di dollari di volume DEX spot. BNB Chain seguiva con 31 miliardi di dollari, Ethereum con 29 miliardi di dollari e Base con 22 miliardi di dollari, secondo The Defiant. Un token distribuito su quattro chain ha comunque bisogno di quattro pool finanziati separatamente. La maggior parte dei progetti concentra la propria liquidità in uno solo.
La serie DEX-to-CEX di The Block ha registrato il volume spot onchain al 24% del volume degli exchange centralizzati a luglio 2026, il livello più alto dall'inizio del tracciamento nel 2019. Il volume DEX assoluto è calato del 26% nello stesso mese. Con un minor numero di arbitraggisti attivi che ripristinano l'equilibrio dopo grandi trade, un pool sbilanciato può rimanere tale più a lungo.
I bin concentrati escono dall'intervallo
I pool DLMM di Meteora e CLMM di Raydium inseriscono il capitale all'interno di bin di prezzo discreti selezionati in anticipo dai liquidity provider. Lo slippage è prossimo allo zero mentre il mercato scambia all'interno di un bin attivo. Una volta che il prezzo esce dall'intervallo popolato, tale liquidità smette di partecipare agli swap. Il pool utilizzabile può quindi risultare molto più piccolo di quanto suggerito dal suo valore totale bloccato di riferimento.
Come evitare problemi di liquidità insufficiente
Evitare l'errore è più economico che correggerlo dopo l'invio. Le transazioni Ethereum fallite consumano comunque gas, mentre gli swap riusciti con uno slippage eccessivo perdono valore a causa dell'esecuzione. Le tre pratiche seguenti aiutano a identificare la scarsa liquidità prima della firma.
1. Utilizza solver basati su intent anziché swap diretti
I sistemi di intent come CoW Swap, UniswapX e 1inch Fusion funzionano diversamente dalle transazioni AMM dirette. Firmi un ordine che descrive il risultato desiderato anziché specificare esattamente come il trade deve essere eseguito.
I solver competono quindi per ottenere l'esecuzione attingendo da pool pubblici, market maker privati o ordini di utenti opposti. Se nessuno è in grado di soddisfare il tuo limit order, non paghi nulla.
Secondo TheStreet, CoW gestisce circa il 22% del volume degli aggregatori su Ethereum. KyberSwap rappresenta circa il 31% e 1inch circa il 15%, mentre Jupiter gestisce quasi il 95% del volume degli aggregatori su Solana. Poiché i solver possono accedere a una profondità che l'interfaccia di un singolo pool non può vedere, eliminano la maggior parte degli errori di liquidità sui token affermati.

2. Controlla la profondità onchain prima di firmare
Un minuto speso a controllare i dati onchain può mostrare se un pool è in grado di assorbire il tuo ordine. Questo è fondamentale soprattutto per launch pool, memecoin e token che non hai mai scambiato prima su quella chain.
Verifica questi dati su DexScreener o DefiLlama prima di inviare un ordine di importo rilevante:
- TVL del pool: assicurati che il pool specifico contenga almeno dieci volte il valore del tuo ordine. Valori inferiori possono spingere l'impatto sul prezzo oltre la tolleranza utilizzata dalla maggior parte delle interfacce.
- Ripartizione delle riserve: analizza entrambi gli asset anziché affidarti al TVL totale. Un pool con 200.000 dollari potrebbe comunque contenere 190.000 dollari in USDC e quasi nulla del token che desideri.
- Rapporto di volume: confronta il volume delle 24 ore con il valore totale bloccato. I pool in cui il volume giornaliero supera di diverse volte le riserve possono subire oscillazioni marcate e sbilanciarsi tra i cicli di arbitraggio.
- Corrispondenza della chain: verifica che il pool con la liquidità maggiore si trovi sulla chain collegata al tuo wallet, e non su un'altra implementazione in cui lo stesso token è più attivo.
- Intervallo attivo: nei pool DLMM e CLMM, conferma che il prezzo corrente rientri nei bin popolati. Il capitale al di fuori dell'intervallo attivo non contribuisce in alcun modo all'esecuzione.
- Audit del token: apri il contratto in un block explorer. Controlla la presenza di tasse di trasferimento, restrizioni alla vendita o funzioni di proprietà che potrebbero rendere impossibile uscire da un pool apparentemente sicuro.
- Trade recenti: esamina le ultime dozzine di swap sia in termini di dimensioni che di direzione. Vendite consistenti e ripetute senza acquisti corrispondenti possono segnalare un pool che probabilmente respingerà o penalizzerà pesantemente il tuo ordine.
- Orari di trading: preferisci le ore di sovrapposizione tra Stati Uniti ed Europa, quando i bot di arbitraggio e i market maker sono più attivi e le tendenze al riequilibrio delle riserve sono più rapide.
DefiLlama traccia il TVL e il volume a livello di pool su oltre 500 chain. La sua dashboard DEX è il modo più rapido per identificare quale chain detiene il pool con la maggiore liquidità per un determinato token.
3. Suddividere gli ordini di grandi dimensioni con il TWAP
Un ordine time-weighted average price suddivide una posizione di grandi dimensioni in parti uguali inviate a intervalli fissi. Ciascuna parte raggiunge così un pool che ha avuto il tempo di riequilibrarsi. Gli ordini ricorrenti di Jupiter, il prodotto TWAP di CoW Swap e diverse interfacce di DEX perpetual offrono questa funzionalità senza richiedere script personalizzati.
Gli ordini ricorrenti di Jupiter variano anche l'intervallo tra i sub-ordine. In questo modo l'esecuzione successiva risulta più difficile da prevedere per i bot e si riduce la finestra di attacco per il sandwich bot creata da una pianificazione fissa. Per ordini che superano all'incirca il 5% della profondità del pool, il TWAP è l'unico modo affidabile per evitare sia l'errore di liquidità che un grave impatto sul prezzo.
Spiegazione dei messaggi di errore comuni durante lo swap
L'avviso di liquidità insufficiente è solo uno dei vari errori di swap legati alle condizioni di esecuzione. Identificare il messaggio esatto aiuta a circoscrivere la soluzione appropriata.
Associa il messaggio sullo schermo alla sua causa e al relativo rimedio indicati di seguito:
- INSUFFICIENT_OUTPUT_AMOUNT: il router di Uniswap V2 o PancakeSwap ha calcolato un output inferiore al tuo minimo. Aumenta leggermente la tolleranza o riduci le dimensioni dell'ordine e verifica se il token prevede una tassa di trasferimento.
- INSUFFICIENT_LIQUIDITY: un lato del pool contiene una quantità di asset troppo esigua per consegnare l'importo richiesto a qualsiasi prezzo. Instrada la transazione tramite un aggregatore o usa un intermediario basato su un asset principale.
- Impatto troppo elevato: l'interfaccia ha bloccato un trade che avrebbe spinto il prezzo oltre il limite di sicurezza integrato. Suddividi l'ordine anziché ignorare l'avviso.
- Scadenza superata: la transazione è rimasta in sospeso oltre il termine previsto, spesso a causa di un picco del gas. Richiedi una nuova quotazione e inviala nuovamente con una priority fee leggermente superiore.
- TRANSFER_FROM_FAILED: il contratto del token ha rifiutato il trasferimento dei fondi. Tra le possibili cause figurano un'approvazione mancante, una blacklist o un honeypot. Verifica il contratto prima di riprovare.
- Slippage superato: il codice di errore 0x1771 di Solana su Jupiter indica che l'esecuzione è avvenuta al di fuori del tuo limite. Riprova attivando lo slippage dinamico o usa un'impostazione fissa marginalmente più ampia.
- Esecuzione annullata: si tratta di un errore generico privo di una stringa con il motivo ed è comune sui pool V4 con hook o sugli AMM personalizzati. Prova a usare il percorso predefinito dell'interfaccia anziché selezionare un pool manualmente.
- Nessuna quotazione: l'aggregatore non ha trovato alcun percorso con sufficiente liquidità sulla chain corrente. Verifica l'indirizzo del contract e controlla se il token viene scambiato altrove.

Gestione dei rischi quando si utilizza un elevato slippage
Aumentare lo slippage è il modo più rapido per superare l'errore, ma può anche distruggere valore. Una tolleranza ampia offre ai sandwich bots maggiori margini di profitto dalla tua transazione.
Applica queste tutele ogni volta che imposti una tolleranza superiore all'1%:
- Invio privato: instrada la transazione tramite Flashbots Protect o MEV Blocker. In questo modo non finisce nel mempool pubblico, dove i bot cercano swap con tolleranza elevata da attaccare con una strategia sandwich.
- Limite di perdita: converti la percentuale di tolleranza in dollari prima di firmare. Un limite del 5% su uno swap da 20.000 $ permette una perdita fino a 1.000 $.
- Asta batch: invia lo stesso trade tramite CoW Swap o un'altra piattaforma basata su intent. Il regolamento batch a un prezzo uniforme elimina il vantaggio nell'ordinamento delle transazioni sfruttato negli attacchi sandwich.
- Limite per le stablecoin: mantieni lo slippage pari o inferiore allo 0,1% per le coppie di stablecoin. Cointelegraph Research ha rilevato che circa il 40% degli attacchi sandwich ha preso di mira pool a bassa volatilità in cui i trader non se lo aspettavano.
- Controllo del minimo: concentrati sulla cifra minima ricevuta anziché sull'output stimato. Una volta firmato, il minimo è l'unico importo fatto rispettare dallo smart contract.
- Tempistica del gas: evita gli swap con tolleranza elevata durante la congestione della rete. Un revert su Ethereum costa comunque gas e riprovare a un prezzo peggiore aggrava la perdita iniziale.
- Scadenza ravvicinata: limita la scadenza della transazione a pochi minuti. Un ordine bloccato dovrebbe scadere anziché essere eseguito più tardi a un prezzo non più valido.
- Swap di prova: inizia con un ordine piccolo per misurare l'impatto effettivo e confermare che il token possa essere rivenduto. Aumenta le dimensioni solo dopo il superamento di entrambi i controlli.
L'estrazione tramite attacchi sandwich su Ethereum è scesa da quasi 10 milioni di dollari al mese alla fine del 2024 a circa 2,5 milioni di dollari entro ottobre 2025, secondo lo stesso set di dati di Cointelegraph ed EigenPhi. Il numero di attacchi mensili è rimasto compreso tra 60.000 e 90.000. I bot sono ancora attivi, ma i trader protetti hanno smesso di fornire loro così tanto valore.

Considerazioni finali
L'errore di liquidità insufficiente per questo trade è una misura di sicurezza. Viene visualizzato quando un pool non è in grado di erogare il tuo output minimo, ed è più sicuro considerare quell'avviso come un'informazione sul pool piuttosto che ignorarlo.
I DEX aggregator e i solver basati su intent possono accedere a una liquidità che l'interfaccia di un singolo pool non può vedere. Per i token consolidati, risolvono la maggior parte degli errori di liquidità senza richiedere uno slippage maggiore.
Gli asset long-tail richiedono maggiore attenzione. Controlla la profondità disponibile, suddividi gli ordini di grandi dimensioni quando necessario e usa l'invio privato per coprire il rischio di esecuzione residuo.






