> ## 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.

# Visão geral do Routing

> O que o programa AMM Routing faz, por que existe como um programa separado e quando usá-lo em vez de stitching de instruções no cliente.

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

  [Ver versão em inglês →](/products/routing/overview)
</Info>

## Resumo em um parágrafo

O programa AMM Routing agrupa swaps multi-hop em uma única transação on-chain que encadeia liquidez entre pools. Você fornece uma rota (uma lista de pools e mints intermediários) e uma instrução com parâmetros de slippage; o router executa todos os N hops em ordem, movendo a saída de um pool para a entrada do próximo. Nenhuma lógica de router separada on-chain é necessária para o cálculo de preço — a taxa e a curva de cada hop são tratadas pelo próprio programa do pool via CPI — mas o router orquestra a passagem de contas e o movimento de tokens.

## Por que um programa router separado?

Clientes e agregadores Raydium sempre podem stitchar swaps multi-hop juntos no cliente sem usar o router: construir N instruções de swap (uma por pool) e enviá-las em uma única transação. Por que, então, ter um programa router dedicado?

### Razões para usar o router

1. **CPI de outros programas.** Se seu próprio programa precisa invocar uma rota como parte de uma transação maior (por exemplo, um gerenciador de liquidez que troca taxas por um token alvo), fazer CPI no router é mais limpo do que agrupar N CPIs filhos e gerenciar todas as suas contas em seu contrato.

2. **Estado de conta atômico.** A lista de contas de cada hop é validada em um contexto de instrução. Se o estado de um pool intermediário estiver corrompido ou uma asserção de limite de preço falhar, toda a rota falha atomicamente sem liquidação parcial.

3. **Composição de instrução única.** SDKs e frontends podem representar uma rota multi-hop como uma operação lógica única, não como N instruções separadas que acontecem estar consecutivas.

### Stitching no cliente ainda é o padrão

Para a maioria das aplicações, construir instruções `Swap` separadas para cada pool e enviá-las em ordem é mais simples, mais composável e igualmente válido. Os fluxos como `Trade.makeSwapTransaction` do SDK Raydium fazem exatamente isso para a maioria das rotas.

O router é uma alternativa, não um substituto. Use-o quando:

* Você está implementando um programa que precisa de roteamento como parte de uma operação atômica maior.
* Você está construindo um agregador que quer uma operação única de "envie esta rota".

## Como funciona

Uma instrução router carrega:

* **Argumentos de swap**: entrada exata (`amount_in`, `minimum_amount_out`) ou saída exata (`maximum_amount_in`, `amount_out`).
* **Especificação de rota**: uma lista de `program_id` + contas de programa-filho para cada hop, em ordem. O router lê a primeira conta em cada grupo de hop para determinar qual programa invocar.
* **Limites de preço** (para CLMM): um `VecDeque<u128>` de limites `sqrt_price_x64`. Usado apenas para hops em pools CLMM; uma deque vazia é um erro para variantes de instrução mais antigas.

O router então:

1. **Executa o primeiro hop:** transfere `amount_in` (ou calcula a entrada necessária para saída exata) para o vault de entrada do primeiro pool, invoca o swap desse pool e coleta a saída.
2. **Encadeia hops subsequentes:** para cada hop N, usa a saída do hop N−1 como entrada para o hop N.
3. **Aplica slippage:** em cada hop CLMM, verifica `sqrt_price` contra o `limit_price` correspondente; no hop final, verifica a saída total contra o `minimum_amount_out` global.

Tokens intermediários podem fluir através de **ATAs controlados pelo usuário** (um por hop, mais lento mas transparente) ou através de uma **conta derivada de PDA compartilhada** (um endereço para todos os hops, mais rápido, opaco).

## Delegação de preços e taxas

O router **não calcula preços em si**. Cada hop delega para a curva do programa filho:

* **AMM v4**: usa a fórmula de produto constante com preços híbridos OpenBook.
* **CPMM**: usa a fórmula de produto constante com a taxa configurada.
* **CLMM**: usa a matemática de liquidez concentrada com preços baseados em ticks.
* **Stable**: usa a curva stable-swap para tokens semelhantes.

Taxas são cobradas por cada pool de acordo com sua própria configuração. O router não cobra taxa própria.

## Quando evitar o router

* **Contagem baixa de hops (1–2 hops).** A sobrecarga de passagem de contas é mínima; apenas use duas instruções de swap separadas.
* **Pools não-Raydium.** O router só conhece os quatro tipos de pool Raydium. Para rotas que cruzam programas externos, faça stitching de instruções no seu cliente.
* **Roteamento condicional.** Se você precisar ramificar baseado em preços ou estados de pool no meio da rota, o roteamento on-chain é menos flexível que a composição no cliente.

## Modelo mental

Pense no router como um **utilitário de empacotamento de transações**. Ele pega sua especificação de rota e a empacota em uma instrução, uma transação, um orçamento de computação. Cada hop internamente faz CPI em seu programa de pool e trata a matemática da curva lá. O trabalho do router é passar contas corretamente, mover tokens entre hops e verificar slippage.

## Para onde ir a seguir

* [`products/routing/accounts`](/pt/products/routing/accounts) — o PDA de autoridade de rota e o padrão de conta compartilhada.
* [`products/routing/instructions`](/pt/products/routing/instructions) — a API completa de instruções (todas as 10 variantes).
* [`products/routing/code-demos`](/pt/products/routing/code-demos) — exemplos de construção de rotas em TypeScript e Rust puro.
* [`integration-guides/routing-and-mev`](/pt/integration-guides/routing-and-mev) — estratégia mais ampla para roteamento multi-hop.