> ## Documentation Index
> Fetch the complete documentation index at: https://docs.raydium.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Slippage e price impact

> Definições precisas de slippage vs price impact, como o SDK da Raydium calcula minAmountOut e maxAmountIn, diferenças entre tipos de AMM e considerações de MEV para roteamento em produção.

<Info>
  **Esta página foi traduzida automaticamente por IA. A versão em inglês é a fonte oficial.**

  [Ver versão em inglês →](/algorithms/slippage-and-price-impact)
</Info>

## Dois conceitos distintos

**Price impact** e **slippage** são frequentemente confundidos em UIs, mas referem-se a coisas diferentes.

* **Price impact** é uma propriedade determinística de uma transação contra um estado específico do pool. Dado `(Δin, reserves)`, o price impact é completamente computável antes da transação ser submetida.

* **Slippage** é a diferença realizada entre o preço que você *esperava* no momento da cotação e o preço que você *realmente obteve* no momento da execução. É uma função de latência, transações concorrentes e ordem de inclusão de blocos — não da matemática do pool.

Uma cotação de 1% contra um pool caso contrário inativo tem 0% de slippage se chegar no próximo bloco; o 1% foi o price impact. Essa mesma cotação resulta 0.2% pior se outra transação atingir o pool primeiro — os 0.2% extras são slippage.

## Definições formais

### Price impact

```
p_before = pool.spot_price()
p_after  = pool.spot_price_if_trade(Δin) applied
impact   = (p_before − p_after) / p_before       // pode ter sinal
```

Para um CPMM: `impact ≈ 2 · Δin / reserve_in` para transações pequenas. Para CLMM: depende de quantos ticks a transação atravessa; frequentemente plano dentro do intervalo de tick atual, saltando em cada cruzamento de tick.

### Slippage realizado

```
quoted_out = amount_out computado no momento da cotação
actual_out = amount_out observado on-chain
slippage   = (quoted_out − actual_out) / quoted_out
```

Slippage é sempre não-negativo (ou zero), assumindo que a cotação foi honesta. Um valor negativo significaria que você recebeu *mais* do que cotado — possível se o estado do pool se moveu a seu favor entre cotação e execução.

## Dimensionando `minAmountOut` e `maxAmountIn`

Toda swap da Raydium tem um limite de proteção contra slippage:

* `SwapBaseInput(amount_in, min_amount_out)` — entrada exata, limita inferiormente a saída.
* `SwapBaseOutput(max_amount_in, amount_out)` — saída exata, limita superiormente a entrada.

O SDK calcula esses valores como:

```ts theme={null}
const computed = raydium.<pool_type>.computeAmountOut({
  poolInfo,
  amountIn,
  mintIn,
  mintOut,
  slippage: 0.005,     // 0.5% de tolerância
});

// computed.amountOut         — a cotação "esperada"
// computed.minAmountOut      — amountOut × (1 − slippage), usado como limite on-chain
// computed.priceImpact       — determinístico, apenas estado do pool
// computed.fee               — taxa total cobrada (todos os componentes somados)
```

A tolerância de slippage é um **buffer ao redor do price impact**, não o price impact em si. Uma tolerância de 0.5% significa "aceitar no máximo 0.5% pior que minha cotação" — independentemente de o price impact ter sido 0.01% (uma transação pequena) ou 2% (uma transação grande). Para uma transação com price impact de 2% e tolerância de 0.5%, `minAmountOut` fica `2.5%` abaixo do spot pré-transação — essencialmente a soma do impacto e tolerância.

## Tolerâncias de slippage recomendadas

Não existe um número único correto; o limite correto depende de:

1. **Estabilidade do par.** Pools stablecoin-stablecoin podem usar com segurança 0.1%. Pools de pares meme voláteis frequentemente precisam de 3–5% apenas para aterrissar com confiabilidade.
2. **Tamanho da transação.** Transações maiores têm price impacts maiores, então a tolerância precisa escalar com eles para evitar reversão. O padrão de auto-slippage do SDK é em torno de `max(0.5%, 2 × price_impact)` por esse motivo.
3. **Latência de inclusão de bloco.** Transações que ficam no mempool por múltiplos blocos são expostas a mais transações concorrentes. Jito bundles e priority fees reduzem isso.

Regras práticas (padrões da UI da Raydium):

| Tipo de par                               | Tolerância padrão |
| ----------------------------------------- | ----------------- |
| Stable-stable (USDC-USDT, USDC-USDS)      | 0.1%              |
| Stable-major (USDC-SOL, USDC-BTC)         | 0.5%              |
| Major-major (SOL-BTC, SOL-ETH)            | 1%                |
| Volátil (meme tokens, long-tail ilíquido) | 3–5%              |

## Diferenças entre tipos de AMM

### CPMM

Price impact é suave e contínuo (forma fechada `2 · Δin / reserve_in`). A tolerância de slippage escala linearmente com o tamanho da transação.

### AMM v4

Mesma matemática de curva que CPMM, mas as "reserves efetivas" incluem as ordens limitadas postadas pelo OpenBook do pool. Na prática, isso significa:

* Cotar apenas os saldos brutos do vault *subestima* reserves e portanto *superestima* impact.
* O SDK busca `AmmInfo` e soma `vault + on_book.free + on_book.locked` para obter o número correto.
* Estado obsoleto do OpenBook (crank bloqueado) pode causar divergência entre o impacto cotado e a realidade on-chain. Agregadores rotineiramente fazem pré-crank (permissionless `MonitorStep`) antes de uma transação AMM-v4 grande.

### CLMM

Price impact é **por partes**. Dentro do intervalo de tick atual, o impacto é aproximadamente linear em `Δin / L`. Cruzar um limite de tick pode mudar `L` discretamente, causando um salto repentino no preço marginal. Uma transação que atravessa vários ticks pouco populados pode ter impacto muito maior do que a regra `2 · Δin / reserve` sugere.

A cotação CLMM do SDK itera o passo de swap deterministicamente para retornar um `amountOut` esperado exato, então `minAmountOut = amountOut · (1 − slippage)` está correto. Mas o valor de retorno **priceImpact** deve ser interpretado como "o spread entre o spot pré-transação e o spot pós-transação", que em CLMM pode ser muito maior que o slippage efetivo da transação para um usuário que se importa apenas com `amount_out`.

### Curva LaunchLab

Similar a CPMM mas com uma curva assimétrica (quadrática ou virtual-reserves). O impacto cresce mais rápido para compradores tardios conforme a curva se torna mais íngreme em direção à graduação. UIs de pré-comprador devem avisar quando uma compra é esperada empurrar a curva mais de \~5% do `quote_reserve_target` em uma transação.

## Considerações de MEV

Em Solana, a extração de MEV contra swaps principalmente toma a forma de **sandwich attacks**: um bot coloca uma transação back-run que troca após a sua, mais um front-run que troca antes, ambos no mesmo slot. Sua transação é preenchida a um preço pior do que teria sido sem o sandwich; o back-run captura a diferença.

Mitigações:

1. **`minAmountOut` apertado.** Limites de slippage agressivos causam reversão da transação vítima se sandwichada pesadamente, protegendo fundos (mas desperdiçando gás). Em Solana isso é prática padrão — rejeição é barata.
2. **Jito bundles.** Submeter via Jito com uma dica agrupada exclui intermediários de reordenar sua tx. Bundles aterram como blocos atômicos.
3. **Priority fees.** Uma priority fee alta aumenta a chance de sua transação aterrar no bloco do líder atual antes que um sandwicher possa reagir. Menos robusto que bundles, mais padrão.
4. **RPC privado.** Submeter via uma RPC privada (ou via endpoint direto de um validador) reduz a janela durante a qual um sandwicher de mempool pode observar sua transação.

O SDK da Raydium não faz bundle; integradores tipicamente colocam Jito em cima. Veja [`integration-guides/routing-and-mev`](/pt/integration-guides/routing-and-mev) para padrões.

## Slippage para rotas multi-hop

Quando uma swap roteia através de múltiplos pools (ex. `USDC → SOL → RAY`), a tolerância de slippage deve ser aplicada por-hop, não apenas end-to-end:

```ts theme={null}
// Ruim: 0.5% aplicado apenas no final, então qualquer hop intermediário deslizando falha no segundo hop.
const finalMin = finalAmount * (1 - 0.005);

// Melhor: cada hop aplica seu próprio limite.
const hop1Min  = hop1Amount * (1 - 0.005);
const hop2Min  = hop2Amount * (1 - 0.005);
// End-to-end isso é mais apertado (composto), mas atômico — se qualquer hop degradar, a tx reverte cedo.
```

O router do SDK aplica limites por-hop automaticamente quando você chama `raydium.trade.swap`. Para roteadores customizados, replique o padrão.

## Reportando aos usuários

Regras práticas para uma boa UI de swap:

* Exiba **ambos** price impact esperado e tolerância de slippage separadamente.
* Destaque quando price impact excede \~2% — aviso "impacto alto".
* Destaque quando price impact excede tolerância — a transação quase certamente reverterá.
* Para pares voláteis, ofereça um "modo slippage alto" que relaxa o limite e mostra um aviso mais forte.

## Referências

* [`products/cpmm/math`](/pt/products/cpmm/math), [`products/amm-v4/math`](/pt/products/amm-v4/math), [`products/clmm/math`](/pt/products/clmm/math) — derivações de impact por tipo de pool.
* [`integration-guides/routing-and-mev`](/pt/integration-guides/routing-and-mev) — roteamento multi-hop + defesas de MEV.
* [`integration-guides/priority-fee-tuning`](/pt/integration-guides/priority-fee-tuning) — dimensionando priority fees para reduzir slippage.

Fontes:

* Implementação de slippage / impact do SDK Raydium v2.
* Flashbots / Jito em MEV no Solana.