Saltar para o conteúdo principal

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.

Esta página foi traduzida automaticamente por IA. A versão em inglês é a fonte oficial.Ver versão em inglês →

​
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: 
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 parTolerâ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 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: 
// 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

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