Versões e migração

​

Status em resumo

O aprendizado mais importante desta tabela: AMM v4 não está descontinuado, e CPMM é o novo padrão — mas coexistem deliberadamente. Os pools AMM v4 têm anos de histórico de negociação e não estão sendo migrados forçadamente. A escolha de qual programa usar para lançar um novo pool é uma recomendação, não uma restrição.

​

AMM v4 — status e trajetória

AMM v4 é o design original de pool Raydium: precificação de produto constante (x · y = k). Foi lançado como um AMM híbrido com integração de orderbook OpenBook (anteriormente Serum) que espelhava porções da curva como ordens limitadas em um mercado vinculado. A integração OpenBook foi posteriormente desativada — os pools não compartilham mais liquidez com OpenBook e todos os swaps executam puramente contra a curva via os entrypoints de swap V2. AMM v4 hoje é, na prática, um AMM de produto constante puro com as contas OpenBook preservadas como estado inerte.

​

O que está congelado

• Sem novos níveis de taxa. A estrutura de taxa AMM v4 é por pool e foi definida no deploy. Novos pools aceitam a mesma taxa de negociação codificada ~0,25%, ~12% para protocolo.
• Sem novo trabalho de features. O time não adicionou novas instruções ao AMM v4 desde que CPMM se tornou o novo padrão. O programa está em modo de administração — apenas correções de bugs, sem expansão de escopo.
• Sem suporte Token-2022. AMM v4 foi escrito antes de Token-2022 existir e a integração nunca foi retrofitada. Mints Token-2022 precisam usar CPMM (ou CLMM, quando apropriado).
• Integração OpenBook desativada. Cada pool AMM v4 ainda está vinculado a uma conta de mercado OpenBook correspondente on-chain, mas o pool não publica mais nem mantém ordens nesse mercado. Uma indisponibilidade OpenBook não afeta mais os swaps AMM v4.

​

O que ainda funciona

• Pools existentes negociam normalmente. Nenhuma migração de estado foi forçada; pools v4 criados em 2021 ainda são o local ativo para muitos pares de alto volume em 2026.
• LPs podem depositar, sacar e coletar recompensas de farm como de costume. A migração para CPMM é opcional.
• Agregadores ainda roteiam através dele. Jupiter e a API Raydium Trade ambos indexam pools v4 como venues de primeira classe.

​

Quando ainda usar AMM v4

Honestamente: raramente. Os casos em que v4 é a melhor resposta são estreitos:

• O par já tem um pool v4 profundo e bem negociado e você quer adicionar liquidez à profundidade existente em vez de dividir um mercado.

(Roteamento integrado OpenBook não é mais uma razão para escolher AMM v4 — essa integração está desligada.) Em todos os outros casos, lance novos pools em CPMM. Veja user-flows/choosing-a-pool-type para a árvore de decisão completa.

​

CPMM — curva de adoção e migração v4 → CPMM

CPMM (constant-product market maker, nome interno raydium-cp-swap) foi deployado em 2024 como uma reescrita em clean-room destinada a ser o novo padrão de pool de produto constante. É estruturalmente o mais simples dos programas Raydium: puro x · y = k, sem orderbook, suporte nativo Token-2022, footprint de transação menor.

​

O que CPMM oferece sobre AMM v4

• Melhor economia de LP por padrão. O AmmConfig padrão de CPMM roteia 100% das taxas de negociação para LPs (com a taxa de protocolo alternável por tier). AMM v4 codifica ~12% para protocolo.
• Custo de criação de pool menor. Sem mercado OpenBook necessário. A criação é uma transação, ~0,15 SOL de aluguel vs ~0,6 SOL para v4.
• Token-2022. Mints com taxa de transferência, mints com transfer-hook (com ressalvas), transferências confidenciais — todos suportados em CPMM, nenhum em v4.
• Superfície de integrador mais limpa. CPMM tem um crate publicado amigável para Anchor-CPI (raydium-cp-swap), uma lista de contas mais simples e um IDL estável. AMM v4 envia um IDL mas nunca teve um crate CPI Rust mantido.
• Lista de contas menor por swap. ~10 contas vs ~17 para v4 (que carrega as contas de mercado OpenBook mesmo quando não as acessa).

​

Quando a migração vale a pena

Para um pool ativamente negociado, o aumento de taxa de LP por si só geralmente justifica a migração em alguns meses. A aritmética: um pool ganhando 0,25% × $X de volume diário dá 0,03% para protocolo em v4 (os 12% faltantes). Em CPMM isso retorna aos LPs. Ao longo de um ano, isso se compõe significativamente. Para um pool de baixo volume, a migração é mais sobre à prova de futuro — melhores padrões, suporte Token-2022 se você precisar, integrações mais fáceis.

​

Como a migração funciona

Não há upgrade in-place. A migração é uma sequência criar-novo-pool, drenar-pool-antigo, reencher-novo-pool. O passo a passo completo está em user-flows/migrate-amm-v4-to-cpmm; a forma de alto nível:

1. Crie um novo pool CPMM para o mesmo par, no mesmo tier de taxa que você quer preservar.
2. Coordene LPs: anuncie uma janela durante a qual o pool antigo é drenado e o novo pool é semeado.
3. Cada LP saca do pool v4 e deposita no novo pool CPMM.
4. (Opcional) Configure um farm no lado CPMM para atrair LPs incentivados para o novo pool.
5. Observe o volume migrar conforme agregadores repesam em direção ao pool mais profundo.

A chain em si não força nada disso — a API e frontend Raydium simplesmente favorecem qualquer pool que seja mais profundo, e agregadores roteiam através de qualquer um que seja mais barato para o usuário.

​

CLMM — programa único, estável entre versões

CLMM está em sua primeira versão de programa. Não houve v2 — melhorias foram enviadas como upgrades in-place para o mesmo ID de programa (atrás do multisig com timelock de 24h), não como uma nova geração. Isso significa que não há história de migração CLMM: posições existentes permanecem onde estão, e o comportamento do programa pode mudar sutilmente quando um upgrade é enviado, mas os layouts de conta e PDAs são estáveis. O que mudou entre upgrades CLMM:

• Instrução SwapV2 adicionada para suportar corretamente a matemática de taxa de transferência Token-2022. O Swap antigo ainda é chamável; novas integrações devem visar SwapV2.
• Extensões de fluxo de recompensa — a contagem de slot RewardInfo foi aumentada (a original 3 → ainda 3 atualmente, mas o padrão de reserva foi apertado). Nenhuma migração de dados necessária.
• Compactação de tick-array — otimização interna para reduzir CU em swap-cruzando-muitos-ticks. Externamente invisível.
• Reconstrução Anchor 1.0 (2026-09-30): move de Anchor 0.32.1 para 1.0.2 e adiciona o admin CollectExcessLamports. Nenhuma instrução ou layout de conta voltado para o usuário mudou. Veja a entrada de changelog.

O IDL vive no repositório dedicado raydium-idl (veja sdk-api/anchor-idl). Se você está rodando um SDK mais antigo contra o programa atual, o pior caso é perder as novas instruções.

​

Farm v3 → v5 → v6

De todos os programas Raydium, Farm tem o histórico de versão mais explícito e o único caminho de migração forçada. As três gerações são programas separados com IDs de programa separados e layouts de estado separados.

​

Gerações

​

Por que três gerações existem

• v3 → v5: precisava de múltiplos fluxos de recompensa concorrentes (ex., farms de incentivo duplo). O design de fluxo único de v3 não podia suportar sem um redesign.
• v5 → v6: a taxa de emissão inteira u64 de v5 limita a taxa mínima expressável a “1 unidade de token por segundo.” Para um mint de 9 decimais, isso é 1 lamport/seg — muito grosseiro para programas de baixa emissão. A taxa fracionária Q64.64 de v6 corrige isso. v6 também levantou a atualização baseada em slot para relógio de parede e adicionou suporte Token-2022.

​

O que permanece igual entre gerações

• O padrão de contabilidade “depositar LP, acumular contador por-share, reivindicar no saque” é idêntico entre v3/v5/v6. A matemática não muda; apenas a precisão do contador de taxa e o número de fluxos suportados.
• UserStake (v3/v5) e UserLedger (v6) são conceitualmente o mesmo registro, com layouts diferentes. O SDK normaliza ambos.

​

Caminho de migração

Não há migração in-place entre versões de farm. Para mover de v3/v5 para v6:

1. Aguarde o fim das emissões da farm existente (ou as execute).
2. Stakers sacam e reivindicam recompensas pendentes na farm antiga.
3. O operador da farm cria uma nova farm v6 contra o mesmo mint de staking.
4. Stakers re-fazem stake na nova farm.

A realidade on-chain são duas contas de farm não relacionadas. Um usuário com stake em ambas tem dois registros UserLedger (v6) / UserStake (v5).

​

O que “encerramento” significa para v3 e v5

• Os programas v3 e v5 ainda estão deployados e chamáveis. Farms existentes ainda podem distribuir recompensas pendentes e aceitar saques.
• A UI Raydium ainda exibe farms v3 e v5 com recompensas ativas; uma vez que o end_time de uma farm v3/v5 passa, a UI a esconde de “ativa” mas a mantém reivindicável.
• O time não criará novas farms v3/v5. Helpers SDK para “criar farm” roteiam apenas para v6.
• v3 e v5 estão recebendo upgrades de segurança mas não trabalho de features. Se um bug crítico for encontrado, é corrigido; se uma feature pudesse ser útil, é adicionada a v6 em vez disso.

Detalhes completos por versão estão em products/farm-staking/accounts e products/farm-staking/instructions.

​

LaunchLab — programa único, config em evolução

LaunchLab está em sua primeira versão de programa. Como CLMM, melhorias são enviadas como upgrades in-place atrás do timelock de 24h — não como novas gerações. O que evoluiu através de upgrades:

• Slot de taxa do criador. Adicionado para que lançamentos possam rotear uma porção das taxas de negociação CPMM pós-graduação para o criador original. Veja products/launchlab/creator-fees.
• Configurabilidade de fórmula de curva. Originalmente codificada como quadrática; agora o LaunchConfig seleciona de um pequeno conjunto de formas de curva.

Lançamentos LaunchLab existentes não são afetados por upgrades — uma vez que um lançamento é inicializado, seus parâmetros são congelados até a graduação.

​

Compatibilidade de versão entre programas

Algumas notas de compatibilidade entre produtos que integradores rotineiramente encontram:

• CLMM SwapV2 não é a mesma instrução que Swap. Se seu cliente fala apenas Swap, ele silenciosamente manipulará mal as taxas de transferência Token-2022 — a matemática está errada pelo valor da taxa. Atualize para SwapV2.
• Farm v6 staking com posições CLMM não é suportado da forma que staking de token LP é. Posições CLMM são NFTs, não tokens LP fungíveis. CLMM tem seu próprio mecanismo de recompensa nativo em vez disso — veja products/clmm/fees.
• Pools CPMM apoiados por mints Token-2022 funcionam em farms apenas em Farm v6. v3 e v5 rejeitam mints de staking Token-2022.
• Pools AMM v4 nunca têm mints LP Token-2022. Se você vir um, é falso — AMM v4 não suporta essa combinação.

​

Onde ler mais

• introduction/history-and-milestones — a linha do tempo de lançamento cronológica e por que cada versão chegou quando chegou.
• user-flows/migrate-amm-v4-to-cpmm — o runbook do operador para o movimento v4 → CPMM.
• user-flows/choosing-a-pool-type — árvore de decisão para novos deployments de pool.
• products/farm-staking/accounts — schema lado a lado para v3 / v5 / v6.
• reference/changelog — o que mudou nesta documentação conforme versões de programa evoluíram.

Fontes:

• Páginas de capítulo por produto citadas inline acima.
• Raydium SDK v2 — lógica de dispatch ciente de versão confirma qual programa um dado pool pertence.
• reference/program-addresses — IDs canônicos por versão.