﻿---
title: "Prazo, slippage e calldata de swap: o que verificar antes de assinar"
description: "Aprenda a decodificar uma chamada de swap em DEX e verificar roteador, função, limites de valor, rota, destinatário e prazo antes de assinar."
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Prazo, slippage e calldata de swap: o que verificar antes de assinar

> Apenas para fins educacionais; não constitui aconselhamento nem recomendação de investimento. Investimentos podem causar perdas.

<a id="answer"></a>

## Resposta direta

Antes de assinar um swap em uma DEX, verifique a rede, o contrato de destino, a função decodificada, os endereços dos tokens, o limite de entrada ou saída, a rota, o destinatário e qualquer prazo. O percentual exibido como “slippage” pela interface não é uma instrução on-chain. Ele costuma ser usado para calcular um limite como `amountOutMin` ou `amountOutMinimum` em um swap exact-input, ou `amountInMax` ou `amountInMaximum` em um exact-output.

O prazo é uma proteção temporal, não uma garantia de preço. Se o roteador verificar o prazo e a transação executar depois dele, a chamada deve reverter. Antes do prazo, ela ainda pode executar por qualquer preço permitido pelo limite de valor. Um prazo longo mantém a autorização utilizável por mais tempo; um prazo curto demais aumenta a chance de expirar antes da inclusão.

Calldata não descreve a si própria. Decodifique-a com a ABI verificada do contrato exato na rede escolhida, inclusive qualquer multicall ou comando do Universal Router aninhado. Se a carteira não mostrar campos decodificados confiáveis, não deduza o significado apenas pela posição dos bytes ou por uma base de nomes de funções.

<a id="mechanism"></a>

## Como funciona

### Decodifique a chamada real

Na ABI do Solidity, os primeiros `4 bytes` da calldata são o seletor da função e os argumentos codificados começam no quinto byte. O seletor pode colidir ou ser rotulado incorretamente, então compare-o com a ABI do contrato de destino verificado. Um proxy, agregador ou roteador pode envolver o swap em `multicall`, `execute` ou outra função; decodifique toda carga aninhada capaz de transferir tokens ou alterar o destinatário final.

Em um swap exact-input, a entrada é fixa e o campo de proteção define a saída mínima aceitável. Em um exact-output, a saída desejada é fixa e o campo de proteção limita a entrada. Um limite zero ou inesperadamente frouxo pode eliminar a proteção de preço significativa. As casas decimais importam: associe cada endereço ao número correto de decimais e ao símbolo antes de comparar valores inteiros brutos.

### Verifique rota, destinatário e value

Confirme que a rota começa com o token gasto e termina com o token esperado. Examine tokens intermediários, taxas dos pools e comandos que envolvam, desembrulhem, recolham ou transfiram saldos. O destinatário deve ser a carteira pretendida ou um contrato cujo comportamento seja compreendido. Confira também o `value` nativo da transação; ele pode ser separado dos valores ERC-20 codificados na calldata.

### Localize o prazo

A posição do prazo depende da versão do roteador. Funções de roteadores no estilo Uniswap V2 incluem o argumento `deadline`, e as estruturas originais do `ISwapRouter` da Uniswap V3 também. O Universal Router expõe `execute(commands, inputs, deadline)` e uma sobrecarga sem prazo. Portanto, não presuma que todo swap tenha prazo nem que ele apareça dentro dos mesmos parâmetros aninhados.

Normalmente, o prazo é comparado com o timestamp do bloco usado na execução. Ele não cancela uma transação pendente, não garante inclusão rápida e não protege contra preço desfavorável dentro do limite. Para cancelar, o remetente precisa usar o mecanismo de substituição de transação da rede e da carteira; a substituição não é garantida depois que a original é incluída.

<a id="example"></a>

## Exemplo completo

Uma cotação prevê `10,000 USDC` em um swap exact-input, e o usuário escolhe `1%` de slippage. Desconsiderando taxas já incluídas na cotação, o mínimo esperado é `9,900 USDC`. Como o USDC usa `6 decimals`, o inteiro bruto desse limite é `9900000000`.

A chamada decodificada contém `amountOutMinimum = 9000000000`, ou `9,000 USDC`. Isso permite receber até `10%` menos que a cotação, não `1%`. O destinatário também é um endereço desconhecido e o prazo está muitas horas adiante. Qualquer uma dessas divergências basta para rejeitar a solicitação e reconstruí-la em uma interface confiável. Depois, simule a transação exata ainda não assinada sobre um estado recente e confira novamente a carga decodificada antes de assinar.

<a id="risks"></a>

## Lista de verificação e riscos

- Compare a rede escolhida e o endereço do roteador ou proxy com os registros oficiais de implantação do protocolo.
- Decodifique com a ABI do contrato verificado; expanda chamadas aninhadas e comandos do roteador em vez de analisar apenas a função externa.
- Confira endereços, direção, decimais, valor fixo, limite protetor, rota, faixas de taxa, destinatário e `value` nativo.
- Converta o prazo em horário absoluto e decida se a janela restante é intencional. Trate a ausência de prazo como uma escolha de projeto que exige análise separada.
- Simule a transação exata a partir do endereço assinante contra um estado recente. O sucesso é evidência apenas para esse estado, não garantia de inclusão ou execução final.
- Analise aprovações ou permissões Permit2 separadamente. Bons limites de swap não tornam segura uma autorização ilimitada ou maliciosa de tokens.
- Limites apertados podem reverter com movimentos normais; limites frouxos aumentam o risco de preço de execução e de ataque sanduíche. Uma transação on-chain revertida ainda pode consumir gas.

<a id="misconceptions"></a>

## Equívocos comuns

### Mito: o percentual de slippage exibido é assinado

Em geral, a carga assinada contém limites derivados desse ajuste. Verifique os inteiros reais e os decimais do token; um rótulo correto na interface não prova que a calldata use a mesma tolerância.

### Mito: todo swap usa `amountOutMin` e `deadline`

Nomes e posições variam por roteador e função. Swaps exact-output protegem o lado da entrada, e alguns pontos de entrada omitem o prazo ou o colocam na chamada externa.

### Mito: o prazo impede um preço ruim

Ele só limita quando a execução é permitida se o código chamado o aplicar. A proteção de preço vem do limite de valor, que ainda permite toda execução dentro dele.

### Mito: basta decodificar a função externa

Agregadores e roteadores universais podem conter várias chamadas, permissões de tokens, transferências e comandos de limpeza. O destinatário ou valor relevante à segurança pode estar em uma carga aninhada.

<a id="related"></a>

## Tópicos relacionados

- [Decodificação de calldata na carteira](/pt-br/crypto/calldata-decoding-wallet/)
- [Lista de slippage e rota em DEX](/pt-br/crypto/dex-slippage-route-checklist/)
- [Ataque sanduíche](/pt-br/crypto/sandwich-attack/)
- [Slippage em negociação de criptoativos](/pt-br/crypto/slippage-crypto/)
- [Simulação de transação](/pt-br/crypto/transaction-simulation/)

<a id="sources"></a>

## Fontes

- [Contract ABI Specification](https://docs.soliditylang.org/en/latest/abi-spec.html) - Solidity Documentation (acesso: 2026-08-21)
- [IUniswapV2Router01.sol](https://github.com/Uniswap/v2-periphery/blob/master/contracts/interfaces/IUniswapV2Router01.sol) - Uniswap (acesso: 2026-08-21)
- [ISwapRouter.sol](https://github.com/Uniswap/v3-periphery/blob/main/contracts/interfaces/ISwapRouter.sol) - Uniswap (acesso: 2026-08-21)
- [Universal Router Commands](https://developers.uniswap.org/docs/protocols/universal-router/concepts/commands) - Uniswap (acesso: 2026-08-21)

Source: https://wiki.fcontext.com/pt-br/crypto/swap-deadline-slippage-calldata/index.mdx
