Solo a scopo educativo; non costituisce consulenza né raccomandazione d’investimento. Gli investimenti possono comportare perdite.
Risposta diretta
Il front-running on-chain avviene quando qualcuno viene a conoscenza di una transazione in attesa e fa eseguire un’altra transazione prima di essa per estrarre valore. Può copiare una chiamata redditizia, acquistare prima di un ordine noto o competere per un’opportunità scarsa on-chain. È una forma di valore massimo estraibile (MEV), non un sinonimo di ogni strategia MEV.
L’opportunità esiste perché una transazione Ethereum inviata viene normalmente diffusa e conservata nei pool di transazioni prima che un validatore la includa in un blocco. I searcher possono esaminare le transazioni in attesa, simulare i risultati e inviare le proprie transazioni o bundle. L’ordine finale dipende dalla costruzione del blocco: una commissione di priorità più alta può favorire l’inclusione, ma non garantisce una posizione precisa.
Per l’utente conta capire se la transazione rivela un’intenzione di valore prima dell’esecuzione, se i suoi limiti lasciano margine di estrazione e chi può influire sull’ordine. Swap DEX con slippage ampio, richieste pubbliche con segreti riutilizzabili, liquidazioni, aste e mint limitati possono attirare concorrenza.
Come funziona
In un’operazione sandwich, un searcher vede un acquisto DEX in attesa, compra lo stesso asset subito prima e lo vende subito dopo. L’acquisto dell’utente fa salire il prezzo nel pool tra le due operazioni del searcher. La strategia riesce solo se l’importo minimo ricevuto dall’utente consente ancora l’esecuzione dopo il movimento aggiuntivo e il ricavo copre tutte le commissioni.
I front-runner generalizzati puntano alle chiamate il cui valore può essere copiato. Se una transazione rivela una risposta o un’autorizzazione non vincolata al destinatario previsto, un altro account può riprodurre la chiamata e cercare di eseguirla prima. Il contratto può usare schemi commit-reveal e vincolare la richiesta a un destinatario specifico; aumentare le commissioni non protegge informazioni già esposte.
I campi delle commissioni Ethereum come maxPriorityFeePerGas e maxFeePerGas incidono su quanto il mittente è disposto a pagare. Non rendono privato il contenuto, e i builder possono valutare bundle anziché ordinare ogni transazione per un solo campo. Il front-running è quindi un problema di informazione e ordinamento, non soltanto una gara sul prezzo del Gas.
Esempio
Supponiamo che un pool AMM contenga 100 ETH e 200,000 USDC. Un utente invia pubblicamente una transazione per comprare ETH con 10,000 USDC e una tolleranza allo slippage del 5%. La transazione in attesa rivela direzione, dimensione e output minimo accettabile.
Un searcher simula lo swap e invia un acquisto da eseguire prima, seguito da una vendita da eseguire dopo. Se le due operazioni vengono ordinate intorno a quella dell’utente, quest’ultimo riceve meno ETH rispetto all’assenza del sandwich, pur restando entro il limite del 5%; il searcher trattiene la differenza al netto delle commissioni.
Il risultato non è garantito. Searcher concorrenti, commissioni del pool, variazioni di prezzo, mancata inclusione o controllo dell’output minimo possono rendere la strategia antieconomica o far fallire la sequenza. Anche una normale operazione di grandi dimensioni genera impatto sul prezzo: prima di attribuire tutto lo slippage a un attacco servono tracce e stato del pool.
Rischi e mitigazioni
Nessuna impostazione elimina ogni rischio di ordinamento. L’obiettivo pratico è ridurre le fughe di informazioni non necessarie e limitare la perdita accettata dalla transazione.
- Impostare un output minimo o un limite di prezzo giustificabile in base alla profondità del pool e alle condizioni correnti; non ampliare lo slippage solo per forzare l’esecuzione.
- Prima della firma, controllare impatto sul prezzo, liquidità, regole di trasferimento del token e percorso, soprattutto per operazioni grandi in pool poco profondi.
- Quando opportuno, usare servizi affidabili di invio privato o protezione MEV, verificando copertura dei builder, comportamento in caso di errore, politica sulla privacy e presupposti di fiducia.
- Nel progettare un protocollo, non inserire nei dati segreti assegnati al primo arrivato; usare vincolo al destinatario, commit-reveal, aste in lotti o altri meccanismi adatti.
L’invio privato può nascondere una transazione al pool pubblico, ma non è una garanzia universale. L’utente deve fidarsi che il servizio e i builder non la divulghino né la sfruttino; cambiare percorso RPC prima della conferma può renderla pubblica. La transazione può anche essere ritardata o esclusa.
Errori comuni
Mito 1: Pagare più Gas impedisce il front-running
Una commissione di priorità maggiore può migliorare le probabilità di inclusione, ma non nasconde l’operazione. Searcher e builder possono proporre un ordine o un bundle di maggior valore: l’offerta sulle commissioni non basta come protezione.
Mito 2: Ogni esecuzione sfavorevole è un attacco sandwich
Gli ordini grandi muovono da soli i prezzi AMM e il mercato può cambiare mentre la transazione è in attesa. Commissioni di routing, tasse di trasferimento e normale concorrenza possono anch’essi peggiorare l’esecuzione.
Mito 3: Lo slippage zero è sempre la scelta più sicura
Un limite troppo stretto può rifiutare normali movimenti di prezzo e consumare comunque Gas se la transazione pubblica viene annullata. Il limite corretto dipende da liquidità, dimensione, urgenza e perdita massima accettabile.
Argomenti correlati
Fonti
- Transactions - ethereum.org (consultato: 2026-08-20)
- Maximal extractable value (MEV) - ethereum.org (consultato: 2026-08-20)
- Flashbots Protect Quick Start - Flashbots (consultato: 2026-08-20)