MEV negli swap: sandwich, slippage e protezioni sui DEX

Revisione tecnica del 6 settembre 2026. Contenuto educativo: gli esempi sono ipotetici, non quotazioni o raccomandazioni di investimento.

Il MEV negli swap aiuta a capire perché uno swap su un DEX può essere eseguito a condizioni peggiori del previsto anche quando il wallet mostra una transazione riuscita. Non significa che ogni differenza di prezzo sia un attacco: liquidità, commissioni, variazioni del mercato e ordine delle transazioni producono effetti diversi. La prima difesa consiste nel distinguerli prima di firmare.

Questa guida riguarda soprattutto gli swap e l’esecuzione su Ethereum. Per il funzionamento generale degli scambi decentralizzati, il riferimento è la guida ai DEX crypto. Altre reti possono avere regole differenti per l’invio e l’ordinamento delle transazioni. Non bisogna quindi trasferire automaticamente un’impostazione RPC, una garanzia commerciale o un comportamento osservato su Ethereum a qualsiasi blockchain.

MEV negli swap: che cosa significa

MEV significa Maximal Extractable Value: valore ottenibile intervenendo sull’inclusione, sull’esclusione o sull’ordine delle transazioni, oltre alle normali ricompense e commissioni previste per la produzione dei blocchi. La documentazione Ethereum sul MEV distingue diverse opportunità di estrazione, tra cui arbitraggio, liquidazioni e sandwich.

Il punto economico è che due sequenze contenenti operazioni simili possono distribuire il valore in modo diverso. Chi compra prima di un ordine che muove il prezzo può trovarsi in una posizione differente da chi compra dopo. Per il lettore che vuole soltanto scambiare token, conta soprattutto quanto riceve e quali condizioni ha autorizzato.

Un risultato sfavorevole non identifica però automaticamente il responsabile. Vedere uno swap vicino al proprio nel blocco non dimostra da solo un sandwich. Una ricostruzione deve considerare direzione degli scambi, pool coinvolti, ordine effettivo, variazioni delle riserve e collegamento tra le operazioni sospette.

Chi interviene tra firma e conferma

Il wallet prepara e firma un’operazione, mentre il canale di invio la trasmette verso l’infrastruttura della rete. Nel contesto Ethereum, i searcher cercano opportunità; i builder possono assemblare blocchi; i proposer partecipano alla loro proposta secondo il sistema di consenso. Non sono sinonimi del DEX utilizzato e non coincidono necessariamente con un unico soggetto.

Dal punto di vista pratico, il lettore dovrebbe chiedersi chi vede la richiesta prima della conferma, chi decide come inoltrarla e quale percorso viene usato se il primo tentativo non riesce. Una schermata con il nome di un aggregatore non risponde necessariamente a tutte queste domande.

La distinzione evita anche un errore di diagnosi: se la transazione non viene inclusa, il problema può essere nella disponibilità del percorso, nelle commissioni, nel nonce o nei vincoli dell’ordine. Aumentare la tolleranza di prezzo senza aver identificato il motivo rischia di modificare una condizione che non era la causa del problema.

Slippage, price impact e commissioni non sono la stessa cosa

Il price impact descrive l’effetto del proprio scambio sul prezzo disponibile nella liquidità utilizzata. Un ordine grande rispetto a un pool può ottenere un prezzo medio peggiore anche se nessun altro interviene. La spiegazione di Uniswap sul price impact mette al centro proprio il rapporto tra dimensione dello scambio e profondità della liquidità.

Lo slippage riguarda invece lo scostamento tra il risultato atteso e quello eseguito secondo il riferimento adottato dall’interfaccia. La tolleranza è un limite autorizzato, non una commissione automaticamente incassata dal protocollo. Un limite ampio non obbliga a una cattiva esecuzione, ma può consentire un risultato molto meno favorevole della stima.

Le commissioni sono un’altra voce. Occorre distinguere gas fee Ethereum, commissioni del pool ed eventuali costi del servizio. Un preventivo con più token in uscita può essere meno conveniente dopo i costi aggiuntivi; viceversa, il percorso apparentemente più economico in gas può offrire un cambio peggiore.

Un esempio numerico: leggere il minimo ricevuto

Immaginiamo un’interfaccia che stimi 1.000 unità del token di destinazione. Per questo esempio scegliamo esplicitamente una regola didattica: il minimo ricevuto è la stima moltiplicata per uno meno la tolleranza. Con l’1% risulta 990; con il 5% risulta 950. Non è una formula universale per ogni SDK o tipo di ordine: nel caso reale va letto il valore effettivamente mostrato e firmato.

Se l’esecuzione restituisce 992 unità, la perdita rispetto alla stima è di 8 unità, cioè lo 0,8%. In questo modello rientra sia nel limite dell’1% sia in quello del 5%. Il fatto di avere impostato il 5% non significa quindi aver pagato automaticamente 50 unità.

Se il risultato disponibile scende a 975, non rispetta il minimo di 990, mentre supera quello di 950. Supponendo un contratto che faccia rispettare il limite e uno swap atomico, il primo ordine non dovrebbe essere eseguito a quel risultato. Questo non rende gratuiti tutti i fallimenti: una transazione inclusa e poi revertita può consumare gas.

L’esempio non dimostra né la presenza né il profitto di un sandwich. Mostra soltanto la differenza tra stima, risultato minimo e risultato effettivo. Per misurare un attacco servirebbe ricostruire anche il prezzo senza l’intervento sospetto, le commissioni e le altre operazioni: la sola percentuale nel wallet non basta.

Un secondo esempio: il prezzo cambia anche senza attaccanti

Consideriamo un liquidity pool didattico con 100 unità del token A e 200.000 unità del token B. Assumiamo una curva a prodotto costante, nessuna commissione, nessun altro scambio e token ordinari senza meccanismi speciali. Il rapporto iniziale è di 2.000 B per A, ma non è il prezzo medio garantito per qualunque quantità.

Se aggiungiamo un’unità di A, la riserva di A diventa 101. Per conservare il prodotto iniziale di 20.000.000, la riserva di B diventa circa 198.019,802. Lo swap restituisce quindi circa 1.980,198 B, non 2.000. La differenza rispetto al rapporto iniziale è circa lo 0,99%: in questo modello deriva dalla curva, senza alcun sandwich.

È una semplificazione matematica, non una quotazione Uniswap. I pool reali possono applicare commissioni, usare liquidità concentrata o altre funzioni, e ricevere operazioni tra il preventivo e l’esecuzione. La documentazione sul pricing di Uniswap v2 distingue il calcolo del risultato dai controlli necessari per non assumere che il prezzo corrente del pool sia automaticamente equo.

L’utilità dell’esempio è diagnostica: se il preventivo contiene già un impatto elevato, abbassare la tolleranza non rimuove quell’impatto iniziale. Sono due confronti diversi. Prima si valuta la qualità della quotazione; poi si decide quanto scostamento successivo accettare. Confondere questi passaggi può far apparire prudente un ordine che parte già da condizioni sfavorevoli.

Come funziona un sandwich, senza confonderlo con ogni ribasso

Nel caso tipico, un soggetto inserisce un’operazione prima dello swap della vittima e una dopo, cercando di beneficiare del movimento indotto nella liquidità. La vittima può ricevere meno del preventivo iniziale pur rispettando il proprio minimo autorizzato. Il margine disponibile dipende dalle condizioni concrete, non soltanto dal valore nominale dell’ordine.

Un pool poco profondo e un limite molto permissivo possono rendere l’esecuzione più vulnerabile. Ma un pool grande non è un’assicurazione e un limite stretto non risolve ogni problema: può anche aumentare i tentativi non eseguiti quando cambiano le condizioni. La scelta va valutata insieme al percorso e al costo dei nuovi tentativi.

Per un controllo a posteriori, conserva il preventivo con l’orario, il minimo firmato e l’hash della transazione. Confronta il risultato con quel preventivo, non con un prezzo letto molto dopo. Se manca lo stato precedente del pool, una stima del danno dovrebbe dichiarare tale limite invece di presentare una cifra precisa come certa.

Perché arbitraggio e liquidazioni non equivalgono sempre a un attacco

Un arbitraggio sfrutta una differenza di prezzo tra mercati; una liquidazione può eseguire le regole di un prestito quando le garanzie non sono sufficienti. Questi meccanismi hanno effetti differenti dal peggioramento intenzionale di uno swap inserito fra due operazioni. Raggrupparli sotto MEV non significa attribuire loro lo stesso giudizio o lo stesso rischio per l’utente.

La domanda utile non è soltanto se qualcuno abbia guadagnato, ma come quel guadagno è stato ottenuto e chi ne ha sopportato il costo. Un profitto osservato non dimostra automaticamente una perdita equivalente per uno specifico wallet. Anche le metriche aggregate richiedono una metodologia chiara prima di essere trasformate in una stima del danno personale.

Routing privato: che cosa cambia e di chi ci si fida

Un canale privato può evitare la normale diffusione della transazione nel mempool pubblico. Questo modifica chi può osservarla prima dell’inclusione, ma non significa che nessuno possa vederla. Il servizio e i destinatari autorizzati entrano nel modello di fiducia.

La guida iniziale di Flashbots Protect avverte esplicitamente che ci si affida ai builder affinché non anticipino la transazione e non la divulghino a terzi. Segnala inoltre che cambiare RPC in MetaMask prima della conferma può provocare un nuovo invio al mempool pubblico. È un limite operativo importante, non un dettaglio estetico dell’interfaccia.

Prima di usare una protezione, verifica rete supportata, modalità di inoltro, destinatari e comportamento delle richieste pendenti. Non inserire endpoint trovati in messaggi privati o annunci sponsorizzati senza confrontarli con la documentazione ufficiale. Un servizio che promette protezione dal MEV non ha bisogno della seed phrase per configurare un percorso di invio.

Impostazioni, rimborsi e fallback: leggere le condizioni

La documentazione delle impostazioni Protect, consultata per questa revisione, distingue configurazione predefinita, modalità fast e opzioni di condivisione. Aggiungere destinatari può favorire l’inclusione, ma estende la fiducia richiesta; le opzioni relative ai dati condivisi non sono tutte equivalenti.

La stessa documentazione permette impostazioni diverse per i revert e per l’intervallo dei blocchi in cui tentare l’inclusione. Non è quindi corretto trasformare il comportamento predefinito in una garanzia valida per qualsiasi configurazione. Anche un eventuale rimborso non deve essere presentato come un rendimento certo o come prova che l’operazione fosse conveniente.

Per confrontare due percorsi, annota le condizioni prima dell’invio. Se uno strumento cambia modalità automaticamente, verifica se cambia anche il livello di esposizione della transazione. Il nome commerciale della funzione può restare identico mentre il percorso effettivo o i destinatari differiscono.

Intent e aste: autorizzare un risultato non significa non firmare rischi

Con un intent, l’utente esprime condizioni di scambio invece di costruire direttamente ogni passaggio esecutivo. La documentazione di CoW Protocol sugli intent descrive l’ordine firmato come un insieme di vincoli, distinto da una transazione utente direttamente eseguibile.

Questa separazione consente a operatori specializzati di cercare un’esecuzione compatibile con quei vincoli. Non rende irrilevante la firma: token, quantità, beneficiario, scadenza e autorizzazioni devono essere corretti. Il fatto che una finestra chieda una firma di messaggio anziché il pagamento immediato del gas non dimostra che l’azione sia priva di conseguenze.

Non tutti i prodotti chiamati intent o auction funzionano nello stesso modo. Occorre leggere le regole del servizio specifico, verificare come si annulla un ordine e distinguere un ordine scaduto da uno eseguito parzialmente quando il protocollo ammette tale modalità. Una categoria tecnologica non è una garanzia uniforme di prezzo migliore.

Dividere uno swap grande: un compromesso, non una regola automatica

La versione precedente suggeriva di frammentare gli ordini grandi come difesa generale. È una semplificazione da correggere: dividere l’importo non garantisce meno MEV né un prezzo complessivo migliore. Se la liquidità non cambia e gli ordini percorrono la stessa curva, il numero dei clic non crea nuova profondità.

In un esempio puramente contabile, quattro operazioni con costo di rete ipotetico di 3 euro ciascuna costano 12 euro, contro i 3 euro di un solo invio allo stesso costo unitario. La differenza di 9 euro andrebbe compensata da un vantaggio esecutivo reale. Sono numeri didattici, non una stima del gas Ethereum.

Distribuire gli ordini nel tempo espone inoltre a variazioni del mercato tra una tranche e l’altra. Il confronto sensato considera il risultato finale dell’intero importo, i costi cumulativi e il tempo impiegato. Valutare soltanto il prezzo della tranche migliore seleziona un risultato favorevole e nasconde le altre esecuzioni.

Checklist prima della firma

1. Controlla rete e indirizzo dei token: simboli simili non identificano necessariamente lo stesso asset.
2. Verifica il destinatario delle autorizzazioni e l’importo approvato, senza concedere accessi che non comprendi.
3. Leggi quantità in entrata, stima in uscita e minimo effettivo, non soltanto la percentuale di tolleranza.
4. Separa gas, commissioni del percorso ed eventuali costi del servizio.
5. Controlla il canale di invio e le condizioni della protezione, incluso ciò che accade se l’ordine rimane pendente.
6. Verifica eventuali scadenze, riempimenti parziali e modalità di annullamento previste dal prodotto.
7. Rileggi il riepilogo finale: una nuova quotazione può aver modificato il percorso o il risultato atteso.

La checklist non certifica la sicurezza del token o dello smart contract. Serve a rendere esplicite le condizioni della singola operazione. Un router affidabile non trasforma automaticamente un token rischioso in un investimento sicuro e un limite di prezzo non protegge da qualsiasi autorizzazione malevola.

Per confrontare due preventivi, registra lo stesso importo iniziale, il token di destinazione, l’orario e le ipotesi sulle commissioni. Una quotazione raccolta diversi minuti prima non è un riferimento affidabile se nel frattempo il mercato è cambiato. Separa il costo di rete stimato da quello pagato e precisa se le quantità sono al netto dei costi del servizio. Questo registro non prevede il percorso vincente al prossimo tentativo: rende riproducibile il confronto e aiuta a distinguere una differenza di routing da un movimento del mercato.

Che cosa verificare dopo lo swap

Controlla lo stato della transazione e le quantità effettivamente ricevute. Il successo tecnico indica che l’esecuzione ha rispettato le regole applicabili, non che il cambio fosse il migliore disponibile in assoluto. Conservare i dati della firma permette di verificare se il risultato rientrava nei vincoli accettati.

Se l’operazione è in attesa, non ripeterla alla cieca. Prima distingui un invio non incluso da un ordine scaduto, una transazione revertita o un aggiornamento lento dell’interfaccia. Segui le istruzioni del wallet e del percorso utilizzato: un nuovo tentativo o una sostituzione può cambiare costi e visibilità.

Se sospetti un sandwich, raccogli hash, orari e preventivo originale prima di formulare una conclusione. Non pubblicare seed phrase, chiavi o esportazioni sensibili per chiedere assistenza. Per un’analisi tecnica sono normalmente utili i dati pubblici della transazione e le condizioni dello swap, non l’accesso al wallet.

Domande frequenti sul MEV

Una tolleranza pari a zero elimina il problema?

Non è una protezione universale. Può impedire alcune esecuzioni peggiori della stima, ma può anche ostacolare l’inclusione quando il risultato cambia. Inoltre non corregge un preventivo iniziale sfavorevole né elimina le commissioni o il rischio del contratto.

Uno swap fallito dimostra che sono stato attaccato?

No. Può dipendere da diversi vincoli o condizioni tecniche. Per attribuirlo a un attacco serve una ricostruzione verificabile; un messaggio generico del wallet o un movimento di prezzo non bastano.

La protezione privata rende anonima l’operazione?

Non va confusa con anonimato. Limitare la diffusione prima dell’inclusione non elimina i dati pubblicati on-chain e non significa che il fornitore non riceva informazioni. Le condizioni di visibilità vanno lette per il servizio concreto.

Qual è la scelta migliore per ogni swap?

Non esiste un percorso universalmente migliore. Importo, liquidità, costi, urgenza e vincoli del prodotto cambiano il confronto. Una decisione verificabile esplicita tali condizioni e non usa la sola etichetta «MEV protected» come sostituto dell’analisi.

Conclusione: controllare l’esecuzione, non inseguire una garanzia assoluta

Capire il MEV negli swap significa leggere uno swap come un insieme di condizioni: prezzo stimato, risultato minimo, percorso, autorizzazioni e costi. Il controllo più utile è quello che distingue questi elementi e permette di confrontare ciò che era stato firmato con ciò che è accaduto.

Le protezioni possono ridurre determinate esposizioni, ma hanno limiti e dipendenze. Il passo concreto è verificare il minimo ricevuto e il canale di invio prima della firma, poi conservare il risultato per confronti coerenti. Non serve una promessa di rischio zero: serve sapere quale rischio rimane.