Changelog

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.

​

Não lançado — CLMM: limit orders, taxa unilateral, taxa dinâmica

​

Resumo para integradores

• Limit orders são agora primitivas CLMM de primeira classe. LPs podem abrir uma ordem de tick único em um pool que as suporte; a ordem é preenchida em modo FIFO quando um swap cruza o tick, e um keeper off-chain (limit_order_admin) pode liquidar o resultado preenchido sem que o proprietário esteja online. Sete novos métodos no SDK (openLimitOrder, increaseLimitOrder, decreaseLimitOrder, settleLimitOrder, closeLimitOrder, closeAllLimitOrder, settleAllLimitOrder) e três novos endpoints na API temporária sob /limit-order/ (ordens ativas, histórico por usuário, log de eventos por PDA) cobrem o fluxo completo.
• Taxa unilateral (CollectFeeOn) permite que um pool colete 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 dos lados do par é o token de contabilidade canônico.
• Taxa dinâmica permite que um pool opte por um adicional de volatilidade que sobe com o movimento rápido de ticks e decai ao longo do tempo, calibrado por um DynamicFeeConfig por tier e um DynamicFeeInfo por pool. O novo endpoint /main/clmm-dynamic-config disponibiliza a lista de tiers.
• Uma nova instrução, CreateCustomizablePool, expõe os três controles no momento da criação do pool. O CreatePool clássico continua funcionando para pools com taxa padrão e sem limit orders.
• Mudança crítica para indexadores: os contadores de volume por direção (swap_in_amount_token_{0,1}, swap_out_amount_token_{0,1}) e os contadores de taxas acumuladas (total_fees_token_{0,1}, total_fees_claimed_token_{0,1}) em PoolState foram substituídos por padding para dar espaço a fee_on e dynamic_fee_info. Indexadores que leem esses campos diretamente devem migrar para o anel de Observation on-chain ou para a API.

​

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

• Traders obtêm cotações mais precisas em pares de cauda longa e orientados a eventos: a taxa dinâmica permite que o pool absorva sobrepreços de volatilidade do taker sem que os LPs precisem ampliar ativamente os ranges, e as ladeiras de limit orders aprofundam a liquidez on-chain em preços específicos sem comprometer capital em todo o range.
• LPs ganham uma terceira estratégia ao lado de ranges concentrados e posições de range completo: posicionar ordens em preço exato, ser preenchido quando o preço chega, e liquidar para o token de cotação. Sem necessidade de rebalanceamento ativo para a parte preenchida.
• Integradores podem modelar pools de taxa dinâmica de forma determinística — o algoritmo e os parâmetros estão totalmente on-chain, os tiers de calibração são consultáveis, e o caminho do swap permanece com a mesma estrutura (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 a taxa dinâmica está habilitada.
• LimitOrderState — conta por ordem (seeds do PDA: [owner, limit_order_nonce, order_nonce]) contendo o pool, o tick, o lado, o valor de entrada, a proporção não preenchida, a fase de cohort FIFO e snapshots de controle. O ciclo de vida é implícito (filled_amount vs total_amount, mais a existência da conta): Open → Filled → Settled → Closed.
• LimitOrderNonce — contador monotonicamente crescente por (owner, nonce_index) que obtém as seeds do PDA de limit order. O nonce_index: u8 permite que o mesmo proprietário particione ordens em até 256 fluxos de nonce independentes.

​

Reestruturação do PoolState

​

Adições ao TickState (sem quebra de compatibilidade)

• order_phase: u64 — contador que diferencia cohorts de limit orders neste tick.
• orders_amount: u64 — total de entrada comprometido por todas as ordens abertas neste tick (nem todas necessariamente totalmente não preenchidas).
• part_filled_orders_remaining: u64 — entrada ainda não preenchida no cohort sendo consumido atualmente pelos swaps.
• unfilled_ratio_x64: u128 — proporção Q64.64 usada para calcular a parcela de preenchimento de cada ordem.

​

Novas instruções

• CreateDynamicFeeConfig (admin) — cria um tier DynamicFeeConfig calibrado. Autoridade: mesmo multisig de tesouraria que CreateAmmConfig.
• UpdateDynamicFeeConfig (admin) — atualiza os parâmetros de um tier existente.
• CreateCustomizablePool — ponto de entrada para criação de pools 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 — abre uma limit order de tick único. Incrementa LimitOrderNonce, aloca LimitOrderState e insere a ordem no cohort FIFO do tick.
• IncreaseLimitOrder / DecreaseLimitOrder — ajusta a porção não preenchida de uma ordem. Reverte em uma ordem totalmente preenchida com InvalidOrderPhase.
• SettleLimitOrder — transfere o resultado preenchido para a ATA do proprietário. O chamador pode ser o proprietário ou o keeper limit_order_admin do pool.
• CloseLimitOrder — fecha uma ordem totalmente liquidada para recuperar o rent.

​

Mudanças de comportamento do SwapV2

1. Taxa dinâmica (quando habilitada): o DynamicFeeInfo do pool é atualizado a cada etapa (decaimento → acumulação → limite), e o adicional resultante é somado à taxa base dessa etapa.
2. Correspondência de limit orders (quando a etapa cruza um tick inicializado que possui ordens abertas): parte da entrada do swap é consumida em modo FIFO para preencher o cohort naquele tick, com unfilled_ratio_x64 atualizado atomicamente.
3. Roteamento de taxa unilateral (quando fee_on != 0): a taxa é cobrada de token_0 ou token_1 independentemente da direção do swap, em vez de sempre do lado de entrada.

​

Novos códigos de erro

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

​

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 helpers REST em raydium.api: getClmmDynamicConfigs, getClmmLimitOrderConfigs.
• Novos tipos: enum CollectFeeOn, DynamicFeeConfig, DynamicFeeInfo, LimitOrderState, LimitOrderConfig.
• Reorganização interna: utils/ foi movido para libraries/. O barrel do pacote permanece inalterado; apenas imports diretos sob @raydium-io/raydium-sdk-v2/utils/... precisam ser atualizados para …/libraries/....

​

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 de limit order por pool.
• temp-api-v1 — três novos endpoints sob /limit-order/:
  • GET /limit-order/order/list?wallet=… — ordens atualmente abertas de uma carteira (abertas e parcialmente preenchidas, servidas 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=… — histórico de limit orders de uma carteira. Filtros opcionais: poolId, mint1, mint2, hideCancel. Paginado 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 de limit order separados por vírgula. Paginado por cursor via nextPageId / size (máx. 100).

​

Superfície de autoridade

​

Páginas atualizadas

• products/clmm/overview — nova seção “O que há de novo” e ponteiros para próximos passos atualizados.
• products/clmm/accounts — três novas contas, reestruturação do PoolState com aviso de migração, adições ao TickState, novos helpers de PDA.
• products/clmm/instructions — sete novas instruções, adendo de comportamento do SwapV2, matriz de mudanças de estado atualizada.
• products/clmm/fees — seção de taxa unilateral, seção de taxa dinâmica com tabela de parâmetros.
• products/clmm/math — pseudocódigo de correspondência de limit orders, derivação de taxa dinâmica.
• products/clmm/code-demos — demo de createCustomizablePool, guia completo de limit orders, novas armadilhas.
• algorithms/clmm-math — referência cruzada para correspondência de limit orders e taxa dinâmica no loop de swap multi-tick.
• sdk-api/typescript-sdk — seção de adições ao módulo CLMM, nota de migração utils/ → libraries/.
• api-reference/openapi/api-v3.yaml — dois novos endpoints com schemas de resposta.
• api-reference/openapi/temp-api-v1.yaml — três novos endpoints de limit order (/limit-order/order/list, /limit-order/history/order/list-by-user, /limit-order/history/event/list-by-pda) com seus schemas de requisição e resposta.
• api-reference/api-v3/overview — nota sobre os novos endpoints de configuração do CLMM.
• api-reference/temp-api-v1/overview — nota sobre os novos endpoints de ordens ativas, histórico por usuário e eventos por PDA.
• reference/error-codes — onze novos códigos de erro do CLMM (6040–6050) mais cinco códigos legados removidos; os códigos numéricos após os pontos de remoção foram deslocados.
• security/admin-and-multisig — nova linha de admin para DynamicFeeConfig e linha de keeper para limit_order_admin, com explicação de autoridade limitada.

• 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

• Implantações de programas ativos no Solana mainnet-beta.
• @raydium-io/raydium-sdk-v2@0.2.42-alpha.
• Documentação pública do Raydium e referências on-chain até abril de 2026.

​

Convenções da documentação

• Versionamento: esta documentação usa versionamento baseado em calendário (AAAA-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 confrontado pela última vez com o estado on-chain/API e o código-fonte do programa. Se não indicada, considere a data principal da entrada.
• Mudanças críticas: destacadas em um aviso em caixa nas páginas afetadas e sinalizadas na entrada abaixo.
• Cobertura: este changelog cobre o próprio conjunto de documentação. A linha do tempo histórica do protocolo está em introduction/history-and-milestones e é a fonte de verdade para “quando X aconteceu no Raydium”.

​

Correções

​

Referências rápidas

• introduction/history-and-milestones — linha do tempo do protocolo.
• security/audits — histórico de auditorias.
• ray/protocol-fees — divisão de taxas do protocolo.
• reference/program-addresses — fonte de verdade dos IDs de programa.