MEV e sandwich attack in DeFi: come proteggere uno swap da front-running, slippage e transazioni malevole

Quando si invia uno swap su un protocollo DeFi, la transazione non passa necessariamente dal wallet al blocco in modo diretto e immediato. In molte blockchain compatibili con Ethereum, viene prima diffusa nella mempool, cioè l’insieme delle transazioni in attesa di essere incluse in un blocco. Durante questo intervallo, alcuni operatori possono osservare i dettagli dell’operazione e tentare di trarne vantaggio.

Questo fenomeno rientra nel cosiddetto MEV, acronimo di Maximal Extractable Value: il valore che può essere estratto modificando l’ordine, la selezione o l’inclusione delle transazioni in un blocco. Il MEV non è sempre una frode e non riguarda soltanto gli utenti comuni, ma può creare costi aggiuntivi, esecuzioni peggiori e rischi concreti per chi usa DEX, aggregatori e altri protocolli DeFi.

Uno degli esempi più intuitivi è il sandwich attack, o attacco a panino. Capire come funziona aiuta a impostare correttamente slippage, importo e modalità di invio senza confondere la protezione dal MEV con una garanzia assoluta di sicurezza.

Che cos’è il MEV e perché riguarda chi usa un DEX

Un DEX esegue gli scambi attraverso smart contract e pool di liquidità oppure attraverso sistemi di ordini e algoritmi di routing. Il prezzo ottenuto dipende dall’attività presente nel mercato e dall’ordine con cui vengono eseguite le transazioni.

Una transazione in attesa contiene spesso informazioni rilevanti: token venduto, token acquistato, quantità, scadenza, limite di slippage, router utilizzato e altri parametri tecnici. Se questi dati sono visibili prima dell’inclusione nel blocco, un operatore può cercare di posizionare altre transazioni prima o dopo quella dell’utente.

Il MEV può assumere forme diverse:

• Arbitraggio: un operatore sfrutta differenze di prezzo tra pool o mercati. In alcuni casi contribuisce a riallineare le quotazioni, ma compete per lo spazio nei blocchi e può aumentare la congestione.
• Liquidazioni: un bot individua posizioni che possono essere liquidate secondo le regole di un protocollo di lending e invia una transazione per ottenere l’incentivo previsto.
• Riordinamento delle transazioni: l’ordine delle operazioni viene sfruttato per ottenere un vantaggio economico.
• Sandwich attack: una transazione dell’utente viene preceduta e seguita da operazioni progettate per influenzarne il prezzo.

Per l’utente finale, il punto importante è che il rischio non nasce necessariamente da una compromissione del wallet o da un bug del protocollo. Può derivare dal modo in cui la transazione viene resa pubblica e dall’impatto che essa ha sul prezzo di un pool.

Come funziona un sandwich attack

Immaginiamo un utente che voglia acquistare un token poco liquido con una transazione sufficientemente grande da modificare il rapporto tra le riserve del pool. Prima dell’esecuzione, un bot osserva la richiesta nella mempool.

Il bot può tentare tre passaggi:

• inviare un acquisto dello stesso token prima della transazione dell’utente;
• lasciare che l’operazione dell’utente spinga ulteriormente il prezzo nella direzione prevista;
• vendere il token acquistato dopo l’operazione dell’utente, incassando la differenza, al netto dei costi.

La transazione dell’utente si trova così “schiacciata” tra due operazioni del bot. L’utente può ricevere meno token del previsto, pur restando entro il limite di slippage impostato. Se il limite è troppo ampio, la perdita potenziale può diventare significativa.

Questo meccanismo non significa che ogni swap in attesa sarà attaccato. Il rischio tende a dipendere da fattori come dimensione dell’operazione, liquidità del pool, volatilità, visibilità della transazione, slippage massimo e incentivi economici disponibili.

Slippage: protezione necessaria, ma non sufficiente

Lo slippage è la differenza tra il prezzo atteso quando si prepara lo swap e il risultato effettivo ottenuto al momento dell’esecuzione. Nei DEX può dipendere da variazioni di mercato, liquidità insufficiente, dimensione dell’ordine e transazioni precedenti nello stesso blocco.

Quando l’utente imposta uno slippage massimo, sta indicando al contratto la perdita di prezzo che è disposto ad accettare. Se il risultato supera quel limite, la transazione dovrebbe fallire invece di essere eseguita.

Uno slippage più basso può ridurre il margine utilizzabile da un sandwich attack, ma non elimina tutti i rischi. Se è eccessivamente basso, la transazione può fallire spesso, soprattutto in mercati volatili o poco liquidi. Se è troppo alto, il contratto ha maggiore spazio per eseguire lo swap a un prezzo sfavorevole.

È importante distinguere tra:

• slippage visualizzato dall’interfaccia: il parametro scelto dall’utente o preimpostato dalla dApp;
• price impact: l’effetto che l’ordine stesso produce sul prezzo del pool;
• commissioni e costi di rete: importi separati che riducono il risultato economico ma non sono necessariamente inclusi nello slippage.

Un ordine grande in un pool poco liquido può avere un price impact elevato anche in assenza di un attacco. Ridurre lo slippage non corregge questo problema strutturale.

Controlli pratici prima di confermare uno swap

La prima difesa è leggere con attenzione ciò che la dApp propone, senza considerare il pulsante di conferma come una semplice formalità.

• Controllare il token ricevuto: verificare nome, simbolo e soprattutto indirizzo del contratto. Un token con un nome simile può essere un asset diverso o contraffatto.
• Verificare la rete: il wallet e la dApp devono operare sulla blockchain prevista. Una rete errata può causare errori, costi inattesi o ricezione di asset non compatibili con l’operatività desiderata.
• Esaminare il price impact: un impatto elevato indica che l’ordine muove sensibilmente il pool. In questi casi può essere preferibile ridurre la dimensione dell’operazione o valutare un mercato più liquido, senza interpretarlo come una raccomandazione di investimento.
• Impostare uno slippage coerente: evitare valori molto ampi scelti solo per far andare a buon fine la transazione. Un errore di esecuzione è spesso preferibile a uno scambio eseguito a condizioni inattese.
• Controllare la scadenza: una deadline troppo lunga lascia la transazione esposta più a lungo se resta in attesa. Una scadenza breve può però causare il fallimento durante congestioni o ritardi.
• Valutare l’importo: dividere un’operazione in più tranche può ridurre il price impact, ma comporta ulteriori commissioni e non elimina il rischio di esecuzione sfavorevole.
• Verificare la chiamata al contratto: il wallet dovrebbe mostrare il destinatario e, quando possibile, una descrizione leggibile dell’azione. Una richiesta non coerente con uno swap, come un’approvazione illimitata a un contratto inatteso, richiede una pausa.

Router, aggregatori e approvazioni: cosa controllare

Un aggregatore può cercare il percorso più conveniente tra più pool e dividere lo swap su diversi mercati. Questo può migliorare l’esecuzione in alcune situazioni, ma introduce anche una maggiore complessità: più contratti, più passaggi e più dati nella transazione.

Prima di firmare, è utile capire se l’operazione è un semplice swap, un’approvazione, un permesso firmato off-chain o una sequenza composta da più chiamate. Un’approvazione autorizza un contratto a utilizzare una quantità di token appartenenti all’utente. Non equivale a eseguire subito lo swap, ma un’approvazione troppo ampia può aumentare le conseguenze di un contratto compromesso o di un errore di indirizzo.

La revoca successiva di un’approvazione riduce un rischio futuro, ma non annulla operazioni già eseguite. Inoltre, la revoca richiede normalmente una nuova transazione e quindi una commissione di rete. Per questo è preferibile controllare l’approvazione prima della firma, non affidarsi soltanto alla correzione successiva.

Invio privato e protezione dal MEV

Alcuni servizi e infrastrutture permettono di inviare una transazione attraverso canali che cercano di evitare la diffusione pubblica immediata nella mempool. L’obiettivo è ridurre la possibilità che un bot osservi l’operazione e la utilizzi per un sandwich attack.

Questa soluzione può essere utile in determinati contesti, ma non deve essere considerata una garanzia assoluta. Occorre valutare:

• chi gestisce il servizio di invio;
• se la transazione viene realmente esclusa dai percorsi pubblici più esposti;
• cosa accade se il servizio è indisponibile;
• quali informazioni vengono trasmesse al provider;
• se il wallet e la dApp mostrano chiaramente il metodo di inoltro.

Un canale privato può ridurre la visibilità nella mempool, ma non corregge uno slippage impostato male, un contratto dannoso, un token falso o un price impact già elevato. La protezione deve quindi essere vista come uno strato aggiuntivo, non come sostituto dei controlli di base.

Errori frequenti da evitare

• Aumentare lo slippage senza comprenderne il motivo: può far eseguire l’ordine a condizioni molto peggiori.
• Confondere il fallimento con una perdita: una transazione revertita può comunque consumare una commissione di rete, ma di norma non completa lo swap. È diverso da uno scambio eseguito con un prezzo sfavorevole.
• Ritentare immediatamente con parametri più permissivi: dopo un errore è meglio capire causa, rete, nonce, gas e condizioni del mercato.
• Usare un RPC o un’estensione trovata casualmente: un’infrastruttura non verificata può alterare la visualizzazione, inoltrare dati a terzi o indirizzare verso contratti diversi.
• Firmare una richiesta incomprensibile: il fatto che il wallet mostri una firma non significa che l’operazione sia sicura.
• Considerare ogni perdita come MEV: variazioni di prezzo, liquidità insufficiente, commissioni e token con meccanismi particolari possono spiegare un risultato diverso senza che ci sia stato un sandwich attack.

Una procedura prudente per uno swap DeFi

Una procedura ripetibile riduce gli errori più di una singola impostazione miracolosa. Prima di tutto, usare un wallet operativo separato dal wallet destinato alla conservazione di lungo periodo e mantenere sul primo soltanto l’importo necessario all’operazione.

Aprire la dApp da un collegamento verificato, controllare la rete e confrontare gli indirizzi dei contratti con fonti affidabili. Se si tratta di un token nuovo o poco conosciuto, verificare contratto, liquidità, possibilità di vendita e autorizzazioni richieste, senza confondere queste verifiche con una certificazione di sicurezza.

Successivamente controllare importo, percorso dello swap, prezzo stimato, price impact, slippage e deadline. Prima della firma, leggere la richiesta del wallet e distinguere approvazione, permesso e chiamata di scambio. Per importi rilevanti, una transazione di prova può aiutare a verificare rete, contratto e ricezione, ma anche una prova comporta costi e rischi.

Dopo l’invio, non firmare automaticamente eventuali richieste aggiuntive. Verificare l’hash su un block explorer e confrontare token inviati, token ricevuti, commissioni e stato finale. Se il risultato è inatteso, conservare i dati della transazione e analizzarli prima di ripetere l’operazione.

MEV e sandwich attack non trasformano ogni swap in un evento pericoloso, ma mostrano perché la DeFi richiede più di un semplice clic. Comprendere mempool, slippage, price impact, approvazioni e modalità di invio permette di distinguere i rischi del mercato da quelli dell’infrastruttura e di usare i protocolli con aspettative più realistiche.