Esta página foi traduzida automaticamente por IA. A versão em inglês é a fonte oficial.Ver versão em inglês →
introduction/history-and-milestones.
Versões
LaunchLab: regras de curva de plataforma substituem a lista branca de parâmetros de curva
As restrições de parâmetros de lançamento saem de
PlatformConfig para contas PlatformCurveRule por configuração. Uma regra contém até 10 grupos de verificação com até 25 restrições (field, op, value) sobre 19 parâmetros de lançamento, com Eq / Gte / Lte / Neq — permitindo que uma plataforma expresse uma faixa de valores, camadas alternativas, um limite de avaliação de graduação, um piso de migração, restrição por tipo de token, ou um grupo que muda em uma data, nenhum dos quais a lista branca somente-igualdade poderia. PlatformConfig mantém seu tamanho de 944 bytes: restrict_curve_param, curve_rule_manager e o prefixo de comprimento do vetor removido saem do preenchimento. Decodificadores devem descartar o Vec<PlatformCurveParam> final, e construtores de lançamento devem anexar o PDA da regra a remaining_accounts enquanto a flag estiver ativa. Duas instruções removidas, quatro adicionadas, duas variantes UpdatePlatformConfig adicionadas, 6024–6030 anexadas. Atualização de IDL necessária. O SDK fornece duas verificações puras off-chain para que um criador nunca precise aprender uma regra de uma transação revertida, e a entrada documenta um ensaio em devnet antes de ativar a flag em mainnet.Leia a entrada completa →LaunchLab: plataforma mantém a autoridade de saque retido da criação de mint
InitializeWithToken2022 agora escreve PlatformConfig.transfer_fee_extension_auth na withdraw_withheld_authority do novo mint base em vez do PDA de authority de lançamento, permitindo que uma plataforma limpe taxas de transferência retidas durante a fase de curva de ligação em vez de esperar pela graduação — o programa em si não possui instrução de saque retido. MigrateToCpswap reatribui essa autoridade apenas quando o PDA ainda a mantém, o que mantém a graduação funcionando para mints de ambas as gerações. transfer_fee_config_authority ainda se move apenas na graduação, então rotacionar transfer_fee_extension_auth no meio do lançamento silenciosamente deixa as duas autoridades em chaves diferentes. Nenhum layout de conta, instrução, argumento ou código de erro mudou.Leia a entrada completa →LaunchLab: limite de taxa de taxa de plataforma aumentado para 500 bps
O teto de
fee_rate da plataforma passa para 50000 (500 bps) em ambos os caminhos que o validam. CreatePlatformConfig estava limitado a 10000 (100 bps) desde o primeiro lançamento do programa; UpdatePlatformConfig estava limitado a 25000 (250 bps) desde 2026-01-27. Os dois verificadores agora concordam, então uma plataforma criada em qualquer taxa permitida também pode ser atualizada nela — incluindo através da variante em massa AllInfo, que revalida fee_rate enquanto reescreve todos os outros campos. Os dois caminhos ainda levantam erros diferentes (InvalidInput na criação, InvalidPlatformInfo na atualização). Nenhum layout de conta, instrução ou código de erro mudou, e nenhuma plataforma ou lançamento existente muda de preço. GlobalConfig.max_share_fee_rate permanece em 100 bps e limita apenas a share_fee_rate de referência por transação.Leia a entrada completa →LaunchLab: mints de cotação Token-2022
Um lançamento agora pode ser cotado em um mint Token-2022.
CreateConfig, InitializeV2, InitializeWithToken2022, as quatro instruções de swap e cada reivindicação de taxa aceitam qualquer programa de token em seu slot de programa de cotação; o Initialize descontinuado permanece apenas legado. Os limites de slippage de swap agora são comparados contra o que o pagador realmente paga ou recebe, líquido da taxa de transferência do mint de cotação. O bit1 de PoolState.token_program_flag torna-se significativo, então decodificadores que testam o byte inteiro contra 0 leem mal um mint base legado como Token-2022. MigrateToCpswap renomeia suas duas contas de programa de token para token_program / token_program_2022, e 6023 é reutilizado para CalculateOverflow.Leia a entrada completa →LaunchLab: lançamentos apenas CPMM e controles de configuração de plataforma
A inicialização de novo lançamento agora requer CPMM enquanto o estado legado vinculado a AMM v4 permanece migrável. Antes desta versão,
creator_scale produzia uma Chave de Taxa de propriedade do criador; migrações CPMM executadas após a atualização consolidam platform_scale + creator_scale em um compartilhamento de Chave de Taxa de propriedade da plataforma. Plataformas também podem restringir lançamentos com seus próprios PDAs PlatformAllowConfig, e construtores de migração devem anexar ambos os PDAs de mint de suporte CPMM.Leia a entrada completa →CLMM: congelamento de NFT de posição de emissor restrito
Novos mints de NFT de posição CLMM usam seu pool como autoridade de congelamento, mas suas contas de token permanecem descongeladas por padrão. O congelamento ocorre apenas em
OpenPositionV2 ou OpenPositionWithToken22Nft quando a autoridade de congelamento de qualquer um dos mints de cofre subjacentes corresponde à lista de emissor restrito. Uma posição correspondente não pode transferir ou mudar de proprietário, mas ainda pode gerenciar liquidez. Sua chamada ClosePosition deve anexar o pool para que CLMM possa descongelar, queimar e fechar atomicamente. Posições existentes permanecem inalteradas.Leia a entrada completa →CPMM: coleta de taxa de criador sem permissão
Uma instrução aditiva
CollectCreatorFeePermissionless permite que qualquer pagador limpe todas as taxas de criador acumuladas, enquanto restringe o beneficiário e ambos os destinos de token a PoolState.pool_creator e aos ATAs canônicos do criador. O caminho original assinado pelo criador permanece inalterado. CreatePermissionPda também aceita uma autoridade de concessão dedicada, enquanto ClosePermissionPda permanece apenas para administrador.Leia a entrada completa →CLMM: multi-pools com permissão e proteção de conta congelada de ordem limitada
Duas atualizações de programa CLMM aditivas e compatíveis com versões anteriores.
CreatePermissionedPool incorpora um seed_index não-zero fornecido pelo cliente nas sementes do PDA do pool, permitindo que um operador na lista branca (um que mantém um PDA Permission) crie múltiplos pools por (config, mint0, mint1) — então um ID de pool não é mais canônico para um par. Novas instruções de administrador CreatePermissionPda / ClosePermissionPda gerenciam essas concessões, e PoolState ganha um campo seed_index (esculpido do preenchimento, sem mudança de tamanho). Separadamente, OpenLimitOrder agora recebe as contas do lado de saída e rejeita ordens cuja conta de token de entrada ou saída está congelada (NotApproved).Leia a entrada completa →AMM v4: remover dependência OpenBook / Serum
AMM v4 remove sua dependência de longa data do OpenBook/Serum, todos os CPIs de livro de ordens e as instruções de criação de mercado mortas.
SwapBaseIn / SwapBaseOut, Deposit e Withdraw mantêm seus layouts (contas de mercado removidas agora são ignoradas, não validadas); um WithdrawPnl com quebra difícil (17 → 10, sem compatibilidade) e SetParams (contas reduzidas + param renumerado); e Initialize, PreInitialize, MonitorStep, MigrateToOpenBook, WithdrawSrm, SimulateInfo, AdminCancelOrders não são mais chamáveis. Layouts de conta on-chain e códigos de erro permanecem estáveis; migre swaps para os pontos de entrada V2.Leia a entrada completa →Stable AMM: remover código OpenBook (mercado) morto
Stable AMM remove suas contas e código de criação de mercado OpenBook de longa data. Layouts menores
SwapBaseIn / SwapBaseOut (18 → 9), Deposit (14 → 12) e Withdraw (21/22 → 12) (layouts antigos ainda compatíveis); uma mudança WithdrawPnl com quebra difícil (16 → 10, sem compatibilidade); a taxa de referência aposentada; e uma fórmula de ativo de pool simplificada apenas para cofre. A maioria das outras instruções Stable não são mais chamáveis.Leia a entrada completa →CLMM: ordens limitadas, taxa unilateral, taxa dinâmica
Três capacidades CLMM opcionais e compatíveis com versões anteriores: ordens limitadas de primeira classe (com um guardião de liquidação
limit_order_admin), coleta de taxa unilateral (CollectFeeOn) e uma taxa dinâmica de rastreamento de volatilidade. Adiciona CreateCustomizablePool, uma reformulação de PoolState (mudança que quebra indexador), novos campos TickState, onze novos códigos de erro (com deslocamento numérico) e adições correspondentes de SDK / API.Leia a entrada completa →Publicação inicial
Primeiro lançamento público do conjunto de documentação Raydium, verificado em relação a implantações mainnet-beta ativas e
@raydium-io/raydium-sdk-v2@0.2.42-alpha.Leia a entrada completa →Convenções de documentação
- Versionamento: esta documentação usa versionamento baseado em calendário (YYYY-MM-DD). Cada atualização adiciona uma nova página de entrada e uma nova linha no topo da linha do tempo acima.
- Uma página por versão: cada resumo de versão vive em sua própria página em
reference/changelog/, então este índice permanece curto e cada entrada é independentemente vinculável. - Data de verificação: cada entrada registra quando o conteúdo foi verificado pela última vez em relação ao estado on-chain / API e ao código-fonte do programa. Se não declarado, assuma a data principal da entrada.
- Mudanças que quebram: destacadas em um aviso em caixa em páginas afetadas e marcadas na entrada.
- Cobertura: este changelog cobre o próprio conjunto de documentação. A linha do tempo histórica do protocolo vive em
introduction/history-and-milestonese é a fonte de verdade para “quando X aconteceu em Raydium”.
Correções
Se você encontrar um erro nesta documentação, abra uma issue ou pull request no repositório de documentação. Correções são registradas como entradas de changelog.Referências
introduction/history-and-milestones— a linha do tempo do próprio protocolo.security/audits— histórico de auditorias.ray/protocol-fees— divisões de taxas de protocolo.reference/program-addresses— fonte de verdade de IDs de programa.