O que é um ataque sandwich? Como os bots MEV roubam das suas transações em DEX

Um ataque sandwich é um tipo de exploração MEV (Maximal Extractable Value) onde um bot deteta uma transação de swap pendente, coloca a sua própria transação antes e depois da da vítima, e extrai lucro do movimento de preço resultante.

Este ataque ocorre em todas as blockchains com exchanges descentralizados baseados em AMM — Solana, Ethereum, BSC, Base e outros. É uma das causas mais frequentes de perdas inesperadas para traders de DEX, e a maioria das vítimas não sabe que aconteceu.

Este guia cobre a mecânica por trás dos ataques sandwich, as condições que os tornam lucrativos e os métodos disponíveis para proteção.

Como as transações blockchain são processadas

Para entender como os ataques sandwich funcionam, ajuda primeiro entender como as transações são processadas em blockchains como Solana, Ethereum e BSC.

As blockchains não processam transações uma a uma no momento em que clica em "Swap". Em vez disso, trabalham em lotes. A blockchain recolhe todas as transações recebidas, agrupa-as e processa o lote inteiro de uma vez. Cada lote chama-se bloco, e o tempo necessário para produzir um bloco chama-se tempo de bloco.

Blockchain	Tempo de Bloco
Solana	~0.4 seg
Monad	~0.4 seg
Arbitrum	~0.25 seg
Base	~2 seg
Polygon	~2 seg
Optimism	~2 seg
Avalanche	~2 seg
BNB Chain	~3 seg
Ethereum	~12 seg

Na Ethereum, um novo bloco é produzido aproximadamente a cada 12 segundos. O exemplo seguinte mostra como cinco transações submetidas em momentos diferentes dentro da mesma janela de 12 segundos são todas confirmadas juntas — mas executadas numa ordem que nada tem a ver com quando foram submetidas:

Transação	Submetida	Confirmada	Ordem de Execução
Transação A	15:00:01	15:00:12	3ª
Transação B	15:00:03	15:00:12	1ª
Transação C	15:00:05	15:00:12	5ª
Transação D	15:00:08	15:00:12	2ª
Transação E	15:00:11	15:00:12	4ª

Todas as cinco transações são confirmadas às 15:00:12 quando o bloco é criado. Mas a ordem de execução — a ordem que realmente determina quem transaciona primeiro — é decidida pelo validador que produz o bloco, não por quem submeteu primeiro.

Fatores como taxas de prioridade, gorjetas MEV ou relações diretas com o validador influenciam qual transação é colocada onde na sequência. A Transação B foi submetida em segundo mas executada em primeiro. A Transação A foi submetida em primeiro mas executada em terceiro.

Esta é a razão fundamental pela qual os ataques sandwich são possíveis. Os bots MEV monitorizam transações pendentes no pipeline, e pagando taxas mais altas, podem manipular a ordem de execução dentro de um bloco para colocar as suas próprias transações antes e depois da sua.

Como funciona um ataque sandwich

Um ataque sandwich explora o facto de que um swap move o preço do token no pool de liquidez. Eis como se desenrola passo a passo.

1. Submete um Swap: Submete uma transação para comprar Token X num DEX. Antes desta transação ser incluída num bloco, entra no pipeline de transações da rede — na Ethereum é o mempool público, na Solana é a camada de encaminhamento de transações — onde é brevemente visível.
2. O Bot deteta a sua transação: Um bot MEV a escanear constantemente o pipeline deteta o seu swap pendente. Vê quanto está a comprar e calcula quanto o seu trade vai mover o preço. Quanto maior o seu trade relativamente à liquidez do pool, mais o preço se move — e mais lucrativo se torna o ataque.
3. O Bot faz front-run: O bot submete a sua própria transação de compra com uma taxa de prioridade mais alta, garantindo que é executada antes da sua no mesmo bloco. A compra do bot empurra o preço do token para cima.
4. A sua transação é executada: O seu swap é executado ao preço agora mais alto. Recebe menos tokens do que teria recebido sem a interferência do bot.
5. O Bot faz back-run: Imediatamente após a sua transação, o bot vende os tokens que comprou no Passo 3. A sua compra criou pressão de preço ascendente adicional, e o bot vende a esse preço mais alto.

Após a venda do bot, o preço desce. Fica com tokens que agora valem menos do que pagou. O bot capturou o spread entre o seu preço de compra e venda — valor extraído diretamente do seu trade.

Toda esta sequência acontece dentro de um único bloco.

A imagem acima mostra um ataque sandwich real capturado num Pool Uniswap V2 da Ethereum. Três transações executadas exatamente ao mesmo tempo (06:28:23 AM) dentro do mesmo bloco:

1. 1FaE13 (Bot MEV) compra $616.13 em token DAT — o front-run.
2. 8a23ff (Vítima) compra $1.9 em token DAT — executando ao preço agora mais alto.
3. 1FaE13 (Bot MEV) vende $617.84 em token DAT — o back-run, capturando aproximadamente $1.71 de lucro.

O trade de $1.9 da vítima era pequeno, mas foi suficiente para o bot extrair lucro. Todo o ataque — compra, vítima, venda — aconteceu num único bloco.

Quando o seu trade se torna alvo de ataque sandwich

Nem todos os swaps são sandwichados. Os bots MEV só atacam quando o lucro esperado supera o custo. As seguintes condições tornam o seu trade um alvo:

• Trade grande relativamente ao tamanho do pool. Um swap de $50 num pool com $500 de liquidez move o preço aproximadamente 10% ou mais — um alvo lucrativo para bots sandwich. Os mesmos $50 num pool com $5,000,000 de liquidez mal movem o preço, não vale a pena atacar.
• Alta tolerância de slippage. Configurar slippage para 10% ou mais sinaliza que aceitará um preço significativamente pior. Isto dá aos bots mais espaço para empurrar o preço antes da sua transação reverter.
• Tokens de baixa liquidez. Tokens recém-lançados e memecoins tendem a ter pools pequenos. Mesmo um swap modesto cria movimento de preço suficiente para os bots explorarem.

Como proteger-se de ataques sandwich

1. Usar encaminhamento de transações com proteção MEV

A proteção mais eficaz é impedir que os bots vejam a sua transação em primeiro lugar.

• Na Solana: Os Jito Bundles contornam o pipeline público de transações e enviam o seu swap diretamente para o Jito Block Engine, onde os bots MEV não o podem observar. A maioria das ferramentas de trading Solana já suporta isto — se vir um campo "Jito Tip", as suas transações estão a ser encaminhadas através do Jito. O Jito também oferece o mecanismo jitodontfront, que garante que a sua transação deve aparecer primeiro em qualquer bundle em que esteja incluída.
• Na Ethereum e cadeias EVM: Serviços como Flashbots Protect, MEV Blocker e RPCs privados encaminham a sua transação através de um mempool privado em vez do público. Algumas wallets e frontends de DEX oferecem isto como opção integrada.

2. Configurar slippage apertado

A tolerância de slippage define o pior preço que está disposto a aceitar. Se configurar 1% de slippage, a sua transação falhará em vez de executar a um preço mais de 1% pior que o esperado.

Isto limita a margem de lucro do bot. Se o bot só puder extrair uma quantia mínima antes da sua transação reverter, o ataque torna-se não lucrativo após contabilizar as próprias taxas e custos de gorjeta do bot.

Para a maioria dos swaps, 1–3% de slippage é suficiente. Só aumente para tokens extremamente voláteis ou durante lançamentos onde esteja disposto a aceitar um preço pior.

3. Dividir trades grandes

Em vez de fazer swap de uma grande quantia numa transação, divida em swaps mais pequenos. Cada trade mais pequeno tem menos impacto no preço, tornando cada um menos atrativo para bots sandwich.

A desvantagem são mais transações e mais taxas, mas as poupanças de evitar um ataque sandwich geralmente superam o custo extra.

4. Evitar pools de liquidez extremamente baixa

Se um pool tem liquidez muito baixa, mesmo um trade pequeno cria impacto de preço enorme. Estes pools são os alvos mais fáceis para bots sandwich. Verifique a liquidez do pool no DEXScreener, Birdeye ou DexTools antes de fazer swap.

5. Verificar as suas transações depois

Ferramentas como sandwiched.me permitem verificar se a sua wallet foi afetada por ataques sandwich. Rever as suas transações passadas ajuda a identificar padrões e ajustar a sua estratégia — slippage mais apertado, trades mais pequenos ou mudar para encaminhamento com proteção MEV.

Ataques sandwich vs. outras quedas de preço

Nem toda perda após comprar é um ataque sandwich.

• Ataque sandwich: O preço dispara antes da sua transação e cai imediatamente depois — dentro do mesmo bloco ou do seguinte. Num explorador de blocos, pode ver uma grande compra antes da sua e uma grande venda depois, da mesma wallet ou programa.
• Pressão de venda normal: O preço declina gradualmente ao longo de minutos ou horas após a sua compra. Outros holders estão a vender, o que é comportamento normal de mercado.
• Rug pull: O desenvolvedor remove toda a liquidez do pool. O preço cai para quase zero instantaneamente e o token torna-se intransacionável.

Resumo

Os ataques sandwich exploram o facto de que os preços em DEX se movem com base no tamanho do trade relativamente à liquidez do pool, e que a ordenação de transações dentro de um bloco é controlada por validadores — não determinada por quem submeteu primeiro.

Para se proteger: use encaminhamento com proteção MEV (Jito na Solana, Flashbots Protect na Ethereum), configure slippage apertado, divida trades grandes e verifique a liquidez do pool antes de fazer swap.

FAQ

Posso ser sandwichado em qualquer cadeia?

Sim. Qualquer cadeia com DEXs baseados em AMM é suscetível — Solana, Ethereum, BSC, Base, Polygon, Arbitrum e outros. A vulnerabilidade vem de como os AMMs calculam preços, não de qualquer cadeia ou DEX específico.

Alto slippage significa que serei sandwichado?

Não automaticamente, mas aumenta significativamente o risco. Alto slippage diz à rede que aceitará um preço pior, o que dá aos bots mais espaço para extrair lucro. Mantenha o slippage o mais baixo possível.

O ataque sandwich é ilegal?

Não há um quadro legal claro na maioria das jurisdições. Na Solana, a Solana Foundation e o Jito tomaram medidas contra validadores que participam em ataques sandwich, removendo-os de programas de delegação. Na Ethereum, Flashbots e outros fornecedores de infraestrutura trabalham para reduzir a extração de MEV.