Tolerância ao Slippage em Cripto: Porque a Predefinição o Esvazia

O que a tolerância ao slippage significa realmente numa troca

Quando clicas em "swap" numa exchange descentralizada, a tua transação não é executada de imediato. É enviada para um mem pool, recolhida por um router e, depois, liquidada na blockchain. Durante esse intervalo, o preço apresentado pode variar. A tolerância ao slippage é a margem de variação que estás disposto a aceitar entre o preço que viste e o preço pelo qual a troca é efetivamente realizada.

Na prática, se o ETH está cotado a 3 000 $ e defines 1% de slippage, o router vai preencher a tua transação a qualquer preço entre cerca de 2 970 $ e 3 030 $. Qualquer valor pior do que 2 970 $ numa venda (ou 3 030 $ numa compra) deveria fazer a transação ser revertida. A maioria das wallets e frontends de DEX escolhe 0,5% como valor predefinido, por ser uma banda estreita que funciona bem em pares com liquidez, em que o preço raramente varia mais do que alguns pontos base nos segundos que a liquidação demora.

A expressão que importa aqui é "autorização, não objetivo". Uma tolerância de 0,5% não significa que vais perder 0,5%. Num par com liquidez, frequentemente não perdes nada. Mas, se defines 5% ou 20%, não estás a apontar para um slippage de 5% ou 20%; estás a dar ao router autorização para te preencher em qualquer valor até esse número. A execução que acabas por obter depende de quem mais está a competir por essa transação.

Como uma definição elevada de slippage te esvazia na prática

Imagina que encontras um novo token em tendência nas redes sociais. Vas a uma DEX, colas o contrato e tentas comprar 500 $. A interface avisa-te de que a liquidez é reduzida. O auto-router sugere um slippage de 5%, depois 12%, depois 49%, à medida que a tua transação continua a ser revertida. Por fim, aumentas para 49%, clicas em confirmar e recebes apenas uma fração dos tokens que esperavas. O resto do ETH que enviaste foi capturado por algo entre a tua wallet e a blockchain.

Habitualmente, há três culpados, e muitas vezes colaboram entre si. Primeiro, a pool em si tem pouca liquidez, pelo que a tua transação move o preço de forma dramática em relação ao seu tamanho; isto chama-se impacto no preço e é diferente do slippage. Segundo, um observador do mem pool vê a tua transação pendente com o seu teto generoso de 49% e usa um ataque sandwich para lucrar com isso. Terceiro, o próprio token pode ser um honeypot concebido para permitir a compra e impedir a venda, sendo o slippage de 49% o mecanismo que permite ao criador extrair valor.

É este o modo de falha em torno do qual o ângulo se constrói: clicar em confirmar num valor predefinido que o utilizador não compreendeu. O valor predefinido de 0,5% não é uma burla. Uma tolerância de 49% "definida e esquecida" num token cujo contrato não consegues ler é que é. O número de slippage que escolhes é o máximo pelo qual estás disposto a ser prejudicado; numa pool com pouca liquidez e agentes adversários, é exatamente esse máximo que te será retirado.

Como a tolerância de slippage é aplicada no router

A tolerância de slippage é aplicada ao nível do smart contract, não pelo site que está a utilizar. Quando assina uma troca na Uniswap, 1inch, Matcha, CowSwap, ou qualquer router que as agregue, a mensagem assinada contém um valor mínimo de saída. O router chama o pool, executa a transação e verifica o resultado face a esse mínimo. Se a saída ficar abaixo do mínimo, toda a transação é revertida e o gas é gasto, mas os seus tokens não são movidos.

A matemática funciona assim. Se está a comprar um token com ETH e o preço cotado indica que deve receber pelo menos 1 000 tokens, uma tolerância de slippage de 1% significa que a saída mínima é 990 tokens. Uma tolerância de 5% define o mínimo em 950 tokens. Uma tolerância de 49% define-o em 510 tokens. O contrato aceita qualquer valor igual ou superior a esse mínimo; não verifica se a transação foi "justa" nem se houve interferência de bots.

Daqui resultam duas implicações. Primeiro, a proteção é binária: a transação ou é executada a um preço igual ou superior ao mínimo, ou é revertida. Não existe execução parcial numa troca típica de AMM. Segundo, o mínimo é definido por si no momento da assinatura. Uma vez assinado e transmitido, não pode ser alterado. É por isso que os frontends lhe pedem para confirmar um valor de slippage, e é por isso que aumentá-lo para que uma transação passe é uma decisão real com consequências reais.

Na Uniswap v3 e em venues de liquidez concentrada semelhantes, a matemática é idêntica do ponto de vista do utilizador, mas o pool pode ser mais fino no tick atual, o que significa que o seu impacto no preço é maior e um slippage apertado tem mais probabilidade de reverter. Nos pools estilo Uniswap v2, a profundidade está distribuída de forma uniforme, pelo que transações grandes contra um pool pequeno produzem um impacto no preço elevado, que é frequentemente confundido com slippage.

Ataques sandwich, bots de MEV e a mem pool

Uma mem pool é a sala de espera pública para transações não confirmadas. Validadores e construtores de blocos veem a sua troca antes de ser incluída num bloco, incluindo o token, o tamanho, o router e o limite de slippage. Searchers, que são bots especializados, analisam esta mem pool em busca de oportunidades lucrativas. O ataque mais comum contra uma definição generosa de slippage é o sandwich.

Um ataque sandwich tem três passos. O bot vê a sua compra pendente do Token X com 10% de slippage. Coloca uma compra do Token X imediatamente antes da sua, empurrando o preço para cima. A sua transação executa depois a um preço pior do que esperava, mas ainda dentro da sua tolerância, pelo que não é revertida. O bot vende então o Token X imediatamente a seguir, capturando o impacto no preço que criou. Recebe menos tokens e o bot lucra com a diferença.

Os ataques sandwich são um subconjunto de MEV, ou Maximal Extractable Value, que é a categoria mais ampla de lucro que produtores de blocos e searchers podem extrair ao reordenar, inserir ou censurar transações. Na mainnet da Ethereum, o MEV é um imposto real e persistente sobre os utilizadores de DEX. O custo manifesta-se como uma pior execução em cada troca que toca numa mem pool pública com slippage não trivial.

Os tokens e pools mais afetados partilham três características. São voláteis, pelo que movimentos de preço de vários percentuais dentro de um único bloco são comuns. Têm liquidez reduzida, pelo que uma transação de tamanho moderado produz um impacto significativo no preço. Atraem compradores impacientes, pelo que as tolerâncias de slippage são definidas suficientemente altas para absorver um sandwich. As memecoins cumprem estes três critérios, e é por isso que a economia do sandwich é mais visível nos lançamentos de novos tokens.

Porque é que 49% de slippage é uma assinatura para um esquema, não uma definição

Quando um frontend de DEX lhe pede para aumentar o slippage acima de cerca de 5% e, em especial, na direção dos 20%, 30% ou 49%, esse pedido está a fazer uma de duas coisas. Ou o pool é tão fino que a sua transação reverteria de outra forma, caso em que provavelmente não deveria estar a negociar com esse tamanho, ou o token tem uma restrição de venda no seu contrato que faz com que trocas honestas falhem.

Tokens honeypot codificam uma regra como "transferências a partir deste contrato estão desativadas" ou "vendas são taxadas a 100%". Pode comprar. Não pode vender, ou vender devolve apenas uma pequena fração. Para que a sua compra chegue antes das restrições, o frontend sugere um slippage elevado. Depois de comprar, os seus tokens ficam ilíquidos. O deployer drena o lado ETH do pool, e fica na posse de um token do qual não consegue sair.

Mesmo num token que não é um esquema, aumentar o slippage para 49% num pool fino dá efetivamente à mem pool um cheque em branco. Um searcher pode mover o preço em 30% no bloco, executar a sua transação ao pior preço permitido e ficar com a diferença. Não precisa de um contrato malicioso para este resultado; só precisa de uma mem pool pública e de um bot agressivo. O slippage que define é o limite máximo do que podem retirar.

A regra prática é que slippage acima de cerca de 3% deve ser um sinal amarelo em qualquer token que não tenha verificado de forma independente. Slippage acima de 10% deve ser um sinal vermelho que exige que leia o contrato, verifique a concentração de detentores e confirme que as vendas não estão taxadas ou bloqueadas. Slippage a 49% deve ser um sinal de paragem. A transação é quase sempre pior do que abdicar dela.

Definições de slippage personalizadas vs automáticas

A maioria das wallets e frontends de DEX oferecem duas formas de definir o slippage. O slippage automático, por vezes chamado de dinâmico ou inteligente, utiliza um algoritmo para estimar o slippage mínimo necessário para a transação passar, com base no pool, no tamanho e na volatilidade recente. O slippage personalizado permite-lhe escrever um número, com 0,1%, 0,5% e 1% como predefinições comuns.

O slippage automático é conveniente e, geralmente, bem calibrado em pares principais. É também a origem do pedido de 49% em tokens honeypot, porque o algoritmo está a tentar fazer a sua transação ser bem-sucedida, não a protegê-lo de uma má transação. Em pares legítimos, o slippage dinâmico escolhe frequentemente 0,1% a 0,5%. Em tokens de cauda longa, pode subir para dois dígitos, porque o pool reverteria de outra forma em cada transação.

O slippage personalizado é a predefinição mais segura depois de perceber o que o número faz. Um bom conjunto inicial é 0,1% a 0,5% para pares principais como ETH e stablecoins, 0,5% a 1% para altcoins líquidas, e 1% a 2% para transações que está a fazer deliberadamente em ativos voláteis que pesquisou. Qualquer valor acima de 2% num token que não consegue justificar merece uma pausa e uma leitura do contrato.

Para transações maiores, pode também dividir a ordem. Duas trocas de metade do tamanho geralmente produzem menos impacto no preço e enfrentam menos oportunidades de sandwich do que uma troca com o tamanho total, porque cada transação individual cabe dentro de uma banda de slippage mais apertada. Dá mais trabalho, mas é o tipo de hábito que separa os swapper casuais dos operadores que dimensionam a sua exposição de forma deliberada.

Como pools de memória privados como o Flashbots Protect ajudam

Uma pool de memória privada é um canal separado entre a sua carteira e os construtores de blocos. Em vez de difundir a sua troca para a pool de memória pública, onde qualquer pesquisador pode vê-la, envia-a diretamente para um construtor que a inclui num bloco sem a expor à pool de memória aberta. O Flashbots Protect é o exemplo mais utilizado na Ethereum, e existem serviços semelhantes noutras cadeias.

Quando a sua transação não aparece na pool de memória pública, os bots de sandwich não a conseguem ver a tempo de inserir operações à volta dela. A execução que obtém está mais próxima do preço que lhe foi indicado, e pode definir um slippage mais apertado sem correr o risco de reversões causadas por reordenação adversária. Para utilizadores que fazem trocas frequentemente na mainnet da Ethereum, encaminhar através de uma pool de memória privada é uma das atualizações de segurança com maior impacto disponíveis.

Existem compromissos. As pools de memória privadas não são gratuitas; o construtor fica com uma pequena comissão, e nem todas as carteiras as suportam. Algumas pools privadas têm um modelo de confiança diferente do da pool de memória pública, uma vez que está a confiar que o construtor não fará frontrunning. Na prática, os principais serviços do tipo Flashbots são operados por equipas reputadas e auditados, mas o pressuposto de confiança é real e vale a pena compreendê-lo.

Nem todas as cadeias têm uma pool de memória privada madura. Em redes Layer 2 e Layer 1s alternativas, a dinâmica da pool de memória difere. Algumas L2s sequenciam transações através de um sequenciador centralizado, o que altera o modelo de ameaça. Outras têm tempos de bloco muito curtos, o que reduz, mas não elimina, oportunidades de sandwich. O princípio é o mesmo, no entanto: se a sua operação estiver visível antes de ser confirmada, alguém pode lucrar com essa visibilidade.

Como definir a tolerância de slippage de forma inteligente

O slippage é uma permissão, um orçamento e uma defesa, tudo codificado num único número. O valor predefinido de 0,5% é um ponto de partida sensato em pares líquidos. Em tokens voláteis, ilíquidos ou não verificados, o slippage adequado depende do que sabe sobre o contrato, a pool e a rota. Um modelo mental útil é: mais apertado é mais seguro, mais largo é mais arriscado, e o número é o pior caso que está a aceitar por escrito.

Antes de qualquer troca, especialmente num token que nunca negociou, verifique três coisas. O contrato num explorador de blocos quanto a restrições de venda, impostos de transferência e privilégios do proprietário. A profundidade da pool e o volume de 24 horas para estimar o impacto no preço no tamanho da sua operação. A distribuição de detentores para ver se algumas carteiras podem despejar tokens de imediato após a sua compra. Se algum destes for desfavorável, o seu slippage deve ser suficientemente apertado para fazer a transação reverter em vez de ser executada de forma desfavorável.

Para utilizadores que trocam na mainnet da Ethereum regularmente, ativar uma pool de memória privada como o Flashbots Protect e encaminhar operações através dela é uma das formas mais eficazes de reduzir a exposição a sandwich. Combinado com definições de slippage disciplinadas, esta abordagem recupera uma parte significativa da qualidade de execução que, de outra forma, seria perdida para MEV.

Acompanhe exploits de slippage e ameaças da pool de memória com o sinal certo

As notícias sobre tolerância de slippage movem-se depressa, tal como os ataques construídos à volta disso. Bots de sandwich, contratos honeypot e alterações de encaminhamento na pool de memória são sinais que importam para qualquer pessoa que negoceie on-chain, e acompanhá-los manualmente em dezenas de tokens e cadeias é uma batalha perdida. A Zippfeed apresenta notícias de cripto com pontuação de sentimento (bullish, neutral ou bearish) e uma classificação de importância, para que possa identificar os avisos que realmente importam antes de clicar em confirmar na próxima troca.