Lista de Vulnerabilidades Comuns

A reentrância é uma das vulnerabilidades mais antigas e devastadoras dos contratos inteligentes (smart contracts), responsável por explorações (exploits) históricas significativas como o hack da The DAO, que levou a um hard fork do Ethereum. Continua a ser uma ameaça crítica com consequências potencialmente terríveis, capaz de drenar todos os fundos dos contratos.

A vulnerabilidade deriva de um anti-padrão de codificação comum, frequentemente transportado de hábitos da Web2: realizar interações externas (como transferir Ether ou chamar outro contrato) antes de atualizar o estado interno do contrato (por exemplo, saldos dos usuários). Quando um contrato envia Ether ou chama um contrato externo, ele transfere temporariamente o controle da execução. Um atacante controlando o contrato receptor pode explorar isso chamando imediatamente de volta o contrato original, muitas vezes através da função receive ou fallback acionada pela transferência de Ether, ou através de hooks dos padrões de token.

Como o estado do contrato original (por exemplo, o saldo do atacante) ainda não foi atualizado, a chamada reentrante passa nas verificações iniciais, permitindo ao atacante repetir a ação (como retirar fundos) múltiplas vezes dentro da mesma transação. Este loop recursivo continua até que os fundos sejam drenados ou os limites de gás sejam atingidos.

Embora o ataque clássico envolva uma única função, existem variações mais complexas, como a reentrância entre funções (explorando estado compartilhado entre funções) e a reentrância somente leitura (read-only reentrancy - manipulando leituras de estado através de funções de visualização, ou view functions).

A defesa principal é o padrão Checks-Effects-Interactions (CEI): realizar todas as verificações necessárias, depois atualizar as variáveis de estado (efeitos) e, somente após estas atualizações, interagir com contratos externos.

A vulnerabilidade de "Manipulação de saldo por recebimento inesperado de Ether" surge porque os contratos inteligentes Solidity podem receber Ether através de mecanismos que contornam as suas funções `receive` e `fallback` definidas. Os métodos primários para esta injeção "inesperada" de Ether são o opcode `selfdestruct`, que transfere forçadamente o saldo de um contrato em destruição para um endereço designado, e as transações coinbase (recompensas de bloco).

A questão central é que estas transferências forçadas aumentam diretamente o saldo de Ether do contrato (`address(this).balance`) sem acionar a lógica programada do contrato para o tratamento de fundos recebidos. Isto quebra uma suposição ou invariante comum, muitas vezes implícita: que o saldo real do contrato reflete com precisão a soma dos fundos processados através das suas funções `payable` pretendidas ou contabilizados internamente.

Contratos que usam incorretamente `address(this).balance` para verificações lógicas críticas tornam-se vulneráveis. Por exemplo, contratos podem verificar se `address(this).balance == montanteEsperado`. Um atacante pode explorar isto usando `selfdestruct` para enviar uma pequena quantidade de Ether, manipulando assim o saldo. Isto pode levar a:

Negação de Serviço (DoS): Verificações de igualdade estrita podem ser permanentemente quebradas, tornando as funções inutilizáveis.

Manipulação da Lógica: Limiares podem ser atingidos prematuramente, desencadeando alterações de estado ou pagamentos não intencionais.

Violações de `assert`: Em casos raros, o saldo inesperado pode levar a inconsistências de estado internas que causam a falha de um `assert()`, consumindo todo o gás da transação.

A mitigação fundamental é nunca depender de `address(this).balance` para a lógica do contrato. Em vez disso, os contratos devem manter uma contabilidade interna precisa usando variáveis de estado dedicadas, atualizando-as apenas dentro de funções legítimas de tratamento de fundos. Todas as verificações críticas e transições de estado devem basear-se nestas variáveis internas confiáveis.

As vulnerabilidades de Negação de Serviço (Denial of Service, DoS) em contratos inteligentes Solidity visam interromper ou parar completamente a funcionalidade pretendida do contrato, impedindo que utilizadores legítimos acedam aos seus serviços. O "serviço" que está a ser negado é a capacidade do contrato de executar as suas funções conforme programado e esperado pelos seus utilizadores.

Os atacantes conseguem isto explorando falhas na lógica do código do contrato, manipulando limitações de recursos (principalmente o gás) ou aproveitando dependências externas.

Padrões comuns incluem:

Exaustão de Gás (Gas Exhaustion): Criar transações ou manipular o estado para fazer com que os custos de execução da função excedam o limite de gás do bloco ou o limite de gás da transação. Isto envolve frequentemente acionar operações computacionalmente caras ou, muito comummente, iterar sobre arrays ilimitados cujo tamanho pode crescer indefinidamente. À medida que os dados aumentam, o custo de gás do ciclo ultrapassa os limites, tornando a função inutilizável.

Reversões Inesperadas (Unexpected Reverts): Causar a reversão (revert) inesperada de funções críticas. Isto pode ser desencadeado forçando chamadas externas falhadas (por exemplo, enviar fundos para um contrato que os rejeita), manipulando o estado para fazer falhar as condições `require`, ou outras exceções não tratadas. Se um contrato depende de uma chamada externa que falha (talvez induzida maliciosamente), toda a operação pode ser bloqueada.

A natureza imutável dos contratos inteligentes torna o DoS particularmente grave. Um ataque bem-sucedido pode levar a fundos bloqueados permanentemente ou a funcionalidade irrecuperável, uma vez que o código do contrato não pode ser facilmente corrigido após a implantação (post-deployment).

A mitigação baseia-se em práticas de codificação seguras: usar operações limitadas em vez de ciclos ilimitados, preferir padrões "pull-payment" (pagamento por solicitação) em vez de enviar fundos para os utilizadores ("push-payment"), o que isola falhas de transferência, tratar robustamente falhas de chamadas externas (por exemplo, usar `try/catch` onde apropriado) e gestão cuidadosa do gás.

Vulnerabilidades de overflow e underflow de inteiros representam uma ameaça persistente no domínio da segurança de contratos inteligentes (smart contracts), decorrentes das limitações fundamentais da aritmética de inteiros de tamanho fixo. Um overflow ocorre quando o resultado de uma operação aritmética excede o valor máximo para seu tipo, e um underflow ocorre quando o resultado fica abaixo do valor mínimo.

Historicamente, em versões do Solidity anteriores à 0.8.0, esses erros aritméticos faziam com que o valor "desse a volta" (wrap around) silenciosamente. Por exemplo, adicionar 1 ao valor máximo de uint8 (255) resultaria em 0, e subtrair 1 de 0 resultaria em 255. Esse comportamento previsível, mas não verificado, era uma fonte importante de exploits, permitindo que atacantes manipulassem saldos de tokens (por exemplo, cunhando enormes quantidades ou drenando fundos ao fazer os saldos darem a volta), contornassem verificações críticas de segurança, corrompessem o estado do contrato ou causassem negação de serviço (denial-of-service).

A versão 0.8.0 do Solidity introduziu uma melhoria de segurança crucial: operações aritméticas padrão (+, -, *, /) agora realizam verificações de overflow e underflow por padrão. Se uma operação resultasse em "wrap around", a transação reverte (reverts) em vez disso, prevenindo a corrupção silenciosa de estado.

No entanto, o risco não é totalmente eliminado. Desenvolvedores podem explicitamente contornar essas verificações padrão usando blocos `unchecked`, frequentemente para otimização de gás. O código dentro de um bloco `unchecked` retorna ao perigoso comportamento de "wrap around" silencioso das versões pré-0.8.0 e exige validação extremamente cuidadosa. Da mesma forma, o código assembly de baixo nível da EVM não se beneficia das verificações do Solidity, exigindo gerenciamento manual de segurança para operações aritméticas. Além disso, operações de deslocamento (shift) (<<, >>) permanecem não verificadas mesmo no modo padrão >=0.8.0 e truncarão os resultados. A conversão de tipo (type casting) inadequada (por exemplo, converter um uint256 grande para um tipo menor como uint8) também pode levar ao truncamento de valor, potencialmente causando comportamento inesperado em cálculos subsequentes.

Portanto, embora significativamente mitigado por padrão no Solidity moderno, o overflow/underflow de inteiros permanece uma vulnerabilidade relevante, especialmente em contratos legados (legacy contracts), código que utiliza blocos `unchecked` ou assembly, e através de operações específicas não verificadas ou conversões de tipo descuidadas.

O uso de `tx.origin` para lógica de autorização em contratos inteligentes (smart contracts) Solidity representa uma vulnerabilidade de segurança crítica. Resulta de um mal-entendido fundamental do seu comportamento em comparação com `msg.sender`. Enquanto `tx.origin` identifica consistentemente a EOA (Externally Owned Account / Conta de Proprietário Externo) que iniciou a transação, `msg.sender` identifica o chamador imediato. Usar `tx.origin` para verificações de permissão falha em validar a entidade que interage diretamente com o contrato.

Essa falha abre a porta para ataques do tipo phishing, onde um contrato intermediário malicioso, invocado por um usuário privilegiado, pode chamar com sucesso funções protegidas no contrato alvo. A verificação `tx.origin` valida incorretamente o usuário original, permitindo que o contrato malicioso execute ações com a autoridade do usuário. As consequências variam desde o roubo direto de Ether e tokens até a manipulação não autorizada do estado do contrato, causando potencialmente perdas financeiras significativas e danos irreparáveis à integridade e reputação do protocolo.

O Controle de Acesso Insuficiente é uma vulnerabilidade crítica em contratos inteligentes Solidity onde as restrições sobre quem pode executar quais funções estão ausentes ou implementadas incorretamente. Como o Solidity não possui modelos de permissão incorporados, os desenvolvedores devem adicionar verificações manualmente, muitas vezes usando modificadores como onlyOwner ou implementando o Controle de Acesso Baseado em Função (RBAC). A falha em fazer isso corretamente cria falhas de segurança.

Essa vulnerabilidade geralmente se manifesta como funções desprotegidas. Funções destinadas a operações administrativas ou sensíveis - como transferir a propriedade do contrato (changeOwner), retirar fundos (withdraw), pausar o contrato, cunhar tokens ou até mesmo destruir o contrato (selfdestruct) - podem ser deixadas disponíveis para chamada por qualquer conta externa. Isso geralmente ocorre devido à falta de modificadores de controle de acesso ou à visibilidade incorreta da função (por exemplo, as funções são public por padrão se não especificadas). Funções de inicialização expostas, que deveriam ser executadas apenas uma vez, também podem ser um vetor de ataque se permanecerem chamáveis após a implantação, permitindo potencialmente que atacantes redefinam a propriedade ou parâmetros críticos.

As consequências são severas, variando desde usuários não autorizados obtendo privilégios administrativos até o roubo completo dos fundos gerenciados pelo contrato ou a destruição irreversível do próprio contrato. Exploits do mundo real, como os incidentes da carteira Parity e o hack do LAND Token, demonstram o potencial devastador do controle de acesso insuficiente.

A mitigação envolve aplicar rigorosamente verificações de controle de acesso a todas as funções sensíveis, aderir ao Princípio do Menor Privilégio, usar padrões estabelecidos como Ownable ou RBAC (frequentemente por meio de bibliotecas como as da OpenZeppelin) e conduzir testes e auditorias completos.

Gerar aleatoriedade segura na Máquina Virtual Ethereum (EVM) é desafiador devido à sua natureza determinística, que é essencial para o consenso da rede. Isso cria uma "ilusão de entropia" onde valores aparentemente aleatórios derivados puramente de dados on-chain são, na verdade, previsíveis.

Desenvolvedores frequentemente usam indevidamente variáveis de bloco prontamente disponíveis como block.timestamp, blockhash e o prevrandao pós-Merge (acessado via block.difficulty) como fontes de pseudo-aleatoriedade. Essas variáveis são inseguras porque podem ser previstas ou influenciadas.

Mineradores (em Proof-of-Work) ou validadores (em Proof-of-Stake) podem manipular esses valores até certo ponto para obter uma vantagem injusta, muitas vezes como parte de estratégias de MEV (Valor Máximo Extraível). Crucialmente, mesmo usuários regulares ou contratos atacantes podem frequentemente prever resultados se a lógica de aleatoriedade depender apenas de entradas conhecidas antes ou durante a execução da transação, permitindo exploits como front-running. Essa previsibilidade mina a justiça de aplicações como loterias, jogos e mints de NFT.

A Colisão de Hash via `abi.encodePacked` com Múltiplos Tipos Dinâmicos não surge de fraquezas na função de hash subjacente Keccak-256, mas da forma como os dados são codificados antes de serem hasheados, especificamente ao usar a função `abi.encodePacked` do Solidity. Ao contrário do padrão `abi.encode`, que preenche (padding) os argumentos para 32 bytes e inclui prefixos de comprimento para tipos dinâmicos, `abi.encodePacked` cria uma codificação compacta e não padronizada concatenando argumentos usando o mínimo de bytes necessários, omitindo o preenchimento para tipos estáticos pequenos e, crucialmente, omitindo informações de comprimento para tipos dinâmicos como `string`, `bytes` ou arrays dinâmicos.

O problema central ocorre quando `abi.encodePacked` é usado com dois ou mais argumentos de tipo dinâmico adjacentes. Como o comprimento de cada argumento dinâmico não é codificado, a fronteira entre eles torna-se ambígua na string de bytes resultante. Essa ambiguidade torna possível, muitas vezes trivialmente, criar diferentes conjuntos de entradas lógicas que produzem exatamente a mesma sequência de bytes compactada. Por exemplo, `abi.encodePacked("a", "bc")` produz a mesma saída de bytes que `abi.encodePacked("ab", "c")`.

Quando esta saída de bytes idêntica é subsequentemente hasheada (por exemplo, `keccak256(abi.encodePacked(...))`), resulta no mesmo valor de hash, uma colisão de hash induzida pela codificação.

Esta vulnerabilidade de colisão de codificação pode ser explorada de várias maneiras se o hash resultante for usado num contexto sensível à segurança:

Bypass da Verificação de Assinatura: Um atacante pode pegar uma assinatura válida criada para um conjunto de parâmetros e reutilizá-la com um conjunto diferente e malicioso de parâmetros que produzem um hash em colisão. A verificação da assinatura do contrato (`ecrecover`) será bem-sucedida, concedendo execução não autorizada.

Corrupção de Estado via Colisões de Chaves de Mapeamento: Se o hash propenso a colisões for usado como chave num mapeamento (`mapping(bytes32 => ...)`), um atacante pode criar entradas para gerar uma chave que colida com a chave de um utilizador legítimo, potencialmente sobrescrevendo os seus dados, contornando controlos de acesso ou causando negação de serviço.

Problemas de Autenticação de Mensagens: A vulnerabilidade mina as verificações que dependem do hash para garantir a integridade dos dados, pois diferentes mensagens lógicas podem parecer idênticas após o hashing.

As consequências de uma exploração bem-sucedida podem ser graves, incluindo Acesso Não Autorizado a funções ou dados, Roubo direto de Fundos (Fund Theft), Corrupção Crítica do Estado e Negação de Serviço (DoS).

Vulnerabilidades de perda de precisão decorrem da dependência da aritmética de inteiros e da falta de suporte nativo para números de ponto flutuante. Esse design prioriza a execução determinística, mas exige que os desenvolvedores gerenciem manualmente valores fracionários, criando oportunidades para erros.

O problema central é o truncamento da divisão de inteiros: o Solidity descarta restos e arredonda os resultados da divisão para zero. Esse comportamento previsível pode ser explorado, frequentemente através de padrões como:

Divisão antes da multiplicação: Calcular (a / b) * c em vez de (a * c) / b trunca o resultado intermediário a / b, amplificando a perda de precisão.

Arredondamento para baixo para zero: Se o numerador A for menor que o denominador B (e ambos forem positivos), A / B sempre resultará em 0. Isso é arriscado para cálculos envolvendo pequenas taxas, recompensas ou conversões de tokens.

Atacantes exploram essas propriedades matemáticas para manipular a lógica do contrato para ganho financeiro. Estratégias comuns incluem:

Manipulação de estado/preço: Provocar erros de arredondamento para distorcer valores críticos do protocolo, como taxas de câmbio, reservas de pool, preços de cotas de cofres (vaults) ou índices de colateralização, que podem então ser explorados em transações subsequentes.

Exploração de casos extremos (edge cases): Usar transações com entradas muito pequenas ou entradas projetadas para interagir com grandes valores internos para maximizar o impacto do truncamento, muitas vezes fazendo com que os cálculos resultem em zero.

Ataques bem-sucedidos de perda de precisão podem levar a consequências negativas significativas:

Custos reduzidos: Atacantes pagam taxas/custos menores ou zero.

Ganhos inflacionados: Atacantes recebem ilegitimamente mais tokens, cotas ou recompensas.

Oportunidades de arbitragem: Criação de diferenças de preço artificiais dentro do protocolo para exploração por atacantes.

Contornar mecanismos de risco: Ignorar liquidações ou outras verificações de segurança devido a cálculos imprecisos.

Drenagem gradual de fundos: Sifonar valor através de transações repetidas que exploram minúsculos erros de arredondamento ("ataques de 1 wei").

A mitigação envolve o manuseio aritmético cuidadoso, como realizar multiplicações antes das divisões, usar escalonamento numérico (simulando matemática de ponto fixo), empregar bibliotecas matemáticas especializadas e implementar lógica de arredondamento apropriada. Verificações padrão de overflow (como SafeMath ou Solidity >=0.8) não previnem a perda de precisão decorrente da divisão.

Esta vulnerabilidade ocorre quando um contrato inteligente (smart contract) usa incorretamente o msg.value dentro de um loop (laço). O problema central decorre do fato de que msg.value permanece constante durante todo o contexto de execução de uma transação. Se um loop itera várias vezes, realizando verificações ou ações com base neste msg.value inicial em cada iteração sem rastrear corretamente o valor cumulativo processado ou gasto ao longo dessas iterações, isso cria uma oportunidade de exploração (exploit).

Um atacante pode explorar isso enviando uma quantidade específica de Ether para acionar a função vulnerável. Dentro do loop, verificações como require(msg.value >= amount_per_item) podem passar repetidamente, ou atualizações de estado podem usar incorretamente o valor inicial completo de msg.value várias vezes. Isso acontece porque a lógica do contrato falha em contabilizar o valor efetivamente 'gasto' ou alocado em iterações anteriores do mesmo loop.

Esta falha permite que um atacante acione ações (como transferências de Ether ou créditos de saldo interno) cujo valor total excede significativamente o Ether que ele realmente enviou com a transação.

ecrecover é um pré-compilado essencial da EVM que permite aos contratos inteligentes recuperar o endereço do signatário a partir de um hash de mensagem e uma assinatura ECDSA (v, r, s). Isso habilita funcionalidades cruciais como a verificação de mensagens assinadas fora da cadeia (off-chain) para meta-transações ou funções `permit`. No entanto, seu uso direto apresenta riscos de segurança significativos, muitas vezes subestimados, se não for tratado com cuidado.

Vulnerabilidade de Retorno de Endereço Zero: Um problema crítico decorre do tratamento de erro exclusivo do `ecrecover`. Quando apresentado com uma assinatura inválida ou matematicamente impossível, ele não reverte a transação. Em vez disso, ele falha silenciosamente e retorna o endereço zero (`address(0)`). Contratos que chamam `ecrecover` mas sofrem com a falta de uma verificação de endereço zero são altamente vulneráveis. Um atacante pode enviar intencionalmente dados de assinatura inválidos, fazendo com que `ecrecover` retorne `address(0)`. Se essa saída não for explicitamente verificada e rejeitada, o contrato pode prosseguir incorretamente, tratando `address(0)` como o signatário legítimo. Isso pode levar a consequências graves, como alterações de estado não autorizadas, emissões de eventos incorretas ou concessão de permissões, especialmente se o endereço zero tiver privilégios especiais ou estado significativo dentro da lógica específica do contrato. Um código robusto deve sempre validar `recoveredAddress != address(0)` imediatamente após a chamada `ecrecover`.

Vulnerabilidade de Maleabilidade da Assinatura: O segundo risco principal surge de uma propriedade inerente do próprio algoritmo ECDSA: a maleabilidade da assinatura. Para qualquer mensagem e chave privada dadas, podem existir múltiplas representações de assinatura distintas, mas criptograficamente válidas (especificamente, uma assinatura usando o componente `s` pode frequentemente ser transformada em uma assinatura válida usando `n-s`, onde `n` é a ordem da curva). Isso se torna uma vulnerabilidade se os contratos assumirem incorretamente que uma assinatura para uma mensagem é única. Atacantes podem explorar isso contornando verificações de unicidade. Por exemplo, se um contrato usa o hash da própria assinatura como nonce para prevenir replays (um padrão falho), um atacante pode pegar uma assinatura válida, calcular sua contraparte maleável e enviá-la para executar a ação novamente, já que os hashes das assinaturas serão diferentes. Isso também pode causar comportamento inesperado ou replay em sistemas que esperam uma forma de assinatura específica, se sistemas externos ou partes da lógica do contrato não foram projetados para lidar com ambas as formas de assinatura válidas. A mitigação eficaz envolve a aplicação da canonização da assinatura – uma verificação robustamente implementada em bibliotecas padrão como a ECDSA da OpenZeppelin, que deve ser preferida ao uso direto do `ecrecover`.

Ataque de Replay Cross-Chain (CCRA): Uma transação validamente executada em uma chain EVM é capturada e reenviada com sucesso em uma chain EVM diferente. Isso explora similaridades nos formatos de transação e assinaturas entre chains, especialmente quando as transações não possuem identificadores de chain únicos (Chain IDs). O hard fork Ethereum/Ethereum Classic é um exemplo clássico onde esse risco se materializou. O EIP-155 foi introduzido para mitigar isso, incorporando o Chain ID nas assinaturas de transação padrão, tornando-as específicas da chain. No entanto, smart contracts (contratos inteligentes) que usam verificação de assinatura personalizada também devem verificar explicitamente o Chain ID. O exploit de US$ 20 milhões na Optimism contra a Wintermute resultou dessa falta de verificação do Chain ID em um contrato implantado cross-chain.

Replay em Nível de Smart Contract (Mesma Chain): Uma mensagem assinada ou transação é repetida (replayed) contra o mesmo smart contract, ou potencialmente contra outro contrato na mesma chain. Isso normalmente explora vulnerabilidades dentro da lógica própria do contrato, particularmente em esquemas de verificação de assinatura personalizados usados para recursos como meta-transações ou funções `permit` do ERC-20. A falha mais comum é a ausência ou implementação inadequada de um nonce no nível da aplicação. Um nonce («número usado uma única vez») é um contador único associado ao signatário que deve ser incluído no resumo (digest) da mensagem assinada e rastreado on-chain pelo contrato para garantir que cada assinatura específica autorize apenas uma ação.

O suporte do Solidity para herança múltipla permite que um contrato herde recursos de vários contratos pais simultaneamente. Embora poderoso para a reutilização de código, isso introduz uma potencial ambiguidade, conhecida como "Problema do Diamante": se dois ou mais contratos base definem uma função com o mesmo nome e parâmetros.

Para resolver isso, o Solidity emprega o algoritmo de linearização C3 para estabelecer uma Ordem de Resolução de Métodos (Method Resolution Order, MRO) única e determinística para cada contrato. Este MRO dita a sequência precisa em que os contratos base são verificados ao resolver chamadas de função.

A vulnerabilidade surge diretamente de como este MRO é determinado. O fator crucial é a ordem em que o desenvolvedor lista os contratos base na declaração `is`. O Solidity exige a listagem de contratos do "mais base" para o "mais derivado". Esta ordem especificada influencia diretamente o MRO final gerado pelo algoritmo C3.

A vulnerabilidade ocorre quando o desenvolvedor fornece uma ordem de herança que não corresponde à hierarquia lógica ou prioridade pretendida. Se um contrato mais geral for listado após um mais específico, ou se a ordem causar de outra forma que o MRO priorize uma implementação de função não intencional, o contrato pode se comportar inesperadamente. Por exemplo, uma chamada pode resolver para uma função base sem verificações de segurança críticas ou lógica atualizada que foi implementada em uma substituição de contrato derivado pretendida, mas incorretamente ordenada.

As consequências da execução da função errada devido à ordem de herança incorreta incluem contornar controles de acesso, executar lógica de negócios desatualizada ou incorreta, corrupção de estado e potencial perda financeira. Essencialmente, o fluxo de execução real do contrato desvia-se do design do desenvolvedor, minando a segurança e a funcionalidade.

O Valor Máximo Extraível (Maximal Extractable Value - MEV) representa o lucro que produtores de blocos e pesquisadores especializados (searchers) podem capturar ao manipular a inclusão e a ordem das transações dentro de um bloco, para além das recompensas de bloco padrão e das taxas de gás. Originalmente denominado "Valor Extraível por Mineradores" (Miner Extractable Value), o nome evoluiu para "Máximo" para refletir a sua ganância por recompensa.

O MEV surge porque as transações pendentes muitas vezes ficam numa área de espera pública chamada mempool, visível para qualquer pessoa. Os produtores de blocos têm a autoridade para decidir a ordem final das transações num bloco. Bots automatizados, operados por "pesquisadores" (searchers), monitorizam constantemente o mempool, simulam resultados potenciais e exploram oportunidades lucrativas ordenando estrategicamente as transações, frequentemente usando leilões de gás (Priority Gas Auctions - PGAs) para garantir um posicionamento preferencial.

Estratégias comuns de MEV, muitas vezes vistas como ataques, incluem:

Front-Running: Colocar a transação de um atacante antes da transação de uma vítima (por exemplo, uma grande negociação numa DEX) para lucrar com o impacto antecipado no preço.

Ataques Sanduíche (Sandwich Attacks): Uma combinação de front-running e back-running (seguir atrás) da negociação DEX de uma vítima para capturar a diferença de preço (derrapagem ou slippage) causada pela manipulação.

Liquidez Just-in-Time (JIT Liquidity): Adicionar e remover temporariamente liquidez em torno de uma grande troca (swap) em DEXs de liquidez concentrada para capturar taxas.

Manipulação de Oráculos (Oracle Manipulation): Explorar atualizações ou imprecisões de oráculos de preços para obter lucro, afetando frequentemente protocolos de empréstimo.

Outros tipos incluem sniping de NFTs (NFT sniping) e ataques de poeira (dust attacks).

As consequências para os utilizadores incluem aumento dos custos de transação devido a guerras de gás (gas wars), piores preços de execução (derrapagem ou slippage) nas negociações, perda impermanente (impermanent loss) exacerbada para provedores de liquidez e liquidações acionadas injustamente.

As estratégias de mitigação visam reduzir o impacto negativo do MEV. Enviar transações através de mempools privados ou relays (como Flashbots Protect ou MEV Blocker) oculta-as da vista pública. Designs (desenhos) ao nível da aplicação, como esquemas Commit-Reveal (compromisso-revelação), ocultam detalhes da transação até que a ordem seja fixada, enquanto o uso de preços médios ponderados pelo tempo (Time-Weighted Average Prices - TWAP) para oráculos pode reduzir os riscos de manipulação.