Skip to main content
Esta página foi traduzida automaticamente por IA. A versão em inglês é a fonte oficial.Ver versão em inglês →
O trabalho de um agregador é oferecer ao usuário o melhor preço possível em muitos pools, possivelmente dividindo uma única entrada em múltiplas rotas de pool, e executá-lo atomicamente. Esta página documenta as partes específicas do Raydium nesse trabalho: descoberta, cotação e montagem de transação.

Descoberta

Inventário de pools

Você precisa da lista completa de pools Raydium ativos para cada produto. Três opções:
  1. REST API (mais simples): GET https://api-v3.raydium.io/pools/info/list?poolType=all&pageSize=1000&page=1 retorna pools em lotes de 1000. Pagine até ter todos. Cache por 1–5 minutos.
  2. Varredura on-chain: getProgramAccounts nos IDs de programa CPMM, CLMM e AMM v4, filtrado pelo discriminador de conta de estado. Produz ~cada pool ativo com ~10s de tempo de RPC. Útil quando a API está inativa ou limitada por taxa.
  3. Híbrido: use a API como fonte primária; execute uma varredura on-chain diária como verificação de sanidade. O time se compromete em manter a API abrangente, mas pools criados através de CPI direto (sem frontend) podem ocasionalmente ficar atrasados.

Busca de par de mints

Para um par específico (mintA, mintB), use GET /pools/info/mint?mint1=...&mint2=...&poolType=all&sort=liquidity. Retorna cada pool em qualquer nível de taxa e tipo de produto. Até ~10 resultados por par é comum em mints bem movimentados; ordene por TVL e pegue os principais para roteamento.

Cotação

A matemática de cotação difere por produto. Use as funções de matemática pura do SDK para não reimplementar:
Os três produtos não compartilham uma assinatura. computeAmountOut existe apenas em raydium.liquidity (AMM v4) e como PoolUtils.computeAmountOut(Format) para CLMM; o equivalente do CPMM é chamado computeSwapAmount e leva parâmetros diferentes. Escreva as três chamadas explicitamente em vez de parametrizar sobre o produto.
Para comparação de agregador use amountOut (pré-slippage) de cada um.

Atualização de cache

O estado do pool fica obsoleto rapidamente. Alvos de atualização recomendados: Para um agregador que toma cotações em latência interativa, inscreva-se em atualizações de conta WebSocket (accountSubscribe) em cada estado de pool relevante. Isso inverte o modelo de polling para push.

Ajustes Token-2022

Se qualquer mint na rota tiver uma taxa de transferência Token-2022, a matemática de cotação deve ajustar entradas e saídas por algorithms/token-2022-transfer-fees. O SDK lida com isso se poolInfo.mintA.extensions.transferFeeConfig for preenchido. Confirme olhando o campo .extensions antes de confiar na cotação.

Roteamento

Rotas de pool único

A maioria das rotas são de pool único. Escolha o pool cujo amountOut é mais alto. Se vários forem próximos, desempate por nível de taxa (menor é melhor), depois por TVL (mais é mais seguro).

Roteamento dividido

Para trades grandes onde um único pool tem >5% de impacto de preço, divida entre pools. Um algoritmo guloso simples:
Isso produz um vetor de roteamento [(pool_A, 0.6), (pool_B, 0.3), (pool_C, 0.1)] que minimiza o impacto agregado. Uma solução de otimização convexa adequada (por exemplo, igualar preços marginais entre pools) fica dentro de ~1% do resultado guloso na prática.

Rotas multi-hop

USDC → RAY → SOL via dois pools separados é comum quando nenhum pool direto USDC-SOL oferece uma boa cotação (raro). Aplique limites de slippage por hop; cada hop impõe seu próprio minAmountOut. Veja algorithms/slippage-and-price-impact. Multi-hop no mesmo pool (por exemplo, dois hops CLMM em SOL-USDC) é sempre subótimo vs um único hop — não gere tais rotas.

Montagem de transação

Single-hop, single-pool

Para um único pool, chame o construtor de swap do tipo de pool — raydium.liquidity.swap, raydium.cpmm.swap ou raydium.clmm.swap. raydium.tradeV2.swap é o executor de rota multi-hop e leva uma forma completamente diferente ({ swapInfo, swapPoolKeys, routeProgram, ownerInfo, txVersion }); não há raydium.trade.

Dividido e multi-hop

Componha ATAs + instruções manualmente. Padrão:
Tudo dentro de uma transação para atomicidade. Para uma divisão de 3 pools em V0 com tabelas de busca de endereço, isso normalmente cabe em ~1100 bytes. Para 4+ pools, o limite de tamanho de transação força multi-tx ou consolidação em um mint hub.

Atomicidade

Agregadores devem garantir atomicidade: ou a rota completa funciona ou nenhuma funciona. As instruções de swap do Raydium revertam em ExceededSlippage, então uma rota multi-pool onde um hop falha causa a transação inteira reverter. Grátis. A única exceção: se sua rota passa por Raydium + um DEX de terceiros, certifique-se de que esse DEX também tem um modelo de revert-on-slippage. Alguns programas ignoram limites de slippage (raro).

Armadilhas

1. Cotações obsoletas

Entre o usuário ver “Você recebe 125.43 RAY” e a transação pousar, as reservas podem mudar. Re-busque o estado do pool imediatamente antes da submissão; re-cotize; se a nova cotação for >1% pior, pause e re-confirme com o usuário.

2. Listas negras de pools

Alguns pools Raydium são tokens de scam com taxas de transferência definidas em 99% ou com extensões não transferíveis. A REST API marca estes (veja o campo tags); pule qualquer pool marcado como scam ou honeypot. Executar suas próprias verificações de segurança além das tags do Raydium é prudente.

3. Requisito de estado de observação em CLMM

CLMM SwapV2 leva uma conta observation_state. O SDK a popula para você; instruções construídas manualmente frequentemente esquecem, o que causa o programa reverter com AccountNotFound. Sempre inclua.

4. Tabelas de busca de endereço

Raydium mantém tabelas de busca públicas para suas contas mais usadas (mints principais, IDs de programa, AmmConfigs). Agregadores devem consumir estas — economiza ~100 bytes por transação e permite que rotas maiores caibam em V0. Puxando os endereços LUT:

5. Tratamento de congestionamento

Durante janelas de alto volume, transações podem ficar na mempool por múltiplos blocos. Retry agressivo em expiração de TX (não em revert — reverts são determinísticos) é recomendado. A opção sendAndConfirm do SDK faz retries básicos; agregadores de produção camada sua própria lógica (bundles Jito, broadcast multi-RPC) em cima.

Checklist

Antes de ir ao vivo, verifique:
  • Descoberta de pool cobre CPMM + CLMM + AMM v4 abrangentemente.
  • Cotações correspondem à cotação da própria UI do Raydium dentro de 1 ponto base em alguns trades de teste.
  • Roteamento dividido ativa para trades >5% impacto em qualquer pool único.
  • Taxas de prioridade são dimensionadas contra taxas recentes de programa de pool (veja integration-guides/priority-fee-tuning).
  • Taxas de transferência Token-2022 são computadas e exibidas ao usuário.
  • Transações revertam limpo quando slippage é excedido.
  • Lógica de retry distingue expiração de tx (retry) de revert (não retry).

Ponteiros

Fontes: