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
CPMM: o protocolo retém uma parte da taxa do criador
O CPMM agora pode reter parte da taxa do criador. A divisão é aplicada quando a taxa é coletada, não quando é cobrada: um swap ainda acumula a taxa completa do criador em
creator_fees_token*, e CollectCreatorFee / CollectCreatorFeePermissionless então movem uma parte para os contadores existentes protocol_fees_token* do pool e pagam o criador o restante — arredondando para baixo, então o pó fica com o criador. A taxa vem de um novo AmmConfig.creator_fee_share_rate (esculpido do padding; a conta ainda tem 236 bytes, mas o antigo padding[0] agora é um campo ativo) ou de um PDA CreatorFeeShare por criador que o substitui, gerenciado pelo novo admin CreateCreatorFeeShare / CloseCreatorFeeShare. Quebra para clientes de taxa de criador: ambas as instruções de coleta levam novas contas anexadas ao final de suas listas — as contas existentes mantêm suas posições, mas as novas são obrigatórias, então uma transação anterior à atualização é rejeitada por contas faltando. UpdateAmmConfig ganha param = 8. PoolState, matemática de swap e a verificação k não são afetadas, e nenhum código de erro foi adicionado. Acompanhando: uma correção de ordenação de duas passagens em CollectExcessLamports.Leia a entrada completa →LaunchLab: Anchor 1.0, recuperação de lamports em excesso e fim dos gates de transição
LaunchLab passa para Anchor
1.0.2 em Agave 3.1.10 e descontinua seu scaffolding de transição. O Initialize descontinuado agora falha incondicionalmente com NotApproved. MigrateToAmm é quebra total para a carteira de migração: todos os três argumentos e nove contas OpenBook desapareceram, seguindo a própria remoção do OpenBook do AMM v4, e o programa não inicializa mais o mercado por CPI. O gate de relógio get_upgrade_timestamp é deletado, então as três remaining_accounts de trade são incondicionalmente necessárias (com o slot system_program agora validado), MigrateToCpswap sempre leva o caminho CPMM com permissão, e InitializeWithToken2022 remove sua restrição amm_fee_on. Um novo admin CollectExcessLamports retorna aluguel liberado por SIMD-0437 — note que contas de origem devem ser agrupadas por qual das três PDAs de autoridade de vault as possui. Três restrições de endereço MigrateToCpswap movidas para o corpo da instrução, mudando 2012 para 2502. 6031 adicionado. Nenhum layout de conta, instrução de trade ou comportamento de taxa mudou.Leia a entrada completa →CPMM: Anchor 1.0, recuperação de lamports em excesso e proprietários de taxa corrigidos
CPMM passa para Anchor
1.0.2 em Agave 3.1.10 e adiciona um admin CollectExcessLamports que retorna aluguel liberado por SIMD-0437 de vaults, mints LP e PDAs — vaults wrapped-SOL inclusos, via uma rodada SyncNative / UnwrapLamports que deixa o saldo wrapped intacto. Três mudanças comportamentais acompanham: CreateAmmConfig agora escreve chaves protocol_fee_owner e fund_fee_owner codificadas em vez do signatário (configs existentes não são migradas — leia os campos), o hardcoded MINT_WHITELIST Token-2022 de quatro endereços é removido então o PDA do registro SupportMintAssociated é o único bypass restante, e ClosePermissionPda agora aceita a autoridade de concessão dedicada. 6015 adicionado. Nenhuma instrução ou layout de conta voltado ao usuário mudou.Leia a entrada completa →AMM v4: dependências Solana 3.0 e recuperação de lamports em excesso
AMM v4 reconstrói contra
solana-program 3.0.0, spl-token 9.0.0, spl-associated-token-account 8.0.0 e o novo crate solana-system-interface, e adiciona um WithdrawExcessLamports (tag 18) apenas para admin que retorna aluguel liberado por SIMD-0437. Cada instrução voltada para trader e LP mantém suas contas, argumentos e matemática, e nada na versão é quebra: CreateConfigAccount parou de ler seu sysvar de aluguel final mas ainda aceita a antiga lista de cinco contas. AmmError ganha código 60 (ele numera de 0, não 6000).Leia a entrada completa →LaunchLab: regras de curva de plataforma substituem a whitelist de parâmetros de curva
Restrições de parâmetro de lançamento saem de
PlatformConfig para contas PlatformCurveRule por config. Uma regra contém até 10 grupos de verificação de até 25 restrições (field, op, value) sobre 19 parâmetros de lançamento, com Eq / Gte / Lte / Neq — então uma plataforma finalmente pode expressar uma banda de valor, tiers alternativos, um limite de valuation de graduação, um piso de migração, gating de tipo de token, ou um grupo que muda em uma data, nenhum dos quais a whitelist apenas-igualdade poderia. PlatformConfig mantém seu tamanho de 944 bytes: restrict_curve_param, curve_rule_manager, e o prefixo de comprimento do vec removido saem do padding. Decodificadores devem descartar o Vec<PlatformCurveParam> final, e construtores de lançamento devem anexar o PDA da regra a remaining_accounts enquanto a flag está ativa. Duas instruções removidas, quatro adicionadas, duas variantes UpdatePlatformConfig adicionadas, 6024–6030 adicionados. Atualização de IDL necessária. O SDK envia duas verificações puras off-chain para que um criador nunca tenha que aprender uma regra de uma transação revertida, e a entrada documenta um ensaio devnet antes de ativar a flag em mainnet.Leia a entrada completa →LaunchLab: plataforma mantém a autoridade de retirada de retido desde a criação do 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, então uma plataforma pode varrer 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 tem instrução de retirada de 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 girar 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 foi limitado a 10000 (100 bps) desde o primeiro lançamento do programa; UpdatePlatformConfig foi limitado a 25000 (250 bps) desde 2026-01-27. Os dois verificações 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 re-valida fee_rate enquanto reescreve cada outro campo. 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 reprecia. GlobalConfig.max_share_fee_rate permanece em 100 bps e limita apenas o 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 config de plataforma
A inicialização de novo lançamento agora requer CPMM enquanto o estado legado vinculado ao AMM v4 permanece migrável. Antes desta versão,
creator_scale produzia uma Fee Key de propriedade do criador; migrações CPMM executadas após a atualização consolidam platform_scale + creator_scale em uma compartilha de Fee Key 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 suporte-mint 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 vault 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 varra todas as taxas de criador acumuladas, enquanto restringe o beneficiário e ambos os destinos de token a PoolState.pool_creator e as ATAs canônicas do criador. O caminho original assinado pelo criador permanece inalterado. CreatePermissionPda também aceita uma autoridade de concessão dedicada, enquanto ClosePermissionPda permanece apenas admin.Leia a entrada completa →CLMM: multi-pools com permissão e guarda de conta congelada de ordem limitada
Duas atualizações de programa CLMM aditivas e compatíveis com versões anteriores.
CreatePermissionedPool dobra um seed_index não-zero fornecido pelo cliente nas sementes do PDA do pool, permitindo que um operador na whitelist (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 admin CreatePermissionPda / ClosePermissionPda gerenciam essas concessões, e PoolState ganha um campo seed_index (esculpido do padding, sem mudança de tamanho). Separadamente, OpenLimitOrder agora leva 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 OpenBook/Serum há muito dorminhoca, todos os CPIs de livro de ordens e as instruções mortas de market-making.
SwapBaseIn / SwapBaseOut, Deposit e Withdraw mantêm seus layouts (contas de mercado removidas agora são ignoradas, não validadas); um WithdrawPnl quebra total (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 entrypoints V2.Leia a entrada completa →Stable AMM: remover código OpenBook morto (mercado)
Stable AMM remove suas contas e código de market-making OpenBook há muito dorminhocas. Layouts menores
SwapBaseIn / SwapBaseOut (18 → 9), Deposit (14 → 12) e Withdraw (21/22 → 12) (layouts antigos ainda compatíveis); uma mudança WithdrawPnl quebra total (16 → 10, sem compatibilidade); a taxa de referência aposentada; e uma fórmula de ativo de pool simplificada apenas para vault. 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 keeper 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 quebra indexador), novos campos TickState, onze novos códigos de erro (com uma mudança numérica) 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 contra 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 sob
reference/changelog/, então este índice permanece curto e cada entrada é independentemente vinculável. - Data verificada: 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 quebra: chamadas 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 taxa de protocolo.reference/program-addresses— fonte de verdade de IDs de programa.