Solo a scopo educativo; non costituisce consulenza sulla sicurezza o sugli investimenti. I limiti di slippage e l’instradamento privato possono ridurre l’esposizione agli attacchi sandwich, ma non garantiscono qualità dell’esecuzione, inclusione, finalità o recupero delle perdite.
Risposta diretta
Un attacco sandwich è una forma dannosa di valore massimo estraibile in cui un aggressore inserisce una transazione immediatamente prima dello swap di un utente e un’altra subito dopo. La prima operazione sposta il prezzo del pool contro l’utente, lo swap viene eseguito a un tasso peggiore e l’ultima operazione chiude la posizione dell’aggressore al prezzo creato in parte dall’ordine dell’utente.
L’attacco richiede visibilità anticipata o controllo privilegiato sull’ordine dell’intento dell’utente, un impatto sul prezzo sufficiente e limiti di esecuzione che consentano ancora allo swap di riuscire. È discusso soprattutto per gli swap degli automated market maker, ma il rischio generale riguarda qualsiasi variazione di stato prevedibile il cui ordinamento consenta a un’altra parte di estrarre valore.
Come funziona
Un utente firma e trasmette uno swap. Se i dettagli raggiungono un pool pubblico di transazioni o un altro canale osservabile di flusso degli ordini prima dell’inclusione, un searcher può decodificare asset, dimensione, percorso, output minimo e scadenza, quindi simulare possibili sequenze.
Per un acquisto in un pool AMM, il searcher compra per primo. Questo front-run modifica le riserve e aumenta il prezzo di esecuzione dell’utente. L’utente riceve quindi meno token in uscita rispetto al preventivo, purché il risultato rispetti ancora la condizione di output minimo. Il searcher vende dopo l’utente con un back-run, catturando parte del movimento di prezzo.
I ricavi lordi non coincidono con il profitto. L’aggressore deve coprire le commissioni di entrambi gli swap, il Gas o i pagamenti al builder, i tentativi falliti e il rischio di inventario. Concorrenza, altre operazioni, la reversione dello swap dell’utente o un diverso ordine del blocco possono rendere la sequenza non redditizia; un sandwich non è automaticamente atomico né garantito.
La protezione dallo slippage limita il peggior output accettato, ma non impedisce l’ordinamento. Una tolleranza molto ampia lascia più spazio a esecuzioni sfavorevoli, mentre una troppo stretta può far fallire uno swap legittimo durante la volatilità. Applicazioni e contratti integratori dovrebbero imporre un output minimo corrente approvato dall’utente e una scadenza adeguata, invece di usare zero o un valore fisso obsoleto.
Invio privato, flusso di ordini protetto, aste batch, esecuzione basata su intenti e suddivisione degli ordini possono ridurre l’esposizione in alcuni sistemi. La protezione dipende dagli intermediari che vedono l’ordine, dalla copertura dei builder, dal comportamento di fallback, da liquidità, costi e implementazione; etichette come “privato” o “protetto da MEV” non sono garanzie universali.
Esempio
Un utente invia uno swap visibile per comprare il Token B con il Token A da un pool AMM. Un searcher simula che l’ordine sia abbastanza grande da spostare il prezzo del pool e che l’output minimo dell’utente lasci spazio all’esecuzione dopo un movimento sfavorevole.
Il searcher compra prima il Token B, poi lo swap dell’utente compra il Token B al tasso peggiorato e subito dopo il searcher lo vende. L’utente riceve almeno il minimo firmato ma meno del preventivo precedente; al searcher resta solo quanto avanza dopo commissioni di swap, pagamenti per l’ordinamento e costi di esecuzione.
Rischi
Il danno diretto per l’utente è un’esecuzione peggiore e uno slippage effettivo maggiore. Lo swap può anche fallire dopo aver consumato Gas quando la blockchain e la struttura della transazione addebitano l’esecuzione non riuscita. Liquidità ridotta, grandi ordini visibili, limiti permissivi, mercati volatili e percorsi prevedibili possono aumentare l’esposizione, ma nessuna singola soglia prova che avverrà un attacco.
Le mitigazioni comportano compromessi. Ordini più piccoli possono pagare più commissioni totali o rivelare una strategia ripetuta; limiti stretti possono aumentare le reversioni; percorsi privati aggiungono questioni di fiducia, censura, registrazione e fallback; le interfacce protette possono coprire solo alcune blockchain o rotte. Verificare output minimo firmato, scadenza, percorso, politica dell’endpoint, ricevuta e finalità richiesta invece di affidarsi a un simbolo di protezione.
Idee sbagliate comuni
- Ogni movimento di prezzo sfavorevole è un attacco sandwich. Anche il normale impatto sul prezzo, il mercato, le variazioni di percorso e l’arbitraggio possono allontanare l’esecuzione dal preventivo; l’attribuzione richiede prove sull’ordine delle transazioni.
- L’aggressore ruba semplicemente i token dal wallet. Un sandwich tipico modifica lo stato del pool attorno a uno swap autorizzato; la transazione dell’aggressore non deve trasferire direttamente asset dal wallet dell’utente.
- Qualsiasi tolleranza allo slippage impedisce l’attacco. L’output minimo limita il peggioramento accettato, ma un searcher può ottimizzare il sandwich affinché lo swap riesca vicino a tale limite.
- L’invio privato elimina il MEV. Può nascondere l’ordine dal pool pubblico, ma operatori RPC, relay, builder, solver o un fallback pubblico possono ancora osservarlo o influenzarlo.
- Una ricevuta riuscita prova un’esecuzione equa. Il successo prova solo che le condizioni del contratto sono state soddisfatte, non che l’utente abbia ottenuto il miglior prezzo o evitato un ordinamento dannoso.
Argomenti correlati
- Automated market maker
- Front-running
- Valore massimo estraibile
- RPC per transazioni private
- Exchange decentralizzati
Fonti
- Maximal extractable value (MEV) - Ethereum.org (accessed: 2026-08-21)
- What is a sandwich attack? - Uniswap Labs (accessed: 2026-08-21)
- SCWE-090: Missing Slippage Protection in Automated Token Swaps - OWASP Smart Contract Security (accessed: 2026-08-21)