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 →
Esta página é o único diagrama de arquitetura canônico da documentação. Todos os outros capítulos fazem referência a ela em vez de redesenhar o sistema. Os IDs dos programas não estão incorporados nesta página — eles vivem em reference/program-addresses para que possam ser atualizados em exatamente um lugar.

​
O que Raydium realmente é

Raydium não é um programa. É um conjunto de programas Solana on-chain independentes que compartilham uma superfície off-chain comum (REST API, SDK TypeScript, registro IDL) e algumas convenções (PDAs de autoridade, contas de configuração de taxas, multisig de administrador). Uma interação do usuário — um swap, um depósito, uma colheita de farm — é roteada para exatamente um desses programas; a superfície off-chain é o que os faz parecer um único produto. A pegada on-chain se agrupa em quatro tipos de programas:
  1. Programas AMM — quatro programas de pool separados, cada um com seu próprio formato e matemática de preço:
    • AMM v4 — o AMM de produto constante original. Originalmente um design híbrido que espelhava a curva em um mercado OpenBook (anteriormente Serum); a integração OpenBook foi posteriormente desativada e os pools agora operam como AMMs puros contra a curva. Ainda o local mais profundo para muitos pares principais.
    • CPMM — um AMM de produto constante simples (x · y = k) construído nativamente no Solana, com suporte de primeira classe para Token-2022. O programa recomendado para novos pools de produto constante.
    • CLMM — um AMM de liquidez concentrada no estilo Uniswap v3. A liquidez é fornecida em faixas de preço; as taxas se acumulam por posição; o estado é organizado em torno de ticks e um sqrt_price_x64.
    • Stable AMM — um programa StableSwap de liquidez fina (bifurcado do AMM v4 com uma curva de preço de tabela de consulta) que o roteador usa para pares correlacionados de stablecoin. Não é exposto como uma opção de criar pool de primeira classe na UI hoje.
  2. Distribuição de recompensas — Farm (v3 / v5 / v6, com v6 como a geração ativa; v3/v5 são apenas encerramento).
  3. Lançamento de token — LaunchLab, um programa de curva de ligação. Os lançamentos recém-inicializados se formam em CPMM. A instrução de migração legada do AMM v4 permanece para o estado de lançamento existente.
  4. Primitivos de liquidez — AMM Routing (o roteador multi-pool on-chain que faz CPI nos quatro programas AMM em uma única transação) e LP-Lock / Burn & Earn (bloqueia posições LP mantendo reivindicações de taxas abertas).
Tudo mais na pilha — as REST APIs, a Transaction API, o SDK TypeScript, a UI — é infraestrutura off-chain que compõe esses programas no topo do Solana e SPL Token / Token-2022. A superfície Perps é uma integração separada no topo da Orderly Network e não é um programa Raydium on-chain; é excluída deste diagrama.

​
Diagrama canônico

Invariantes-chave que este diagrama captura:
  • Programas AMM são pares. CPMM não chama CLMM; CLMM não chama AMM v4; Stable AMM é seu próprio programa. Um swap direto em um pool toca exatamente um programa AMM. O único programa que compõe múltiplos AMMs em uma única transação é AMM Routing, que faz CPI em AMM v4 / CPMM / CLMM / Stable AMM conforme necessário quando uma rota cruza tipos de pool.
  • O SDK e a Transaction API são camadas de composição, não programas. Quando a web UI ou um agregador constrói uma transação “swap através de três pools”, o SDK (lado do cliente) ou a Transaction API (lado do servidor) costura as instruções usando cotações obtidas da REST API. A cadeia vê uma única transação Solana com N instruções — nenhum programa orquestrador possui o fluxo inteiro.
  • A fiação OpenBook do AMM v4 é inerte. AMM v4 foi o único AMM jamais vinculado ao OpenBook, mas a integração foi desativada — os pools não compartilham mais liquidez com OpenBook, MonitorStep não é mais acionado, e uma interrupção do OpenBook não tem impacto no tráfego de swap atual. As contas de mercado permanecem no AmmInfo do pool para compatibilidade com versões anteriores, mas fazem referência a estado não utilizado. CPMM, CLMM e Stable AMM nunca tiveram uma dependência CLOB.
  • Novos pools LaunchLab se formam em CPMM. A inicialização agora requer migrate_type = CPSWAP. MigrateToAmm permanece para estado legado existente. Antes da atualização de 2026-08-17, a migração CPMM bloqueava creator_scale separadamente para o criador. As migrações executadas depois combinam com platform_scale em uma posição LP bloqueada de propriedade da plataforma. As Fee Keys anteriores permanecem inalteradas.
  • LP-Lock é um wrapper, não um quinto AMM. Ele mantém posições LP em nome dos criadores sob uma PDA para que as taxas subjacentes ainda possam ser reivindicadas sem expor a capacidade de retirar liquidez. Ele compõe sobre pools CPMM e CLMM.
  • Superfícies off-chain se complementam. A REST API é somente leitura com cache; a Transaction API constrói transações prontas para assinar no lado do servidor; o SDK as constrói no lado do cliente. Todos os três dependem do mesmo registro IDL como fonte de verdade do esquema.

​
Fluxo de dados: um swap CPMM, end to end

Para tornar a imagem concreta, aqui está o que acontece quando um usuário faz swap USDC → RAY em um pool CPMM a partir da UI do Raydium. (AMM v4 e CLMM diferem nas contas que precisam, não na forma de alto nível.)
  1. Solicitação de cotação (off-chain). A UI chama GET https://api-v3.raydium.io/compute/swap-base-in com o mint de entrada, mint de saída, quantidade e tolerância de slippage. A API consulta seu indexador, escolhe uma rota (possivelmente através de múltiplos pools) e retorna uma cotação mais a lista de IDs de programa, IDs de pool e contas de taxa que o cliente precisará.
  2. Construção de transação (cliente + SDK). O cliente passa a cotação para raydium-sdk-v2. O SDK resolve cada PDA que precisa (PDA de autoridade, estado do pool, observação, vaults — veja products/cpmm/accounts), injeta as contas de token associadas do usuário (criando-as com o Associated Token Program se faltarem) e emite uma Transaction não assinada.
  3. Assinatura da carteira. A carteira do usuário assina a transação. Nada específico do Raydium aqui; este é o fluxo padrão de carteira Solana.
  4. Execução on-chain. A transação assinada atinge o programa CPMM do Raydium, que (a) valida o estado do pool, (b) aplica a curva de produto constante com a configuração de taxa do pool, (c) move tokens entre os ATAs do usuário e os vaults do pool via CPI em SPL Token / Token-2022, (d) atualiza a conta observation para o TWAP e (e) retorna.
  5. Ingestão do indexador. O RPC Solana alguns slots depois expõe os logs do programa. O indexador do Raydium os analisa, atualiza as reservas do pool, volume de 24h e APR, e serve os valores atualizados para a próxima solicitação /pools/info/ids.
Todos os quatro passos 2–4 acontecem dentro de uma única transação Solana. A API está envolvida apenas no passo 1 (cotação) e passo 5 (indexação para a próxima vez). Se a API estiver inativa, um cliente com um SDK ativo e um RPC Solana ainda pode fazer transações — ele apenas precisa calcular a rota por si mesmo.

​
Infraestrutura compartilhada

Vários primitivos são usados por cada produto e valem a pena nomear uma vez para que capítulos posteriores possam se referir a eles sem redefinição. Os detalhes vivem em protocol-overview/shared-infrastructure; este é o índice.

​
Superfície off-chain: API vs SDK vs IDL

Estes três são frequentemente confundidos. Eles fazem coisas diferentes:
  • REST API (api-v3.raydium.io) é uma visualização principalmente de leitura e em cache do estado on-chain mais o mecanismo de cotação. Ela diz quais pools existem, quais são suas reservas, como os APRs parecem e qual é a melhor rota para um swap. Ela não constrói transações.
  • SDK TypeScript (@raydium-io/raydium-sdk-v2) é um construtor de transações. Ele conhece o layout de conta e formato de instrução de cada programa. Ele busca estado fresco de um RPC (não da API) antes de compor uma instrução, para que possa assinar transações precisas. Ele fala com a API apenas quando precisa de uma cotação.
  • Registro IDL é o esquema do qual ambos acima dependem. Se você está escrevendo CPIs Rust em um programa Raydium, o IDL é o contrato; se você está escrevendo uma integração TS, você está usando IDLs indiretamente através do SDK.

​
Onde cada capítulo se encaixa

O diagrama acima recorre — em forma reduzida — em toda a documentação. Aqui está onde o tratamento completo de cada peça vive para que você possa detalhar:
  • Programas on-chain: um capítulo por produto sob products/. Cada capítulo segue o mesmo modelo (visão geral → contas → matemática → instruções → taxas → demos de código).
  • Primitivos compartilhados entre programas: protocol-overview/shared-infrastructure e algorithms/ para a matemática que recorre (produto constante, liquidez concentrada, preço de curva).
  • Superfície off-chain: sdk-api/ tem a referência completa do SDK e REST API, mais sdk-api/anchor-idl e sdk-api/rust-cpi.
  • Fluxos de nível de usuário (criar um pool, swap, LP, reivindicar recompensas, lançar um token): user-flows/.
  • Padrões de integração para outras equipes (agregadores, carteiras, bots): integration-guides/.
  • Superfície de segurança, chaves de administrador, riscos conhecidos, auditorias: security/.
  • Mudanças versionadas e a história de migração AMM v4 → CPMM / Farm v3 → v6: protocol-overview/versions-and-migration.

​
Não-objetivos deste diagrama

Algumas omissões deliberadas, para que ninguém leia mais do que há:
  • Sem oráculos de preço. Raydium não depende de Pyth, Switchboard ou qualquer oráculo externo para seu preço AMM central. As cotações vêm das reservas on-chain. A conta observation existe para que outros contratos possam ler um TWAP Raydium — o próprio Raydium não precisa dela.
  • Sem programa de votação de token on-chain. Ações de administrador, como atualizações de configuração de taxa e upgrades de programa, são executadas por um multisig. As chaves multisig e política de rotação estão em security/admin-and-multisig.
  • Sem pontes. Raydium é nativo do Solana. Fluxos entre cadeias são problema do integrador e vivem fora deste diagrama.
Fontes: