Changelog

Registro datado de atualizações neste conjunto de documentação. As entradas registram quais capítulos foram alterados, por que, e quando o conteúdo foi verificado em relação ao estado da chain e ao código-fonte do programa.

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

Ver versão em inglês →

Este é o changelog da documentação — o registro de atualizações nessas páginas desde o lançamento do projeto. Para o cronograma histórico do próprio protocolo, veja introduction/history-and-milestones. Cada entrada aqui contém uma data, uma lista de capítulos afetados, o motivo da alteração e uma data de verificação que indica quando o estado da chain e o código-fonte do programa foram verificados pela última vez em relação ao conteúdo escrito.

​

2026-05-18 — CLMM: limit orders, single-sided fee, dynamic fee

O próximo lançamento do CLMM adiciona três funcionalidades no nível do pool. Elas são opcionais no momento da criação do pool e compatíveis com versões anteriores com pools e posições existentes.

​

TL;DR para integradores

• Limit orders agora são primitivos CLMM de primeira classe. LPs podem abrir uma ordem de tick único em um pool que as suporte; a ordem é preenchida FIFO quando um swap cruza o tick, e um keeper off-chain (limit_order_admin) pode liquidar o resultado preenchido sem o proprietário estar online. Sete novos métodos de SDK (openLimitOrder, increaseLimitOrder, decreaseLimitOrder, settleLimitOrder, closeLimitOrder, closeAllLimitOrder, settleAllLimitOrder) e três novos endpoints da Temp API sob /limit-order/ (ordens ativas, histórico por usuário, log de eventos por PDA) cobrem o fluxo completo.
• Single-sided fee (CollectFeeOn) permite que um pool colha taxas de swap do lado de entrada (legado, modo 0), sempre de token_0 (modo 1), ou sempre de token_1 (modo 2). Útil quando um lado do par é o token contábil canônico.
• Dynamic fee permite que um pool opte por uma sobretaxa de rastreamento de volatilidade que aumenta com o movimento rápido de tick e decai ao longo do tempo, calibrada por um DynamicFeeConfig por tier e um DynamicFeeInfo por pool. O novo endpoint /main/clmm-dynamic-config apresenta a lista de tiers.
• Uma nova instrução, CreateCustomizablePool, expõe todos os três controles no momento da criação do pool. O clássico CreatePool continua funcionando para pools sem limite de ordem e com taxa padrão.
• Breaking change no indexador: os contadores de volume por direção (swap_in_amount_token_{0,1}, swap_out_amount_token_{0,1}) e os contadores de taxa vitalícia (total_fees_token_{0,1}, total_fees_claimed_token_{0,1}) em PoolState foram retirados para o preenchimento a fim de abrir espaço para fee_on e dynamic_fee_info. Indexadores que leem esses campos diretamente devem migrar para o ring Observation on-chain ou para a API.

​

Por que isso importa (para traders, LPs e integradores)

• Traders obtêm cotações mais apertadas em pares de cauda longa e orientados por eventos: dynamic fee permite que o pool absorva sobrecargas de volatilidade do taker sem que LPs tenham que ampliar ativamente intervalos, e escadas de limite de ordem aprofundam a liquidez on-chain a preços específicos sem comprometer capital em toda a amplitude.
• LPs obtêm uma terceira estratégia além de intervalos concentrados e posições de amplitude total: estacionem ordens a preço exato, sejam preenchidas quando o preço visita, liquidem no token de cotação. Nenhum rebalanceamento ativo necessário para a porção preenchida.
• Integradores podem modelar pools de dynamic fee determinísticamente — o algoritmo e os parâmetros estão totalmente on-chain, os tiers de calibração são consultáveis e o caminho de swap é inalterado em forma (apenas a taxa por etapa varia).

​

O que mudou no programa

​

Novas contas

• DynamicFeeConfig — registro de calibração por tier (período de filtro, período de decaimento, fator de redução, controle de taxa dinâmica, acumulador máximo de volatilidade). Criado por CreateDynamicFeeConfig (admin), referenciado por CreateCustomizablePool quando dynamic fee está habilitado.
• LimitOrderState — conta por ordem (seeds de PDA: [owner, limit_order_nonce, order_nonce]) contendo o pool, tick, lado, quantidade de entrada, razão de não preenchimento, fase de coorte FIFO e snapshots de escrituração. O ciclo de vida é implícito (filled_amount vs total_amount, mais existência de conta): Open → Filled → Settled → Closed.
• LimitOrderNonce — contador monotonicamente crescente por-(owner, nonce_index) que obtém as seeds de PDA limit-order. O nonce_index: u8 permite que o mesmo proprietário particione ordens em até 256 fluxos de nonce independentes.

Veja Accounts → DynamicFeeConfig and DynamicFeeInfo e Accounts → LimitOrderState.

​

Reformulação de PoolState

Grupo de campo	Layout antigo	Novo layout
Contadores de volume por direção	swap_in_amount_token_0, swap_out_amount_token_0, swap_in_amount_token_1, swap_out_amount_token_1	Incorporados em padding5: [u128; 4]
Contadores de taxa vitalícia	total_fees_token_0, total_fees_claimed_token_0, total_fees_token_1, total_fees_claimed_token_1	Incorporados em padding6: [u64; 4]
Single-sided fee	—	fee_on: u8 (0 = FromInput, 1 = Token0Only, 2 = Token1Only)
Dynamic fee	—	dynamic_fee_info: DynamicFeeInfo (incorporado)

O tamanho total da conta é inalterado. Indexadores: mude o rastreamento de volume de PoolState para o ring Observation ou para a API. Os contadores retirados não são zerados em pools existentes (eles contêm o que quer que tenham carregado por último), portanto, relê-los após a atualização retornará dados obsoletos.

​

Adições a TickState (nenhuma breaking change)

Quatro novos campos são adicionados no final de TickState, substituindo um pouco de seu preenchimento final:

• order_phase: u64 — contador que desambigua coortes limit-order neste tick.
• orders_amount: u64 — total de entrada comprometido por todas as ordens abertas neste tick (nem todas estão completamente não preenchidas).
• part_filled_orders_remaining: u64 — entrada ainda não preenchida na coorte sendo consumida atualmente por swaps.
• unfilled_ratio_x64: u128 — razão Q64.64 usada para calcular a parcela de preenchimento de cada ordem.

Layout de tick-array, dimensionamento e seeds de PDA são inalterados.

​

Novas instruções

• CreateDynamicFeeConfig (admin) — criar um tier DynamicFeeConfig calibrado. Autoridade: mesma multisig de tesouro que CreateAmmConfig.
• UpdateDynamicFeeConfig (admin) — atualizar os parâmetros de um tier existente.
• CreateCustomizablePool — ponto de entrada de criação de pool que expõe collect_fee_on, enable_dynamic_fee e dynamic_fee_config. Coexiste com CreatePool; recomendamos CreateCustomizablePool para qualquer novo pool que precise dos novos controles.
• OpenLimitOrder — abrir uma ordem limit de tick único. Incrementa LimitOrderNonce, aloca LimitOrderState, encaixa a ordem na coorte FIFO do tick.
• IncreaseLimitOrder / DecreaseLimitOrder — ajustar a porção não preenchida de uma ordem. Reverte em uma ordem completamente preenchida com InvalidOrderPhase.
• SettleLimitOrder — varrer saída preenchida para o ATA do proprietário. O chamador pode ser o proprietário ou o keeper limit_order_admin do pool.
• CloseLimitOrder — fechar uma ordem completamente liquidada para recuperar aluguel.

​

Mudanças de comportamento de SwapV2

O caminho de swap em si é inalterado em forma, mas três coisas agora acontecem ao longo do caminho:

1. Dynamic fee (quando habilitado): o DynamicFeeInfo do pool é atualizado a cada etapa (decay → accumulate → cap), e a sobretaxa resultante é adicionada no topo da taxa base para essa etapa.
2. Limit-order matching (quando a etapa cruza um tick inicializado que tem ordens abertas): parte da entrada de swap é consumida FIFO para preencher a coorte do tick, com unfilled_ratio_x64 atualizado atomicamente.
3. Single-sided fee routing (quando fee_on != 0): a taxa é retirada de token_0 ou token_1 independentemente da direção do swap, em vez de sempre do lado de entrada.

Cada um desses é um no-op quando o pool foi criado com os padrões herdados. Veja Instructions → SwapV2 para a matriz de mudança de estado atualizada.

​

Novos códigos de erro

A enumeração ErrorCode foi renumerada neste lançamento: cinco variantes legadas (LOK, ZeroMintAmount, InvalidLiquidity, TransactionTooOld, InvalidRewardDesiredAmount) foram removidas e onze novas variantes foram anexadas. Como o Anchor numera erros por ordem de enum a partir de 6000, todo código de erro nas posições removidas ou depois delas foi alterado — clientes que codificaram numericamente códigos precisam remapear.

Os novos códigos são:

• 6040 OrderAlreadyFilled
• 6041 InvalidOrderPhase
• 6042 InvalidLimitOrderAmount
• 6043 OrderPhaseSaturated
• 6044 InvalidDynamicFeeConfigParams
• 6045 InvalidFeeOn
• 6046 ZeroSqrtPrice
• 6047 ZeroLiquidity
• 6048 MissingBaseFlag
• 6049 MissingMintAccount
• 6050 MissingTokenProgram2022

Strings completas e a tabela pós-alteração para todos os erros CLMM estão em Error codes.

​

O que mudou no SDK (@raydium-io/raydium-sdk-v2)

• Novos métodos em raydium.clmm: createCustomizablePool, openLimitOrder, increaseLimitOrder, decreaseLimitOrder, settleLimitOrder, settleAllLimitOrder, closeLimitOrder, closeAllLimitOrder.
• Novos auxiliares REST em raydium.api: getClmmDynamicConfigs, getClmmLimitOrderConfigs.
• Novos tipos: enumeração CollectFeeOn, DynamicFeeConfig, DynamicFeeInfo, LimitOrderState, LimitOrderConfig.
• Reorganização interna: utils/ movido para libraries/. O barrel do pacote é inalterado; apenas importações profundas sob @raydium-io/raydium-sdk-v2/utils/... precisam ser atualizadas para …/libraries/....

Passo a passo de TypeScript de ponta a ponta vivem em products/clmm/code-demos.

​

O que mudou nas APIs

• api-v3 — dois novos endpoints sob /main/:
  • GET /main/clmm-dynamic-config — lista de tiers DynamicFeeConfig.
  • GET /main/clmm-limit-order-config — configuração limit-order por pool.
• temp-api-v1 — três novos endpoints sob /limit-order/:
  • GET /limit-order/order/list?wallet=… — ordens atualmente estacionadas de uma carteira (abertas e parcialmente preenchidas, servidas a partir do cache Redis do indexador; o mesmo payload cobre ambas as fases via totalAmount / filledAmount / pendingSettle).
  • GET /limit-order/history/order/list-by-user?wallet=… — ordens limit históricas de uma carteira. Filtros opcionais: poolId, mint1, mint2, hideCancel. Paginação por cursor via nextPageId / size (máx 100).
  • GET /limit-order/history/event/list-by-pda?pda=… — log de eventos por PDA (open / increase / decrease / settle / close) para um ou mais PDAs limit-order separados por vírgula. Paginação por cursor via nextPageId / size (máx 100).

Todos os cinco estão documentados na guia API Reference.

​

Superfície de autoridade

O limit_order_admin é um keeper operacional off-chain, não uma multisig. Ele pode apenas chamar SettleLimitOrder e CloseLimitOrder em ordens existentes, e o resultado de um settlement sempre chega ao ATA do proprietário. Ele não pode mutar campos de pool, abrir ou modificar ordens, ou assinar qualquer outra coisa. Veja Admin keys and multisig → CLMM.

​

Páginas atualizadas

• products/clmm/overview — nova seção “What’s new” e ponteiros de próximas etapas atualizados.
• products/clmm/accounts — três novas contas, reformulação de PoolState com aviso de migração, adições de TickState, novos auxiliares de PDA.
• products/clmm/instructions — sete novas instruções, adendum de comportamento de SwapV2, matriz de mudança de estado atualizada.
• products/clmm/fees — seção single-sided fee, seção dynamic-fee com tabela de parâmetros.
• products/clmm/math — pseudo-código limit-order matching, derivação dynamic-fee.
• products/clmm/code-demos — demonstração de createCustomizablePool, passo a passo completo limit-order, novas armadilhas.
• algorithms/clmm-math — referência cruzada para limit-order matching e dynamic fee no loop de swap multi-tick.
• sdk-api/typescript-sdk — seção de adições de módulo CLMM, nota de migração utils/ → libraries/.
• api-reference/openapi/api-v3.yaml — dois novos endpoints com esquemas de resposta.
• api-reference/openapi/temp-api-v1.yaml — três novos endpoints limit-order (/limit-order/order/list, /limit-order/history/order/list-by-user, /limit-order/history/event/list-by-pda) com seus esquemas de solicitação e resposta.
• api-reference/api-v3/overview — nota sobre os novos endpoints CLMM config.
• api-reference/temp-api-v1/overview — nota sobre os novos endpoints de ordens ativas, histórico por usuário e evento por PDA.
• reference/error-codes — onze novos códigos de erro CLMM (6040–6050) mais cinco códigos legados removidos; códigos numéricos após os pontos de remoção foram alterados.
• security/admin-and-multisig — nova linha admin DynamicFeeConfig e linha keeper limit_order_admin, com explicador de autoridade limitada.

Verificado contra:

• Código-fonte de raydium-clmm.
• Código-fonte de @raydium-io/raydium-sdk-v2.
• Código-fonte de api-v3 e temp-api-v1.

​

2026-04-26 — Publicação inicial

Primeiro lançamento público do conjunto de documentação do Raydium.

Verificado contra:

• Implantações de programas ao vivo na Solana mainnet-beta.
• @raydium-io/raydium-sdk-v2@0.2.42-alpha.
• Referências de docs e on-chain públicas do Raydium até abril de 2026.

Daqui em diante, cada upgrade de protocolo, auditoria ou revisão de doc aterrissa como uma nova entrada neste arquivo.

​

Convenções de documentação

• Versionamento: esta documentação usa versionamento baseado em calendário (YYYY-MM-DD). Cada atualização cria uma nova entrada no topo do arquivo.
• Data de verificação: cada entrada registra quando o conteúdo foi verificado pela última vez contra o estado on-chain / API e o código-fonte do programa. Se não estiver indicado, assuma a data principal da entrada.
• Breaking changes: destacadas em um aviso em caixa nas páginas afetadas e marcadas na entrada abaixo.
• Cobertura: este changelog cobre o próprio conjunto de documentação. O cronograma histórico do protocolo fica em introduction/history-and-milestones e é a fonte de verdade para “quando X aconteceu no Raydium”.

​

Correções

Se você encontrar um erro nesta documentação, abra um issue ou pull request no repositório de documentação. As correções são registradas neste changelog.

​

Ponteiros

• introduction/history-and-milestones — o cronograma do protocolo.
• security/audits — histórico de auditorias.
• ray/protocol-fees — divisões de taxa de protocolo.
• reference/program-addresses — fonte de verdade do ID do programa.