Proteção MEV com Jito DontFront

Maximal Extractable Value (MEV) refere-se ao valor que pode ser capturado ao reordenar, incluir ou excluir transações dentro de um bloco. O MEV não é exclusivo de nenhuma chain específica; é uma propriedade fundamental de qualquer blockchain onde os produtores de blocos controlam a ordenação das transações. Algumas formas de MEV, como arbitragem, ajudam a manter os mercados eficientes ao corrigir discrepâncias de preço entre DEXs. Outras, como ataques sanduíche, extraem valor diretamente dos usuários. Para desenvolvedores construindo aplicações DeFi, isso pode significar pior execução de negociações e perda de lucros.

Este guia foca em ataques sanduíche, uma forma comum de MEV prejudicial, e em como mitigá-los usando o recurso dontfront da Jito.

Leitura prévia recomendada: Jito Bundles

MEV na Solana

A arquitetura da Solana já reduz a superfície de ataque do MEV em comparação com chains com mempools públicos. As transações são encaminhadas diretamente ao próximo líder de bloco em vez de ficarem em um mempool compartilhado, e transações não processadas expiram após aproximadamente 150 blocos (~1 minuto). Isso reduz significativamente a janela para que searchers observem e ajam sobre transações pendentes.

Dito isso, a extração de MEV ainda ocorre. Searchers com infraestrutura otimizada e conexões diretas com validators podem observar o fluxo de transações e reagir a ele. Grande parte da atividade de MEV na Solana é arbitragem atômica: bots que corrigem diferenças de preço entre DEXs em uma única transação. Esse tipo de MEV é geralmente benéfico, pois melhora a consistência de preços entre os mercados.

A variedade prejudicial, os ataques sanduíche, é contra a qual os desenvolvedores devem ativamente se proteger.

O que é um Ataque Sanduíche?

Um ataque sanduíche ocorre quando um searcher detecta seu swap pendente e explora a ordenação de transações:

1. Front-run: o searcher compra o token antes da sua negociação, empurrando o preço para cima
2. Sua negociação é executada a um preço pior do que o esperado
3. Back-run: o searcher vende o token após sua negociação, embolsando a diferença

Na Solana, isso pode acontecer por meio de Jito bundles. Um searcher envia um bundle de transações como: [frontrun_tx, your_tx, backrun_tx], e o block engine as executa atomicamente em ordem. A vítima obtém um preço de execução pior enquanto o searcher lucra com o spread.

Como o DontFront Funciona

DontFront é um recurso do block engine da Jito que impede searchers de colocar transações antes da sua em um bundle.

O mecanismo: adicione qualquer chave pública Solana válida que comece com jitodontfront a qualquer instrução na sua transação. O block engine reconhece esse prefixo e aplica uma regra: qualquer bundle contendo sua transação deve colocá-la no índice 0.

Without dontfront:  [frontrun_tx, your_tx, backrun_tx]  ← sandwich possible
With dontfront:     [your_tx, ...]                       ← your tx must be first

Passo a Passo

1. Escolha um endereço válido começando com jitodontfront (ex.: jitodontfront111111111111111111111111111111). A conta não precisa existir onchain; ela nunca é lida ou gravada. Você pode verificar se uma string é um endereço válido usando a função assertIsAddress do @solana/kit ou pode inserir o endereço no Solana Explorer para ver se ele resolve. Aqui está um exemplo de endereço inválido.

2. Adicione-o como uma conta somente leitura e sem assinatura a qualquer instrução na sua transação. Marque-o como somente leitura para velocidade de inclusão ideal. A maioria dos programas (incluindo o System Program) ignora contas extras além do que esperam.

3. Envie pelo block engine da Jito:

   • sendTransaction: https://mainnet.block-engine.jito.wtf/api/v1/transactions
   • sendBundle: https://mainnet.block-engine.jito.wtf/api/v1/bundles

   Docs: sendTransaction e sendBundle

4. O block engine detecta o prefixo jitodontfront e aplica as regras de ordenação.

O que Acontece no Block Engine

Quando o block engine encontra uma transação contendo uma conta jitodontfront:

• Via sendTransaction: a transação é protegida. Nenhum bundle pode colocar outra transação antes dela
• Via sendBundle: a transação deve aparecer no índice 0, ou o bundle inteiro é rejeitado

Transações e bundles que não contêm uma conta jitodontfront não são afetados.

Regras de Ordenação de Bundles

Essas regras se aplicam quando uma transação jitodontfront aparece em um bundle.

Padrões Permitidos

[tx_with_dontfront, tip]
[tx_with_dontfront, arbitrage, tip]
[tx_with_dontfront_signer1, tx_with_dontfront_signer1_and_signer2, tip]

Múltiplas Transações DontFront em um Bundle

Múltiplas transações dontfront em um único bundle são permitidas quando ambas as condições são atendidas:

1. Todas as transações dontfront são contíguas no início do bundle
2. Cada transação dontfront compartilha pelo menos um signatário com a primeira transação dontfront

✅ [txA_df, txB_df, txC_df, arbitrage, tip]
   (contiguous at front, overlapping signers)

✅ [txA_df_signer1_signer2, txB_df_signer1_signer3, txC_df_signer2_signer4]
   (each shares a signer with txA)

Padrões Rejeitados

❌ [tip, tx_with_dontfront]
   → dontfront tx is not at index 0

❌ [txA_df_signer1, txB_df_signer2]
   → no overlapping signer between txA and txB

❌ [trade, tx_with_dontfront, arbitrage, tip]
   → dontfront tx is not at the front

Exemplos de Integração

Para uma receita de código rápida, consulte a entrada do cookbook de Proteção MEV.

TypeScript (@solana/kit)

A ideia central é um auxiliar que anexa a conta dontfront a qualquer instrução:

import {
  address,
  AccountRole,
  type Instruction,
  type Address
} from "@solana/kit";

const DONT_FRONT: Address = address(
  "jitodontfront111111111111111111111111111111"
);

function withDontFront(ix: Instruction): Instruction {
  return {
    ...ix,
    accounts: [
      ...(ix.accounts ?? []),
      { address: DONT_FRONT, role: AccountRole.READONLY }
    ]
  };
}

Em seguida, envie a transação assinada ao block engine da Jito em vez de um nó RPC padrão. Use sempre a codificação base64. O Base58 está obsoleto na API da Jito.

const response = await fetch(
  "https://mainnet.block-engine.jito.wtf/api/v1/transactions",
  {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      jsonrpc: "2.0",
      id: 1,
      method: "sendTransaction",
      params: [base64Tx, { encoding: "base64" }]
    })
  }
);

Boas Práticas

O DontFront é uma camada de proteção. Uma estratégia robusta de mitigação de MEV combina múltiplas abordagens:

Proteção no Nível da Transação

• Defina tolerâncias de slippage rigorosas. A defesa mais eficaz contra ataques sanduíche é limitar o slippage aceitável nos swaps. Uma janela de slippage menor reduz a margem de lucro disponível para os atacantes, tornando sua transação menos atraente para o sanduíche.

• Defina gorjetas e taxas de prioridade adequadas. Durante congestionamentos, gorjetas e taxas de prioridade mais altas aumentam a probabilidade de que sua transação/bundle seja incluída rapidamente, reduzindo a janela para os searchers agirem. Consulte a documentação da Jito sobre Valores de Gorjeta para mais detalhes sobre como definir gorjetas adequadas.

• Otimize o uso de unidades de computação. Cada bloco tem um número limitado de unidades de computação disponíveis (e as contas têm um número limitado de unidades de computação disponíveis por bloco). Para maximizar a probabilidade de que sua transação/bundle seja incluída em um bloco, você deve otimizar o uso das unidades de computação. Consulte o guia Como Otimizar o Uso de Computação na Solana para mais detalhes.

Específico do DontFront

1. Marque a conta dontfront como somente leitura. A marcação como gravável funciona, mas somente leitura otimiza a velocidade de inclusão.

2. Use um pubkey dontfront único por aplicação. Qualquer pubkey começando com jitodontfront funciona. Usar uma variante única (ex.: jitodontfront111111111111111111111111111123) permite distinguir o uso por app ao inspecionar dados onchain.

3. O DontFront suporta Address Lookup Tables. A conta dontfront pode ser incluída via ALT. Mas não use ALTs para contas de gorjeta.

Limitações

• Apenas block engine. O DontFront é aplicado pelo block engine da Jito. Transações enviadas diretamente aos validators (contornando o Jito) não são protegidas.

• Sem garantia. Da documentação da Jito: "Este recurso pode ajudar a reduzir ataques sanduíche, mas não garante isso e não é uma solução para todas as variações na ordenação de transações, incluindo qualquer ordenação conduzida por terceiros."

• Apenas Mainnet/Testnet. Este é um recurso do block engine da Jito. Não funciona em devnet ou localhost.

Referências

• Docs Jito: Mitigação de Sanduíche
• Docs Jito: sendTransaction
• Docs Jito: sendBundle
• Docs Jito: Contas de Gorjeta
• Docs Jito: Valores de Gorjeta
• API Tip Floor
• @solana/kit no GitHub
• solana-sdk no crates.io