> ## 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.
# Versões e migração
> Histórico de versões para cada programa Raydium, status de deprecação de cada geração e caminhos práticos de migração entre elas.
**Esta página foi traduzida automaticamente por IA. A versão em inglês é a fonte oficial.**
[Ver versão em inglês →](/protocol-overview/versions-and-migration)
Raydium existe há cinco anos. Vários de seus programas estão em sua terceira ou quarta geração. Esta página oferece uma visão do operador: "qual versão do programa devo usar, qual é o status das versões antigas e como migro de A para B se estou rodando a versão antiga hoje?"
## Status em resumo
| Programa | Atual | Deprecado | Novos deployments | Instâncias existentes |
| ------------- | ---------------- | --------- | ---------------------------------- | -------------------------------------------------------- |
| **AMM v4** | v4 (uma geração) | Não | Desaconselhado mas aceito | Totalmente operacional |
| **CPMM** | v1 | — | **Padrão recomendado** | Totalmente operacional |
| **CLMM** | v1 | — | Recomendado para LPs de alcance | Totalmente operacional |
| **Farm** | v6 | v3, v5 | Apenas v6 | v3 + v5 em encerramento (principalmente somente leitura) |
| **LaunchLab** | v1 | — | Recomendado para novos lançamentos | Totalmente operacional |
O aprendizado mais importante dessa tabela: **AMM v4 não está deprecado**, 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 forçadamente migrados. 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: preço de produto constante (`x · y = k`). Foi lançado como um AMM híbrido com integração de orderbook OpenBook (antigo Serum) que espelhava partes da curva como ordens limitadas em um mercado acoplado. **A integração OpenBook foi desde então desativada** — pools não compartilham mais liquidez com OpenBook e todos os swaps são executados puramente contra a curva via endpoints 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 mais novos tiers de taxa.** A estrutura de taxa AMM v4 é por pool e foi definida no deploy. Novos pools aceitam a mesma taxa comercial fixa \~0.25%, \~12% para protocolo.
* **Sem novo trabalho de funcionalidades.** A equipe não adicionou novas instruções a AMM v4 desde que CPMM se tornou o novo padrão. O programa está em modo de manutençã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 têm que usar CPMM (ou CLMM, quando apropriado).
* **Integração OpenBook desativada.** Cada pool AMM v4 ainda está ligado a uma conta de mercado OpenBook correspondente na chain, mas o pool não publica mais ou mantém ordens naquele mercado. Uma interrupção de 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.** Migração para CPMM é opcional.
* **Agregadores ainda roteiam através disso.** Jupiter e a Raydium Trade API indexam pools v4 como venues de primeira classe.
### Quando ainda usar AMM v4
Honestamente: raramente. Os casos onde 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 com 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`](/pt/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 com intenção de 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, menor footprint de transação.
### O que CPMM oferece sobre AMM v4
* **Melhor economia de LP por padrão.** O AmmConfig padrão de CPMM roteia 100% das taxas comerciais para LPs (com taxa de protocolo ativável por tier). AMM v4 hardcoda \~12% para protocolo.
* **Custo mais baixo de criação de pool.** 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 — tudo suportado em CPMM, nada em v4.
* **Superfície de integrador mais limpa.** CPMM tem uma crate publicada amigável a Anchor-CPI (`raydium-cp-swap`), uma lista de contas mais simples e um IDL estável. AMM v4 envia um IDL mas nunca teve uma crate Rust CPI mantida.
* **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 sozinho geralmente justifica migração em alguns meses. A aritmética: um pool ganhando 0.25% × \$X de volume diário fornece 0.03% para protocolo em v4 (os 12% ausentes). Em CPMM isso retorna para LPs. Ao longo de um ano, isso se compõe significativamente.
Para um pool de baixo volume, migração é mais sobre futuro-proofing — melhores padrões, suporte Token-2022 se precisar, integrações mais fáceis.
### Como a migração funciona
Não há upgrade in-place. Migração é uma sequência *criar novo pool, drenar pool antigo, reabastecer novo pool*. O passo a passo completo está em [`user-flows/migrate-amm-v4-to-cpmm`](/pt/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 deseja 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 uma farm CPMM para atrair LPs incentivados para o novo pool.
5. Observe o volume migrar conforme agregadores repesam para o pool mais profundo.
A chain em si não impõe nada disso — a API e frontend Raydium simplesmente favorecem o pool mais profundo, e agregadores roteiam através do 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 ficam 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 antigo `Swap` ainda é chamável; novas integrações devem usar `SwapV2`.
* **Extensões de stream de recompensa** — a contagem de slot `RewardInfo` foi aumentada (a original 3 → ainda 3 atualmente, mas o padrão de reserva foi ajustado). 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.
O IDL reside no repositório dedicado [`raydium-idl`](https://github.com/raydium-io/raydium-idl/blob/master/raydium_clmm/raydium_clmm.json) (veja [`sdk-api/anchor-idl`](/pt/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
| Versão | Lançada | Status | Funcionalidades principais |
| ------ | -------- | ------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
| **v3** | 2021 | **Encerramento.** Farms existentes rodam; nenhuma nova farm aceita. | Stream de recompensa única. Emissão baseada em slot. |
| **v5** | Out 2022 | **Encerramento.** Farms existentes rodam; nenhuma nova farm aceita. | Até 2 streams de recompensa. Emissão baseada em slot. Integer `per_second`. |
| **v6** | 2024 | **Atual.** Todas as novas farms. | Até 5 streams de recompensa. Emissão de relógio de parede. Q64.64 taxa fixa `per_second`. Suporte Token-2022 para staking + recompensas. |
### Por que três gerações existem
* **v3 → v5**: necessárias múltiplas streams de recompensa simultâneas (p.ex., farms com duplo incentivo). O design de stream único v3 não podia suportar sem redesenho.
* **v5 → v6**: a taxa de emissão inteira `u64` 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 v6 corrige isso. v6 também elevou 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, reclamar ao sacar" é 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 streams 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 término das emissões da farm existente (ou as execute até o fim).
2. Stakers sacam e reclamam 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 podem ser chamados. 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 "ativo" mas a mantém reclamável.
* A equipe não criará novas farms v3/v5. Helpers de SDK para "criar farm" roteiam apenas para v6.
* v3 e v5 estão *recebendo upgrades de segurança mas não trabalho de funcionalidades*. Se um bug crítico for encontrado, é corrigido; se uma funcionalidade puder ser útil, é adicionada a v6 em vez disso.
Detalhes completos por versão estão em [`products/farm-staking/accounts`](/pt/products/farm-staking/accounts) e [`products/farm-staking/instructions`](/pt/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 comerciais CPMM pós-graduação para o criador original. Veja [`products/launchlab/creator-fees`](/pt/products/launchlab/creator-fees).
* **Configurabilidade de fórmula de curva.** Originalmente hardcoded 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é graduação.
## Compatibilidade de versão entre programas
Algumas notas de compatibilidade entre produtos que os integradores rotineiramente encontram:
* **CLMM `SwapV2` não é a mesma instrução que `Swap`.** Se seu cliente fala apenas `Swap`, ele manipulará silenciosamente mal as taxas de transferência Token-2022 — a matemática está errada pelo valor da taxa. Atualize para `SwapV2`.
* **Staking Farm v6 com posições CLMM** não é suportado da mesma 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`](/pt/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 de LP Token-2022.** Se você vir um, é falso — AMM v4 não suporta essa combinação.
## Onde ler mais
* [`introduction/history-and-milestones`](/pt/introduction/history-and-milestones) — a timeline de lançamento cronológica e por que cada versão foi lançada quando foi.
* [`user-flows/migrate-amm-v4-to-cpmm`](/pt/user-flows/migrate-amm-v4-to-cpmm) — o runbook do operador para o movimento v4 → CPMM.
* [`user-flows/choosing-a-pool-type`](/pt/user-flows/choosing-a-pool-type) — árvore de decisão para novos deployments de pool.
* [`products/farm-staking/accounts`](/pt/products/farm-staking/accounts) — schema lado a lado para v3 / v5 / v6.
* [`reference/changelog`](/pt/reference/changelog) — o que mudou nesta documentação conforme as versões de programa evoluíram.
Fontes:
* Páginas de capítulo por produto citadas inline acima.
* [Raydium SDK v2](https://github.com/raydium-io/raydium-sdk-V2) — lógica de dispatch com conhecimento de versão confirma qual programa um dado pool pertence.
* [`reference/program-addresses`](/pt/reference/program-addresses) — IDs canônicos por versão.