Uma taxonomia do abuso de mercado

Curiosidade

1. Por que um contrato de token precisa de uma chave de administrador se é suposto ser sem permissões?
2. Como é que duas transações idênticas podem ter preços diferentes dependendo de quem as envia primeiro?
3. Se o código não pode prevenir a engenharia social, qual parte do mercado permanece vulnerável?

Explorar

Parte IUma taxonomia do abuso de mercado

1. O abuso de mercado se divide em seis camadas distintas, cada uma explorando uma fraqueza estrutural específica. A camada de contrato envolve poderes retidos como a criação (minting) ou o congelamento; a camada de estrutura de mercado inclui pools finos e designs de curvas; a camada de ordenação explora a sequenciação das transações; a camada de atividade falsa infla o volume e o número de holders; a camada social manipula a confiança por meio de falsificação de identidade; e a camada de carteira esvazia ativos por meio de phishing. Cada camada se refere a um dos quatro tipos de defensores (código, design do mercado, criptografia ou pessoas), e esse nível mostra que já existem ferramentas para cada um deles. Foi escrito tanto para desenvolvedores quanto para usuários.
2. A camada de contrato é onde o roubo geralmente começa. Se um desenvolvedor retém a autoridade de minting, ele pode imprimir novos tokens à vontade e vendê-los contra os holders existentes. As funções de congelamento permitem que ele bloqueie carteiras específicas de vender, prendendo efetivamente o capital. Os proxies atualizáveis permitem que os desenvolvedores substituam o código subjacente após o lançamento. Isso não são bugs; são funcionalidades que criam uma superfície de ataque. Remover essas chaves elimina a ameaça, mas também remove a capacidade de corrigir erros críticos ou responder a emergências.
3. Os ataques de ordenação exploram aqueles que conseguem ver as transações pendentes antes que sejam ordenadas. O front-running ocorre quando um trader vê uma ordem pendente e envia sua própria transação com uma taxa mais alta para ser executada primeiro. O sandwiching envolve comprar logo antes da grande troca de uma vítima e vender imediatamente em seguida, lucrando com o impacto no preço causado por essa troca. Essas perdas recaem sobre os traders comuns, que recebem preços de execução piores. Os limites de slippage limitam as perdas potenciais, mas não impedem o ataque em si.
4. Os ataques de lançamento exploram a velocidade da precificação por ordem de chegada. Snipers compram tokens no primeiro bloco do lançamento, muitas vezes usando bundles para agrupar várias transações juntas para inclusão atômica. Carteiras Sybil permitem que um único ator controle vários endereços, disfarçando a concentração e obtendo recompensas por carteira. Esses ataques dependem da criação barata de endereços e de estruturas de recompensa que não são lineares em relação às quantidades possuídas. A detecção geralmente requer a análise dos gráficos de financiamento após o fato.
5. A atividade falsa infla as métricas que geram atenção. O wash trading envolve a compra e venda de tokens entre as próprias carteiras para criar volume artificial. Bots de volume realizam transações para subir nas listas de tendências, enquanto o dust spraying cria números falsos de holders. Quando cada transação paga uma taxa, o wash trading se torna caro; mas quando os algoritmos de tendências dão peso às carteiras únicas, os ataques Sybil se tornam lucrativos. Essas distorções enganam os investidores quanto ao verdadeiro interesse do mercado.
6. A camada social explora a confiança humana em vez do código. Promoções pagas não divulgadas, falsificação de contas oficiais e operações coordenadas de “pump-and-dump” não exigem vulnerabilidades técnicas. Sites de phishing e aprovações maliciosas esvaziam as carteiras dos usuários diretamente. O código pode tornar esses ataques visíveis por meio da verificação do histórico na cadeia, mas não consegue impedi-los. Essas ameaças residem no comportamento das pessoas, e não na lógica dos contratos.

Parte IIQue código pode consertar e o que não pode

7. A lógica do contrato define o que é possível. Se o código mantiver uma função de criação de moedas acessível apenas a um administrador, essa chave continuará sendo uma superfície de ataque permanente. Remover completamente a autoridade para criar moedas elimina o risco de inflação descontrolada. Da mesma forma, excluir variáveis relacionadas a impostos sobre vendas ou funções de congelamento impede o abuso de “honeypots” e listas negras. São escolhas binárias: o poder existe ou não existe.
8. A estrutura de mercado determina a ordem de execução. No processamento sequencial, a primeira compra em um bloco obtém o melhor preço. Os mecanismos de liquidação em lote agrupam transações dentro de uma janela de tempo e as executam todas por um preço de liquidação uniforme. Isso neutraliza o front-running e práticas como “sanduíches” dentro do lote, pois toda ordem recebe o mesmo preço: ser a primeira ou envolver a ordem de outra pessoa não traz nenhum benefício.
9. Alguns riscos são limitados, mas não eliminados. Um criador que possui 40% do estoque pode vendê-lo em grande quantidade, fazendo com que o preço caia para os compradores antecipados. O código pode bloquear ou condicionar a venda do estoque de um criador, mas não pode impedir que um detentor sem restrições o venda. Esse é um risco de mercado, distinto do roubo. Comprar em um bloco anterior também pode ser vantajoso. Os criadores devem aceitar que a volatilidade causada por grandes detentores é uma característica inerente aos mercados sem permissões, e não um erro a ser corrigido.
10. A engenharia social opera fora da base de código. Links de phishing, contas falsificadas e promoções pagas exploram a confiança humana, não vulnerabilidades computacionais. Nenhum contrato inteligente consegue verificar se um influenciador divulgou seu interesse antes de emitir um token. Esses ataques persistem independentemente da segurança técnica, pois operam com base na atenção e na crença, e não em transições de estado.
11. Um documento de design honesto lista quais classes de ataques são eliminadas pelo código, quais são neutralizadas pelas mecânicas de mercado e quais permanecem irreduzíveis ao comportamento humano. Ele afirma explicitamente: o abuso da função “mint” é impossível; os ataques do tipo “sandwich” são mitigados por meio do agrupamento de transações; o phishing continua sendo uma responsabilidade de segurança pessoal. Essa transparência permite que os usuários avaliem com precisão seu risco, em vez de assumir total segurança.
12. Abra um explorador de blocos para um token EVM com código-fonte verificado e procure por funções como `mint`, `pause` ou `owner`; na Solana, verifique as autoridades de criação e congelamento de tokens, bem como a autoridade de atualização do programa. Verifique se essas funções podem ser chamadas por qualquer pessoa ou se são restritas a um endereço específico. Se não existirem tais funções e o contrato não for atualizável, esses vetores de ataque estão estruturalmente ausentes, e não apenas desativados.

Fatos-chave

Exercício nove, seis, três, um

Verificação de fatos

Datas, números e afirmações verificados com as fontes publicadas listadas abaixo.

• Chainalysis, Crypto Crime Report (2024)
• P. Daian et al., 'Flash Boys 2.0' (IEEE S&P 2020)
• SPL Token documentation
• OpenZeppelin proxy documentation
• E. Budish, P. Cramton & J. Shim, 'The High-Frequency Trading Arms Race' (QJE 2015)